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

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

Software is hard. It’s hard to find out what’s needed. The real requirements are hard to discover; plus, they change over time, and they change as a result of the software being created. But even once we know what’s wanted, software is still hard. It’s hard to master many details, and it’s hard to merge together the results of a team’s work.

Extreme Programming—XP—is a software development method designed to help teams create software more effectively. XP uses "simple rules" as a starting point for a team’s process. XP’s claim is that if we:

• put the whole team in a room together,
• force feedback through constant planning, integration, and release, and
• adopt a test-driven approach to programming

then the team can be highly responsive and productive.

We’ll look at XP as a series of nested conversations. You’ll see a pattern repeated at each level: explore, plan, define a test, do the work, verify the result.

Nested Conversations in XP
Month scale	Release planning, iterations, release to users
Week scale	Iteration planning, daily work, release to customer
Day scale	Standup meeting, paired programming, release to development team
Hour/Minute scale	Test, code, refactor

Three Voices

Let’s consider three situations where you might develop a program.

First, suppose you have a problem, and the resources, time, ability, and desire to write a program (and that’s the easiest thing to do). Then you may write the program to meet your needs. You may feel no need to separate roles.

Next, suppose you are a business owner and you have the resources and a need, but no ability or desire to write a program. You might hire a programmer to do it for you. It makes sense for you to distinguish your role from the programmer’s.

Finally, imagine that you have the vision and need for a program, but you’re not able to write it yourself, and you don’t have the money or resources to hire a programmer. You might convince someone else to provide the money to hire a programmer. The person putting up the money will want to be involved (to be sure the money isn’t wasted).

XP views teams as similar to this final scenario. An XP team has three sub-teams:

• Customer: Someone with needs and vision for a solution
• Programmer: Someone with the technical skill to create a solution
• Manager: Someone who provides an environment and resources for a customer and developer to work together.

The interaction between sub-teams is treated as a conversation between these roles. Underneath, each role is composed of several people, each with their own conflicts and compromises, but when they speak to the other roles, they speak with one voice.

Here, we see one of the ways XP simplifies reality. In reality, people have many skills: testing, analysis, programming, etc. But for the sake of the process, we act "as if" reality were simpler.

Key Points – Three Voices XP acts as if different sub-teams each speak with one voice. The manager provides the context for the team. The customer has a need to be addressed by software. The programmer implements the software.

The Context

Just as a choir needs rehearsal space and an accompanist, an XP team needs resources: workspace, computers, money, software, people, and so on. Management provides this context. They take responsibility for hiring, firing, space, tools, and so on. They control the flow of their investment; they may increase or decrease it.

XP asks for a special environment: a place where the whole team can sit together. Who is the whole team? It includes all the roles, but especially Customer and Programmers. Sit together means "really" together: in the same room (not in cubicles in the same building), where people can see each other. (XP is not saying a good software team can’t be split across locations; it’s saying that a team can be more productive if it sits together.)

People who are near each other talk to each other more. XP teams value communication and feedback, and collocation feeds both.

Key Points – The Context The whole team sits together.

Some Vocabulary

A release is the delivery of software, ready for use. Ideally, and usually, this is "use" by real end users, so the team gets feedback. A release is typically developed and delivered in one to three months, but some teams deliver every week or even more frequently.

An iteration is a time period during which the team develops software. Iterations have a fixed length, usually one or two weeks. Iterations are time-boxed: if a feature won’t be done as planned, the scope of the iteration is adjusted—the iteration is not changed in length.

Page 2   Back to the archive list