Spec Writing Game

You’ve been redirected to SolutionsIQ.com. BigVisible and SolutionsIQ have joined forces, and–lucky you!–you still have access to all of that awesome content. Dig in.

Several people have asked for the hand outs to support the “spec writing game“, so I want to make those available to everyone. Let me offer a few guidelines for those of you who may choose to run the exercise

#1 – Take your time introducing the rules, it goes a long way towards making sure everyone knows what they are doing.

#2 – the Game works best when you have more than 4 people per team. With such small teams you are deprived interest dynamics of multiple people trying to work together (or not). Having a sole spec writer or developer introduces very different dynamics.

#3 – Give each team a little time before they start to organize themselves, this will usually lead to some interesting insights and may help them develop more innovative ways to work together. Remember, some people will really excel at this game and show powerful techniques to communicate and get feedback.

#4 – The instructions say 12 minutes, but I have found you can do it in shorter periods, as quickly at 5-6 minutes. However, a longer time period lets people get closer to a product and allows you to observe more behaviors (both good things).

#5 – While the facilitator doesn’t have much to do during the actual game, there are several things to observe and watch

  • How long does it take for the first spec to get to the development team (sometimes this can be as last as halfway through the round)
  • How much detail is in the first specification
  • Do teams try to split apart work. Some spec writing groups will write 3-5 sets of instructions at the same time, one for each element to be drawn
  • Do the analysts linger and watch what the developers do, or do they simply go back to their table
  • Once the specification has been completed, what do the spec writers do?
  • How do teams deal with confusion and mistakes?
  • Do the developers use things like component based construction (I have seen stickies or pieces of paper put together) or set-based development (I have seen teams drafting 3+ versions of the diagram at the same time, where they periodically throw out the ones that aren’t working and copy the one that the analysts say is closest)
  • Do the developers ever write questions for the spec writers?

As you can see, there is a lot to watch for. This is a great exercise, and is most effective when you do it with an actual team. Its especially fun to make non-technical people be “developers” and make the actual developers be “spec writers”. My one caveat would be to make sure you leave enough time for a proper debrief. Share your observations, ask teams what their experience was like, as people for specific things they did that were either particularly effective or ineffective.

I must acknowledge that I did not develop this game, but my search to find the original creator has been fruitless. This is the oldest reference I can find, so let me give some credit to the Scrum Trainer’s Gathering in 2008, as this is where I found it.

That’s about it. Good luck conducting this exercise and please let me know how it works out for you.

comments powered by Disqus