The Four Pillars of Agile Adoption

[article]
Summary:
Now that the world has heard of Agile [1], they think–incorrectly–that the pieces of Agile they like best can be cherry-picked and used in isolation. Unless it is combined with Lean Thinking, agile software development can achieve only a fraction of its potential. Agile software teams are not sustainable for very long if they are islands in a sea of waterfall projects. This artcle examines four change processes that must occur simultaneously for agile adoption to succeed.

Now that the world has heard of Agile [1], they think–incorrectly–that the pieces of Agile they like best can be cherry-picked and used in isolation. Unless it is combined with Lean Thinking, agile software development can achieve only a fraction of its potential. Agile software teams are not sustainable for very long if they are islands in a sea of waterfall projects. The presence of agile teams creates a new and incompatible dynamic within a waterfall company. Agile adoption programs conducted without a thorough understanding of this dynamic will continue to have a very high mortality rate, especially in larger organizations. This artcle examines four change processes that must occur simultaneously for agile adoption to succeed.

High Mortality of Agile Adoption
Why do we see such a wide variation in agile adoption programmes across companies? Why is it that we so often see agile pilot projects able to deliver better quality software in significantly less time, and yet the companies involved do not replicate this success across the enterprise? Every year a growing number of agile conferences offer new experience reports showing high quality projects delivered in 30% to 50% of the time they would have needed using previous methods. From the agile coach community (no verifiable statistics, unfortunately) I know that a very large percent of companies fail in their attempt to take agile the rest of the way to being used enterprise-wide.

Often when a company has piloted a few successful agile teams, managers decide that they can mostly go on as before and just "cherry-pick" some of the Agile practices and tools. The "mostly go on as before" part means conducting product development as a push system, rather than as a lean pull system. So rather than bother with having a product pwner (the person who pulls value from the development team on behalf of the business), they let analysts decide via committees what features to have the agile team build. Testing is difficult for realistic data and error handling scenarios so rather than invest the effort, they settle for superficial testing that is too labour-intensive to be sustained. These are just a couple typical compromises that pave the way for failure.

There are actually four change initiatives that must be managed successfully if a business is to sustain and spread the success of agile pilot teams throughout the enterprise. Even more critical is that they must occur simultaneously. These pillars of agile adoption are:

  • Teams must be able to produce bug-resistant software sustainably
  • Teams must consist of empowered, engaged people
  • Work flow to the agile teams must be controlled via a ‘pull' system
  • Lean portfolio management must be used to control work flow for the organization

Unless all four of these change initiatives are running successfully, characteristic problems arise. They did for the Comet team—an agile development group at an insurance company. Let's look in on this agile team a year after they started their agile adoption initiative.

Agile Entropy–An Example
The Comet team is one of several agile teams that were set up to pilot agile adoption at this insurance company. Their story here is a composite of events that I and other agile coaches have seen. They had external help for a total of eight months: Scrum training, and additional technical training in the use of agile test frameworks and help in cleaning up their build process. Their consultant Scrum Master was on site most of the time for the first three months and then present every other week until disengagement when they felt confident to continue on their own.

Comet Team from Agile

Pages

About the author

Nancy Van Schooenderwoert's picture Nancy Van Schooenderwoert

Nancy Van Schooenderwoert does agile enterprise coaching— everything from launching new agile technical teams to advising executives on how to take agile and lean principles far beyond software development in their drive to deliver more customer value faster. She works with large and small companies. Nancy pioneered agile practices for embedded software development beginning in 1998. Her background in electronics and software development for avionics, factory automation, medical, and defense systems brings a unique perspective to her coaching practice.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!