Timing
30 mins
Ingredients
- Supplies for each team: play dough, pipe cleaners (chenille stems)
Directions
Each team selects one Business Analyst (or Product Owner) to come to the front of the class to look at a picture of an item that the customer wants built. The BA’s are instructed to only use imperatives and similes (no ‘rhymes with’) and to not use certain words when describing the item to the rest of their team.
- In round 1, the item is something simple (such as a chair), but the BA must communicate only in writing. This should only take a few minutes for the team to create using the given supplies.
- In round 2, the item is something simple (a teapot), but the BA can speak with their team. This should show how much easier it is to communicate by speaking.
- In round 3, the BA is shown an item that isn’t as easy to communicate (a motor-cycle RV or a make-up kit built in to a computer mouse for instance). Since items like these are not common, it should be much harder to build.
Note: A quicker alternative to this game is to have teams draw the items instead of using the supplies.
Learning Points
- In software, we are rarely creating something that already exists. So we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.
Posted by Mike
I am very much in favor of activating people when learning, and preferably in a fun way.
I do think this is a nice exercise, but I am wondering to what extent we need to let people experience “In software, we are rarely creating something that already exists. So we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.”
Certainly almost every developer is aware of this, right?
Now I am wondering if this could be improved (and e.g. “Mr. Happy Face” does a better job at that) to let people experience an alternative way of working: indeed the difference in round 1 and 2 is doing that, but the overall feeling after the game will remain: we have a problem (as we already knew).
So why not have (equally difficult?) assignments where in the last round, additional iteration/feedback cycles are allowed, to show that the result is actually better? (or even continuous feedback while the team is working…)
You could even introduce economics in it, perhaps? -> e.g. cost per time unit, every time you iterate, costs additional, delivering the wrong thing will yield nothing.
If I am on the wrong track with my suggestions; please enlighten me!
cheers,
Lodewijk Bergmans
PS: especially when drawing, this is much like the party game ‘pictionary’–great fun indeed
Hi Lodewijk!
Thanks so much for your comment. I agree, many developers understand the imperfection of language to completely describe what is fundamentally an uncertain goal. The intent of this game is to illustrate that point to those less familiar with the nature of building software.
The idea of changing the game to illustrate the need for feedback in empirical processes sounds really interesting. I wouldn’t say you’re on the wrong track in any way. It is just not the path we went down when we created the game. I would be interested in hearing how this works for you. Perhaps you could even post it as a new game!
Mike