Section 2.4. Agility Is Not an End State


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.




Refactoring to Agility
Refactoring to Agility
ISBN: B000P28WK8
EAN: N/A
Year: 2006
Pages: 58

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net