Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

 

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

Software Testing
Magazine


The Scrum Expert