Click here to view the complete list of archived articles

This article was originally published in the Winter 2002 issue of Methods & Tools

---

Extreme Programming as Nested Conversations - Page 3

William C. Wake, http://www.xp123.com

Day-Scale Conversations: Daily Activities

The team begins its day with a stand-up meeting. (This practice was adapted from the Scrum process.) The team stands in a circle, and each person takes a minute to tell what they did yesterday, what they plan to do today, and what’s in their way. (If they need help, they can ask for a followup meeting.)

About halfway or two-thirds through the iteration, the team should do what Ward Cunningham calls a "Sanity Check": "Are we on track? Will we finish the stories we planned? Do we need more stories?" If the team is behind, they may need to re-negotiate the iteration plan with the customer: defer a story, choose a simpler one, etc. (These adjustments – dropping or adding stories – are what allow velocity to change from iteration to iteration.)

After the standup meeting, the team will break into pairs – groups of two. XP specifies that production code will be implemented by pair programming, for immediate design and code review. (See Pair Programming Illuminated.)

The pair selects a task, and works on it together. Periodically, they integrate their work into the main body of code, or pick up what others have integrated. After a couple hours, the pairs may swap around.

At the end of the day, the pair will integrate one last time. If they’ve completed a task, they’ll mark it off. (Very rarely, they may decide they’re on a wrong track, and abandon the last bit of work.)

Several things enable such flexible teamwork:

1. The team has daily standup meetings and sits together, so everybody has some idea of what everybody else is up to.
2. The team owns the code jointly; any pair can change any code it needs to.
3. Each pair integrates its work into the mainline many times per day.
4. The mainline is kept working: no code is checked in that causes a regression in the tests.

Key Points – Day-Scale Conversation The day starts with a standup meeting. Pairs form and shuffle during the day. Code is integrated into the mainline many times per day. The mainline is kept in a working state.

Hour- and Minute-Scale Conversations: Programming

The programmers talk to each other, and the customer, as they work on their task.

There is also a "conversation" with the code. XP uses a development style known as test-driven development. You’ll hear many different words and phrases associated with this technique: simple design, test-first programming, refactoring, green-bar/red-bar.

To create a new feature, the programmer writes a new, small, "programmer" test for part of the feature. The test fails, of course, since the feature doesn’t exist yet. So the programmer implements the feature in a simple way to make the test pass. Then they refactor (systematically improve the design) to remove any duplication and leave the code communicating as well as it can. The whole cycle repeats until the feature is completely added. Each trip through the cycle takes a few minutes.

At the end of a session, the program will have a new feature, and an automated set of programmer tests that demonstrate it. The code and tests go into the mainline, and the team will keep both the feature and the tests working while other code is added.

Programmers have found that this style yields programs with decoupled and encapsulated designs, and the code is known to be testable (as it has been demonstrated).

Key Points – Hour/Minute-Scale Conversation The programmers and customers talk to each other during the day. Programmers have a conversation with the code: test, code, refactor. This creates new features and automated programmer tests.

Beyond the Mechanics

The description above represents a starting point for a team’s process. Real teams will evolve their process over time.

Teams have found that there is a synergy in the XP practices. They support each other, so you can’t just pick and choose without finding some new practices to balance the missing ones.

Many teams have found that adding a regular retrospective is helpful: it builds in time to reflect on how things are going and how they can be improved.

Conceptual Frameworks

We’ve looked at XP from the "mechanical" side; now we’ll consider its underpinnings from some other perspectives:

• Values and practices
• Agile methods
• Self-organization at the team level
• Empirical vs. defined processes
• Emergence at the code level
• Lean Manufacturing

Values and Practices

The first XP book, Extreme Programming Explained (by Kent Beck), introduced a framework of "values" and "practices" for describing XP. Values are more fundamental; practices are activities or skills that are compatible with the values, and form a starting configuration of team skills.

The values:

• Communication
• Feedback
• Simplicity
• Courage

The practices:

On-site customer Planning Game Metaphor Short Releases

Testing Continuous Integration Collective Ownership Forty-Hour Week

Pair Programming Simple Design Refactoring Coding Standards

(Most of these practices were worked into the description of the mechanics described in the first part of this paper. There are other lists of practices that use different words to explain the same themes.)

Agile Methods

Extreme Programming is an example of what are known as agile methods. Some others include:

• Scrum (www.controlchaos.com): This is probably the most philosophically compatible with XP. Scrum uses one-month iterations, and its own approach to planning. It allows for large projects via a "Scrum of Scrums."
• Crystal Clear: "Management by milestones and risk lists." Crystal Clear is the simplest in a family of methods.
• FDD (www.featuredrivendevelopment.com): Plan, design, and build by feature, in a model-driven approach supported by a chief programmer.
• DSDM (www.dsdm.org): Model and implement through time-bound iterations. (DSDM is an outgrowth of earlier RAD approaches.)

See www.agilemanifesto.org for a manifesto and principles statement from a number of leaders in agilemethods, and www.agilealliance.com for the home of the Agile Alliance.

Self-Organization of the Team

Among agile methods, XP and Scrum stand out as relying on a team to organize itself. This flows from the team taking on responsibilities. It’s also due to the lack of built-in role specialization. XP teams value specialized skills; but they don’t pigeonhole people into having only one aspect. (Database programmers who want to learn some GUI programming can pair with someone who has more experience.)

The team takes responsibility: the team accepts stories, and the team finds a way to do them. In most XP teams, individuals accept tasks. Even so, they’re understood to have the full support of the team. If they ever need help, they ask, and it will be given.

The physical environment encourages self-organization too. When people sit together and eat together, they build bonds and realize, "We’re in this together," and "What affects you affects me."

Defined and Empirical Processes

(Scrum brings this vocabulary into play as well.) Consider making cookies. You have a recipe, and you follow it. If you make another batch, with the same ingredients, in the same proportion, in the same oven, you expect to get the same result. This is an example of a defined process.

Consider instead the process of creating a cookie recipe. The value comes from its originality. You might try a number of variations, to get just the right result. Iteration is inherently part of the process; this is an empirical process. (Reinertsen, Managing the Design Factory, suggests the cooking example.)

Software development tends to be an empirical process: the goal is not to get the same result a team got earlier, but to create something new. Experimentation is a critical part of this, not a failure.

In spite of the concrete description in the first half of this article, XP is in the "empirical" camp. It accepts that there will be experimentation on all levels, including experiments about the process itself.

Page 2   Page 4    Back to the archive list