Let's Kill an Agile Project - Facilitators Guide

by Evan Leybourn on      5 minutes read

I've had a few people express interest in being able to run my "Let's Kill and Agile Project" game within their own organisation. To that end, I have written up the rules and instructions and released them here under a creative commons license (CC BY-SA). Downloadable files are at the bottom of this post.

Introduction

Other talks and games will teach participants how to run a successful Agile project. Only this one will teach them how to ruin an Agile project*. In this game we will break every Agile rule, disregard the manifesto and ignore common sense in the singular pursuit of failure (and fun).

Each of the players will be part of an Agile team with a dis-engaged Customer and micro-managing boss. Being Agile, there will be daily stand-ups, planning sessions, retrospectives, and kanban boards but nothing will go as expected.

* More importantly, this activity will teach you "how" Agile projects can fail and the reason behind many common Agile practices.

Learning Outcomes

Players will come away from this game with an understanding of how and why even the best intentioned Agile projects can fail. Players will learn to identify causes of failure in their own projects (hopefully before they become problematic).

Most importantly players will learn the importance of customer engagement, team dynamics & morale, supportive environments and adaptability.

Game Mechanics and Overview

During the first 5 minutes, players will be introduced to the rules of the game, split into teams (7+/-2), allocated roles within the team, and given secret agendas. The game will then be split into timeboxed, sprints of 10-15 minutes. During each iteration the teams will;

  • run a planning workshop
  • run a review
  • run a retrospective

Each game will be different, but in general some players will be argumentative, some will not communicate. The scrum master(s) will be a manager with their own agenda and the customer will be aloof but fussy about the results. There will be mis-communication and cross-communication and if any team actually delivers a product I will be greatly surprised.

Secret Agenda’s

To keep things interesting, each player in each team will be given a secret agenda. This will contain specific instructions and should not be disclosed to the other team mates until the end of each iteration.

Retrospectives

At the end of each iteration and at the end of the game, you should point out the specifics of each failure and get the teams to discuss how that impacted them. As a group, the teams should discuss how to identify these issues early and what opposite behaviours work well.

  1. "What behaviours did you see?"
  2. "How was it for you?"
  3. "What insights do you have for the ScrumMaster or team?"
  4. "What does this tell you about the roles?"
  5. "What will you do in the future?"

Setup and Iteration 0 (5 minutes)

  1. Find and print out at least 10 unique origami instructions for each team - I use http://en.origami-club.com/easy/index.html.
  2. Buy (or cut) square paper, in multiple colours, for the origami.
  3. Setup a timer on a screen, projector or tablet
  4. Bring planning poker (optional)
  5. Hand out the player instruction sheet, origami sheets and related components
  6. Get the players to read through the instruction sheet
  7. Split the room into teams (7 +/-2)
  8. Get teams to name themselves
  9. Describe the rules of the game
  10. Iteration 0: Describe goal of the game: (for example; to build a scene of tranquility).

Iteration 1 (5 minutes planning + 15 minutes build + 5 minutes retro)

  1. Organise team (choose 1x Scrum Master, 1x Designer, 2x Tester, 3x Developer) - these roles are fixed
  2. Hand out secret agendas
  3. Planning: Provide strict instructions of what you want to occur (it should be greater than the teams capability to deliver, and do not mention the colour requirement unless asked). Do not allow the teams to estimate.
  4. Build: Have the team build the appropriate origami
  5. Review: Have representatives of each time demonstrate their finished products (reject any product that does not meet your exacting standards; including colour).
  6. Retrospective: Have the team discuss their opinions of Iteration 1 and make suggestions for iteration 2. (NOTE: For iteration 2, ignore all suggestions from iteration 1)

Iteration 2 (5 minutes planning + 15(+) minutes build + 5 minutes retro)

Note: let this iteration run over time, unless someone points it out.

  1. Self-organise teams (allow any combination but, once chosen, team roles are fixed)
  2. Hand out secret agendas
  3. Planning: Provide simple instructions of what you want to occur. Allow the team to estimate and plan.
  4. Build: Have the team build the appropriate origami, but hide a specific colour.
  5. Review: Have representatives of each time show their finished products.
  6. Retrospective: Have the team discuss their opinions of Iteration 2 and make suggestions for iteration 3.

(Optional) Daily StandUp (15 minutes)

Play Daily Scrum from Hell

Iteration 3 (5 minutes planning + 15(-) minutes build + 5 minutes retro)

Note: This iteration may not have sufficient time due to iteration 2. Call this out during the planning.

  1. Move people between teams and they take some models with them, then self-organise teams (completely open)
  2. Hand out secret agendas
  3. Planning: Provide simple instructions of what you want to occur. Allow the team to estimate and plan.
  4. Build: Have the team build the appropriate origami in pairs (swap every 5 minutes).
  5. Review: Have representatives of each time show their finished products.
  6. Retrospective: Have the team discuss their opinions of Iteration 3 and make suggestions for iteration 4.

(Optional) Iteration 4 (5 minutes planning + 15 minutes build + 5 minutes retro)

Note: there should be no impediments (or negative secret agenda's) in this iteration. This is our comparative state.

  1. Self-organise teams (completely open)
  2. Hand out secret agendas
  3. Planning: Provide detailed instructions of what you want to occur. Allow the team to estimate and plan.
  4. Build: Have the team build the appropriate origami.
  5. Review: Have representatives of each time show their finished products.
  6. Retrospective: Have the team discuss their opinions of Iteration 4.

Files