Let's Make a Meal!

As an Agile Coach I need to find a way to help people practice the concepts I'm teaching in a way that makes it relevant and easy to understand and apply so they can start using those concepts immediately in their daily work.

I wrote about using games to help teach recently and wanted to share a game I created because I think it's so helpful with illustrating the reason we have to work so closely with our customer/product owner and team; and it's relevant to all cultures.

It's essentially a planning session where the team is working on something they are all familiar with and all consume.

I called it "Let's Make a Meal" because I am nothing if not a child of American culture; there once was a television game show called "Let's Make a Deal" and in looking for the link to share I discovered--to my surprise--it's still airing.

Bad puns aside, the game is actually fun and quite good at helping people practice multiple Agile concepts. But don't just take my word for it! Read on...

Let's Make a Meal!

Teams work together to plan an event which includes food. Cards with food names written on them are provided along with other materials: sharpies, post its, pens, and blank paper. The time box is about ~1.5 hours; though it can take up to 2 hours depending on the number of people.

If there are really good conversations happening I'll encourage them to continue just to help drive that message a little deeper into their psyches.

INSTRUCTIONS

• Break group into teams of 5-7 people and select a Product Owner and Scrum Master (2-3 mins)
• The Product Owner decides what the event is (the vision); decides on a menu using the cards provided; the Scrum Master helps the Product Owner get organized and the team listens (5-10 mins)
• The team works with the Product Owner to start writing stories (10-20 mins)
• The team discusses and decides what the Definition of Done is for the event (5-10 mins)
• The team and the Product Owner discuss stories and edit them for clarity and to identify/understand acceptance criteria (30 mins)
• Then the team estimates each item with story points and breaks the stories down into tasks to estimate the time to Done; Product Owner provides clarity as needed (5-10 mins)
• The Scrum Master keeps everyone on track for time; ensuring they keep the game outcome in mind--each team should have:
• an event description; artwork/posters are optional
• a menu
• stories complete with acceptance criteria 
• the definition of done
• total story points and estimated duration
• When all are done each team reads the event description, menu, definition of done, and totals to other teams; if there is time they can possibly share a story or two with acceptance criteria.

The most awesome part of this exercise is seeing the light bulb go on for the people who said at the beginning of the class that they thought there was no value in story writing or planning sessions. 

In the game, these teams spend about an hour and a half planning an imaginary event with food they're not going to eat and they are serious about it. I've seen arguments (albeit good-natured) about how to cook a specific item; that's how serious some people take it.

When I point this out, and ask how they think (hypothetically) the event might have turned out without the discussion and clarification they almost all say something along the lines of "It will be better because we did that."

It turns out there are some people who know how to cook and others who don't. Those who don't make assumptions about the time it takes and what the ingredients might include. There are food items no one has ever heard of and they have to figure out what to do about that; some of them decided for themselves what it was and others Googled them.

There was one team whose Product Owner chose to plan an event for her elderly grandmother and wanted to include a dish that everyone was familiar with but there was a twist; her grandmother always made it a certain way with extra ingredients. 

Her team would have planned to make it the way they knew how if they hadn't discussed it with her. Because although she'd written it in the story and acceptance criteria they just thought she didn't know how to make it; they would have ignored what she wrote.

Then there are the story point estimates and duration estimates. Many times have I heard the claims that story points are a waste of time, or should have time attached to them, or should be "normalized" so everyone understands what they mean across teams.

When the teams in this exercise look around at the differences in the estimates and realizes that each team has widely varied expertise in event planning and catering the penny drops. The sudden realization is sometimes comical, but always electrifying.

I've had very excited students come up to me after the class asking for the game instructions and copies of the food cards so they can share it with their team at work.

What I point out to them at the end is this: we all eat food and we all hold or attend parties but we don't do it exactly the same. Our experiences and knowledge may be similar but are not the same. We all may know what tira misu is but not necessarily what's in it or how to make it. 

We all know what a wedding is but they are culturally vastly different--an American wedding generally lasts about half a day; an Indian wedding can go three days--that's a lot more food and planning.

We have to talk to come to an understanding of what we're doing, when, why and how. This game is a fun way of getting people to see that. 

As a side note, the reality and creativity people bring to this exercise consistently blows me away. It's really their energetic participation that makes it so much fun and resonate so deeply. 

I often tell the students they should take the same energy to their teams and they're often a little sheepish about that, telling me they didn't realize they could.

That is why I'm sharing this with all of you. Because we all should have that kind of fun with our teams... every day.