XPlorations

One thing coaches do is help teams get better at the skills they need. By practicing a skill in a focused way, the team is better able to use the skill in real situations. This fits nicely with the notion of XP practices as etudes. In music, an etude is a piece of music written to help a student improve one particular skill (for example, playing in octaves or doing trills). Then when the student needs the skill while playing a real piece, the new technique feels natural.

Teams may have a lull time, perhaps after planning is done, during lunch, or on a Friday afternoon. You might want to try a game or exercise at that time. I usually try to pick an exercise relevant to the team’s situation.

Booster Shots

One easy thing to do is pick a simple skill and create an exercise that reinforces it. 

• Planning: Have the team chart out the planning process, and test their understanding with some "what-ifs."
• Test-First: Provide tests, and let them write the corresponding code. Or have the team write both code and tests, perhaps under a rule such as "no code without a failing test."
• Refactoring: Give the team some code, and ask them to apply certain refactorings, step by step out of Martin Fowler’s Refactoring catalog.
• Pairing: Try switching typists every three minutes during an exercise. Push things further than you would in real life, so you get a sense of what "too far" is.

It's usually best to not try these on "live" stories or code. Instead, make your exercises set up microworlds, where some aspects are true to life, but where it’s safe to make mistakes.

Coming to Terms

After a few weeks with a group, you’ll hear terms being used differently by different people, as the team develops its sense of how it works. One exercise that tries to address this works like this: write a term or phrase on the board and ask questions.

"Tested"

• Does the code have unit tests for all functionality [Would it ever not? What about …?]
• Was the code written test-first?
• Would developers have talked to QA about any special tests or cases?

"Checked in"

• Does this mean everything compiles?
• Does this mean it ran on the developer's machine?
• Did it run on the integration machine (or in the integration environment)?

"Done" (for a task)

• Does the task have implemented all the features it should?
• Is everything tested?
• Is everything refactored?
• If the requirements don't change, would we need to modify the code?
• [Does "done" mean "done"?]

"Done" (for a story)

• Are all aspects of the story done?
• Is the code as refactored as possible?
• Is there an acceptance test?
• Do all acceptance tests for this story pass?
• Have we explained to the customer (or QA, etc.) how everything works?

You want to find out things like, "Would you ever check in without running the tests?" You’ll find different people have different answers. By forcing the team to confront these inconsistencies, you can help them achieve consensus on how things work.

Coding Standard

One team I know of agreed to evolve to a compatible style but didn’t choose a particular coding standard in advance. They developed for several iterations without a coding standard.

As an exercise, I put together a list of about a dozen "style scenarios," usually with multiple choice answers. Each scenario got two answers:

• What is the team’s consensus style? (Allow "none" as an answer.)
• What do you wish the style was?

For example:

In what order do "using" statements appear?

A.     System ones then ours

B.     Ours then system ones

C.     Either order is acceptable

When the "then" clause of an if statement has only one line, should it be enclosed in braces?

A.     Yes

B.     No

C.     Either way is acceptable

Going through these questions revealed places where the team didn’t agree on a style, and let them agree on styles when they could.

Debrief

There’s a saying in simulation circles: "The simulation is the excuse for the debrief." It’s not enough to "do" an exercise. You need to build in time to debrief.

The debrief helps the team draw its lessons explicitly, and helps them agree on what the lessons were. It offers insight into what misconceptions or issues remain, and it serves as a chance for team-building.

Conclusion

Some lessons can be drawn from normal work and retrospectives. Other lessons may be learned faster by a targeted exercise. If you use an exercise, be sure to debrief it so the team shares an understanding of what it has learned.

[Written June, 2002.]

Copyright 1994-2009, William C. Wake - William.Wake@acm.org