- step toward transitioning.
Advantages and Disadvantages of Going All In
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.
Technical Practices First or Iterative First?
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