Checklist for an Agile Game

17 February 2009

Posted in Life & Work

Here is the recipe for an agile game that I did four times in the last two weeks. The game is intended to practice a team’s capability at self-organization. I developed the idea for this game after doing a smaller but similar game with Elisabeth Hendrickson and several other people some months ago. But I changed the concept to suit my own purposes.

Update (March 14, 2009): I was contacted by Alistair Cockburn who told me that the "create a fairy tale" game is his idea. In my previous post I credited Jeffrey Fredrick and Elisabeth Hendrickson for planting this idea in my mind. But apparently, it was Alistair who gave Jeffrey the original idea in the first place, which is something I either didn't know or didn't remember. So let it be known that the agile game, as described here, is based on an idea by Alistair Cockburn. My game description probably looks suspiciously like Alistair's (unpublished) game, but you will understand that this is neither intentional, nor coincidental.

Plan half a day with a development team
This game takes about 4 hours, including team planning, demos and retrospectives, so you need to reserve half a day with them.

Assign a Scrum Master
Ask someone to act as a Scrum Master for the team. The team will choose to use different kinds of materials (paper, pencils, markers, scissors, etc.) and the Scrum Master will have to find what the team needs. The Scrum Master is also there to assist the team with their task board, sticky notes, and other process-related issues. Furthermore, the Scrum Master can help the team reflect on their progress during the game.

Be a Product Owner
Ask someone to be the Product Owner in this game. (In our games I performed this role myself.) The Product Owner is the only one who should read this text, because he will be driving the project. (If you are not playing the Product Owner role, stop reading this text now!) Try not to show this text to the team, because it might spoil the surprise. (And you don’t get to enjoy the priceless looks on their faces when they hear about the product!)

From this point on, I will assume that you will be the Product Owner in the game…

Define a product that will consist of text and drawings
It is best when the product that the team will make requires both text and drawings. This will require the team to take inventory of their writing and drawing talents, and allocate their work accordingly. It also makes the dynamics of the sprints much more interesting. The game is not about coding! Programming would only distract from the goal of this game, which is to learn about self-organisation.

Bert and Ernie and a birthday cake

Each time I did this game, I explicitly asked for a children's product. For some reason, creating texts and pictures for children turns out to be a lot of fun. It also enables you to set constraints on the style of writing and drawing. As a Product Owner I regularly had to reject texts when they contained words that were too difficult for children.

These were the products I asked for:

Team 1: A fairy tale book about Little Red Riding Hood

Team 2: A film script for a Bert and Ernie movie (from Sesame Street)

Team 3: A children’s book about Jip & Janneke (popular Dutch characters)

Team 4: A children’s book about Miffy (popular Dutch character)

Write a vision statement
Though I actually did this only once, it can be helpful for the team to have a short vision statement about the intended product. You could hang it on the wall at the start of the game. It should communicate things like "consistency", "for children", etc.

Team 4: authors of the Miffy story

Start the game with an introduction
Start the game by telling the group that you’re a customer and that they have a timebox of four hours to create a finished product. Also tell them that you’ve agreed with the Scrum Master to apply the Scrum process of planning + sprint + demo + retrospective. In my experience 20 minutes seemed to be a fine sprint length (which in this case excludes the planning, demo and retrospective).

In four hours, all teams were able to do five or six sprints, which is sufficient to allow self-organization to do its job. Allow the team to take all the time they need for proper planning, demo and retrospectives. I think the learning experience is more important than timeboxing those meetings. The only thing you should timebox is the actual product creation.

Start with a requirements/design sprint
In three of the four games I didn’t prepare a product backlog. Instead, I asked the team to spend the first sprint on creating a storyline and to turn that into a product backlog. I noticed that people had fun when they could create their own story.

As a Product Owner I simply asked them to give me an interesting story, and to turn that story into ten to fifteen individual scenes (drawings plus texts). It is important that the team understands that their work is timeboxed. They may not be able to write and draw all the scenes in four hours. As a Product Owner you will have to assign priorities to the scenes. Some will be essential to the story, while others could be left out when time is up.

This also teaches the team to plan for uncertainty. They will be creating essential scenes in random order, and move to the non-essential ones later. (In our games, two of the teams delivered drawings with page numbers already written on them. This was incorrect of course, as the exact number of pages will only be known at the very end.)

Little Red Riding Hood eaten by the wolf

Sprint planning
At the start of each sprint there is a planning meeting. Like in Scrum, the Product Owner will tell the team what the highest priorities are. The team will have to ask all kinds of questions, like “Do you want the drawings in color?”, “What is the page size?”, “Do you want page numbers?”, “Handwritten or digital?”, and “Portrait or landscape?” Try not to give all information at once. The team should learn to ask for all the information they need.

Allow the team to organize their planning process themselves. Some teams wanted to work with story points per scene. Others didn’t bother because all scenes were roughly the same amount of work. Some teams used a real task board, others thought handing each other the sticky notes worked well enough. As a Product Owner you shouldn’t care about that part of the process. Focus on what they deliver at the end of each sprint, and let them work out the details of the process.

Team 3: authors of the Jip and Janneke story

Set the a constraint for consistency
This is one of the crucial parts of the game! You must tell the team that all drawings and texts have to be consistent in style. If you don’t do this, the team will try to give every individual team member one full scene to complete. You would then end up with very different looking Berts and Ernies on every drawing. I explicitly demanded that the main characters should be consistent across all pictures (and the same requirement applied to the handwriting).

This part is crucial to the game, because from this constraint it follows that the team will have to analyze the types of activities for each scene, and divide the tasks among each other. The team will find out that they need to have some specialists drawing the main characters on each page, and they will have generalists doing all other work (sketching, coloring, etc.) It also teaches them about the specialists vs. generalists issue, and they will see that they have to relieve the specialists (often the bottleneck in the process) of as much work as possible.

Set a constraint for reviews
To make it even more challenging, require that you want to review every sketch of both drawings and texts before they are finalized. The team will then have to figure out how to implement that review process. I usually walked away to my desk during the 20 minute sprints, and team members came running up and down the stairs to ask for my review of the sketches. Other teams decided to treat sketch and finalization as two different product backlog items, and they let the review of the sketches coincide with the sprint review.

As a Product Owner I didn’t care how they solved their problems, as long as I was able to make some (arbitrary) changes to the sketches and final drawings, pointing out some flaws and inconsistencies, and thereby introducing a small stream of rework into their process.

Miffy lost her new bike

Let the team demo their work
After every sprint of 20 minutes, the team will show the Product Owner what they have achieved. As I said, I usually walk away and I return after exactly 20 minutes to keep the pressure up, and to emphasize the fact that the customer expects a demo of the results.

Do a retrospective after each demo
Temporarily replace your Product Owner hat with the hat of an agile coach. Ask the team if everybody had something to do, what the bottlenecks were, and if they could go faster. In my experience, the first two sprints are usually crappy, with a lot of confusion and some people having less work than others. The team will have some trouble organizing itself and figuring out what the process needs to be. In the third sprint the flow is emerging, and in the last two or three sprints the team is fully up to speed.

Set a constraint for finishing up
Last but not least, you should require that the team delivers a finished product, which means that the booklet needs a cover, possibly a back flap, and the pages need to be bound together. Don’t tell them straight away, because it is interesting to see if they can figure this out for themselves.

Finalization of the booklet is the equivalent of a release sprint. In a release sprint some extra work needs to be done to get the product properly wrapped up and delivered to the customer. It will change the dynamics of the last sprint.

Team 1: designers of the big bad wolf

Don't mix different goals
In one game I tried to disturb the team with a show stopper priority halfway during their sprint. But in the next three games I decided against it. I considered that the goal of the game was to see how self-organization works, and how a production flow can emerge, without a manager guiding everyone. Dealing with difficult customers is not the goal of this game. Of course, you may also decide that intentional disruption of the team's process will teach them how to re-organize. But first you'd have to allow them to get up to speed in three or four sprints. Otherwise, they won't see the effect of disruption on their velocity.

Reflect on the game
Make the final retrospective a longer one, and review the entire project. Ask each team member what they noticed and what they learned. In our games the team members told me they could see how they could go faster and faster when the flow started to stabilize. They also saw the problem of working with specialists on the team, and how you can try to arrange the flow around them. Many of the problems that they encountered were the same as in their projects.

They all agreed they did a good team job (in some cases better than in the projects they were working on). People said they had a fun doing the game, while at the same time being very committed to end result. (One team told me of the real panic that broke out when they noticed Miffy’s scarf had the wrong color in one of the drawings.)

Jip and Janneke taking a ride on dolphins

Make it useful for you
My last tip is: try to make sure you can really use the product. The team will be much more committed if you tell them that you’re really going to use their booklets. I told our teams I would be reading their books to my children. And as you can see, they were very interested in the story of Miffy and her New Bike…

Daddy telling an exciting story