The goal of the Play doh Zoo Game is to explain and practice the reasons behind agile, and the principles that the methodology is built on. It is specifically targeted at designers and aims to highlight the benefits of agile, and illustrate how design activities can occur in an agile environment.
Cathie Hagen, Marie-Claire Dean and Megan Cook invented the game and originally ran this at SxSW 2012. There’s a write-up of that session on Marie-Claire’s blog and also on Adam Kleinberg’s blog (he was a participant).
This game can be run in 60mins (we did so at SxSW), but you can also make it a longer session if you wish.
For the “Customers”
For the Zoo Building Team:
Business & Design Group
A variety of craft supplies will allow teams to be creative. Therefore, variety in raw materials is encouraged. Also, sharing resources within the team should be encouraged.
Split the players into 2 main groups: the customers, and the zoo builders.
The customer group will help the facilitators guide the game play, by acting as customers of the zoos. They will vote with their feet to determine that zoo offers the most fun.
The zoo builders will be split up into teams to compete against each other. Each team will be split into 2 equally sized groups:
Once the teams have been formed, the game can start. The game is carried out over 3 iterations, during which time the zoo is built. After each iteration, the safety inspector will determine if the zoo is safe to open, and if so the customers “visit” their preferred zoo. A retrospective occurs between each iteration to reinforce the learnings from the game.
After the final iteration is finished, the points are counted and a winner is declared.
The objective of this exercise is to the demonstrate the principles of agile, in particular for experience designers:
You will learn the above by:
This game is designed for a large number of people 50-150.
Each zoo builder teams consists of 3-12 people
The customer team consists of 5 – 50 people. The recommended minimum number of people for this team is twice the number of zoo-builder teams, to allow for greater variance in voting and a richer experience during iterations.
Please note: As the size of players increase, so will the number of facilitators required. It is useful to have 1 safety inspector/facilitator for every 2 zoo-builder groups, a dedicated facilitator for the customer group.
For each iteration:
Facilitator Notes: Most teams will be unfamiliar with retrospectives. Provide a quick briefing before the first retrospective to everyone, and assist the teams by helping them focus on process improvement. It may also be useful to provide templates as a framework for the running the retrospectives. The anchors and engines template is an easy, quickly understood template.
Congratulations! You as a customer get to mess with the rest of the teams J
This group will act as customers for the zoo building teams. This team should be located away from the zoo building teams, a break-out room is preferred. Zoo building team members can visit at any time.
The customer group may require hands-on facilitation, depending on the pro-activeness of this group. If needed, help the determining their requirements using fun gamestorming techniques.
Start with 3 equally balanced teams. The teams can self organize, but people working outside their role are handicapped.
Resist the urge to prevent the zoo-building team from making mistakes, e.g. overlong planning. Mistakes should be highlighted by the scoring system, and raised within the retrospectives (hopefully by the players themselves).
You get access to lots of materials. Only current members of the can build the zoo.
Correlation in a software team: developers (front & back end)
Only have pens/pencils, planning paper, post-its notes. You determine the direction of the build; the construction workers must follow your say-so.
Correlation in a software team: analysts, designers, managers, testers, SMEs.
A facilitator will play the safety inspector(s). They provide briefings on the rules that the zoos need to follow. Briefings are carried out with all teams.
The safety inspector also can inspect. Inspections are only carried out for 1 team at a time. If inspecting during an iteration, they act as consultants, allowing the team to correct mistakes without penalty. If inspecting after an iteration is complete, the safety inspector can prevent the zoo from opening, or remove features that are dangerous (e.g. remove a animal which does not have an enclosure), when inspecting at the end of an iteration. Reasons for failing inspection are always explained.
Facilitator notes: The safety inspector should demonstrate the benefit of testing often, and why quality should be embedded into the process.
|Basic zoo: gate and gate personnel, and at least 1 animal enclosure
|Animals [Optional]||1 for each different animal|
|Infrastructure/Facilities [Optional]||1 for each facility|
|Customer votes||1 for each customer visiting|