Section 1.3. Managing the Risk of Transitioning to Agility

1.3. Managing the Risk of Transitioning to Agility

The published plan-driven methods (waterfall, spiral, etc.) are very different from agile methods (XP, Scrum, etc.), and they require a significantly different set of management skills. In plan-driven methods, managers are responsible for planning and controlling the development activities. They spend much of their time making plans, verifying progress against those plans, and replanning. In agile teams, managers behave much more like technical coaches and are primarily responsible for identifying and eliminating obstacles that the team encounters. Clearly, agile managers require different skills than plan-driven managers.

The way plan-driven developers produce systems is significantly different from that of agile developers. Plan-driven developers produce lengthy requirements and design documents that are thorough and (at the time) complete. Agile developers produce only enough of those documents to understand what needs to be done. Plan-driven teams tend to partition the system into subsystems, and most developers work within a subsystem, whereas agile teams encourage everyone to feel responsible for the entire system. During implementation, plan-driven developers often develop their respective components (classes, pages, modules, etc.) in isolation and wait until that coding is complete to integrate those components into features. Agile developers work directly on features, programming in pairs in an open environment. Again, agile developers require different skills than plan-driven developers.

In addition, agile teams often interact with external organizations (marketing, customers, management, human resources, etc.) in different ways than plan-driven teams, so transitioning to agility can affect more than just your development organization. It may seem that such a dramatic change could threaten your ability to produce anything, but careful transitioning can reduce those risks and allow you to experience the benefits of agility quickly.

Most of us have been educated in plan-driven methods and have experience working in a plan-driven environment. Because the differences proposed by agile methods are significant, making the transition from plan-driven to agile development can be very risky and intimidating and is not something to be approached lightly.

Several strategies for making the transition to agility have been advocated. Kent Beck has summarized these specifically for XP[3], but the strategies he offers apply to other agile methods as well. Beck suggests three transition strategies: cannonballs, racing dives, and toe dipping. Initially, Beck advocated cannonballs: switching the entire process at once for one project within the organization, and after that project demonstrates success, using those engineers to carry the process into other projects. Although Scrum does not necessarily affect the development strategy, it does advocate overlaying Scrum in its entirety on top of the existing development strategy. In fact, some advocates of Scrum have suggested that the pilot project be the "single most difficult and critical project."[8]

Clearly, a radical change in process brings with it significant risk. If the learning curve is too steep, you could fail to deliver anything. In companies that have few projects, the risk may be life threatening. Many organizations have mitigated this risk by bringing in a consultant to help ease the transition (Beck calls this a racing dive). These consultants are well versed in the techniques of a particular methodology and reduce the learning curve by guiding the organization through the transition. Although this is a strong approach to jumpstart the transition, there is always the risk that the consultant may not help you internalize the change and, after she leaves, you will revert to your old ways.

The final alternative is toe dipping, in which the organization selects one or two XP practices to initiate their transition. After they are comfortable with those practices, they begin to incorporate other practices as they seem appropriate. Although this strategy reduces risk by preventing a dramatic change, it also may delay the benefits that agility can bring. With no experience or guidance, the team may not make wise decisions about which practices to incorporate and may not achieve the goals set for the change.

The strategy this book advocates is a phased transition that reduces risk and gives engineers the time to adjust to the changes. This strategy builds on the foundation laid by Don Wells in Beck's original XP text[2]. In fact, it is essentially a structured version of toe dipping. Wells' strategy was

1. Pick your worst problem (the worst problem your process causes)

2. Solve it the XP way

3. When it's no longer your worst problem, repeat

Each of these statements raises interesting questions, especially when we are interested in agility in general as opposed to XP specifically:

1. How do I know which problem is my "worst" and where my investment in change will give me the biggest payback?

2. What are the proven ways other people have solved this problem?

3. How do I know the change to my process has been an improvement?

This book provides a framework that will help everyone (engineers, managers, customers, etc.) manage the change process in a way that maximizes potential benefits while minimizing risk.