Final Program Schedule is live!   |   Attend our Second Annual Agile Job Fair
Conference Time
Local Time

Scaling Agile Adoption Day 1

Wed, Mar 25
Timezone: Asia/Kolkata (IST)

    Registration - 30 mins


    Opening Talk - 15 mins


    Coffee/Tea Break - 15 mins


    Lunch - 60 mins

  • Added to My Schedule
    Tathagat Varma

    Tathagat Varma - From Waterfall to Weekly Releases: A Case Study in using Evo and Kanban

    schedule  01:30 - 02:15 PM IST place Grand Ballroom 1 star_halfRate

    In 2003, we had a major problem to solve - our products had far too many open field defects, and the bug arrival rate was moe than the closure rate. We tried to fix using our process which involved shipping quarterly service packs, but that was not only elongating the lead time, it was also not very amenable to changes. The process for customer specials (specific features, etc.) was not any better, and invariably it led to exec-level escalations just to get some deal-blocking customer escalations into the service packs mid-way in the quarter.

    In 2004-05, we experimented with a pull system that limited the work in progress and created a more smoother flow of value. The result of this system was that we were able to significantly reduce the defect backlog, and were able to bring down cadence of features and bugs to a weekly cadence. The experiment was so successful that in about 6 quarters, we had fixed most of the field defects (brought down individual product's defect backlog to single digit) and we had to disband the team as there was no work left for them!

    We were inspired by Tom Gilb's "Evo" method and experimented with it to create a weekly cadence. However, we found that the nature of field defects and customer specials was stochastic in nature and didn't lend itself very well to a timeboxed framework like scrum. However, there were no off-the-shelf methods available back then that were a viable alternative. Hence, we experimented with various methods and blended-in elements form various methods to create out our very first kanban by limiting work in progress.

    In this talk, I will explain our first kanban experiment, and also compare and contrast with the later-day Lean Kanban by David Anderson.

  • Added to My Schedule
    Seshadri Veeraraghavan

    Seshadri Veeraraghavan - Agile Transformation: Practical Insights into Behavioral Adjustments and Cultural Changes

    schedule  01:30 - 02:15 PM IST place Grand Ballroom 2 star_halfRate

    An all-encompassing effort such as a full-scale agile transformation goes to the very roots of an organization and tends to shake things up quite dramatically. Indeed, it’s very much like undergoing heart surgery AND brain surgery – simultaneously.

    Imagine the damage caused from a failed organization-wide change:

    • Loss of credibility
    • Loss of trust
    • Loss of face and reputation
    • Strong demotivation and loss of commitment and faith on the part of employees
    • Clinging even tighter to the old (safe!) ways of doing things
    • Diminished success of future attempts by leaving behind a wary and highly skeptical audience

    After the storm passes, where things have settled often determines how and where the organization goes from that point onwards. Ensure your transformation plan succeeds and the pieces fall into place according to the set goals and plans -- and not according to someone’s whims and fancies; politics; cultural and attitude issues; or naysayers.

  • Added to My Schedule
    Jeff Lopez-Stuit, CEC

    Jeff Lopez-Stuit, CEC - Exploit Core Agile Practices at the Program Level

    schedule  01:30 - 02:15 PM IST place Esquire Hall star_halfRate

    Core Agile practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and focus on clearing impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.

    What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?

    This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:

    • What program management challenges are ripe for improvement through Agile practices?

    • The Program Impediment Board: Visible impediments, dependencies and milestones at a program level

    • The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program

    • What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.


    Coffee/Tea Break - 15 mins

  • schedule  02:30 - 02:50 PM IST place Grand Ballroom 1 star_halfRate

    Most Agile teams learn the ceremonies and other Agile jargons sooner than we could imagine.They add few meetings to their project execution and talk in a fancy language that would make us believe in Agile utopia. Everything seems fine and happy, until one day their happy bubble bursts and they realize that they are just 'doing' Agile and not 'being' Agile. One primary culprit here is that the teams often neglect their core technical practices and don't challenge their status quo. Which means they don't change anything about the way they design, code or test but just modify their management processes and await a miracle. There are three primary reason why we observe this Agile smell in most teams. It is believed that there are no immediate results in modifying these practices, its is hard to change the existing practice because of umpteen man-made reasons and finally no one knows where to begin their journey.

    Here in this talk I would like to address the third challenge and explain how a (non-technical) coach could pair with the team members on their day-to-day activities and help them initiate this journey. The focus of this presentation is on the do's and don'ts while pairing with the team members. It will also explain the benefits of this exercise.

  • schedule  02:30 - 02:50 PM IST place Grand Ballroom 2 star_halfRate

    In my previous role as the leader of the of a products group, leading one-of-its kind agile transformation initiative, we tried to fundamentally change how value is delivered to customers in legacy technologies. In this experience report, I would like to share my insights about the agile transformation journey by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. To complicate things further, implementing agile in a mainframe technology stack is extremely challenging because people working with legacy technology/code-base, have a mindset that it is not possible to introduce modern tools/technologies or a different way of developing software in this environment. Specifically I would like to touch upon the following areas to drive agility across the organization:

    1. The need for Agile transformation initiative
      1. Time to market - Long release cycles; Impact on release feature relevance;  - Need for reducing release cycle as well as the need to build what is relevant
      2. Rapid changes in Data Center requirements as well change in direction for technology stack – Heterogeneous platforms, On Premise to Cloud, Web and Mobility driving different usage patterns – driving the need for more and faster innovation
      3. Lack of customer involvement in product roadmap and release plans – Need for early feedback and validation
      4. R&D - Lack of understanding of customer environment; Siloed functional groups inhibiting collaboration;  - De-risk knowledge levels within the organization; Improve cross functional team behaviors; improve engineering practices and usage of productivity tools
    2. Challenges faced during the journey – Communication; Expectation Management; Changing culture and behaviors; HR – role of HR, systems, processes, performance management, job titles/description, Rewards and Recognition; Skills – Technology as well as softer skills; Engineering practices and tools;
    3. Organizational changes introduced to make the transformation successful
      1. Communication and expectation Management
      2. Culture and behaviors – soft skills workshops, move from an I to a WE, emphasize on team thru team goals and team success, team based rewards and recognition; changed job description of managers to get effective participation and right behaviors as well as how they can contribute to the team success; Enabled cross functional skills (T skills / Generalists)
      3. HR – Systems/processes, introduction of new job titles and changes to job description, Team based quarterly performance goals and reviews, multi-rater feedback;   Moved from Individual performance reviews to team based quarterly performance reviews
      4. Engineering excellence – enabling skills and tools for continuous integration, build and deployment to provide faster feedback as well as shorter release cycles; improve quality;   Moved from waterfall to a daily integration and build model;  
      5. Value Delivery – Requirements voted to understand high priority needs; reduce release cycle; customer involvement during roadmap and release planning, sprint review feedback;   Release cycle reduce from 18 months to quarterly incremental releases

    Due to the nature and complexity of the change, the impact and touch points involved in this transformation, it is very critical to have an active and deeper participation from the leadership team to effectively plan change management to make the transformation successful.   Since it was a multi-year transformation initiative as well as continuous improvement journey, we had taken a phased approach to implement the overall transformation plan so as to take benefit out of learning coming out from each of the phases.


  • Added to My Schedule
    Rathinakumar Balasubramanian

    Rathinakumar Balasubramanian - Edward De Bono's Creative Thinking meets with Agile

    schedule  02:30 - 03:15 PM IST place Esquire Hall star_halfRate

    Slide Deck used in the conference:


    Building 'happy' teams is one of the cherished goals for Agile Coaches and Scrum Masters. In my coaching experience, all the high-performance agile teams have joy and happiness as the core to their performance. 

    I have taken Edward De Bono as my support and his work on creative thinking as my guide for this purpose. Edward De Bono's crative thinking patterns include several aspects like curiosity, provocation, synergy, fun, hypotheis etc. Edward De Bono's work can be applied in every field where we look for creative outcomes. 

    These creative thinking patterns can be adopted by agile coaches/scrum masters to improve their effectiveness in building high-performance teams.  

    This session has exercises that are derived from Edward De Bono's work on creative thinking patterns. These exercises can be used by agile coaches/scrum masters with appropriate modifications in their real world contexts.

    Join me in building "happy" teams with the help of Edward De Bono.

  • Added to My Schedule
    Krishnamurty VG Pammi

    Krishnamurty VG Pammi - 6 X 2 Planning Errors in Scaled Agile Delivery Model

    schedule  05:00 - 05:20 PM IST place Grand Ballroom 2 star_halfRate

    2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

    Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

    Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

  • Added to My Schedule
    vinaya muralidharan

    vinaya muralidharan / Sutap - The Snowball Effect - From Team Kanban to Enterprise Kanban

    schedule  05:00 - 05:20 PM IST place Esquire Hall star_halfRate

    About two years ago, we embarked on our journey towards Agility and Kanban was our vehicle.

    But Kanban had people worried.

    How can we not have detailed plans?! How can we limit WIP when we have so many things to work on?!

    We have due dates to meet! And so on.

    We would like to share one of the approaches that we adopted to help move the change along.

    In addition to focusing on the Kanban implementation at the project levels, we adopted another route – to work through the individuals and the teams – a grounds up approach. We encouraged people and teams to use Kanban boards to manage their daily tasks.

    You have difficulty in managing personal stuff? We’ll help you manage better!

    You have issues in managing team level priority? Look what we did within our team- we have a Team Kanban and we are now much better organized!

    One by one we saw people getting interested. The movement gathered steam - we worked directly with a handful of people and they in turn got their peers onboard. And we saw various flavors like Personal Kanban, Team Kanban cropping up all over the place – even in our Travel Office and Corporate Office. What this did was give people a safe, controlled environment to experiment and learn in.

    As they got used to the ideas of limiting WIP, pulling work, visualizing work and “stop starting, start finishing”, it gave them the confidence to work this way at the project level too. And it made our lives as change agents just a wee-bit easier!

    We welcome you to come hear our story about nurturing the change towards Agility by making it a grass roots movement.

    A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.


Scaling Agile Adoption Day 2

Thu, Mar 26

    Opening Talk - 15 mins


    Coffee/Tea Break - 15 mins

  • schedule  10:30 - 11:30 AM IST place Grand Ballroom 1 star_halfRate

    Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

  • schedule  10:30 - 11:30 AM IST place Grand Ballroom 2 star_halfRate

    You’ve started on Agile project. You've probably got IT management on board. You've read the manifesto. You've got a wall covered in post-its. You’re probably not using pair programming but you’re following most other Scrum and XP practices. But now you have a problem. Operations, HR and finance can’t keep up. Ops is having problems (or just refusing to) deploy each iteration. HR won’t let you form self-organising teams and don't know how to write KPI’s to support collaborative work practices. And finance wants a 3 year budget with fully costed initiatives.

    Like many cultural problems, change comes from understanding. This presentation will explain how non-IT business functions operate and why they have legitimate problems with Agile delivery.

    We won’t stop there however.

    By understanding your business, this presentation will provide you with the tools you need to align your corporate business functions to your agile development approach. From improved communication integrated sales, rolling budgets, agile KPI’s and aligning to revenue drivers. You will learn how to build a truly agile organization.

  • schedule  10:30 - 11:30 AM IST place Esquire Hall star_halfRate

    Organizations invest energy, effort and real dollars to stay in trend. Here's one of the trend: Agile is no longer a buzz word, Scaling Agile is. Terms like Enterprise Agile, Scaled Agile, SAFe, LESS, DAD, Agility Path are conveniently thrown around in meetings and speeches as organizations line up to get on the bandwagon of 'Scaling Agile'. Scaling Agile - from the team and product level to the organizational level has it's own benefits and challenges. Is scaling Agile right for you? Are you ready for it? If you've been thinking of scaling, you might be in luck. In this session, we will discuss grounds up approach of how to analyze and evaluate if an organization (or a business unit) is ready for scaling Agile. You'll create your own set of evaluation criteria specific to your organization's situation and learn steps your organization can take to be more prepared for scaling Agile and reap organization-wide benefits. The focus will remain on your context and not on promoting any particular scaling framework.

            "Scaling. Its about the context not the process." - Jeff Sutherland

    PS: This will be a no slides, hands-on workshop. Be prepared to actively participate throughout the session.


    Break - 15 mins

  • schedule  11:45 AM - 12:30 PM IST place Grand Ballroom 1 star_halfRate

    Kanban is one of the fastest-growing development methodologies today.  Teams increasingly turn to Kanban to simplify and streamline their agile development, but few people know the inside story of how and why Kanban was created.  The Secret History of Kanban pulls back the curtain and gives you a first-hand account of how Kanban went from being a colossal failure to a startling success, presented by one of the original team leaders.  Learn how a team turned theory into practice, what it means for the future of Agile, and how you can apply those lessons in your own organization.

  • Added to My Schedule
    Avinash Rao

    Avinash Rao - The Double Helix Model for Lean Agile

    schedule  11:45 AM - 12:30 PM IST place Grand Ballroom 2 star_halfRate

    We are living through a winter of discontent in the Enterprise IT space serviced by IT services organizations.

    Agile is no longer new; Agile projects which are running effectively are being asked to be efficient; at the same time, cost efficient projects are being asked to be more Agile (with Agile meaning different things to different stakeholders). In the minds of clients, the words Agile and Lean have become synonymous with effective and efficient IT services delivery. Long seen as two parallel ways of work, we are now being asked to do both. Does ‘Lean Agile’ – which is becoming fashionable with some clients - exist, and what does it look like?

    The authors of this session come at the problem from opposite directions. Avinash’s starting point is a tightly managed traditional project burned by a (past) failed Agile implementation, that nonetheless needs to deliver the value Business is demanding; Jay runs a large successful Agile program that the customer is now demanding efficiencies from. We came together to create the Double Helix, a model to implement Lean Agile.

    Before the implementation of Double Helix, our structures existed in traditional forms - a Hierarchy in case of projects that thought themselves efficient. and for agile, a Scrum structure within a deeply entrenched structure based on designations and seniority. By implementing the Double Helix, we overlaid this structure with Planning teams that cut across designations (from the program manager to entry level trainees) and Execution teams that are mainly peer-level (all managers, all leads, for example). Power shifts from a experience and role basis to the basis of contribution to the respective planning and execution teams. As we will show, this is very similar to the Lean organizations that Japanese manfacturers have adopted. 

    Our measurements reflect this change. Our efficiency measures indicate the progress made in reducing waste (57% of the project work was non-value add, in the example presented, reduced to 20%) and effectiveness measures show the RFT (Right First Time) and also use feedback from the end-users (defects / fresh Function Point delivered) to measure how effectively the program is delivering value. 

    We will share how tooling was used to idiot-proof (Poka Yoke) development, especially during steep ramp ups - reducing the time for a new entrant to be productive in a mission critical development project from 45 to 30 days.

  • Added to My Schedule
    Ahmed Sidky

    Ahmed Sidky - Value Teams: The Next Evolution of Product Owners

    schedule  11:45 AM - 12:30 PM IST place Esquire Hall star_halfRate

    When people learn about agile they usually learn about Scrum (since it is the most popular flavor of agile). While Scrum is beneficial, it does not have answers to all the challenges of software development. One of the common challenges teams face is that of having an effective Product Owner. From experience, it is not about who is fulfilling the role of the Product owner in your organization but about the definition of the role itself. We have played with many different variations of the PO role, till we ended up with the concept and structure of the Value Team. To keep it simple, the Value Team is responsible for making sure the product is (1) Feasible, (2) Valuable, (3) Useable.  After using Value Teams in many corporations (the session will have many real-life examples of this) they seems to be a practical solution to many problems about how agile can work in complex environments where there is no ONE product owner, but rather multiple organizations and people that have a say in what needs to get build and how. This session will present the idea of Value teams and answer questions on how to create them, how they operate, who is in charge, and why they are so critical to the success of the agile delivery team.


    Lunch - 60 mins

  • Added to My Schedule
    Prasad Kunte

    Prasad Kunte / Naresh Jain - Implementing Agile Engineering Practices in Legacy Codebases

    schedule  01:30 - 02:15 PM IST place Grand Ballroom 1 star_halfRate

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Added to My Schedule
    Nanda Lankalapalli

    Nanda Lankalapalli - Happy Teams are key to successful agile transformation– Teams’ self-design

    schedule  01:30 - 02:15 PM IST place Grand Ballroom 2 star_halfRate

    Agile Teams' self-design is very important (though not very common) exercise in a large-scale agile transformation. In teams’ self design, team members choose their own teams in a collaborative way. This concept here is that the teams will gel quickly and excel when they are self-designed.

    In this session I am going to present my experience with such exercise. I facilitated at least 4 such sessions to help an organization as part of a large-scale transformation. The session is going to explain

    1. Benefits of Feature teams over Component teams
    2. Self-design of feature teams
    3. Pilot exercise of self-design of 2 feature teams.
    4. Large scale self-design of 4 product groups with 30 to 50 members per group.


  • schedule  01:30 - 03:00 PM IST place Esquire Hall star_halfRate

    This workshop will help participants to understand how the Kanban method really works.

    We will learn how to use the Kanban method to visualize your current process ("start where you are"). Will figure out how to limit work in progress (WiP); define and make process policies explicit; measure and manage flow.

    Also we will figure out what does it mean to search for opportunities for continuous improvement. We will learn how to increase your team speed and at the same time decrease pressure at work.

    All of these we will touch through extremely hands-on step-by-step simulation using LEGO bricks.


  • Added to My Schedule

    Prasad / Alok Uniyal - Speed 2 Value.. helping large Enterprise IT to be in the game..

    schedule  03:05 - 03:25 PM IST place Esquire Hall star_halfRate

    Technology has blurred the lines between the digital and traditional methods of dealing with a consumer of any Global Enterprises. The Business Process and IT is no more separate, in most of the industry verticals the Business is driven by IT.   Constant Innovation around IT has become the new normal to the Enterprises to meet rapidly changing consumer expectations and behavior dynamics.

    More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope, and they seek to deliver on new demands by adding piecemeal elements to their existing operations. This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, tools, delivery models, partnership model.

    This experience report  brings strategy of 2 speed IT, through which Infosys helped its Global top 10 clients to 'renew' its IT related to Digital & Mobility space using Agile as a key lever.

    This session gives you experiences, practical on the ground challenges, stakeholder and vendor complexity and approach and journey towards Speed 2 value. Also I am pairing with Alok Uniyal who is senior leader at Infosys and a CIO coach who helped 50 plus clients to transform their IT organization in last 20 years.

  • Added to My Schedule
    kavita kapoor

    kavita kapoor - Hacking the Sales Process with Kanban/Agile

    schedule  04:00 - 04:45 PM IST place Grand Ballroom 1 star_halfRate

    The sales process is hard. As a business owner, you spend your entire time doing it. Often wishing you were back, cutting code. If you are successful you might have a raft of sales people closing deals under their own process while your product people deliver under Agile. Your worlds are split and often, it breaks.

    Change that. Apply Agile and Kanban to supercharge your sales team. Get your developers and scrum master in on the action. Unify your company.

    Kavita has spent the last two years changing the global process of a leading Ad Agency while based in Delhi. Now at Fifty based in London and Barcelona she has created a unified Product and Sales team from scratch. Turning her work over the last 6 months into a case study, get a fresh of the presss step by step break down of hacking the sales process from both the CEO, developer and copy writer perspective. Kavita will be transparent about mistakes and the open about the recipe for success.

  • Added to My Schedule
    Raja Bavani

    Raja Bavani - Detect and Eliminate Bureaucracy in Geographically Distributed Large Agile Teams!

    schedule  04:00 - 04:45 PM IST place Grand Ballroom 2 star_halfRate

    One of the many great things about working in Agile teams is the lack of bureaucracy. Agility and bureaucracy do not and cannot coexist. In general, bureaucracy is a system of government in which most of the important decisions are made by state officials rather than by elected representatives.  

    Management guru Gary Hamel says,

    “Strategy gets set at the top. Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion. This is the recipe for “bureaucracy,” the 150-year old mashup of military command structures and industrial engineering that constitutes the operating system for virtually every large-scale organization on the planet. It is the unchallenged tenets of bureaucracy that disable our organizations—that make them inertial, incremental and uninspiring.”

    In our context, bureaucracy is with reference to geographically distributed teams working together to run Agile projects. When there is bureaucracy in geographically distributed teams, you will find powerful forces setting the rules, defining practices and mandating criteria. And there will be several followers who are ready succumb to the pressure. When this happens one may witness specialized definitions, measurement criteria, and rituals that define the software lifecycle to be followed by distributed teams. Decision making will move up in the hierarchy. Teams will practice practices just for the sake of practicing. Many of the team members will eventually forget the purpose, essence and sprit of processes. That is a slippery slope! In geographically distributed teams – especially when multiple organizations and powerful leaders come together, it is very difficult and challenging to guard against bureaucracy.   When that happens, we cannot have true Agile enablement.

    This session will present the ground realities seen in distributed Agile projects and techniques to overcome bureaucracy in geographically distributed teams.

  • Added to My Schedule
    Ahmed Sidky

    Ahmed Sidky - The Secret, yet Obvious, Ingredient to Achieving Sustainable Organizational Agility

    schedule  05:00 - 06:00 PM IST place Grand Ballroom star_halfRate

    Education is a critical component in a sustainable agile transformation. Sustainable agile is realized when people have truly change the way they think – that needs education. If we truly understand that we need to change the mindset of everyone in the organization, including its leaders, then we need a combination of education, coaching and mentoring to successfully equip people with the knowledge and skills they need to develop and execute agile habits. If we think of agile as a process, not a mindset, then we default to training instead of education.

    Training is about the mechanics of how practices are done, such as a template for writing a user story, education will focus on changing the thought process to focus on value and enable the educated to think and decide what works for them and for their team in a given context. That is true agility.

    While we acknowledge our bias towards the learning roadmap published by the International Consortium of Agile (, we truly believe that it is the most comprehensive roadmap in the agile community that focuses on a common education roadmap for agile and agility and not training on a particular agile methodology. ICAgile has gathered experts from around the world and they have collaborated to define an education roadmap for every discipline needed to change how the organization as a whole works, and provides education as a foundation for sustainable organizational agility. (Focus on people not process, education not training)

    Certifications are a way to give people confidence in the learning and competency of others. Agile certifications should be no different. ICAgile has developed a set of competency based certifications to ensure we keep the focus on Education. 


    Panel Discussion : Agile Adoption Trends in the near future - 45 mins


Agile Lifecycle Day 1

Fri, Mar 27

    Registration - 30 mins

  • schedule  09:00 - 10:00 AM IST place Grand Ballroom star_halfRate

    In order to successful scale any method or practice, it has to have some basis in theory. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for that theory. Seeing software development as a problem of knowledge management, the theory will elaborate a understanding of applications as the emergent property of a co-evolutionary interactions between technology capability and unarticulated user requirements.

    Having established a basic theory a range of methods and tools will be elaborated. These include:

    - Narrative based approaches to requirements capture (not to be confused with Story telling or story boarding) which gather thousands of fragmented self-signified anecdotes relating to real and imagined needs within a user community and allow interpretation and integration into project planning.

    - Approaches to project planning and implementation that focus on the creation of self-organising teams of specialists and users to create novel approaches, supported by evidence to previously intractable problems. This is particularly relevant to the 5-10% of any major project which creates 95-90% of the grief.

    - The integration of tools such as blogs, wiki's etc into the development environment. Too often corporate environments over-constrain those tools into over rigid structures which destroy their utility.


    Opening Talk - 15 mins


    Coffee/Tea Break - 15 mins


    Break - 15 mins

  • Added to My Schedule

    DEBASHIS BANERJEE - Agilists - Detect, Protect and Celebrate IP Created During Sprints

    schedule  12:10 - 12:30 PM IST place Esquire Hall star_halfRate

    In the context of continuous and periodic delivery of same day, monthly and agile incremental delivery in both established and startup contexts there is a possibility of teams missing key elements of protecting their IP. Some simple elements such as making your work public prior to protecting it can cause loss of business. Additionally in short sprints filing IP may not be the most important focus within teams (especially in startups or smaller companies where budgets might also be a constraint). In this session it will demonstrate (a) Some key elements of how to keep IP in mind in Agile sprints (b) Some general best practices of how IP can be used as a bond/glue for teaming (c) Some process changes possible to ensure IP becomes a key element of agile delivery. These is based on experience of over 6 years submitting IP self and also having 6 people having approved IP, 20+ people encouraged to submit and 75+ submissions. (d) As a influencer will provide some best practices to Leaders and Product owners to encourage IP. (e) Additionally IP can be a great occassion for team building and bonding and a retention tool.  Note: The session will be generic and will not cover any specific IP process of any company but a general set of practices via experiences


    Lunch - 60 mins


    Coffee/Tea Break - 15 mins

  • Added to My Schedule
    Todd Little

    Todd Little - Mythbusting Software Estimation

    schedule  03:15 - 04:00 PM IST place Grand Ballroom 1 star_halfRate

    Estimating software projects has proven to be particularly challenging.  Over-running schedules happens frequently in our industry.  As a result software estimation is often viewed as a black art.  In this session Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

    Some of the myths that will be explored include:

    • Historical Estimation Accuracy
    • Relative Estimation
    • The Cone of Uncertainty
    • Velocity
    • Scope Creep
    • Estimation Tools
    • Wisdom of Crowds
  • Added to My Schedule
    Yuval Yeret

    Yuval Yeret - Kanban - A Way Towards DevOps in the Legacy Enterprise

    schedule  03:15 - 04:00 PM IST place Grand Ballroom 2 star_halfRate

    DevOps is a higher form of agility. It is a blueprint for a great culture and and process between the different groups involved in the delivery pipeline. The big question is how to achieve it. If you are founding a startup today, it can be quite easy to take that blueprint and use it to create your process, hire the right versatile flexible people, and start delivering without any technical/automation debt or friction. But most of us are not founding new startups. Most of us already have a running operation with people, culture, process that matured over the years and despite its flaws is currently the way we do things. Changing that is non-trivial. For things to change people need to understand WHY change, what we are changing, and we need an effective process for managing the change itself (HOW to change). So what ARE we changing to? DevOps is highly focused on looking at the whole value stream from idea to value and ensuring effective flow through this pipeline. Kanban is ONE way of HOW to change. It starts by visualizing all the work flowing in the pipeline, then managing the flow focusing on finishing things end to end rather than starting in order to stay busy. It continues to what we call the “Work in process Diet” – Straining the flow more and more in order to identify obstacles to tighter and tighter DevOps culture/operation and faster feedback cycles. You can expect to come out of this session with ideas how to take your current operation and DevOpsify it in a safe evolutionary way using the Kanban method.

  • schedule  03:15 - 04:45 PM IST place Esquire Hall star_halfRate

    Over the past ten years, software development teams using Agile approaches to work have adopted retrospective meetings as a critical practice for learning and continuous improvement. To the extent that practitioners say, “If you’re not holding iteration retrospectives, you’re not doing Agile.”

     Agile retrospectives at the end of each iteration or work increment set aside time for the team to examine feedback from current conditions and develop targeted tactics to keep the project on track. Many practitioners experience retrospectives as great means for detecting good, poor, and missing practices; as a handle to make tacit knowledge about effective practices explicit; and to define improvement actions in order to deal with ineffective or inefficient technical, process, and teamwork practices.

    However, too many teams and practitioners don’t reap the benefits that effective retrospective meetings can provide. Too many retrospective meetings receive cursory or inadequate facilitation. Too many retrospective meetings are held to  “check the box” on the project management template, rather than to focus on real improvements. For too many teams, the action plans coming out of retrospectives are never implemented or revisited. Too many teams seek to shift blame and responsibility for action through the retrospective.

    In too many organizations, retrospective meetings don’t deliver the promised return on time invested (ROTI).

    In this session, you’ll learn how to get the most from your retrospective practices. Diana Larsen, co-author of Agile Retrospectives: Making Good Teams Great, will introduce you to a simple framework for getting better outcomes from retrospective meetings, suggest ways to maintain the relevance of improvement to the work of your team, and provide tips and pointers to get great returns from the time your teams devote to every meeting. 

  • schedule  04:15 - 05:00 PM IST place Grand Ballroom 1 star_halfRate

    What is coaching?

    “It is helping to identify the skills and capabilities that are within the person, and enabling them to use them to the best of their ability” — wikipedia

    "Individuals and Interactions over Process and Tools"

    The above is first of the 4 values espoused in the manifesto but yet it is common to see many agile coaches engage with teams and organisations advocating more and more processes. This is a common sight with new teams and also with teams on the path of agile transition from few months to few years irrespective of the competency, skills and maturity of the teams. Agile Fluency model created by Diana Larse and James Shore highlights the focus on value over compliance and practices at any given level

    “ Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency ”

    An agile coach responsible for building high performing teams will need right set of powerful tools and techniques to leverage while working with teams and also to set the right expectations to both management and teams. This talk will draw from experience using few such powerful tools mentioned below while coaching teams attain fluency.

    1. Deliberate Practice
    2. Driving Empowerment & Self Organisation: Working Agreements
    3. Scaling Agile Transformation: Creating a Learning Org 
    4. Driving Commitment: Key Measures Highlighting Self Organisation

    This is not a beginner level talk and assumes participants having experience in leading agile teams and transformation initiatives in your respective organisations.

  • Added to My Schedule
    Sean Dunn

    Sean Dunn - Agile Architecture: A Contradiction in Terms? Our Journey in Discovering the Role

    schedule  04:15 - 05:00 PM IST place Grand Ballroom 2 star_halfRate

    The role of "Architect" is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and eventual discovery on how the role brings can bring an immense amount of value to the organization and the teams, especially on large, multi-team projects. 

  • schedule  05:15 - 06:00 PM IST place Grand Ballroom 1 star_halfRate

    What could be more important for leaders than increasing their teams’ productivity? Conventional thinking would rank “increased motivation” as one of the most important tools for increasing productivity of teams.

       Motivation --> increases Progress --> increases Productivity

    This interactive session will disrupt and challenge the above notion, and will provide an alternative view:

       Progress --> increases Motivation --> increases Productivity

    Dipesh will be drawing upon more than a decade of research including 26 project teams, 7 companies and a deep analysis of nearly 12,000 daily diaries kept by team members, and use real case studies and examples to illustrate the following key elements:

       Catalysts – events and actions that help a team move forward

       Inhibitors – events and actions that can induce setbacks

       Nourishers – interpersonal interactions that lift team’s spirits

       Toxins – interpersonal interactions that undermine team’s spirits

    Awareness of the above principle is important and may sound simple; however turning the awareness of these elements into the inner workings of our daily routine takes discipline. With that in mind, all attendees will be given 'The Progress Enablement Checklist' that will assist them in making such behaviours habitual.

    If you are a leader or an aspiring leader of an Agile team, this session will provide clear implications for where to focus your efforts so that you do not worry about the wrong things. You will be inspired by knowing what serves to catalyse and nourish progress – and what does the opposite.

  • Added to My Schedule
    Mikael Lundquist

    Mikael Lundquist / Fredrik Hedlund - 10 times better quality with agile transformation. How we did it!!!

    schedule  05:15 - 06:00 PM IST place Grand Ballroom 2 star_halfRate


    In 2011 the Ladok section at ITS had serious quality issues, resulting in dissatisfied customers. At the beginning of 2012 the section started an agile transformation, in steps, throughout the whole section. One year later the whole section had transformed and currently the section now eats, sleeps and breathes Agile. The quality has improved remarkably and our customers are understandably much more satisfied. Besides satisfied customers, our employees are happier.

    The ideas to try agile came from the people working in the project and we think that was an important factor for the success.

    We are going to talk about our experiences of this transformation and how the transformation contributed to the remarkable increase of the quality. The talk will cover the background, our roadmap, the result of the transformation and the factors of success.

    We have identified two key factors of our success that we will promote a little extra during our talk.


    Presentation technique

    We are going to perform this presentation in an agile way, in the way we interpret scrum. This means that we are going to interact with the audience and we expect them to influence our presentation.

    The point is to not just talk of how we did, but also show it on stage. We also think that this is a good way for the audience to really get the most out of the presentation.


    We want you to prioritize the presentation parts

    We consider the different parts of the presentation as the presentation backlog. We want the audience to prioritize the parts of our presentation, in advance. Prioritize here.


  • Added to My Schedule
    Madhavi Ledalla

    Madhavi Ledalla / Jerry Rajamoney - Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!

    schedule  05:15 - 06:15 PM IST place Esquire Hall star_halfRate

             Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve! 

    Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

    R-> Realize where you are and where you want to be

    E-> Engage the teams in fruitful discussions

    T-> Team work to build “We over I” attitude

    R-> Relish the power of Inspect and Adapt cycles

    O->Openness and Transparency to make retrospectives efficient and effective

    In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective. 

    R-> Repeated issues pop-up

    E-> Engrossing & Engaging discussions are missing

    T-> Team present virtually, loses trust.

    R-> Routine stuff, nothing interests the teams.

    O->Observably gets boring over time.

    To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively!  Teams need to do out-of-box thinking and appreciate that these short gatherings need not  be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!



Agile Lifecycle Day 2

Sat, Mar 28

    Opening Talk - 15 mins


    Coffee/Tea Break - 15 mins


    Break - 15 mins


    Lunch - 60 mins

  • Added to My Schedule
    Ashish Parkhi

    Ashish Parkhi / Naresh Jain - Techniques to Speed Up your Build Pipeline for Faster Feedback.

    schedule  01:30 - 02:15 PM IST place Grand Ballroom 1 star_halfRate

    We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

    Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

    Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

  • schedule  01:30 - 02:15 PM IST place Grand Ballroom 2 star_halfRate

    Since the late nineties, the Agile books in the non-fiction aisle have steadily increased in number. It's common to see a book or three about Agile on a colleague's desk. It's also common to see such a book look practically new, the book spin showing no sign of having been opened. Non-fiction books are great at providing bullet points of things to do and reasons why. But non-fiction books are poor at:

    • inspiring,
    • creating emotional attachement (so the reader finishes the book), 
    • creating a full sensory environment for the reader,
    • describing a holostic environment, or
    • 'intriguing' a reader who is un-interested in the topic. 

    (This bullet list above is a good example of how non-fiction can excite thoughts who already know the story behind the bullets, but doesn't inspire much if the reader hasn't any context or background.)

    Fiction is well positioned to do the above because its number one job is to give pleasure and entertainment.  It can't be successful if it can't do this. The oral tradition of fiction has been part of human culture for millions of years, since a Cro-Magnon passed on a story to another, and upon re-telling some details were forgotten and the storyteller had to make them up.  Fiction is in fact is the most successful format for culture change as this is the format of the world's religious works and is responsible for guiding or changing the behaviors of billions of people.  The CIA and the Pentagon use fiction to develop scenarios which are used to create simulations to test preparedness.

    What force could be stronger than fiction for giving an individual the courage to initiate an organizational change in the face of uncertain co-workers and often antagonistic corporate environment?  What tester, developer, PM, director could not use the courage of knowing a "David verses the Goliath," "Legend of the IpMan," or "V for Vendetta" to not only understand the bullet points, but to have the stedfast to sustain in the face of resistance because they believe in the change as if they've lived that life, due to reading stories which placed them in one or many virtual versions of that world.

  • Added to My Schedule
    Vivek Ganesan

    Vivek Ganesan - Congratulations! You are our startup's first Scrum Master! What's next?

    schedule  01:30 - 02:30 PM IST place Esquire Hall star_halfRate

    Do you fancy playing the first Scrum Master of a startup?

    Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

    In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

    Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.

  • schedule  03:00 - 03:20 PM IST place Grand Ballroom 1 star_halfRate

    Testing is overated. Let's correct that statement - "Manual Testing is overrated". In this this talk, I plan to take you on whirlwind tour of why an Agile outfit does not need manual testing at all and how to get fantastic Quality Assurance without manual testing.

    In this talk - I outline a agile process with a difference - everyone is a developer and a tester. However, there is no dedicated QA people. In fact, this process does not require anyone other than the developers and one process/product owner.

    Development using a central reposito