Scrum Trainers Gathering (3/4): The Specification Exercise

Update: part 1, part 2, part 3 and part 4.

This is a continuation of my report from the Trainers gathering. In part 1 I gave an overview of some of the topics discussed and in part 2 I presented Boris’ Ball Point game. In this post I’d like to discuss anther exercise that was presented by Jens Østergaard . His exercise is designed to demonstrate the difficulties encountered when trying to interpret a written specification.

In this team-based exercise, each team is divided into “Developers” and “Spec-writers.” The “Developers” are separated from the “Spec-writers” and only allowed to communicate using written specifications. “Spec-writers” are then presented with a diagram that they need to communicate to the “Developers,” who, in turn, must interpret the written specifications and reproduce the diagram. The exercise is run twice with two different diagrams and a retrospective is held at the end of each run.

I found the exercise to be fun and exciting, especially when the “Spec-writers” observed how the emerging product differed from their vision and tried to race specification updates to the “Developers” before time expired. Twelve minutes does not feel like nearly enough time.

This exercise nicely illustrates a number of points. It show the difficulties that the “Developers” have understanding the written specifications and the importance of verbal communication in communicating a vision. It also demonstrates some of the difficulties that teams have when there is a separation between the “Spec-writers” and the “Developers.”

The Exercise
Jens’ posted a description of the exercise on the Scrum Trainers email list. I’ve edited his description for clarity. The total time for the full exercise is about 30 minutes which makes it ideal for a lunch break.

  1. Find two “Developers” in each team. (Jen’s comment: “I usually do that by asking who is a PM or non-developer since I want them to feel how hard it can be to understand a specification.”)
  2. The rules of the exercise are:
    • a) The originals can not leave the room.
    • b) Specifications must be written. Diagrams, symbols and numbers are not permitted.
    • c) As many specifications as desired can be delivered, as often as desired.
    • d) The only allowed communication is for “Spec-writers” to hand over the written specifications to developers.
    • e) “Spec-writers” can look at what the “Developers” are doing, but not communicate verbally or with body language.
  3. Move the “Developers” out out of the room and place them so that the “Developer” teams cannot see what other teams are doing.
  4. Distribute copies of the first original to the “Spec-writers.” It’s important that the “Developers” don’t see the original.
  5. Run the exercise. Often “Spec-writers” have a hard time not communicating with the “Developers” with body language, so pay attention to this.
  6. After 12 minutes stop the teams and collect the results. Show them to class.
  7. Let the teams do a retrospective under the given rules.
  8. Run the exercise again with the second original.

Many of the lessons from this exercise are self-evident. If you feel the need for a debriefing, you may want to talk about the difficulties encountered when trying to interpret written documents and how the separation of “Spec-writers” and “Developers” greatly reduces the team’s performance. Finally, here are the diagrams needed for this exercise (link).

Bookmark and Share

8 thoughts on “Scrum Trainers Gathering (3/4): The Specification Exercise

Comments are closed.