Tag Archives: exercises

Elephant Carpaccio facilitation guide

Posted on by

The Elephant Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices.

The exercise was invented by Alistair Cockburn. We’ve co-facilitated it a bunch of times and encourage people to run it everywhere.

Here’s a pretty detailed (shu-level) guide showing how to run the exercise.

Great Retrospectives

Posted on by

Great retrospectives are amazing, they have a way of really getting a team to work together and to energize them ahead of a new challenge. But even a great retrospective becomes boring and routine after a while. Luckily, there are a lot of us at Crisp working with different teams, so we got together this evening for a peer to peer exchange about retrospectives. We each got to pitch retrospective exercises and games that we’d like to try, or that we wanted to share. We ended up discussing and trying out 9 of them. Here’s a summary  in case you’d like to try some of them out at your next retrospective!

read more »

The power of open-ended requirements

Posted on by

David Barnholdt and I recently attended a 1-week PSL workshop (Problem Solving Leadership) with Jerry Weinberg, Esther Derby, and Johanna Rothman, one of the best courses I’ve ever attended. After that course we’ve been thinking about ways to make our own training courses more interactive.

David was first out and invented a brilliant exercise demonstrating the power of open-ended requirements. I built upon that idea and tried out my own variant for the first time last week, with 20 people divided into 4 teams. Here’s what we did:

Step 1 – follow open-ended spec:
Team 1 & 2 were given the task "Draw a summer meadow", Team 3 & 4 the task "Draw a christmas card". The teams were given direct access to the customer (me & Arne, my co-teacher). When they showed prototypes and asked for detailed requirements we were cooperative but gave only high-level answers such as "I want the picture to make me long for summer" or "Some more life would be nice", letting the teams figure out the implementation.

Step 2 – write detailed spec:
The teams were now asked to write a detailed specification for their picture, so that offshore teams could re-create the same exact picture as closely as possible. Due to "bandwidth cost restrictions" we only allowed written text in the specification :o)

Step 3 – follow detailed spec:
Send the spec to the "offshore team" – i.e. team 1 & 3 swapped specifications with each other, and team 2 & 4 did likewise. No communication between the teams. So now each team had to try to recreate the other team’s exact picture using only an overly detailed spec ("draw a 2.5cm wide blue cloud 2 cm under the top-left corner"….etc)

Step 4 – art gallery
All pictures up on the wall. Each person got to grade each picture (draw 1-5 dots on it) indicating which pictures they would most like to take home.

Step 5 – debrief
Not surprisingly, in 3 of 4 cases the "offshore team" pictures from step 3 were significantly uglier. See the examples below. We talked about open-ended specs vs detailed specs, and how this can impact the overall quality of the product. We also talked about how each of the first three steps felt like. Several people mentioned that they recognized the feeling (and result) from real projects they’d been in.

My conclusion:
Fun exercise! The debrief part was a bit too rushed and controlled from my part, I should have been more open-ended there (go figure…). And I might work on the timings. But everyone I talked to liked the exercise, and people referred back to it several times during the course, so I will most likely do this again!

Thanks again David :o)

So, here’s one of the examples. Guess which picture below was drawn to en open-ended spec and which was drawn to a detailed spec…