Learn About Agile Principles with the Coin, Paper Airplane, DevOps Games and more.

Paper Airplane Game

A good game that explores continuous improvement and Lean workflow.

Learning goals: Lean workflow, value stream mapping

Time to play: 60 minutes

In person or Virtual: Both

Number of players: 4+ players

Resources required: Recycled or scrap paper

How the game works:

The goal of the paper airplane game is to fold as many airplanes as possible in a given timeframe, but only one person can make a fold at a time.

Paper Airplane game rules

The goal is to, as one team, make as many paper planes of the same design.

The rules are as follows

• There are 3 minutes per iteration and 5 iterations
• In between, there is a 1-minute retrospective
• The airplanes folded must be of the same design and quality.
• Only one person can fold at any one time. Others can do other things as needed for their design.

Gather the team and provide the goals and instructions.

Ask them to agree on the design of the airplane. It can be a simple design with a few drawings that can fly one meter. This includes an element of design, production, and quality testing.

Start the process and time the activity. Let them play it out and then record the number of airplanes that have met the quality requirements. Record the number of airplanes created.

Now time the retrospective, allowing people to change how they work in the next round. They can provide a new estimate if they wish.

Repeat the above process for as many iterations as possible, recording the number each time.

Once all iterations are completed, run a debrief. You can ask questions such as

• Where did you notice you were waiting (waste)?
• How often was everyone engaged?
• What changes were made, and how did they affect the production process?
• What design aspects could make the flow slower or faster?
• How would this game differ if it was played virtually versus in person?
• How did quality controls play a part in this process?
• Did you experience the concept of flow?
• Which iteration stood out?
• How did you feel like working as a team?
• Did leadership change during the iterations?
• What did you learn from playing this game?

Variations to the Paper Airplane game

You can vary to this challenge by

• Timing how long it would take the team to create a set number of planes.
• Increasing or decreasing the complexity of the design of the airplane.
• Introducing quality control at the midpoint of the game rather than at the end.
• Increase the difficulty, e.g., the airplane must fly at least 2 meters to count.

Chocolate Bar Game

Become a product owner and get feedback on your ultimate chocolate bar.

Learning goals: Product ownership, iterative feedback, customer value

Time to play: 60 minutes

In person or Virtual: Both

Number of players: 3+ people

Resources required: Recycled or scrap paper

How the game works:

The goal of the Agile Chocolate Bar game is to create the most attractive chocolate bar to your customers as possible.

Agile Chocolate Bar game rules

The goal is a Scrum simulation where you have to create a chocolate bar that is the most attractive to your customers within a certain set of constraints.

The rules are as follows

• For each team, there should be a designated Product Owner. Otherwise, for a small group, each person is also a product owner.
• There is an iteration round (3 minutes) and a feedback round (1min) for each phase.
• There are at least 3 phases.

Gather the team and provide the goals and instructions.

Set a timer for 3 minutes and each team or person creates an example of a chocolate bar they think their customers would love. They can draw this out with as much or as little detail as possible for the “Plate of DOD (Definition of Done, or Done and delivered).”

Then they have 1 minute to present what they have on their plate and get feedback from the rest of the group, who will act as customers. Customers can request changes or simply provide feedback.

Based on the feedback, they then redesign the chocolate bar to be presented on the “Plate of DOD”.

Each phase is repeated until the allotted time elapses.

Once all phases are completed, run a debrief. You can ask questions such as

• How did you decide how to design your chocolate bar in each phase?
• How useful was the feedback from customers, and how did you improve the feedback asked for from each round?
• How did you measure the value of the chocolate bar to the customer each time to make improvements?
• If you didn’t measure customer value, why not?
• How did the feedback you received influence the design of the chocolate bar?
• What trade-offs did you have to find in the design?
• What proportion of the customers did you satisfy at the end?
• Would you have personally bought this chocolate bar?
• Were there any features that were added that did not come from customer feedback?
• Were any agile processes applied in the game, such as backlog, dot voting, or prototyping?
• What else did you learn from this activity that you wanted to share?

Variations to the Chocolate Bar game

You can vary to this challenge by

• Adding a score from each customer each round on their likelihood to buy the chocolate bar.
• Allowing or not allowing the design team to listen to customer feedback sessions (e.g., just the product owner gets the feedback).
• Adding constraints to the design of the chocolate, such as materials or size.

Coin Game

Get flipping with a kanban workflow challenge that will help teams stay active.

Learning goals: The first principle of the Agile Manifesto,  Continuous deployment

Time to play: 15 minutes

In person or Virtual: Both

Number of players: 3+ people

Resources required: 20 coins – They don’t have to be the same.

How the game works:

The goal of the coin game is to learn about the first principle of the agile manifesto, which is “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

The Coin Game rules

The goal of this game is to work out the fastest way to deliver value to the customer as a team. Essentially this means comparing agile to traditional approaches and determining the best batch size.

The rules are as follows

• There is a set number of coins representing value to the customer.
• Each coin needs to be flipped by each person along the value chain before it is given to the customer.
• The process is timed to see how long it takes to deliver value to the customer.
• There will be 3+ iterations that are timed.

Gather the team and provide the goals and instructions.

Separate them into teams of 5 or 6 people. They can represent different roles in the value chain.

Have people decide the fastest way they can take turns flipping the coins and stacking them at the end of the process, ready for delivery to the customer.

After a minute of discussion, start the timer and let them play it out. Stop the timer when all the coins have been flipped by each person and stacked.

Allow a one-minute retrospective to see how they might change the strategy and then repeat the activity above.

Re-run the activity, recording the time taken for each iteration.

Once all iterations are completed, run a debrief. You can ask questions such as

• Which batch sizes did the best in terms of time? Why do you think that is?
• Was there anything that surprised you in the game?
• How do you think it would change if the distance between people were increased?
• How do you think things would change if you had to wait 10 seconds each time there was a handover of coins?
• If you introduced a change request during the game, how did that impact the process?
• If you had compared it to the traditional waterfall approach, what differences did you notice?
• How good were the team’s time estimates?
• What else did you learn from this activity that you wanted to share?

Variations to the Coin Agile Game

You can vary to this challenge by

• Having the teams start off by completing the task in a traditional waterfall approach where every coin was flipped by one person before it was moved to the next person. This acts as a baseline.
• Introducing one or more change requests to the process – e.g., I only want $2 coins or Coins with a picture of an animal.
• Have teams estimate how long it would take to complete the task at different batch times.

Marshmallow Game

Explore problem-solving strategies and builds that require learning from failures and timeboxing.

Learning goals: Creativity, problem-solving, collaborative teamwork.

Time to play: 20 minutes to build the tower, then debrief.

In-person or Virtual: Both

Number of players: 3+ people

Resources required: For each team, 1 large marshmallow, 30 dry spaghetti sticks, 1 meter of tape, 1 meter of string, 1 pair of scissors. Measuring tape.

How the game works:

This game allows you to challenge teams to be creative and collaborative. It involves teamwork, listening, and working together to build the best-performing structure.

The Coin Game rules

The goal of the marshmallow challenge game is to build the tallest freestanding tower with a marshmallow at the top.

The rules are as follows

• The marshmallow must be intact. No tearing or biting.
• You can break or tear any of the other items.
• Once time is up, everyone must back away from the structure. You cannot hold onto it.
• The structure must be free-standing.

Gather the team and provide the goals and instructions.

Set the time that you have allowed for the exercise and let the teams go.

Once time is up, teams back away from their structure. Now record the maximum height of each of the marshmallow towers.

Celebrate and congratulate all teams as well as the winning team.

It’s now extra important to debrief on the exercise. You can ask questions such as:

• How would you rate the overall performance of the team and your tower?
• What factors contributed to the success?
• What factors contributed to failures?
• What failures did you experience on the way?
• How did your team communicate?
• Were there any aspects of the challenge that you thought helped with the tower’s creation?
• What roles did each person play, and did it change?
• How much planning did you do?
• What was the impact of the resource constraint?
• If you were allowed to double just one of those resources, which one would it be and why?
• Did you use all of your resources? Why or why not?

Variations to the Marshmallow Tower Game

You can vary to this challenge by

• Allowing teams to trade resources between teams
• Adding a second marshmallow into the challenge

How long does it take to make a cup of tea

Enhance and explore estimations and the impact on the team outcomes.

Learning goals: Estimations and task sizing

Time to play: 30 mins

In person or Virtual: Both

Number of players: 3+ people

Resources required: Tea, plus whatever tools, gadgets, and items each person decides to use to make their cup of tea.

How the Make a Cup of Tea game works:

This game helps teams understand estimations of tasks and being able to develop the right ability to ask questions and consider factors that will improve estimations in agile.

The Make a Cup of Tea Game rules

The goal is to estimate how long it would take everyone in the team to make a cup of tea and to be ready to drink altogether. There is a round of questions that allows people to guess, and then they then head off to make the cup of tea. The timer stops when the last person returns, and everyone is ready to sip their cup of tea.

The rules are as follows

• You have 1 minute for people to ask questions to the team to allow them to estimate how long it would take to make a cup of tea.
• Each person then writes down their own estimate. (By Minutes and Seconds)
• As a whole, the team then comes up with a final estimate. (By Minutes and Seconds)
• The timer stops when everyone is back and ready to take the first sip of tea.

Gather the team and provide the goals and instructions.

Ask each person to ask questions to the group and listen to the response. After a minute, ask each person to share their estimate. Based on this, ask the team to create a final group estimate and record this. (Minutes and Seconds).

Start the timer and let everyone head off to make a cup of tea. When everyone comes back, they are ready to take their first sip.

Stop the timer and write down the time. Have teams compare their individual, group, and real-time.

The important part of this game is then to debrief this. You can ask questions such as

• How close were your estimates to the real-time?
• How different are your estimates from the group estimates and the real-time?
• What factors caused your estimates to be wrong? Or right?
• What events surprised you and you did not expect or plan for?
• What would have helped you make a better estimate?
• What questions should you have asked that would improve your estimations?
• What do you think is the value of good estimations – why did we just do this exercise?
• What are the impacts of getting estimations too wrong?
• How did it feel being the first person back versus the last person back?
• If you run the same activity again next time, do you think your estimates would be the same or different? Why?

Variations to the Make a Tea Game

You can vary to this challenge by

• Keeping personal estimates unknown.
• Using different ways to calculate the group estimate – by average time, most common, by consensus.

The Multitasking Name Game (Henrik Kniberg)

Which is better, single-focus or multi-tasking? Take the challenge and find out.

Learning goals: Limiting WIP, Kanban, task planning

Time to play: 10 mins

In person or Virtual: Both

Number of players: 5+ people

Resources required: Pen, Paper and timer

How the multitasking name game works

This is a short, simple but powerful game that highlights the effects of multi-tasking and context shifting. In a busy world, people are often doing multiple projects, open tabs in the browser, or trying to switch between tasks. This game highlights how effective people actually are at multitasking. This game was introduced by Henrik Kniberg.

The Name Game rules

The goal is to write down everyone’s names as fast as possible so that all names are written out in full.

The rules are as follows

• There are 2 phases.
• In the 1st phase, you can only write one letter of each person’s name at a time. E.g. all the first letters, then all the seconds and so on.
• Every time a name is completed, record the time of completion.
• When all names are completed, record the time of completion.
• In the 2nd phase, you can only write one name at a time. At the end of each name, complete the time of completion. When all names are completed, record the time of completion.
• Compare the 2 results.

Gather the team and provide the goals and instructions.

Create a list of all the names of the people in the room.

You can either have someone act as a scribe for the team and have someone else time each name and list completion.

Ask teams to estimate how long it would take to write all the names one letter at a time per name versus one name at a time.

Start phase one and record the times.

Run phase two and record the times.

Calculate the difference in times – what was the proportional change?

The important part of this game is then to debrief this. You can ask questions such as

• How close were your estimates to the real-time?
• What made phase 2 easier than round one?
• Would it make a difference if the names were scientific words or uncommon words instead of names?
• What made it easier to uni-task rather than multi-task?
• In reflection, which activities do you multitask?
• Do you think it would be faster to write 2 names at a time rather than one?
• What other learnings did you want to share?

Variations to the Name Game

You can vary to this challenge by

• Changing it from names to a set of numbers, scientific terms, or formulas.
• Try having paired scribes in both phases and see if it makes a difference.

LEGO Flow

Role-based workflow game that will be sure to get a few neurons firing.

Learning goals: Backlogs, Kanban, inspection and adaption.

Time to play: ~60 minutes, based on 3 rounds of 5 minutes

In person or Virtual: Virtual

Number of players: ~5 people per team

Resources required: Lego pieces of any colour, sticky tape or 4 pieces of paper. You can download printable resources here thanks to Organize Agile under the Creative Commons.

How the LEGO Flow game works

This game highlights differences between existing processes and using a kanban system to help optimize workflow and output.  It uses assigned roles for each per, a backlog of orders, and other game theories to help teams experiment with ways to optimize their workflow.

The Lego Flow Game rules

The goal is to create as many lego animals as possible each round (3). With each round, the process is timed and the teams get to see how long it takes them to construct as many animals as possible. The team should manage their flow (left to right) and create explicit agreements to work together. Points are earned for each completed animal and points are deducted for unused parts or undelivered animals.

The rules are as follows

• This game is played in 3 rounds.
• There are 4 types of animals to be built based on a set of resources.
• In each round, points are earned for each completed animal built and delivered to the right specification. They must be 2 blocks high and the color does not matter.
• The roles are as follows:
  • Analyst (Leg builder): gathers the legs.
  • Developer (Body builder: puts 2 blocks on top of each other
  • Designer (Head builder: builds the head)
  • Delivery (Transporter: puts the animal in transport for 30 seconds)
  • Tester (Quality Assurance: checks output, keeps score and takes the animal apart).
• Animals are built and then transported for delivery.
• There is a 30-second delay for transportation. The animal stays in the transport zone during this time.
• There are a maximum of 3 animals transported at the same time. (ie. 1 animal per truck)
• Once the animal is checked, it is then disassembled and put back into a starting pile.
• Points are scored as follows:
  • +10 points for each fully delivered animal
  • -1 point for every unused leg
  • -4 points for every unused body
  • -4 points for every unused head
  • -10 points for every completed animal not yet arrived.

Round 1

Gather the teams and provide the goals and instructions. Simply give them a pile of lego bricks.

There is no backlog, or visualisation of workflow. The team chooses what animals to build.

Set the timer for 5 minutes and ask people to start building.

At the end of the round, record the final score and allow a minute for reflection of the task.

Round 2

Now introduce a workflow system. Ask the team to create a visual workflow either with tape on the table or pieces of paper, going from left to right. Unassembled pieces are then pulled from one pile and moved from leg builder to body builder to head builder, then transport/testing.

Set the timer for 5 minutes and ask people to start building.

At the end of the round, record the final score and allow a minute for reflection of the task.

Round 3

Keep the visualized workflow and this time introduce the backlog or order of production. E.g Cow Cow, Sheep Sheep, Duck Duck, Horse Horse.

Set the timer for 5 minutes and ask people to start building.

At the end of the round, record the final score and allow a minute for reflection of the task.

Now ask the following debrief questions

• How did your scores change from round to round?
• What went well?
• When and where did the work pile up (bottleneck)?
• What improvements did you introduce and what impact did it have?
• What was the differences between the first and third round?
• Did you experience flow? When did this happen?
• Did your WIP limits change after each round?
• Was there any reword that needed to be done?
• What else would you change to improve the overall results?

Variations to the Lego Flow Game

You can vary to this challenge by

• Introducing some limits to a specific type of lego blocks.
• Allowing the teams to come up with their own backlog.

Lego Retrospective Game

Each team member builds and talks about their experience of the last sprint through their lego design.

Learning goals: Creativity, Retrospective

Time to play: 3-minute build and 1 minute per person

In person or Virtual: Both

Number of players: Any

Resources required: Assorted Lego pieces

How the Lego Retrospective game works

This is a free-style, easy game that lets people talk through a lego design about their experience of the last sprint. It can help break down communication barriers by using each piece, or the whole shape for people to use as talking appoint.

The Name Game rules

The goal is to create a simple Lego design that reflects your experience of the last sprint. There are no right or wrong answers.

Place an assortment of legos or give each person a pile of legos and give them a few minutes to build anything they like that represents their experience of the last sprint.

Then, give each person a turn at describing what they have created. You can ask questions such as

• Why did you use the pieces you used?
• Tell us more about a particular experience?
• What did you love most or think was missing in your design?

Variations to the Name Game

You can vary to this challenge by

• Posing a particular scenario and having people build ther version of it. Examples include:
  • What would good/bad communication look like?
  • What is your vision for this team or project?
  • How would a perfect user story be represented?
  • How would you portray our teams culture?

Kanban Pizza

Learning goal: Practice using a whole Kanban system including understanding the effects of limiting the team’s Work in Progress (WIP).

Time to play: 2 to 3 hours

In-person or virtual: In person

Number of players: 4-8 per team

Resources required: Sticky notes in three colors: yellow (mozzarella), pink (pepperoni) and green (herbs), paper (for pizza bases), red markers (for tomato sauce), glue or transparent tape, masking tape, scissors (one small and one large per team), paper plate (oven) and a stopwatch.

How the Kanban game works

Players step into the role of pizza chefs. Thay are divided into teams and given the materials they need to make a version of a pizza.  They must create as many of the same pizzas as the one created by the facilitator. At the end of each round, the team counts the number of pizzas delivered and aims to reduce the amount of waste.

Kanban Pizza game rules

• The team must create as many pizzas as possible in the allocated time.
• The pizza must be exactly the same as the one created by the facilitator. (5 points)
• Each pizza must be ‘cooked’ for at least 30 seconds.
• The oven can only hold three pizzas at a time.
• Wastage should be kept to a minimum. (- 1 point for each waste item)
• Unused resources created from one round can be used in the next.

Getting started

Round one – Create your own process

• Have an example ‘pizza’ made up to show the group – A white circular base using the printing paper that is colored red with the marker for tomato sauce. Add six yellow (mozzarella) squares, six pink (pepperoni) squares and three green (herbs) squares.
• Show them the paper plate as the oven.
• After five minutes, count how many pizzas were made, assess the level of wasted food, and calculate scores.

Round two – Introduce Kanban

• Introduce Kanban and the core practices of Kanban. (Visualize the Workflow, Limit your Work in Progress (WIP), Manage the Flow, Implement Feedback Loops, Make Process Policies Explicit, Improve Collaboratively).
• Have teams visualize the workflow and make the process explicit by introducing storage for production materials (pizza bottoms, slices of ham, etc.) directly on the table. The teams can use the materials at hand (masking tape, post-its and paper).
• Advise the teams to limit their Work in Progress (WIP).
• Run a new round with the newly established Kanban system. At the end of five minutes run a debrief and calculate scores.

Round three – Extend the system

• Introducing a new pizza type. Customer orders can now contain pizzas of two different kinds.
• The team can only count the pizzas when the whole order is fulfilled.
• A team can pull several orders at once.
• Allow the teams five minutes to discuss how they will extend the system.
• Run a new round . At the end of five minutes run a debrief and calculate scores.

Round four – Iterate and improve

• Give the teams five minutes to discuss and improve their system. Have them focus on the workflow and different WIP limits.
• At the end of five minutes run a debrief and calculate scores.
• Finally debrief on all four rounds to see what the team learned.

Agile 42 offers resources to support their game. Shared under the Creative Commons Attribution 4.0 International Licence.

Agile Battleship

An activity created by James Scrimshire that takes the classic game of Battleship and gives it an agile twist.

Learning goal: To understand the importance of communication, collaboration, and the benefits of the iterative development process.

Duration: 30 minutes.

In-person or virtual: Both.

Number of players: 4-12

Resources required: Battleship game set

How the Agile Battleships game works

Teams play rounds of Battleships. The first is played without any feedback. Subsequent rounds gradually introduce more feedback.

Agile Battleships game rules

Each team can see their own board but not their opponent’s board.

Teams take turns firing at their opponent’s board, calling out the coordinates of their target.

The game ends when one team successfully sinks all of the opposing team’s ships.

Getting started

Divide the group into two.

Set up the battleship boards and fleet pieces.

The teams take turns to sink each other’s ships.

Round one – No feedback

• Begin the game with teams taking turns to call out coordinates.
• After 5 minutes, stop the game. Count how many hits the team made.
• Debrief by discussing how the players felt, and how their experience could apply to their work.

Round two – Limited feedback

• This time, after every five shots, the team is told if they ‘hit’ or ‘missed’ a ship.
• After 5 minutes, stop the game. Count how many hits the team made.
• Debrief by discussing how this iteration differed from the first.

Round three – Real time feedback

• This time, after every shot, the team is told if they ‘hit’ or ‘missed’ a ship.
• After 5 minutes, stop the game. Count how many hits the team made.
• Debrief by discussing how this iteration differed from the first.
• Ask teams how they get and receive feedback in their workplace.

Variations to the Battleships game

• A pen and paper version of Battleships can be found here.
• A virtual version is offered by BoxUK
• Play without timeboxing the rounds. Instead, stop when one team has sunk all of the ships of the other. Use this to inform discussions around the influence of feedback on time management.
• If time allows, additional rounds can be included that more gradually increase the amount of feedback the teams receive.

Shared under the Creative Commons Attribution 4.0 International Licence.

XP Game

A game designed by Vera Peeters and Pascal Van Cauwenberghe to introduce participants to the principles and practices of Extreme Programming (XP) methodology.

Learning goal: Increase understanding of concepts such as velocity, story estimation, yesterday’s weather and the cycle of life of both developers and customers.

Time to play: 2-3 hours

In-person or virtual: In-person

Number of players: 5-12

Resources required: Pre-filled story cards, planning and scoring sheets, pencils, playing cards, dice, balloons, other small props to perform stories, a timer per team.

How the XP Game works:

The XP Game makes the players act as either a developer or customer, so that they understand each other’s role.

XP Game rules

• The aim of the game is to earn as many business points by delivering value with a timeframe or budget.
• Value is delivered by completing stories that have been accepted by the customer.
• Stories are found on story cards. These are simple activities to be done.
• Players provide an estimate for each story card and decide what the team should attempt to deliver within an iteration. Not all time needs to be used.
• An iteration is three minutes.
• Teams with the most points are the most successful.

Getting started

Participants are divided into teams and assigned the roles of developers or customers.

Round one – Determining velocity

• Allocate each team 12 story cards.
• Players estimate the stories from one to six, or impossible. Players may ask the coach questions about each story.
• Customers choose the stories they think can be implemented by the developers in three minutes and then order the cards.
• Developers implement the stories one at a time, in order.
• Start the timer when a developer starts a story. Stop the timer when they think the story is finished.
• The customer accepts or rejects the story. If rejected, the timer is restarted and the story is done again. If successful, the developer picks up the next story.
• At the end of the round, tally up the business points of all fully delivered stories and add to the score sheet. Calculate velocity based on the time used.

Round two – Determining business value

• Have the team debrief the first round.
• Give each team seven more story cards. The team estimates the new cards.
• Customers choose stories to equal the team velocity from round one and orders them.
• Developers implement the stories, in order, until the timer runs out.
• At the end of the round, tally up the business value and calculate velocity.
• Compare it to the first round and debrief.

Run as many iterations as you would like to improve iteration planning.

Shared under the Creative Commons Attribution 4.0 International Licence.

DevOps Dream

A simulation game from the team at Mechanical Rock. It’s designed to introduce participants to the principles and practices of DevOps methodology in a fun and interactive way.

Learning goal: To help participants reflect on how they develop and run software.

Time to play: Flexible

In person or virtual: virtual

Number of players: 1

Resources required: DevOps Dream

How the DevOps Dream game works

Players step into the role of the CIO of a company. They need to pick the right combination of initiatives and actions to lead their team to success.

The DevOps Dream game

The game offers a guided tutorial.

The steps include –

• Choosing a company
• Deciding on initiatives
• Examining performance metrics

Different scenarios are present along with a choice of steps that can be taken in response.

The player is assessed on four key results over a 3 year period.

• People
• Productivity
• Customer Satisfaction
• Stability