Extreme Programming Explained, Second Edition: Week 4

This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters six and seven in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters six and seven explore the practices that operationalize the values and practices we have explored in previous installments.

Chapter 6: Practices

Practices are the mechanism for applying an idea or method. While values and principles provide the why, practices deliver the how. In Chapter 3 we described the relationship as a bridge between two cliffs; values on one side, principles as the bridge and practices on the other side. Linking practices through principles to values is a nice metaphor to illustrate that all three components are needed to ensure that practices don’t become rote and lose value.

Chapter six provides a transition from the high level to the pragmatic. In this chapter, Beck notes that the practices represent endpoints that need to be pursued using “baby steps” (one of the principles we identified in chapter 5). XP, like most other methodologies, provides the most value if all of the practices are practiced together; however, teams and organizations implementing XP can get value by implementing the practices one at a time.

Chapter 7: Primary Practices

The primary practices are the foundation of XP. The primary practices are not the whole of XP, Chapter 9 builds on this foundation introduced in Chapter 7 with corollary practices. The primary practices are:

Sit together. Sitting together helps people interact and work together. Death to cube farms that keep people apart. Teams need both a collaborative space so they can talk and interact and private space so that individuals can focus when needed. This simple practice is one of the most difficult for most organizations. Distributed teams can’t sit together, and even when teams are collocated it is difficult to find the right balance between togetherness and alone time. Creeping up on getting people to sit together (Beck’s words) is a good idea so that teams can find the right balance. Recognize that the balance can change based on team composition and the type of work being tackled.
Whole team. Use cross-functional teams that include all the skills and perspectives necessary for the project to succeed. Recognize that the definition of what constitutes the whole team is dynamic. Teams in XP include whole people; fractional people are a bad idea because of the huge productivity penalty caused by task switching.
Informative workspace. The workspace is not just a shell to hold people, but should also be part of telling the story of the work to the stakeholders and the team members. Story cards hung on the walls, lists of team norms and other big information radiators show the team’s goals and their progress.
Energized work- Team members should work as many hours as they can be productive and only as many as can be consistently sustained. During one stretch of my career, I worked 80 or more hours a week to keep up with a colleague nicknamed DEFCON Don (he was an ex-missileer).While the competition was fun, I am not sure our productivity was as high as it could have been if we work a more reasonable schedule. Beck puts it succinctly,
“Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”
Pair programming. Pair programming is easily one of the most controversial practices in XP. The practice of pair programming occurs when two people and one keyboard collaborate on programming. Typically one person talks and watches while the other types, rotating roles frequently. This practice can be useful for most any function including analysis, design, and testing. When pairing, rotate pairs frequently, respect culture, personal space, respect personal hygiene rules and don’t pair if you have the flu!
Stories. Plan work using user stories, which are units of customer-visible functionality. The concept of the user story shifts the discussion of needs away from the permanence and obligatory nature of the word requirement. Estimate user stories as soon as they are written to provide the business and technical perspectives a chance to interact while the story is still top of mind. User stories have migrated into almost every Agile implementation.
Weekly cycle. XP suggests planning work a week at a time. While Scrum has settled roughly on a two-week cycle, XP recommends re-planning every week. The use of a single week ensures that teams break work into small chunks and generate feedback quickly. XP’s work cycle begins by writing tests followed by coding and finally running the tests to prove the solution. The cycle repeats until the tests are passed. XP introduced the concept of the planning meeting now used in Scrum. The weekly heartbeat gives you a convenient, frequent and predictable platform.
Quarterly cycle. Plan work a quarter at a time. The quarterly cycle allows the team to reflect and consider the big picture so they stay aligned with larger organizational or program goals. The quarterly cycle is very much akin to the planning increment in SAFe.
Slack. Teams require slack to deal with issues that will invariably pop up. Overcommitment causes waste as teams are stressed to make up time by pushing too hard or cutting corners. The innovation sprint in SAFe is an example of planning slack into the process.
10-minute build. Build the whole system and run all of the tests in 10 minutes. The concept of the 10-minute build is that builds that take substantially longer will be done less often, reducing the chance for feedback.
Continuous integration. Integrate all changes into the whole application after no more than a couple of hours. Continuous integration provides feedback to prove that the system works. Beck recommends using synchronous builds in which all team members commit their code to the build at specific times. The build is then tested, and if it passes coding begins anew (if not, a fix is needed). Teams often begin with asynchronous builds because they require less coordination and then evolve to synchronous builds.
Test-first programming. Test-first programming is a powerful practice that begins by writing the tests that the developer will use to prove they have solved the business problem. Test-first programming reduces scope creep, increases technical cohesion, trust, and rhythm. I have found that test-first development also helps to ensure that testers, business analysts, and developers collaborate.
Incremental design. Invest in the design every day using the knowledge that was gained the previous day as a mechanism, so the design continually evolves based on need. Incremental design is a form of real options theory. Making small decisions helps reduce the cost of change and allows decisions to be made closer to the point of need.

The 13 primary practices provide the foundation for the practice of XP. Even if an organization is not practicing XP, many of the primary practices are used to augment less technical Agile frameworks, such as Scrum.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 -5