| Communication relies on context as well as message. This paper discusses the thinking behind things XP team members say. |
Introduction
XP teams have their own way of doing certain things. Part of this reality is that there are certain things you’ll hear an XP team say that have special meaning.
One way to look at what people say is to consider whether the statements are true or false. But there’s another approach to evaluating speech known as speech act theory, with roots in the philosophy of Wittgenstein. (See Terry Winograd and Fernando Flores’ Understanding Computers and Cognition [Addison-Wesley, 1995, ISBN 0-201-11297-3], for an introduction.)
Speech act theory views statements as moves in a language game. Some moves are requests for action, others are statements of fact, and still others are declarations. Declarations are an interesting case; they’re statements where the act of making the statement makes it true. For example, a minister saying, “I now pronounce you husband and wife” makes it true by the statement.
In XP (or any team), there are speeches that represent important events. This article looks at some statements that people make, considering exactly what they mean. They don’t necessarily logically imply their full meaning, because they rely on a team’s shared understanding.
1. Customer (to team): “Here’s a new story.”
This means:
- I (the customer) have a new requirement.
- I’ll write a few sentences on a card as a reminder for us.
- I’m prepared to discuss this with you in more detail later.
- I understand my requirement well enough that I could specify a test that would assure me the implementation is correct.
As you can see, a simple statement is more than a truth about the world; it’s also a web of promises and understanding.
2. Programmer (to customer): “We estimate this story…”
“We estimate this story to be a 1 (or a 2 or a 3).” This means:
- We’ve based our estimate on what you’ve said, any tests you’ve shown us, any experiments we’ve done, and on our knowledge and experience.
- The estimate is relative to other estimates we’ve made.
3. Programmer (to customer): “Could you split this story?”
This means:
- We don’t feel confident enough to make an estimate because the story is too big.
- We know programmers don’t always do so well at splitting stories in a way that maximizes value, and we know you’ll be happier if you split it your way.
4. Programmer (to customer): “Our velocity is n points per iteration.”
This means:
- Without real experience, we’ll give you our best guess or estimate.
- We know you understand that the real velocity could be different from this estimate.
5. Programmer (to team): “Our pair is going to integrate.”
This means:
- Don’t rely on the mainline code for a while, as it will be unstable while we change it.
- We won’t take too long.
- If we can’t integrate successfully, we’ll put the mainline back the way it started.
6. Programmer (to team): “Is anybody integrating?”
This means:
- We’re seeing something funny; is someone in mid integration?
-or- - It doesn’t seem like we’re integrating enough today.
- etc.
7. Programmer (to team): “We’re done integrating.”
This means:
- It’s safe to fetch the latest version again.
- Unit tests are running at 100%.
- Let us know if you have any questions about the things we changed.
8. Programmer (to team): “This task is done.”
This means:
- We believe that the code needed for the task is present and working properly.
- We built tests for the code we added.
- We refactored to make that code as clean as possible.
- We’re free to start another task, or help anybody who needs it.
9. Programmer (to customer or whole team): “We’re done with this story.”
This means:
- All tasks for this story are complete.
- Any customer-defined tests are implemented and working.
- We’ll show this feature to the customer and make sure they think it’s done too.
10. Customer (to team): “This story is done.”
This means:
- This feature is working the way we expected.
- Please move on to the next story.
- If we want this to work differently in the future, we know it’s a new feature to negotiate.
Conclusion
Speech is not just a series of propositions; it’s a tool that creates shared understanding. We’ve deconstructed some typical statements to see the promises and declarations that underlie them.
[Written February, 2002. This article is available in the articles section at http://www.informit.com as part of a feature on agile methods. Navigate to Home > Articles > Software Engineering > Agile Computing. (Sorry, I can’t give a direct link as their URLs use session IDs.)]