CHAPTER 0 | UNKNOWABLE AND INCOMMUNICABLE | 1 |
Figure i-1 | One arc and an arc pair | 4 |
Figure i-2 | Arcs forming a face | 4 |
Figure i-3 | Apple cores? | 4 |
Figure i-4 | Complex circle | 4 |
Figure i-5 | Yin and yang | 6 |
CHAPTER 1 | A COOPERATIVE GAME OF INVENTION AND COMMUNICATION | 27 |
Figure 1-1 | Different categories of games | 31 |
CHAPTER 1.1 | A COOPERATIVE GAME OF INVENTION AND COMMUNICATION: EVOLUTION | 47 |
Figure 1.1-1 | Some of the rewards for the Development Game (Cummins 2003) | 51 |
Figure 1.1-2 | Flow of decisions on a software development project, showing types of decision made and highlighting feedback loops | 59 |
CHAPTER 3 | COMMUNICATING, COOPERATING TEAMS | 105 |
Figure 3-1 | Two people pair programming | 108 |
Figure 3-2 | Two people sitting at opposites sides of the room | 108 |
Figure 3-3 | Pair programming and working across a partition | 109 |
Figure 3-4 | Energy and information moving through a barrier complex | 110 |
Figure 3-5 | Gas canisters (or people) in three different configurations | 110 |
Figure 3-6 | Hall with information radiators | 115 |
Figure 3-7 | Status display showing completion level and quality of user stories being implemented | 115 |
Figure 3-8 | Large information radiator wall showing the iteration plan, one flipchart per user story | 116 |
Figure 3-9 | Detail of an XP task signup and status for one iteration (nicknamed "Mary Ann") | 116 |
Figure 3-10 | Reflection workshop output | 117 |
Figure 3-11 | Graph showing growing completion | 117 |
Figure 3-12 | The RoleModel Software team at work | 119 |
Figure 3-13 | The "caves and common" room layout used at RoleModel Software | 120 |
Figure 3-14 | Effectiveness of different modes of communication | 125 |
Figure 3-15 | Two people working at a shared, sticky information radiator | 127 |
Figure 3-16 | Dynamic and static information radiators at work | 127 |
Figure 3-17 | An average team working to pull toward a goal on the right | 130 |
Figure 3-18 | A slightly better aligned team | 130 |
Figure 3-19 | Four organizational paradigms | 135 |
CHAPTER 3.1 | TEAMS: EVOLUTION | 143 |
Figure 3.1-1 | Completed office layout (Courtesy of Ken Auer, RoleModel Software) | 145 |
CHAPTER 4 | METHODOLOGIES | 147 |
Figure 4-1 | Elements of a methodology | 150 |
Figure 4-2 | The three dimensions of scope | 155 |
Figure 4-3 | Scope of Extreme Programming | 156 |
Figure 4-4 | Scope of Constantine & Lockwood's Design for Use methodology fragment | 156 |
Figure 4-5 | A project map: a low-precision version of a project plan | 159 |
Figure 4-6 | An Actors-Goals list: the lowest-precision view of behavioral requirements | 160 |
Figure 4-7 | A Responsibility-Collaborations diagram: the low-precision view of an object-oriented design | 161 |
Figure 4-8 | Using low levels of precision to trigger other activities | 162 |
Figure 4-9 | Work expands with increasing precision level (shown for use cases) | 163 |
Figure 4-10 | Reducing fluctuations over the course of a project | 164 |
Figure 4-11 | Successful serial development takes longer (but fewer workdays) compared to successful concurrent development | 164 |
Figure 4-12 | Serial development | 165 |
Figure 4-13 | Concurrent development | 166 |
Figure 4-14 | Keeping upstream activities more stable than downstream activities | 167 |
Figure 4-15 | Role-deliverable-milestone view of a methodology | 168 |
Figure 4-16 | Effectiveness of different communication channels (repeat of Figure 3-14) | 183 |
Figure 4-17 | Effect of adding methodology weight to a small team | 184 |
Figure 4-18 | Effect of adding methodology weight to a large team | 185 |
Figure 4-19 | Documentation is not understanding, process is not discipline, formality is not skill | 189 |
Figure 4-20 | The five Smalltalk programmers feeding work to the one DBA | 190 |
Figure 4-21 | Bottleneck station starts work higher on the completeness and stability curve than do nonbottleneck stations | 191 |
Figure 4-22 | Reduced effectiveness with increasing communication needs (methodology size) | 194 |
Figure 4-23 | Characterizing projects by communication load, criticality, and priorities | 196 |
Figure 4-24 | Small methodologies are good but run out of steam | 198 |
CHAPTER 4.1 | METHODOLOGIES: EVOLUTION | 207 |
Figure 4.1-1 | Nested-cycle model of an agile process | 212 |
Figure 4.1-2 | The cycles unrolled | 212 |
CHAPTER 5 | AGILE AND SELF-ADAPTING | 217 |
Figure 5-1 | Sample poster from reflection workshop | 237 |
CHAPTER 5.1 | AGILE AND SELF-ADAPTING: EVOLUTION | 241 |
Figure 5.1-1 | The graphical argument that constant refactoring is less expensive in the long run and extends a system's life span | 250 |
Figure 5.1-2 | Ten critical factors in project success | 253 |
Figure 5.1-3 | Role of the project manager in modern agile projects | 254 |
Figure 5.1-4 | The old view of a one-dimensional spectrum of discipline between cowboy coding and plan-driven | 255 |
Figure 5.1-5 | A more accurate view shows discipline and flux as separate dimensions. Agile development occupies the high-flux zone and permits a varying amount of discipline | 255 |
Figure 5.1-6 | Some groups cannot use highly productive strategies because those strategies require more tolerance for ambiguity and uncertainty than the groups can manage | 256 |
Figure 5.1-7 | Starfish diagram showing the shifting home territories of agile and plan-driven development (from Boehm 2003) | 259 |
Figure 5.1-8 | Different projects call for different amounts of planning (after Boehm 2002, 2003) | 267 |
Figure 5.1-9 | Decision "inventory" shown on software projects of different types (thanks to Kent Beck) | 271 |
Figure 5.1-10 | Cumulative flow graph for a software project used to track pipeline delay and queue size. The original caption was "CFD showing lead time fall as a result of reduced WIP" [WIP = work in progress] | 272 |
Figure 5.1-11 | Sample earned-value chart (showing progress lines, not financial lines) | 278 |
Figure 5.1-12 | Equivalent burn-up chart | 279 |
Figure 5.1-13 | The vertical axis of the burn-up chart converts to a compressed view of project status | 280 |
Figure 5.1-14 | Four projects with different strategies and status | 281 |
Figure 5.1-15 | Four projects with varying progress and cost status (courtesy of John Rusk) | 282 |
Figure 5.1-16 | Full program status for a program involving three applications sitting on a common architecture | 282 |
Figure 5.1-17 | Detail sheets for two projects with different strategies and status | 283 |
Figure 5.1-18 | Growth in estimated number of user stories needed to complete the project | 286 |
Figure 5.1-19 | A way to track projects' use of the agile ideas | 307 |
CHAPTER 6 | THE CRYSTAL METHODOLOGIES | 335 |
Figure 6-1 | The Crystal methodologies are named by color | 338 |
