A Simple Collaboration Exercise to Show Why Written Requirements Don’t Work

A couple of weeks I was playing the XP Game with a client and one of the stories in the game is to blow up a bunch of balloons to a certain size and tie a knot in it. A funny thing happened. One of the more dominant personalities playing the game interpreted ‘knot’ literally and ‘added a feature’ to the balloon by taking the string provided in the game materials and tying a knot around the opening of the balloon.

They finished the story and showed it to the product owner and he couldn’t figure out why there were a bunch of strings dangling from all the balloons. A team member showed him the card that clearly said “tie a knot…” Every other time I’ve played this game people simply tie up the open end of the balloon.

This provided for some interesting discussion and “AHA!” moments from the people playing. This particular team was culturally diverse as well so language and interpretation played a role. We talked about that if it was possible for team members and product owners to be at odds over a simple word like ‘knot‘ then it’s all that more important to collaborate with each other over worrying about what the written requirement is.

Working software over comprehensive documentation is a part of the Manifesto for a reason!

For those who aren’t familiar with it, the XP Game is a 3-ish hour simulation, if you’re working with a team and can’t manage to play the whole simulation, a couple of the exercises can be done off the cuff and help demonstrate the value of collaboration quickly.

Handling Feedback

One of the most frequent questions or statements I’ve encountered doing quick simulations is that moving pennies or blowing up balloons is simple and doesn’t reflect what software development is about. This type of feedback proves the point. If people can be confused by the words in a simple task, how much MORE important is it to foster more frequent collaboration in software projects?

Sounds simple enough, however I’ve found the perceived safety and security of heavy documentation makes it difficult for teams to let go and rely on working together.

Actually, this doesn’t show that written requirements don’t work. It just shows that there’s more than one possible implementation of a set of written requirements, and I’m not seeing why that’s a concern.