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.
Advantages and Disadvantages of Iterative First
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.
Stealth Mode or Public Display of Agility
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