5 great activities to get your team excited about agile.
Here is a challenge; make your team excited about agile development practices.
Do not just explain what agile is, but try to win them over it. Convince them, this is not another managerial mumbo jumbo, which translates into more work, less visibility and even more meetings (but in a weirder format).
Try to avoid this Dilbert scenario:
I am sure many of you product owners/scrum masters/agile coaches faced a similar challenge.
Series of long lectures with fancily animated Powerpoint slides might look nice in the report for senior management but it will hardly impress an engineering team. For suspicious, curious and inquisitive people like the ones from your dev team; seeing is believing.
This is where agile games come in handy. These activities create a safe and fun environment for simulating real-life processes and convey learnings, through hands-on experience, which is much better than any dry lecture.
So, here a couple ideas for fun & learn games, to get your team started with agile.
A note: None of the game scenarios are mine ( so none credit is taken), I provide a source material, which I highly recommend to go through before running any of the games. Nevertheless, I do provide a couple of improvement suggestions here and there, based on my own experience;)
A warning; if you don’t plan to run the games but participate in them, beware, there are SPOILERS ahead!
1. The Marshmallow Challenge
Source: https://www.ted.com/talks/tom_wujec_build_a_tower
Set up:
What you need for each team is a set of 20 spaghetti sticks, one yard of string, one yard of tape and a marshmallow. Teams are formed out of 4–5 people.
Rules overview:
Teams have 18 minutes to form a tallest possible constructions out of available materials. Marshmallow has to be the highest element of the structure. The structure needs to be free standing (so you can’t glue it to the table). You can’t rip, eat or break the marshmallow (but you can pierce it). The team that sets the tallest structure (that remains standing at least for 20 seconds) wins.
Core takeaways:
- Teaches a lean approach to risk management and the value of continuous experimentation (waste reduction)
- Recommended for teams new to agile
- Rewards creativity and team collaboration
- Especially valuable for design & engineering teams
- Great team building aspect (big fun factor)
My comment:
The whole point of the exercise its to teach the teams lean approach to the risk management and the value of continuous experimentation. There is a trick to the game (which is explained in the Ted talk video provided in the source link). Teams that go with a typical waterfall system (place the marshmallow at the very end of the time limit) usually fail miserably with the whole beautiful designed construction falling apart in the very instant it is put to test. Just like in real life projects.
What works the best in this game is testing the stability of the construction (by placing a marshmallow on top) at the earliest stage possible and then doing the adjustments accordingly.
The game has the biggest impact on teams which are entirely new to agile, showcasing the value of agile approach as a risk & waste limiting methodology. Facilitator should use the video provided in the link for the teams to serve as a summary, after they are done with the exercise.
2. Traditional vs. Agile Approach of Managing Work (aka Easter Egg Challenge)
Source: http://www.360pmo.com/traditional-vs-agile-approach-managing-work/
Set up:
What you need for each participating team is a pack of crayons, 2–3 scissors and a decent amount of printed Easter Egg Sheets (minimum 30 per team). Teams ideally should be formed out of 4–5 people but there is no upper limit.
Rules overview:
The goal of the game is to provide as many colored, paper eggs as possible. Eggs need to be cut around the edges and colored within lines. At the beginning of the game, the facilitator explains that a team which provides most eggs wins.
Coloring rules are as follow:
- Each egg needs to be colored by at least two people
- Two different colors must be used and different colors can’t be used in the same area (within edges).
The exercise runs in two rounds; waterfall round & agile round (in that order);
- Waterfall round is divided into 3 sessions; 3-minute planning, 6 minutes execution and 3 minutes learning (which optionally can be merged with QA). Additionally, during waterfall round, team members are assigned specific roles; cutters (who cut the eggs out), painters (who paint the eggs) and QA (who are the only ones that can assess and correct the eggs). Each team member can only perform a role he was assigned to.
- Agile round is divided into 3 iterations; each consists of 1-minute planning, 2-minute execution and 1-minute retrospective (learnings). During the agile round the roles within the team are made obsolete — everyone within the team can perform any activity (the painting rules are kept though). After each round is done the facilitator counts the result of each team and reveals the true purpose of the game. It didn’t matter how teams scored against each other, but how they scored against themselves from one round to another (waterfall vs agile).
Core takeaways:
- Teaches the value of teams autonomy to self organize and the advantage of iterative delivery process over waterfall approach
- Provides a clear evidence on how productivity can radically increase when better work methodology is applied
- Highest impact on organizations & teams which are deeply rooted in waterfall mindset
- By adding some modifications (sudden shift in business requirements) can showcase the strength of the lean approach in responding to change
My comment:
This game is really fun and works great as “deal breaker” for teams which are hesitant to see the advantages of the agile approach. The real, hidden goal of the exercise it not how teams performed against each other, but how the performance of each team changed (read: improved) after applying different work organization. So far, every team I ran this game with, has achieved much higher score in an agile round (versus the one from waterfall round).
If you have doubts that the outcome might be different I highly recommend to add a twist to the game (not provided in the source material). The twist is to change the business requirements twice — once in the midst of the waterfall round (so after 3 minutes of execution round) and the second time in the midst of agile round ( after 1st minute of execution in the second iteration).
The business requirement change should be different in each round (so teams can’t anticipate it). This twist can be anything from banning a specific color (together with all eggs of that color of course) to forcing the teams to cut out the eggs differently (for example not around the edges but as rectangular pieces). The underlying principle should be that as a result, it should force the teams to waste much (if not all) of their work produced up until that point. Teams will find it much easier to respond and reorganize themselves for such change when working in the agile system, which provides additional learning value to the exercise (“Responding to change over following a plan”).
We have run this game very successfully for the management team in tajawal and there is a great article that showcases in depth the whole exercise (here).
3. The Human Knot Game
Source: http://wilderdom.com/games/descriptions/HumanKnot.html
Set up:
A team(s) of 7–10 should be formed.
The team comes together in a close proximity (shoulder to shoulder) and then participants put their hands together in the middle of the formed circle. Each participant grabs a hand of another participant at random (the rule is; you are not allowed to hold both hands of the same person). All participants need to keep their hands hold (they can’t let go even for a moment) during the exercise.
Facilitator a appoints one person to be the “project manager”.
Rules overview:
The goal is for the team to “untangle” and sort the knot into its simplest structure (usually that means to form a circle or a straight line).
The exercise runs in two rounds. The first round has an appointed project manager, who is the only person that is allowed to communicate & organize the team. Team members can only communicate with the project manager.
In the second participants can talk to each other freely and there are no appointed leaders. Facilitator measures the time that team needed to untangle in both rounds
Core takeaways:
- Showcases the value of teams autonomy to self-organize
- Demonstrates advantages of flat hierarchy in a small team
- Teaches team to rely on each other
- Fun, team building activity (not for everyone though; see the comments)
My comment:
This is a quick and easy game, but it’s not for everyone. It involves close physical contact, hence a trainer should carefully consider all cultural/social (and safety!) implications before deciding to run it with the team. If all checkboxes are checked, it offers almost immediate learnings on the value of self-organization as well as a bit of a respite from traditional sit/draw/brainstorm games.
It is a good exercise to add to an agenda of a team building event.
4. The Ball Point Game
Source: https://scrumology.com/from-the-archives-the-ball-point-game/
Set up:
What you will need it a set of tennis and/or golf balls (minimum twenty). The number of participants should be minimum 6 (there is no upper limit) but from my experience, ideal team size is 8–15 people. Participants form a circle and all of them are part of the same team. Additionally, have a whiteboard prepared for the briefing and writing down points for each iteration.
Rules overview:
The goal of the game is to pass through the team as many balls as possible.
There are specific rules, that govern on how the balls should be passed;
- Each ball must have air-time
- Each ball must be touched at least once by every participant
- It is forbidden to pass the balls to your direct neighbors (left or right)
- Each ball must return to its initial provider
The game is running in five iterations, which are structured as follow;
- Two minutes preparation (balls can’t be used in that time)
- The team gives an estimation on how many balls it will pass through the system
- Two minutes execution
- 1-minute retrospective
After each iteration facilitator writes down on the whiteboard the estimation and the actual number of balls delivered.
Core takeaways:
- Good sprint ”simulator”
- Showcases that applying learnings in iterative process can improve the efficiency of a team
- Puts accent on the communications skills of the team and their ability to self-organize
My Comment:
Ballpoint game works best with a very active facilitator, who takes care not only of rules arbitration but who can also provide a twist to the activity by simulating “corporate obstacles”.
Just to throw a couple of examples;
- Creating a pressure by setting up an undoable benchmark for balls processing (“Average team can pass 100 balls in one session, we have to do more than that, so we can reach our yearly goals”)
- Passing the balls to the team in a ridiculous way like throwing them from far away, or just releasing at once all balls from the bag to one person (“Well… you didn’t specify how you want the materials to be delivered so what’s the problem?”). Of course, if the team actually specified with facilitator how the balls should be entered into the system then you should skip this one;)
- Adding a new rule; Balls that fall on the floor are eliminated for that iteration (“Waste management!”)
These twists will not only make the game more fun but more importantly, they will bring it even closer to a real-life project execution, where communication issues, tight deadlines, and ever-changing requirements are a common factor.
5. The Paper Plane Game
Source: https://agileparkinglot.blog/activities-and-games-for-learning-agile/paper-plane-game/
Set up:
Teams should be formed out of 4–7 people. Each team receives 50 blank A4 pieces of paper. Facilitator prepares a whiteboard to write & keep track of scores. The venue, where the game is played, should be big enough for the paper airplanes to fly (or have a corridor available).
Rules overview:
The goal of the game is to create as many successful paper airplanes as possible within 3 iterations. What constitutes a “successful” is an airplane that flies at least 30 meters and has its front folded/blunt (for security reasons).
Each iteration consists of the 3-minute planning phase, 3-minute execution phase and 3-minute retrospective (where improvements in the process are discussed).
The rules for creating and flying the planes are as follow;
- Each person in a team can do only one fold at a time (all other team members have to make a fold, before a person that started can do his/her next fold)
- Testing of the airplanes can be done only during the execution phase
- Planes have to fly, you can’t mash them into paper balls and throw them
Additionally, at the end of each planning phase, the facilitator asks the teams for their estimations on the number of planes delivered in that round. Planes that were not completed or tested should be subtracted from the total of successful planes count.
Core takeaways:
- One of the best games out there for simulating scrum
- Great for showcasing how the estimations accuracy improve with the teams getting a better feeling of their own capacities/velocity
- Recommended for teams who already work in iterative processes, to stir the discussion about the things they could improve in their existing setup
My Comment:
This activity is probably the closest one to the real-life scrum of all listed here. Unlike some other games, it focuses less on showcasing what agile actually is, and more on how to improve iterative processes that are already in place.
A simple plane assembling activity that is a the core of the game can mirror real life problems that your team is encountering in their product development processes like; lack of communication, delaying of QA until last moment and overestimating the scope of the delivery.
It is important that the facilitator leads the discussion after the exercise and is able to steer it to draw clear action points on how learnings could be applied in real life scenarios.
