The Four Pillars of Agile Adoption

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.
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 huge per cent of companies fail in their attempt to take sharp 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.
These are just a couple of typical compromises that pave the way for failure.
Four change initiatives 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 coincide. These pillars of agile adoption are:
  • Teams must be able to produce bug-resistant software sustainably
  • Teams must consist of empowered, engaged people
  • Workflow to the agile teams must be controlled via a ‘pull’ system
  • Lean portfolio management must be used to manage workflow for the organization
Unless all four of these change initiatives are running successfully, particular 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.
Dissension Within Team
The biggest letdown in Tony’s mind was that agile had opened the door to turning software development into a sweatshop. That’s the word he used—”sweatshop”. Before the conversion, the developers had their cubicles, and in the enthusiasm of early agile they’d given them up in favour of a team room. But they were happy for eight months with the team room–why the problem now? They were arguing a lot now, and being together all the time in a team room only increased the tension.
Stressors
They were arguing a lot because of disagreements over how much time to devote to cleaning up quick fixes they’d had to put into the code versus getting new functionality in place that their customers needed. At least that’s when the arguing began. Now there were many running arguments on all sorts of things. The quick fixes got rushed into place when new features activated a couple of latent bugs in the code that their agile test framework didn’t yet cover. Those bugs got a set of insurance policies written with incorrect risk assessments, forcing the legal department to sort out a remedy.

Comments

Popular posts from this blog

Why You Need to Be Specific about Agile Practice Adoption

The Crucial Role DevOps Plays in Change and Configuration Management

Configuration Management and DevOps with Jez Humble and Bob Aiello