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.

I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.

This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.

Tools required:

- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- pens
- play-food could be optional to make it more fun!

Set the Stage:

Have the group split into small groups of 3, depending on class size.  I had 3 groups of 4 in this particular class.  As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back.  You can leave the room, but I stayed in the room to hear the type of conversation that is happening.

Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)

Expected result:

- ideally you will get at least 2 different orders.  In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise

Observations:

- immediately I heard conversations like “what did he mean?  does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best

Learnings:

- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
-  the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily

I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other!  I plan to try this exercise again, the feedback from the group was unanimous.  They all ‘got it’ that the point of the user story was the conversation.  I start each class with a focus question and this exercise quickly answered about half of the responses.  Most were concerned about the story missing details, how can I write better stories for the team etc.

Would love to hear your thoughts!