Section 1.5. Outline of This Book

1.5. Outline of This Book

To give a solid foundation for the transition, Chapter 2 broadens the definition of agility beyond the traditional definition and provides a justification for the transition this book advocates. It also gives a brief overview of agile values because agile teams are generally structured and managed differently from plan-driven organizations. This overview is for background information only and refers the reader to other texts on this topic.

Chapters 3, 4, and 5 define the three phases of the transition toward agility.

Chapter 6 provides a topical index into the process innovations, which are grouped by the part of the process they affect. The goal of this chapter is to compare and contrast the process innovations that address similar issues. One of the risks of this strategy is that various parts of your process might be interconnected in a way of which you are unaware. For example, in XP, pair programming is an essential part of code review and a mechanism for communication. However, without team ownership of code, pair programming can only be applied in a limited fashion. Therefore, as you begin to refactor your process, it is important that you look for the broader effects that your change may cause. Chapter 6 is designed to help you find those relationships.

Chapter 7 defines the process smells and possible process innovations. Because each smell is really a symptom of an underlying problem, there is not a one-to-one mapping from smell to process innovation. This chapter suggests process innovations based on the suspected underlying cause of the smell.

1.6. References

[1] Auer, Ken, and Roy Miller, Extreme Programming AppliedPlaying to Win, Upper Saddle River, NJ: Addison-Wesley, 2002.

[2] Beck, Kent, eXtreme Programming eXplainedEmbrace Change, Upper Saddle River, NJ: Addison-Wesley, 2000.

[3] Beck, Kent, "Getting Started with XP: Toe Dipping, Racing Dives, and Cannonballs," at, as of 1/7/2006.

[4] Boehm, Barry W. , "A Spiral Model of Software Development and Enhancement," Computer, Vol. 21, No. 5, 1988.

[5] Elssamadisy, Amr and Gregory Schalliol, "Recognizing and responding to 'bad smells' in extreme programming," Proceedings of the 24th International Conference on Software Engineering, ACM Press, New York, NY, 2002.

[6] Fowler, Martin, RefactoringImproving the Design of Existing Code, Upper Saddle River, NJ: Addison-Wesley, 1999.

[7] Goldratt, Eliyahu M. , and Jeff Cox, The GoalA Process of Ongoing Improvement, Great Barrington, MA: North River Press, 2004.

[8] Larman, Craig, Agile & Iterative DevelopmentA Manager's Guide, Upper Saddle River, NJ: Addison-Wesley, 2004.

[9] Poppendieck, Mary and Tom Poppendieck, Lean Software DevelopmentAn Agile Toolkit for Software Development Managers, Upper Saddle River, NJ: Addison-Wesley, 2003.

[10] Royce, Winston, "Managing the Development of Large Software Systems," Proceedings of IEEE Wescon, 1970.

Chapter 2. What Is Agility?

    Section 2.1.  Agility Is Not Binary

    Section 2.2.  How Much Agility Is Realistic Today?

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

    Section 2.4.  Agility Is Not an End State

    Section 2.5.  Agile Values

    Section 2.6.  Agile Teams

    Section 2.7.  Agile Management

    Section 2.8.  References

2.1. Agility Is Not Binary

Currently, processes are divided into two distinct categories: agile and plan-driven. Each has a community, a variety of practices, and a list of successful applications of those practices. With a few notable exceptions, there is very little overlap between these categories. This gives the appearance that agility is a binary attribute. However, agility is not an all-or-nothing affair that we can achieve through a single change in the development process.

Instead of asking, "Are we agile?" and trying to initiate a single, dramatic process change that will "achieve" agility, a more appropriate perspective focuses on "To what degree are we agile?" Within its community, agility has been defined as "the ability to both create and respond to change."[5] We can answer this question by measuring the length of time between a requirement change and when we deliver the updated functionality to a customer. This length of time is known in Lean Software Development as cycle time.

Figure 2.1. Apparent distinction between agile and plan-driven methods

Agile methodologies have been designed to have very short cycle times when compared with plan-driven methodologies. In general, agile methods advocate releasing new functionality in fixed-length iterations, and the iteration length defines their cycle time. This is the most significant difference between agile and plan-driven methods: agile methods have a fixed cycle time that is relatively short, which lets the team adjust to changing customer needs rapidly.

Plan-driven (and ad hoc) methodologies define the length of time between releases by the functionality they want to be included in the release. As a result, releases are not of a fixed length, so they do not have a consistent cycle time. However, as a starting point, every process has a (possibly variable) cycle time and therefore some (possibly low) degree of agility.

With this perspective, agility is not a binary attribute and does not mandate a dramatic change in your process today. The current process has some degree of agility (though it may be slow and unstable) and defines a starting point on the path to improved agility. The challenge is to maximize the strengths of the current process and to make changes to that process in a disciplined manner with specific goals in mind.