Mike Cohn Provides New Patterns of Agile Adoption
How widespread: ‘Start Small’ or go ‘All In’?
Mike suggests that the more conventional Start Small approach – in which a transition starts with a pilot team, then gradually spreads throughout the organization – has the advantages of minimizing the cost of mistakes, optimizing chances for initial success, and generating internal ‘experts’ that can help in later phases of the transition. He follows noting three disadvantages of this approach: early success with a handpicked pilot team may give false hope for organizational success, it takes longer, and skeptics may view it as a sign of non-commitment by the company.
Conversely, the All In approach – characterized by transitioning all teams right from the start – can benefit an organization by demonstrating management’s commitment, being over more quickly, avoiding dissonance from two processes in use concurrently, and reducing overall resistance. Mike notes the drawbacks to All In as higher risk, higher cost, the likely need for structural reorganization, and high organizational stress.
How technical: ‘Technical Practices First’ or ‘Iterative First’?
Technical Practices First – where adoption starts with a focus on the XP practices of simple design, test-driven development, pair programming, continuous integration, and short iterations – presents the team with the advantages of higher probability for rapid and a quicker transition. Mike notes the disadvantages of this approach as it being generally more difficult and cost intensive, as well as having a tendency to move teams away from the user-centric thinking central to true agility.
In contrast, the Iterative First approach – where the initial focus is solely on getting the team to work iteratively, changing technical practices only when they impede this goal – may be advantageous in that it’s easier to start and often meets less resistance from team members, but poses the risk that teams may choose not ever to adopt the engineering practices fundamental to optimal agility.
How visible: ‘Stealth Mode’ or a ‘Public Display of Agility’?
The Stealth Mode approach – when knowledge of the team’s adoption of agile practices is kept largely only to the team itself – can be beneficial in that it allows the team to achieve success with its new methods before gaining the attention of others; attention from those hoping to emulate them as well as those who might oppose the initiative. On the other hand, this approach’s drawbacks include a lack of potentially necessary organizational support, as well as having a lower chance of convincing skeptics even when the team is successful.
The Public Display of Agility approach – where the team’s adoption efforts are common knowledge outside of the team or even outside the organization -- has the advantages of providing incentive for the team to stick with the adoption, building support among others outside the team, exposing skeptic’s concerns earlier, and demonstrating a higher level of commitment by the organization to the transition and its success. Conversely, this approach can be disadvantageous in that it may look foolish announcing something and then failing to succeed, as well as that exposing naysayer objections may be as disruptive as it is helpful.
Mike closes the article by noting that while any combination can result in success, some patterns may have a more a natural compliment to others, such as Going All In with Iterative First. What’s most important is that the organization does in fact choose deliberately about which patterns it will use on its path to agility.
Another source of patterns related to Agile Adoption is InfoQ's own Patterns of Agile Practice Adoption by Amr Elssamadisy, and also the Adopting Agile page on InfoQ at: http://infoq.com/adopting-agile.
Tools support is critical
I think adopting a tool specifically designed to support your agile process is critical to being successful with Agile. I'd love to hear about other software process tools people out there are using to support their Agile process.
Re: Tools support is critical
To succeed in introducing these practices, it works well to add practices gradually in subsets of relalted processes and improve them until the benefits show clealry and people get used and bought into them, and then add another subset. The three aspects of coordinating and directing tasks I mentioned above, hang together nicely as a set that can be introduced at once. Success also depends on the right set of people and in particular the right thought leasders in the team. if they belive, and are united in their opinion about the process and methodology - it will succeed.
Re: Tools support is critical
Also, using a tool makes it difficult to use the Start_Small pattern, since the tools I've seen generally assume All_In.
Re: Tools support is critical
I witnessed the situation where tools were being evaluated, then tailored and then implemented across the company so long that the whole idea of introducing agile methodology just failed.
Also imagine religious wars about which tools to choose, how to integrate them, how much to pay, hot to deploy and maintain them, etc.
In my opinion it is more beneficial and resonable to start introducing those practices which affect your core business and the biggest issues you have. Typically they are related to frequency of releases, software quality, development eficiency, knowledge exchange, technical risks and so on.
Exchanging the tools used for managing software projects will not help too much, if engineering practices are still poor.
But, if the only problem a company has is having ineffective managment tools, then of course it should concentrate on them. But I doubt if such a company would switch to agile methodology in such circumstances.
So actually I think it's better to start lean and light regarding tools supporting the process (whiteboard/corkboard + memo notes are very often enough) and only when some automation in the managent area (the process) becomes necessary and high priority, then go for it.
Having said all of that, I still believe that we without good development tools introducing efficient agile methodologies will be virtually impossible.