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 look at a picture of an item that a customer wants built. The BA’s are instructed to only use imperatives and similes (no ‘rhymes with’) and to not use certain words (like the game Taboo) 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.
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. Without a common vocabulary, we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.
- Iterative development with demonstrations allow us to hone in on what is really needed, rather than what is asked for.
VN:F [1.9.16_1159]
Rating: 4.4/5 (10 votes cast)
What Were They Thinking?, 4.4 out of 5 based on 10 ratings Written by: Michael McCullough on June 19, 2009.
Last revised by: Tim Yevgrashyn on October 21, 2011.
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
Hello,
For the hard of learning, what is an ‘imperative’ in this game? Could you give an example?
Thanks,
Mike
Great question Mike.
So by imperative I mean a statement like ” It shall ….” or “It must …”
Hope that helps,
Mike McCullough
What words would you not allow them to use when describing the item? Obviously Chair, but what other descriptive words would you leave out?
Hi Amber,
The taboo words I use are:
For Chair: sit, seat, stool, rest, furniture, table
For Teapot: tea, pot, short, stout, coffee, water, heat
For RV-Bike: motorcycle, bike, camper, rv, trailer, chopper, harley
Of course, these may need to be adjusted for different audiences and cultures.
Don
A few notes on how this exercise has evolved for me over the years:
1. I only ever have them draw, rather than use play dough or pipe cleaners. I get the same results and it is a lot easier to prep and a lot less messy.
2. For larger groups, I pair people up (one a product owner and one a developer) and have the developers face away from the projector screen, which displays the image and taboo words. This is quicker and smoother than having a PO come up and write down the taboo words.