Section 2.2. How Much Agility Is Realistic Today?

2.2. How Much Agility Is Realistic Today?

Having acknowledged that there are degrees of agility, the relevant questions change significantly. Instead of asking, "Are we agile?" the question becomes, "To what degree should we be agile?" Increasing an organization's agility requires an investment that may be non-trivial and brings a certain amount of risk. The cost of change must be weighed against the benefits, including any reduction in development risks, to ensure the long-term viability of the organization. It is only beneficial to pursue agility in cases where increasing agility increases the capabilities of the organization. These decisions will require that we define what is needed for long-term viability and specify how to measure our progress toward that goal.

Fully embracing an agile methodology requires changing the way engineers allocate their time and how they approach all software development activities.

The management mechanisms and the techniques and strategies for developing software differ dramatically from plan-driven mechanisms. Therefore, effectively using an agile methodology requires new skills for the engineers, project managers, and the organization as a whole. This means that we also need to consider our organization's ability to achieve agility given its current skill set. So we need to ask, "To what degree can we be agile?"

2.3. What Do We Need to React to with Agility?

In general, the "changes" that agility refers to have been changes in requirements. Agile processes have been designed for situations when requirements are either not well known or quickly changing. Usually, "agile" refers to a process, but in a broader sense, agility denotes the ability to deliver functionality in a timely manner and the ability to adjust to externally imposed change. In these terms, "change" usually means changing requirements, but it can also mean changes in things like technology requirements, assigned personnel, or management.

In fact, an organization demonstrates agility, or a lack thereof, in response to a wide variety of changesnot just changes in requirements. For example, a plan-driven organization with a solid training and mentoring program may be quite agile when dealing with changes in personnel, but it is unlikely that it will be agile in response to changes in the customer's needs. Similarly, an XP organization may be quite agile when the customer's needs change, but the level of automation and uniqueness of their process may make them less agile in dealing with changes in personnel. For these reasons, we must ask, "What kind of agility do we need?"

2.4. Agility Is Not an End State

As Jim Highsmith says, "Agility isn't a one-shot deal that can be checked off the organizational initiative list. Agility is a way of life..."[5] Although a number of different agile methodologies have been specified and successfully deployed, it is important to acknowledge that there is no single methodology that is optimal for all organizations. Specific details of the process that is optimal for your organization depend on a wide variety of characteristics such as

  • The capabilities of your engineers,

  • Your customer's needs,

  • The relationship the engineering team has with other internal organizations like marketing and project management,

  • The physical environment your engineers work in, and

  • The technology in which you are developing.

In fact, as with plan-driven organizations, mature agile organizations are always looking for ways to improve the functioning of their team by modifying their development process. As an example of this maturity, in the first edition of Kent Beck's eXtreme Programming eXplained[2], he espoused XP as a specific methodology in the way he had originally developed it. The book specified exact details such as iteration length and recommended adoption of all of the basic practices without exception. By the second edition[3], Beck had more experience with more organizations, and he wisely revised that philosophy to allow organizations to tailor XP to their needs and capabilities. The goal of every quality software engineering organization is to mature to the level that allows the local optimization of their process.

Optimization of one's development process requires the ability to

  • Detect problems,

  • Weigh changes that could reduce or eliminate those problems,

  • Make the optimal change, and

  • Measure the effect of the change you made to ensure that the result was an improvement.

Although almost everyone in an organization will be able to list the problems, actually making the change can be very complex. With a list of problems and potential solutions, selecting a problem to address is not a trivial challenge. Process problems are often detected by different parts of the organization with differing interests. For example, marketing may be concerned with the ability to deliver functionality by a given date, while engineers might be concerned about a growing backlog of defects. In situations like these, the solutions to the problems can actually compete because addressing one problem may aggravate another.

The source of this tension may be that there is no common understanding of the direction of the organization. In order to make choices about which problems to address, we need to understand the goal of the entire organization (not just development) and weigh potential solutions against that goal. In Chapter 4, "Phase 2Measuring the Process," we will define that goal carefully and provide metrics that will help us achieve the goal. When you understand that goal, the optimal change to the process is the one that is likely to have the biggest effect on meeting that goal.