InfoQ

News

Mike Cohn Provides New Patterns of Agile Adoption

Posted by Mike Bria on Jan 18, 2008 01:29 PM

Community
Agile
Topics
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Tools support is critical by Kirstan Vandersluis Posted Jan 21, 2008 4:04 PM
Re: Tools support is critical by Anat Gafni Posted Jan 22, 2008 12:06 PM
Re: Tools support is critical by Ted Young Posted Jan 22, 2008 7:04 PM
Re: Tools support is critical by Wojciech Seliga Posted Jan 25, 2008 5:15 AM
  1. Back to top

    Tools support is critical

    Jan 21, 2008 4:04 PM by Kirstan Vandersluis

    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.

  2. Back to top

    Re: Tools support is critical

    Jan 22, 2008 12:06 PM by Anat Gafni

    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.

  3. Back to top

    Re: Tools support is critical

    Jan 22, 2008 7:04 PM by Ted Young

    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

  4. Back to top

    Re: Tools support is critical

    Jan 25, 2008 5:15 AM by Wojciech Seliga

    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

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.