Agile Alliance founding member, consultant, and book author Mike Cohn recently distilled his experiences helping teams adopt Agile into three core pairs of patterns that can be used by teams when launching an agile transition. He suggests that a team or organization adopting agile should choose the core pattern that best suits their situation from each of the three sets, summarized here:
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.
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.
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
![[R]Evolutionize Your Retrospectives with Active Sensemaking](https://imgopt.infoq.com/fit-in/50x50/filters:quality(80)/articles/retrospectives-active-sensemaking/en/smallimage/revolutionize-your-retrospectives-with-active-sensemaking-small-1684227204199.jpg)
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/rebuild-tech-culture-layoffs/en/smallimage/how-to-rebuild-tech-culture-for-those-who-survived-the-layoffs-small-1677236107330.jpg)
/articles/secure-delivery-workflow/en/smallimage/logo-1675435091128.jpg){kind=logo}
/articles/energy-consumption-bugs/en/smallimage/logo-1673281703209.jpg){kind=logo}
/articles/motivational-diagnostic/en/smallimage/increasing-team-and-individual-motivation-with-motivational-diagnostic-small-1672932888794.jpg)
/articles/group-coaching-beyond-individual/en/smallimage/group-coaching-extending-growth-opportunity-beyond-individual-coaching-small-1671614956735.jpg)
/articles/platform-engineering-roadmap/en/smallimage/logo-1670836548184.jpg){kind=logo}
/articles/software-testing-energy-management/en/smallimage/logo-1670618011406.jpg){kind=logo}
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
Community comments
Tools support is critical
by Kirstan Vandersluis,
Re: Tools support is critical
by Anat Gafni,
Re: Tools support is critical
by Ted Young,
Re: Tools support is critical
by Wojciech Seliga,
Tools support is critical
by Kirstan Vandersluis,
Your message is awaiting moderation. Thank you for participating in the discussion.
We've been using Agile/Scrum at XAware for almost 3 years. We would not be where we are today without software process tools support. We use Rally Development (www.rallydev.com) to manage the process from feature requests to story creation, tasking, schedule tracking, acceptance, etc.
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
by Anat Gafni,
Your message is awaiting moderation. Thank you for participating in the discussion.
We have a very distributed team around the world, and we have been very successful with the XP/Agile processes Mike mentioned. We use Jira for weekly tracking of all tasks (in a priority queue), weekly progress review and estimates/committing for new tasks for next week. This three-way process using one tool (that we adapt and improve for these purposes) has proven great. We get the perspective of the customers by merging into the priority queue the appropriate mix of tasks to capture all interests. Being the manager (who has a wider view) I prepare the priority queue of jira tasks, weekly. The Architect reviews estimates and approach, and the "coach" reviews the progress.
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
by Ted Young,
Your message is awaiting moderation. Thank you for participating in the discussion.
My experience is that using tools at the initial adoption phase can actually cause more problems. We initially used a tool, but found that its lack of All-Visible-All-The-Time, i.e., the entire iteration being visible at once all the time, made it harder for people to feel like they were actually doing anything different. Once we switched to using Cards_On_A_Wall, things started going more smoothly.
Also, using a tool makes it difficult to use the Start_Small pattern, since the tools I've seen generally assume All_In.
;ted
Re: Tools support is critical
by Wojciech Seliga,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with Ted Young. Very often tools (especially dedicated for project management or whole the process) overshadow core agile practices (which are human-centric by their nature) and the spirit of agility.
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.
Wojtek