A Retrospective Training Workshop
Update: Added retrospective result example
I learned by favorite team building exercise on the ROOTS conference in Bergen three years ago. Alistair Cockburn conducted a great workshop that really drove home the lessons of iterative development at the same time as it showed a very useful technique for conducting retrospectives. I have later conducted the same exercise as a workshop in different situations. Maybe the most fun occasion was Oslo XP Meetup March 2006
The workshop works like this: The participants are divided into teams of six or so. It works best with about four or five teams. Each team is further subdivided into “developers” and “customers”, which sit apart during the workshop. When the exercise begins, the “customers” will be given a picture on a piece of paper. They are to describe the picture to the developers using only written instructions. Only one “customer” can visit the “developers” at any time. The teams are given five to ten minutes to plan their work before the exercise begins. Then they are given ten minutes to complete the first picture. After they have completed the picture, the “customers” and “developers” join together to do a quick retrospective for the next round. The exercise is then repeated.
For example: Consider if you were on the “customer” team, and got the following picture:
Example “picture” - how do you “specify” this using only written requirements?
Just to add to the cruelty: Yes, that is Arabic writing. Usually, my hand-outs are easier than this.
Oslo XP Meetup Team One prepares
Alistair’s retrospective is very simple: Divide a piece of paper (or even better: A flip-over) into three areas: “Keep these”, “Try these”, and “Ongoing problems”. The team brainstorms items for each category and decides on a reasonable number of things to try for the next iteration. 
Common themes
The retrospectives workshops seem to have a few very usual results. Most interestingly, the teams always seem to improve enormously between the first and the second exercise. Completing the picture in time for the first exercise is very unusual. Completing the second picture is very common, even when I use a more complex picture for round two. This is a real eye opener to many. Even if you expect iterative development to be effective, most people don’t expect the degree of learning that goes on in such an experience.
Oslo XP Meetup Developers wait for requirements
One of the most marked issues plaguing round one is that the “developers” are left waiting for requirements for a very long time. The customers very often try to get good requirements. As a result, half of the is idle for much of the time. There are also a few tricks that always always emerge when it comes to how to convey a picture, most of which I will not reveal here, in fear of ruining the exercise for my readers. But look for coordinate systems, item numbering, and metaphors. (Especially metaphors that are so obvious that they don’t even seem like metaphors) Finally: The “customers” always want to “help” the “developers” with their process:
“Work separately! Left half: Circle, not spiral!”
Material
I have material like example drawings and an instruction presentation if any of my readers want to try this exercise out for themselves. I am not going to post the material on my blog in fear of spoiling the fun for any of my readers who would like to participate in the exercise. But if you contact me, I will send you the material (for free, of course). Or even better, you can ask me to hold the workshop for you. I would love to get the chance to play again.