There are many ways to transition to an agile process. Choosing the approach that is most likely to work best for your organization can be critical to a smooth transition. Through helping hundreds of teams make the transition to agile over the years, I have identified six core patterns that teams use to initiate the transition to agile. These patterns fall into three sets of opposing pairs. You should choose the core pattern from each set that best suits your team or organization:

• Start Small or go All In?

• Technical Practices First or Iterative First?

• Stealth Mode or a Public Display of Agility?

Conventional, long-standing advice regarding transitioning to agile has been to start with a pilot project, learn from it, and then spread agile throughout the organization.[i]  This approach is the frequently used Start Small pattern in which an organization selects typically one to three teams (of five to ten people each), gets them successful, and then expands agile from there. As agile spreads through the organization new teams benefit from the lessons learned by the teams that have gone before. There are many variations of Start Small, usually because of how many people the organization wants to transition to agile and how quickly they want to do it. Start Small can also be applied differently based on how risk-averse or uncertain about the transition the organization is. For example, in some cases the first team or teams will finish their projects before a second set of teams even begins. Other organizations will take an overlapping approach, where the second set of teams starts only one or two iterations after the first. 

• The cost of mistakes is minimized. Making a mistake with one team is far less costly than making that same mistake with 100 teams.

• You can stack the deck in your favor by selecting the team and project most likely to be successful. This isn't cheating. Having made the decision to transition to agile you are not conducting some double-blind, randomized clinical trial. You are trying to help your organization succeed. Often, an early success can be vital to gaining buy-in from skeptics or fence-sitters.

• It seeds the organization with people who can be the ambassadors and mentors for others as they begin to make the move.

There are of course drawbacks to the Start Small approach:

• Conclusions may not be compelling. Success on a small project staffed by handpicked people does not necessarily mean success will follow on every other project.

• It obviously takes longer to Start Small and scale than it does to take the plunge and go All In.

• It may be seen as a small, tentative step, indicative that the company is not fully committed to agile. In some environments this will bring out sufficient additional resistance to squash even this first step toward transitioning.

The advantages to the All In approach include:

• It demonstrates management's commitment to agile and to overcoming the pain of the transition.

• It's over quickly. Transitioning an entire software development team to agile all at once is like quickly pulling a bandage off a wound. It may hurt a lot but it probably won't hurt for long.

• There is no organizational dissonance from two processes in use concurrently. Chris Fry and Steve Greene of Salesforce.com report that, "The key factor driving us toward a big-bang rollout was to avoid organizational dissonance and a desire for decisive action. Everyone would be doing the same thing at the same time."[iii]

• Resistance is often reduced if skeptics are not allowed to hold out hope that things will revert to normal once the "agile experiment" is over. Like Cortes burning his boats at Vera Cruz to prove his resolve to his soldiers, an organization that chooses to go All In is demonstrating that it is committed to the new process and that it will not turn back. This level of visible commitment to the change can be beneficial in helping the change succeed.

There are of course drawbacks to All In:

• An all-at-once transition can be very risky. The cost of small mistakes will be magnified across the entire transition effort.

• Transitioning all at once is costly, not only due to the increased cost of any mistakes but because successful All In transitions are more likely to rely on outside coaches and trainers.

• It's unlikely you can transition an entire organization of any size all at once without reorganizing some teams and reporting relationships.

• An All In transition can create a lot of stress on an organization. If the organization is already under stress for other reasons, a sudden switch could be the proverbial straw that breaks the camel's back.

A view most closely aligned with Extreme Programming (XP) is that becoming agile begins with becoming good at certain technical practices. If a team is using the right technical practices-simple design, automated testing, pair programming, refactoring, and so on-then agility will be the natural result. Based on the broad popularity of XP, the Technical Practices First is one of the most common patterns of agile adoption.

When following this pattern of agile adoption, a team typically starts by introducing the standard XP practices of simple design, short iterations, test-driven development, pair programming, refactoring, continuous integration, a strong emphasis on automated testing, and so on. As other teams see the productivity and job satisfaction gains of the initial team, they begin to emulate their practices. As the rest of the company sees the improvements, their trust of the development teams increases. This creates a virtuous cycle: the team improves, creating more business-side trust of the team, which in turn allows them to improve further, leading to more trust and an increasingly collaborative relationship.

Almost the direct opposite of the Technical Practices First pattern is the Iterative First pattern. The initial focus of this approach is solely on getting a team to work iteratively. Unlike Technical Practices First, there is little concern for the specific engineering practices of the team, except where those practices impede the team's ability to work iteratively. The Iterative First pattern is based on the notion that moving to an iterative process is often much easier than moving a team all the way to agile. Once a team has begun to work iteratively, the shift to agile is much easier.

Advantages and Disadvantages of Technical Practices First
There are a variety of advantages to the Technical Practices First approach:

• Because teams don't debate which practices to begin with-they are supposed to all be adopted-very rapid improvements are possible.

• The transition can be very quick, especially in teams that are already predisposed towards adopting these agile practices. 

The disadvantages to this approach include:

• The technical practices often support each other in subtle ways. Introducing practices piecemeal and in the wrong order may lead to undesirable results.

• Introducing some of the technical practices will likely present some of the more difficult of all of the challenges of transitioning. Many individuals are extremely reluctant to try such things as simple design, pair programming, and test-driven development.

• Some of the technical practices require significant new learning, which will likely require outside trainers or coaches, increasing the cost of the transition.

• By focusing so strongly on improving their technical practices some teams move further away from the user-centric thinking they should be adopting as central to becoming agile.

There are certain strengths to the Iterative First approach:

• It's easy to start. In some ways the Iterative First approach can be started in the same way we used to teach a kid to swim-throw him in the lake and let him figure it out. A team can be started by doing as little as saying, "Four weeks from now I'd like you to have a new version of your product in a shippable state." Having never done this before, the team will panic, but they'll also likely figure out how to do it.

• It's hard to argue against the benefits of working iteratively. Some of the agile technical practices such as test-driven development and pair programming can evoke fierce opposition from team members. Most team members are willing to work iteratively; the most common resistance will be only to the length of the iterations.

• The primary drawback to the Iterative First approach is that the team may not choose to go any further and may not adopt any of the other agile engineering practices. They may feel that having become iterative they are now "agile enough." They aren't; they've only just begun.

The final choice to make is whether to publicize your transition. One option is to operate in Stealth Mode, or in other words use agile methods but keep that fact private until the project is complete. This happened at one of my client sites. On my first visit there, I spoke with Sarah, the director of the company's project management office. She told me that the transition to agile was underway and had begun after I had delivered a two-day training class to many developers at their headquarters. Sarah outlined a well thought out plan to introduce agile across her company's more than 200 developers. Sarah's plan showed four initial pilot teams, each of which had been selected for very specific reasons. One team was chosen for their willingness to relocate into a shared team space very different from the dedicated cubicle environment in use at the time. Another team was chosen because they would be one of the first to use a new technology in which the company was making a significant investment. The other two teams were selected to be part of the pilot for equally good reasons. Sarah's plan was great because it was going to maximize the learning created right at the outset of this transition effort.

I left Sarah's office planning to visit each of the four teams so I could get their perspective on how things were going. Strangely, though, I didn't find four teams-I found five. When I figured out which of the five wasn't one that Sarah had told me about, I went back and talked with that team some more. I discovered that while to any outside observer they looked exactly like any other agile team, they were not an officially sanctioned part of Sarah's pilot project. They had noticed one of the official teams, liked what they saw, and decided to try it themselves. They had a vague sense that they probably shouldn't be doing what they were doing and had placed their wall-hanging task board and burndown chart well inside a labyrinth of cube walls. I had only stumbled across it because I was unfamiliar with the building and had gotten lost looking for one of the official teams. This team was transitioning using the Stealth Mode pattern. They were using an agile approach, but were keeping their activities to themselves until the project was complete.

In contrast to a Stealth Mode transition is the Public Display of Agility. In this approach the team or organization announces with great fanfare that they are transitioning to agile. Depending on the scope and significance of the transition, the announcements may range from lunch room comments to other teams all the way up to press releases in the national media.

Advantages and Disadvantages of Stealth Mode
The advantages to a Stealth Mode transition include:

• When operating in Stealth Mode you can wait until the project is successful before indicating that the project was run in a different way. Or, if the project fails, you can adjust your agile process, try again, and only tell people you're using an agile development process after you've figured how to do it successfully.

• If you start quietly such that no one but the individuals involved know about the change, there's no one who can tell you to stop. This fits with the old adage of it being easier to ask forgiveness than permission.

There are of course drawbacks to Stealth Mode:

• You won't have any organizational support. If you need organizational support for some of the necessary changes you may not be able to get it.

• Announcing at the end of a project that the project was successful in part because of agile is much less compelling to skeptics than telling them upfront. Of all Babe Ruth's home runs the most famous is the 1932 "called shot." With a count of two balls and two strikes Ruth pointed to the centerfield fence and hit the next pitch into the centerfield bleachers. Saying what you'll do and then doing it is more powerful than announcing your goal after it's been achieved.

The advantages to the Public Display of Agility include:

• Everyone knows you're doing it so you're more likely to stick with it.

• Publicly proclaiming your intent provides an opportunity to create thought and discussion around the goal. With the intent out in the open, team members will feel comfortable talking about the transition with those outside the team. This hopefully will build support among some individuals and get the resistance of others out in the open for discussion.

• Unlike a Stealth Mode transition there's no backing away from the Public Display of Agility. This makes a very powerful statement: not only does the organization plan to initiate the transition, it plans to succeed.

• Like the All In approach, the Public Display of Agility certainly demonstrates a high level of commitment to agile and the transition process.

There are of course drawbacks to the Public Display of Agility:

• Announcing something before you do it can make you look foolish. Pointing to centerfield and then turning the next pitch into a home run over the centerfield fence is one thing; pointing to centerfield and then striking out on the next pitch is another.

• Announcing your intentions before having moved very far toward them is a sure way to bring out the naysayers and their objections.

Organizations benefit from making deliberate decisions between Start Small and All In, Technical Practices First and Iterative First, and between Stealth Mode and Public Display of Affection. While I've seen all eight combinations result in successful transitions to agile, some combinations of patterns are used more frequently than others. Going All In, for example, is most commonly combined with Iterative First because of the complexity that would be involved in changing the technical practices of an organization all at once. By consciously considering these patterns of agile adoption and choosing carefully you will be able to improve your chances of a successful transition.

Mike Cohn is the founder of Mountain Goat Software, an agile training and consulting firm. He is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development and an upcoming book on transitioning to agile development from which this article is drawn. Mike is a founding member of both the Agile Alliance and the Scrum Alliance.

[i] Jim Highsmith, Agile Software Development Ecosystems.

[ii] Steve Greene and Chris Fry, Large Scale Agile Transformation, Agile 2007. Available at http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference.

[iii] Chris Fry and Steve Greene, Big Bang Agile Transformation in an On-Demand World, Agile 2007. Available at http://www.agile2007.org/downloads/proceedings/028_fry-LargeScaleTransition-final_703.pdf.

Comments (7)

chuck suscheck: ... Another pattern I've noticed points to who is driving the adoption - grassroots or topdown. Most of what I've seen has been grassroots, those in the trenches want agile so they can control their own world without PHB dictators. Top down is directed from upper management and usually from the standpoint of cost savings or time to market, without really understanding what agile is about. Problem with grass roots is that it gets shot down, or doesn't propogate to the whole organization, or doesn't get the support needed by those 'in charge'. 1 January 31, 2008 Kenji Hiranabe: ... I liked "Iterative first or technical practices first". Iterative first looks like more evo or scrum. Technical first reminds me of ADC2004 talk of "Anti Practices Patters". In which the team stick to XP practices too much. http://agile.openmex.com/agile2007/2004/files/XR1-1.pdf And, I like your pattern format that shows advantage and disadvantage at the same time and let the readers think. 2 January 18, 2008 Linked to from InfoQ: ... FYI: http://www.infoq.com/news/2008/01/agile-adoption-patterns 3 January 18, 2008 Sarasu: ... Why to choose between Technical Practices First and Iterative First if you can start changing all at once? This is the question I suppose it came to the drivers of the change to agile in my organization. We had within few weeks many trainings, presentation sessions, coachers visits. And at the same time we were supposed to have a shippable version of the product within an iteration. There were too many changes at once, people got confused about agile, XP, iteration development, scrum. Is the combination of both patterns at once and anti-pattern or does anyone has different experiences? 4 January 16, 2008 Jeff Anderson: ... I especially like the "stealth mode". I've had to do a variety of that frequently with my PMM oriented management. It's the "stay in stealth mode" variety. Where I'd never admit to having used something from the agile toolkit. I've use things like planning poker to develop release and iteration plans but had to call it "collaborative planning" as opposed to agile, because there is such a bias against it. Oh well he rose by any other name... http://agileconsulting.blogspot.com/ 5 January 15, 2008 Mike Cohn: ... Hi--I don't know why you'd feel foolish commenting about anything I write. I love constructive criticism and I'm pretty darn sure I haven't seen it all. Let's all add all the pros and cons to these approaches we can! :) I'm not sure if you really "lose some of the stakeholders" when Starting Small as much as you lose an opportunity to have engaged them in a success. Stealth Mode is often invoked by teams that can't get approval from above to try agile. They don't want to get in trouble so they do it quietly. I can see myself having taken that type of approach years ago, early in my career. I would have loved stakeholder buy-in but I wasn't in a position to get it. 6 January 15, 2008 pkr: ... I feel a bit foolish commenting about Mike's work, but I would imagine one of the issue of 'stealth mode' (and maybe even the 'start small') would be that you will potentially lose some of the stakeholders. Ideally you want to make it known that you want participation and participation for the life of the project. So by hiding away and making tentative moves then I'd imagine you'd put that participation and stakeholder commitment at risk? 7 January 09, 2008

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close