Skip to content

Latest commit

 

History

History
1515 lines (1106 loc) · 53 KB

Games.md

File metadata and controls

1515 lines (1106 loc) · 53 KB
Home | Agile |

Agile : Games

Agile Principles

Agile Values Puzzle

  1. Material & Equipment

  2. Objective

  • Agile Value Cards
  • Twelve Agile Principles Cards
  • I like to print them in A4 colored pages so one can put them in a board and they are visible and readable by all attendees.
  • To let participants learn and discover about agile values and principles in fully interactive and participative mode, without presentations, minimal facilitation, full debate and fun.

Instructions

Connection - What do you know about agile?

It is good to start asking to participants what they think agile is and what is not.

Write everything they say in two columns ("Agile is", "Agile is not") without questioning or arguing any response. This is just to capture what they "think" agile is.

Concept -- Clean up answers

After adding all entries, ask if any entry should be removed or someone disagree, discuss with the group and strikethrough the ones that are incorrect.

Concrete Practice - Agile Values Puzzle game

  1. No Manifesto yet: Do not mention anything about the agile manifesto, values or principles.

  2. Groups: Tell the attendees to split into 2 to 4 groups of about 2 to 6 persons. Do not say how, just let them auto organize.

  3. Agile Values:

    1. Provide a set of the  Agile value cards to each group
    2. Directions:
      1. Four pairs of concepts: Tell the participants to organize the cards into 4 pairs, where each pair should be two concepts that are contradictory on their own but complementary at the same time when they are together.
      2. More value: For each pair of concepts, tell the participants to select the concept that they think is more important in a scenario where you could only pick one and just one. Put the most valuable concept on the left.
      3. If at any steps a group is confused, do not give answers, tell them to consult to another group. Clarify the directions of the exercise if needed.
    3. Values Wall: Tell to each group to
      1. Pick one pair and stand up and show the cards to the other groups. They must pick a pair that no other group has picked.
      2. Explain to the other groups their selection and decision.
      3. If other groups do not agree or the selection is not aligned to the agile manifesto, facilitate discussion until they agree.
      4. If the other groups agree with their selection, they can put the cards on a wall with tape. The concept with most value should be on the left.
      5. Repeat until 4 different unique pairs of concepts are in the wall totally aligned with the  agile manifesto values page http://agilemanifesto.org/ . It should look like this: No alt text provided for this image

  4. Agile Manifesto: Explain that what they have built intuitively is the Agile Manifesto and these are the four values "That is, while there is value in the items on the right, we value the items on the left more." who are the signers, history and whatever else you want.

    1. Dot voting -- Most important / most difficult: You can also ask for dot voting on which value is the most important value and which one is the most difficult and discuss why.

  5. Agile Principles: Provide about 6 to 12  agile principle cards to each group and tell them that they are the twelve principles of the agile manifesto.

    1. Principles mapping to values: Tell each group to
    2. Discuss all the principles for 4 minutes and decide to which of the values each of them match better.
    3. Stand up with one principle, read it to all groups, say to which value they map it and put it in the row aligned to that value (this is totally subjective, there is no official mapping of principles to any value, it is just a memory and discussion game).
    4. Ask to other groups if they would like to add anything.
    5. Repeat until all the 12 principles are in the wall with the values. It should look something like this:

  6. Conclusion

  7. Videos

Ball Point

  1. Material & Equipment

  2. Objective

  • A great game for introducing Scrum to new agile teams.
  • The point of this game is to pass as many balls as possible through every team member in 2 minutes. The team gets a point for each ball passed through every member of the team provided that the first person to touch that ball is also the last. There are 5 iterations. Before each iteration the team estimates how many they think they will pass. At the end of each iteration the actual number passed is recorded.

Instructions

  1. Provide an overview of the game and the rules.

    1. Everyone is part of one big team.
    2. Each ball must have air-time.
    3. Each ball must be touched at least once by every team member.
    4. Balls cannot be passed to your direct neighbour to your immediate left or right.
    5. Each ball must return to the same person who introduced it into the system.
    6. There are a total of five iterations.

  2. Allow the team two minutes of preparation time to determine how they will organize themselves.

  3. Get an estimate from the team of how many balls they can pass through the system.

  4. Run a two-minute iteration.

  5. Allow the team one minute to discuss how to improve the process.

  6. Repeat for five iterations. Make the fifth iteration a challenge. If you need to, make up some ridiculous statistic such as "The world record is 150 points. Can you beat that?"

  7. Conclusion

  8. Videos

Example Based Specifications

  1. Material & Equipment

  2. Objective

Instructions

Schedule:

  1. 1 hour -- One person plays customer, the rest of the team writes tests
  2. 30 minute debrief
  3. 1 hour -- Small group discussions
  4. 30 minutes -- sharing and conclusions

Test Writing

  1. Group 1

Domain -- a statistical tool that evaluates inputs according to a formula, and plots the results.

Their test:

(A, B, and Y are inputs; b0, b1, b2, and b12 are outputs, produced by a process of matrix algebra.)

A B Y b0 b1 b2 b12
10 75 8 11.0 5.0 8.0 12.0
20 75 12
10 100 10
20 100 15

This is a textual representation of the graph

b0 b1 b2 b12 B-1 B-2 B+1 B+2
0 5 8 12 (1,1,RGB) (10,10,RGB) (10,1,RGB) (1,10,RGB)

Their expected graph (described here, though the team drew a picture):

  1. a large X with each line in a different colors

  2. labels +1 and -1 in the graph

  3. a horizontal axis labeled "A" (also having labels -1 to +1)

  4. a vertical axis ("Y")

  5. a graph name ("B").

  6. Group 2

Domain -- a session scheduler, matching audiences to rooms

Test: Schedule a session --

Preconditions: user has logged in, room size < audience size

  1. TU35 has iaudience 100
  2. Room NICA has capacity 25
  3. TU35 is not scheduled
  4. NICA is available Monday 11-12:30

Execution:

  1. User assigns TU35 to NICA at Monday 11-12:30
  2. System displays a warning, "Room size mismatch... Continue or cancel?"
  3. User selects "Continue"

Expected Results:

  1. TU35 shows up scheduled in NICA, Monday 11-12:30

  2. Group 3

Domain -- a graphical tool for tracking and identifying criminal conspiracies. (Tool helps build a network of connections between people).

Their test:

Select template criminal
Create node
Create node
Select link template ?
Create link
Check count links 1
Delete node 1
Check count links 0
Create node policeman
Set first name Tom
Set last name Nassau
Create criminal
Set last name Soze
Select link template arrest
Create link Nassau to Soze
Check link exists
Select template policeman
Create node
Add role
Select node 1
Check has role policeman
Check has role drug dealer

  1. Group 4

Domain -- an expense approval manager

A GUI mockup:

Manager approval: Purpose:

Type Date Description Amount Needs Receipt
American Airlines SEA to MSP $600.00

X

Issues: editing, are you sure?, manager approval, expense group

Test:

Type Date Vendor v Description Amount
Air tix 7/16/06 AA ORD to MSP 763.42

Purpose: Trip to agile conference
Manager approval:    Pointy-haired boss

An analysis of states:

New -- Open, can't pay, can't approve, can't close Submitted -- Open, can't pay, can approve, can't close

Is Open Can Pay Can Approve Can Close
New
Submitted
Approved
Paid
Closed

  1. Group 5 {#Agile-Games-Group5}

A stock trading program

A screen mockup with annotations:

Start Time [   ] v : [   ] v 9:30-16:00 ET (market start to market end)
End time [   ] v : [   ] v
Stock Symbol [    ] 1-4 alpha
# Shares [    ] 1
Order Size [    ] 100->1 million (int) (+- 100)
[Buy/Sell]
Price $ [    ] (optional) numeric + 2 decimal optional
[OK]    [Cancel]

Test of algorithm:

  1. Start time >= now >= 9:30 EST

  2. End time > start time <= 16:00 EST

  3. Distribution list (file) exists

  4. Test invalid symbol entry

  5. Test for valid symbol entry

  6. Test all shares are traded if no limit price

  7. Test trades don't violate limit price

  8. Buys or sells based on selection

  9. Group 6

Insurance tracking program

Test for story "Insurer adds provider":

Test 1 -- Sunny day

Add table:

Johnson, David name 15ch, 15ch
1200 Nicolette Dr addr1 40ch
12345 addr2 5d or 5d-4d
123456789 taxid 9 ch num
ALLINA network id must exist in db

Read: (same)

Test 2- Invalid zip code (and more like this...)

Johnson, David name 15ch, 15ch
1200 Nicolette Dr addr1 40ch
1234 addr2 5d or 5d-4d
123456789 taxid 9 ch num
ALLINA network id must exist in db

Expected error: "Invalid zip could should be 5 digits"

Test for story "Analyst approves pending claims < 60 days since claim made"

Test 1 -- Sunny day

Populate database -- set up claim 1

Date of claim 30 days ago
Member name Doe, Jane
Provider name Johnson, David
Diagnosis 769
Charge $500.00
Network id ALLINA

Step 1. Analyst views pending claims < 60 days (display claim A => OK)

Step 2. Analyst approves pending...

Signal "ok" = submit
Claim disappears from list
Message "approved"

Step 3. Read claim, status "approved"

  1. Group 7

Domain: Shipping company.

Test: 1. Customer ABC call to know where shipment with order #33 is. The system should answer, "Last stop was Tampa, FL."

Note Order # from Customer Request Answer from System
Truck left origin #33 last stop? Tampa, FL
Not in truck #34 last stop? nothing
Truck at destination #35 last stop? Daytona, FL
Truck at destination #35 arrived? yes
Not in truck #34 arrived? no
Not arrived #34 expected date? 26/7
Arrived #35 expected date? 25/7
Truck underway #33 arrived? no

Example context:

# Pick up origin Final drop destination Expected Date
#33 Tampa, FL Toronto, ONT 27/7
time 24/7 8 AM
#34 Vancouver, BC Toronto, ONT 26/7
time
#35 Toronto, ONT Daytona, FL 25/7
time 24/7 17:00 time 25/7 10:00

Test 2: I want the system to help me minimize empty truck displacement. For example, I want to be able to ask if there is an empty truck in Ontario on July 27. Arrival within 2 days.

Empty truck in? Shipment order
Ontario/27/07 #33, #34 truck at city
Ontario/25/07 no truck because wrong date
Montreal/QC no truck because wrong location

  1. Conclusion

We noticed these things from the experience of writing tests:

  1. What to do is vague.

  2. Developers tend to embellish.

  3. Tests teach developers, but it's a challenge to pick the right level.

  4. It's hard to turn descriptions into tests.

  5. Tests (and collaboration) can help you discover new things.

  6. The idea of a GUI became actions on a model (for the test).

  7. Customers should come in prepared.

  8. We need many questioners per answerer.

  9. Someone came in late, and found that the examples helped them understand.

  10. Topics

In small groups, we explored these topics:

  1. Sufficient coverage: How do you know you're done -- what's sufficient coverage?
  2. Test styles: What is the relationship between example-based specifications and other styles of tests?
  3. Product Owner: Techniques for interviewing product owners

Sufficient Coverage

  1. When adding tests to a legacy system, how much do you "backfill"?
  2. Should we just use "change detector" tests (record what the system currently does, knowing that it may change later, and may not even be correct).
  3. Do we need all combinations?
  4. Where do we fit example-based tests?

Test Styles

We suspected these things about example-based tests:

  1. They may bring about exploratory testing, regression tests, better unit tests, acceptance tests. Load tests?
  2. They provide a concise account of an edge case.
  3. They serve to train new developers in a domain.
  4. They provoke a certain style of conversation.
  5. They may overwhelm developers with distracting detail (no "metaphor").
  6. Alternatively, developers may ignore examples! It happens...

Product Owner

  1. Use Sophie's Rule -- keep asking "why?"
  2. Ask the end goal, define the business problem, define acceptance criteria
  3. Discuss requirements "as if you were blind" (without reference to UI)
  4. Need a customer who is is readily accessible
  5. Helps to talk to end users
  6. Programmers need to understand the domain
  7. Let product owners ramble

  8. Videos

Pizza

Material & Equipment

  • The slideset follows the game from the beginning to the end
  • Make sure you have adequate materials! See the list at the end of this page
  • There should be at least four persons per team
  • The game can be played with one team, but is more fun with more teams and a little healthy competition
  • (OPTIONAL) If there's an uneven number of people, consider asking somebody to act as an observer, perform quality assurance and measure lead time
  • Post-Its in three colors: yellow (pineapple), pink (ham*) and green (rucola i.e. rocket salad)
  • Printer paper to cut pizza bottoms from (A4/Letter works fine but you can also use other sizes)
  • Red markers as tomato sauce
  • Glue or transparent tape (to make the Post-Its stick better)
  • Masking tape (aka. painter's tape)
  • Scissors (one small + one large per team)
  • Stopwatch
  • Order cards - one set per team
  • Oven plate - one per team
  • The Kanban Pizza Game slides
  • Rule Sheets
  • Kanban Overview Sheets

Objective

If you want to understand what Kanban is and practice some Lean concepts in a safe environment outside of your daily work, then the Kanban Pizza Game is for you! We start our Kanban trainings with this game, in order to introduce the whole method and its principles and practices in one tight package. Software development teams and process development teams use this game to get acquainted with Kanban.

The game has been designed for a half-day workshop. It takes at least one hour at the bare minimum, if you rush through the principles and practices and don't wrap up much at the end. Two hours is enough to cover the theory adequately and allow for reflecting and summarizing.

What are the goals of the game from a training perspective? We want participants to:

  1. Experience how a Kanban system emerges from an existing process, as it does in the real world
  2. Experience a whole Kanban system, as opposed to focusing only on the Kanban board and related mechanics
  3. Understand that boards are context-dependent: for any given process there are many different board designs that are adequate and useful, but the perfect board doesn't necessarily exist
  4. Understand the effects of limiting your Work in Progress
  5. Experience self-organization and adaptation
  6. Have fun!

Each team gets paper of different colors, scissors and other materials (the full list of materials is at the bottom of this page). They will cut, shape and tape these together to form pizza slices according to the given recipe.

  1. Instructions

  2. Create an implicit process

Kanban always starts where you are, from an existing process. At the start of the game we let the teams to get to grips with the paper pieces and constraints by building as many pizza slices (Hawaiian) as possible.

Present a ready-made slice of Hawaiian pizza to the teams and explain what goes into the pizza: a slice of pizza base (paper triangle), tomato sauce (red marker), three slices of ham (pink Post-Its) and three slices of pineapple (yellow Post-Its). The tomato sauce covers the pizza bottom nicely and the toppings are carefully cut and distributed evenly across the pizza. Yum!

Show the oven plate and explain how it works. There can be a maximum of three pizza slices in the oven at one time. Cooking time is at least 30 seconds. No adding or removing of slices while baking!

Then ask the teams to produce as many pizzas as they can while trying to avoid waste i.e. raw materials prepared but not used. When you decide that time's up (after 5-7 minutes or so) clap your hands and tell them to stop.

  1. Introduce Kanban

At the end of the initial round, introduce Kanban and the core practices of Kanban:

  1. Visualize the Workflow
  2. Limit your Work in Progress (WIP)
  3. Manage the Flow
  4. Implement Feedback Loops
  5. Make Process Policies Explicit
  6. Improve Collaboratively

These principles are going to be used throughout the game.

Next, explain the scoring system and let each team calculate their score. The scoring system is designed to promote limiting the WIP and also serves as an indirect measure of flow (in our case, it correlates with the lead time as long as people don't know the exact length of the round, and thereby produces the same behavior). Collect the scores and write them down in a matrix (teams vs. rounds) on a whiteboard or flip chart. At this point you can also ask the teams to pick names for their pizzerias.

Ask the teams to visualize the workflow and make the process explicit by introducing storage for production materials (pizza bottoms, slices of ham etc.) directly on the table. Don't try to optimize the workflow now, just document it as it emerged during the first round. The teams can use the materials at hand, e.g. painter's tape (masking tape), post-its, paper and so on.

Ask the teams to limit their work in progress. Did they have materials piling up and becoming waste at the end of the round? What would be a sensible WIP limit for that step and for the other steps?

How about the pizza quality? Did the teams cut corners (perhaps literally)? Pizza bottoms should be the same size and well covered with tomato sauce, and the toppings should be nicely cut and distributed evenly. Ask each team to bring forward their best pizza(s). Then ask the room to choose the most beautiful specimen. This will become the Reference Pizza and should be put in a prominent and visible place.

Before the next round, ask the teams to throw away the half-baked and delivered pizzas, but keep the unused raw materials for the next round.

  1. Second round with established Kanban system

Now run a new one round with your newly established Kanban system. Again, don't give any indications of when the round will end, just end it when you feel like it's a good moment in time (after 5-7 minutes). At the end of the round run a debrief and count the points.

  1. Third round, extending the system

Make the game a bit more complex by introducing the new Pizza Rucola recipe and the concept of customer orders.

  1. Pizza Rucola contains only tomato sauce and seven pieces of rocket salad (green Post-Its). There's no ham and no pineapple. Unfortunately rocket salad burns easily and must therefore be added after the pizza has been taken out from the oven.
  2. Orders can contain several pizzas of two different kinds, and the team gets points only when the whole order is fulfilled and delivered. Establish a central place where teams can pick up new orders and deliver fulfilled orders. Teams can pull several orders at once, but not so many that it affects other teams.

When you have presented the extensions to the game and answered any questions the teams may have, allow the teams five minutes to discuss and extend their system to account for Pizza Rucola and the orders.

Run the third round. Debrief, measure the points.

  1. Fourth and final round

Allow the teams some minutes to discuss and improve their system. Tell them to play around with the workflow and try different WIP limits.

Run the fourth round. Debrief, measure the points.

  1. From the game to a real Kanban Board

The final step in the game is to visualize the process that is currently drawn on the tables with painter's tape, and create something that is closer to a real Kanban board.

Ask the teams to look back on the game, draw the flow on a flipchart or whiteboard (including WIP limits) and make it look nice using paper materials and pizzas produced during the game.

  1. Conclusion

Having the experience of the Pizza Game in fresh memory and some nice Kanban boards on display, it's now really easy to anchor the Kanban practices.

  1. Visualize the workflow

With the physical production of the Pizza the workflow is always present, and by drawing the workflow we create a model that we can use for reflecting on the current process. Remember: all models are wrong, but some are useful. The workflow is a simplification and can never match reality perfectly, but it allows us to study and understand our work.

Note that the workflow can be represented in multiple ways. The fact that some pizzas go into the oven with toppings and some without can be described using tags, swimlanes, non-linear workflows, directed networks, cadences (alternating between hawaii and rucola in the oven) or a number of other methods.

Over the course of the game, each team created a workflow that made sense in their own context of people, resources and bottlenecks. While it is likely that other teams could pick up a board and make it their own, it doesn't mean that any one of the boards is necessarily "more right" than the others.

  1. Limit WIP

Throughout the game, the built-in bottlenecks caused queues to pile up. This is intentional. During the game the teams introduced limits on the work in progress (WiP) to make sure that they produce the right things and to avoid losing points for unused materials. The participants experienced that WiP limits are more than simple limitations: they drive and change the behavior of people. People tend to interact more on the overall production, communicate more and help each other when needed.

  1. Manage flow

Kanban works best when work is flowing nicely through the system. Normally you would increase the flow by measuring and minimizing the lead time. Unfortunately this takes too much time away from the facilitator, and so in the Pizza Game we use a scoring system that is set up to penalize inventory and trigger similar flow-optimizing behavior.

In the first rounds of the game there is a tendency to prepare small stockpiles of materials in advance. In later rounds the team learns to keep inventory down and maintain flow by tightening the WIP limits.

Measuring the flow in the Pizza Game can be very instructive, but you will need a co-facilitator to do this.

  1. Make process policies explicit

After the first round, each team documented their workflow by marking it on the table. Any changes to the system were made immediately on the table. We also set a common quality standard by selecting a Reference Pizza. How did this help the work? How about roles? Did people have clear roles? How did they appear? Who allocated the "resources" in this simulation?

  1. Implement feedback loops

What did we collect feedback on? Ask the teams to think for a moment about what kinds of feedback loops there were in the game, and write these on post-its. You can either collect all post-its on a board, or ask people to give examples. During the debrief, ask them what would have happened without each specific type of feedback.

  1. Improve collaboratively and experimentally

The game consisted of four rounds, with time for inspecting and adapting in between. What would have happened without the possibility to inspect and adapt? Who did the inspecting and adapting? What information was it based on? What did people in the tables talk about during pizza production?

  1. Other things worth considering:

  2. The physical environment: Did the original table arrangement affect the initial workflow? The way the workflow evolved?

  3. Group dynamics: How did the different team members participate in design of the workflow?

  4. Videos

Story Maps

Template

  1. Material & Equipment

  2. Objective

Giving people an idea about what a Story map is and how it can be used to facilitate prioritization, release planning and finding MMF's

  1. Instructions

To describe what a story map is. Then I roughly do it this way (You might want to twist the "story" a bit. The one below is just the basic version).

Divide people into groups of 5-8 and hand each team these user stories and vision.

Draw the following backbone on a whiteboard -- one for each team.

  1. Log ind
  2. See available appointments
  3. Book appointment
  4. Confirm
  5. Change
  6. Remind
  7. Admin.

Story: Tell them they are both hairdressers trying to set up a business in a small town and will be competing for the same customers as well as against existing hairdressers. Market research shows that this particular town is filled with young people eager to have a more flexible
and easy way of booking hairdresser appointments and that given the opportunity to do this online, whenever they want, they would turn away from their prior hairdresser. It does however have to very quick and intuitive for them to make this transition.

Time to market is key and the first hairdresser on the market with an online solution that customers accept will likely survive while the other will go bankrupt within a very short while.

Timeline: Give them 10 minutes to go through the user stories and place them in the "right" column on the backbone (there is no right or wrong). Then allow 20-25 min. to find the "Walking Skeleton" and the content of the next 2-3 subsequent releases.

The winning team will be the one that can offer the most convincing story on why they chose to balance functionality and time-to-market the way they did. Having a theme/vision for each release will give them extra points but of course the most important thing is their story and the arguments they use to explain why their release plan is the best one.

  1. Conclusion

  2. Videos

Multitask

Name Game

  1. Material & Equipment

  2. Sheets of paper or cardboard name cards, one per person

  3. Sharpies/pen, at least one per 5-8 person table

  4. Objective

Create a name card (first name only) for each participant

  1. Instructions

  2. Round One

  3. Choose a Worker at each table; everyone else will be a Customer.

  4. Customers will each time how long it takes the Worker to write down their names.

  5. Begin the exercise: All Customers begin shouting their names at the Worker, who starts writing them down, one per card.

  6. The exercise ends when all names have been recorded. Note the best and worst times.

  7. Round One Debrief

  8. Note the chaos that likely ensued. This closely parallels the way prioritization works at many companies (e.g. the squeakiest wheel gets the grease).

  9. Ask a Worker how they felt. They probably were stressed, distracted and frustrated.

  10. Write the best and worst completion times somewhere visible. We'll compare these results to those in succeeding rounds.

  11. Round Two ("Everyone's Happy?") Instructions

  12. The Worker, Customers and Goal remain the same.

  13. The Worker will write each person's name one letter at a time in a round robin fashion. 
    Example: If Anna, Bill and Joey are on the team, the Worker would write "A" on one sheet of paper, then "B" on another, and "J" on the last. Then they would revisit those sheets to write "n," "I" and "o" (the second letters in each name), continuing until all names are complete.

  14. Round Two Debrief

  15. Note how things were now orderly, but very inefficient, and ask why. Several forms of waste are occurring here, but most notably context and task switching. There is also motion waste (moving from one card to the next), transportation waste (moving the cards themselves), and waiting (the time between actual writing), all of which impact throughput of completed work.

  16. Ask Customers how they felt. By servicing all customers at once, we serve none of them well. Compare this round's times to the last.

  17. Ask Workers how they felt. This round was likely frustrating in a different way; while the process was orderly, a sense of true closure and productivity was likely missing. A great deal of working was happening, but little work was getting done.

  18. Round Three ("Focus") Instructions

  19. The Worker, Customers and Goal remain the same.

  20. The Worker chooses the order of Customers to service

  21. The Worker writes each Customer's name in its entirety before moving on to the next.

  22. Round Three Debrief

  23. Ask Customers how they felt. How was this time different from the previous rounds? Was the capacity clearer? Did you feel a need to fight for the top spot? Compare the results; they should be at least twice as quick as the previous rounds, and possibly several times.

  24. Ask Workers how they felt. This approach is by far the best controlled, least stressful and easiest to manage.

  25. Could this work even better? One thing we could do to make this more "agile" is prioritization by value, which could start a conversation about Product Owners, if desired.

  26. Conclusion

In summary, the human brain does not multitask. Focusing on a single job at a time yields better quality, faster delivery, happier customers and less wasted time. This factor becomes vastly more critical when dealing with teams of people and the attendant destructive interference from so many simultaneous possible interactions.

This lesson has substantial implications at all levels from individual task management to project portfolio management and resource allocation systems, and is fundamental to lean-inspired methods such as Kanban. This concludes our third entry on Agile games. Once again, let us know if there's a particular lesson you'd like your teams to learn, and we'll see if we know an exercise to demonstrate it.

  1. Videos

Three Little Pigs

  1. Material & Equipment

  2. paper and pen

  3. Objective

Will be comparing the effects of divided attention versus focused attention.

  1. Instructions

  2. Round 1

You will attend to two different cognitive tasks.

Task 1: For the first task, grab a sheet of paper and a pen. You will be writing a story. Your story can be about anything: How your day was, "The Three Little Pigs," anything.  Allow students to set up materials.

Task 2: While performing task one, you will have another simple task: Count backwards in increments of "1" from 200 to 1.  *200, 199, 198. *And, do so  out loud .

As students are performing this set of tasks, time them to see how much they accomplished in 4 minutes.

At the end of round 1, jot down what number you ended at and how many words you wrote.

  1. Round 2

You will attend to one task at a time. You will spend two minutes on task one. Then, I will announce for you to switch and spend two minutes on task 2.

Task 1: You will once again write a story. Please make your story about something different than in round 1.

Task 2: Count backwards from 200.

After 4 minutes, jot down how many words you wrote in task one and the number on which you ended your count. Discuss your findings!

  1. Conclusion

  2. Videos

Hands, Numbers, Song

  1. Material & Equipment

  2. 6-20 people (note - if you have more than this, just split into multiple groups. In theory you can handle as many people as you have space for)

  3. One facilitator

  4. One stop watch

  5. White board / Easel or equivalent to record a few scores.

  6. Objective

  7. Instructions

  8. Round 1 - Warm-up

  9. Have each person pair up and then line up in two lines facing each other like this:

    1. A1 A2 A3 A4 A5 (A1 faces B1, A2 faces B2, etc)
    2. B1 B2 B3 B4 B5
    3. If you have an uneven number, you can ask one person to be your time keeper. If you have some sceptics or others who don't want to participate, you can ask them to be observers ;). However, you need at least 3 pairs and more is better.

  10. Have each pair practice the Hands activity as below

  11. Now switch pairs by having everyone in line A move one spot. A5 will have to move all the way to A1. Your line should now look like this:

    1. A5 A1 A2 A3 A4 (A5 is paired with B1, etc)
    2. B1 B2 B3 B4 B5

  12. Have each new pair practice the Numbers activity below

  13. Now switch pairs again by having everyone in line A move one spot. You should now look like this:

    1. A4 A5 A1 A2 A3
    2. B1 B2 B3 B4 B5

  14. Have each new pair practice the Song activity below

  15. Round 2

  16. You as the project manager will tell the teams which activity (project) to work on.

  17. You will bark out instructions ("Shout-Driven Develolpment") and they are expected to switch tasks on your command. For each activity they need to switch to perform the activity with the pair they practiced that activity with. (This will involve a lot of movement.)

  18. When each pair resumes an activity that they have already started they must pick up where they previously left off.

  19. Your time keeper should record the time when the whole team (all pairs) have finished each activity.

  20. Keep asking the team to task switch every 2-10 seconds (be random!) until all pairs have completed the activities.

  21. Record the completed time for each activity.

  22. Round 2

  23. You as the project manager will tell them the priority of the activities (projects). You will ask them to complete Hands first, Numbers second, and Song third. You ask them to complete each activity (project) before starting the next.

  24. Your time keeper should record the time when the whole team (all pairs) have finished each activity.

  25. Record the completed time for each activity

  26. Your results should look similar to the results in the image below. Note: we played this game twice after adding more people - the purple numbers are the results of the second game.

  27. Additional Tips and or Alterations

  28. Have the group decide how to rotate partners instead of defining the rotation for them.

  29. Run the sequential round first and then the multitasking round.

  30. Have the group choose their own song instead of Happy Birthday.

  31. For larger groups, ask them to put their hands up when they complete each 'project'. This will help the time keeper to understand when each project is completed amidst the chaos.

  32. Instead of acting as the project manager, act as the product owner who represents three different customers/stakeholders.

  33. Conclusion

  34. Videos

Work In Progress (WIP)

Coin Game

  1. Material & Equipment

  2. 2 sets of 15 Coins

    1. 5 x $0.25
    2. 5 x $0.10
    3. 5 x $0.05

  3. 2 teams of 3+ people. Teams need to be even.

  4. paper and pen

  5. Timer or stop watch

  6. Objective

The worker passes the pieces to the customer. The customer measures the time that the first piece has to arrive at him and the time that all the pieces put to arrive to him. Finally, the manager measures the time taken by the worker to get rid of his pieces.

Each member of the team would represent someone in the SDLC. Ie.. BA, Developer, Tester, and Stakeholder.

  1. Instructions

Customer would be represented by the organizer or person who is timing the game.

Give a set of to the first worker in both teams. Instruct everyone that the objective of this game is to process the coins through the system of workers.

Worker can only use one hand - usually the non dominate.

Small Group / 1 Team

  1. Round One

Workers operate on the full batches i.e. they may only pass coins to the next worker once they have flipped all 20 coins

  1. Round Two

Workers operate on half of the batches i.e. they may pass a batch of 10 coins to the next worker once they have flipped 10 coins

  1. Round Three

Workers operate on third of batches  i.e. they may pass a batch of 5 coins to the next worker once they have flipped 5 coins

  1. Round Four

Workers operate in batches of 1 i.e. they may pass each coin to the next worker once they have flipped it

Multiple Teams

  1. Scenario 1

  2. Team 1 - Waterfall

To process the coins. Each coin must be flipped and stacked one at a time -- and then passed the stack to the next worker in the chain who will flip and stack one coin at a time. Once the stack have been processed by the team, they are considered "done".

Workers may only pass the coins once the full batch of coins is complete.

  1. Team 2 - Agile

To process the coins. Each coin must be flipped before passing it to the next member of the team. Once the stack have been processed by the team, they are considered "done".

  1. Scenario 2

  2. Team 1 - Waterfall

To process the coins. Each coin must be flipped and stacked one at a time -- and then passed the stack to the next worker in the chain who will flip and stack one coin at a time. Once the stack have been processed by the team, they are considered "done".

Workers may only pass the coins once the full batch of coins is complete.

  1. Team 2 - Agile

To process the coins. Each coin must be flipped before passing it to the next member of the team. Once the stack have been processed by the team, they are considered "done".

  1. Conclusion

  2. Videos

Movie

  1. Material & Equipment

  2. Objective

  3. The one experience I know we share is the session we're in, but using a retrospective on the class sets up an awkward "meta" and recursive dynamic, as we try to do something and think about doing it at the same time.

  4. A class often shares another experience (or set of experiences): the projects they're working on. Everybody may not be on the same project, but even if they are, real projects have real issues, and using real issues for an example almost instantly violates safety and takes away the magic circle aspect where it's safe to try new behaviors.

  5. Instructions

Identify a movie as the shared experience. I've been using  Star Wars, Episode IV, with the part of the movie from the rescue of Leia until Obi-Wan dies and the protagonists escape. (Sorry if that's a spoiler:)

(I'm sure other well-known movies would work as well but I haven't tried any; perhaps The Wizard of Oz or The Godfather or something more modern?)

It's possible a person or two hasn't seen the movie; I'm willing to take that chance. If I thought the background of the group was so diverse that a substantial part of the group would not have a shared movie, I'd try a different approach.

Ask people to imagine they were the protagonists, to recollect for a moment what happened in the relevant part of the movie.[A couple times I tried to show the movie clip in fast-forward. From a technology standpoint, it was painful. But from the perspective of the simulation, it's a better simulation NOT to show anything. As in real life, people will have different memories of what happened and different perceptions of what's important.]

Use the recalled scenes as the basis for a retrospective.I like Esther Derby and Diana Larsen's approach in Agile Retrospectives, and I use an abbreviated sample exercise addressing each of their sections. For example:

A. Set the stage: Check-In -- "In a word or two, what's on your mind?"

B. Gather data: Timeline -- "Recall the memorable, meaningful, and/or significant events; write one per sticky note, then put it on the timeline."

C. Generate Insights -- Patterns and Shifts -- "Look for patterns. What links? What shifts? Which are most important?". Or perhaps do a "Worked Well / Do Differently" analysis.

D. Decide What to Do -- Dot Voting -- Give everybody 3 dots to vote for what to focus on as a group over the near term. (They can put their dots on 3 different things, or all on the same one if they feel strongly.) Agree on the immediate (concrete) next steps, who will lead them, and how and when progress will be reported.

E. Close the Retrospective -- Appreciations -- Identify how others have contributed. "Bob, I appreciate you for ___." ("Thank you.")

Even doing this in an abbreviated manner (a few minutes for each) lets you run through a complete retrospective in miniature.

You can then follow it up with some debriefing to bring out any points you need to make.

  1. Conclusion

  2. Videos

Leadership

How Agile Are you

  1. Material & Equipment

  2. 2-6 players (even though more is possible)

  3. Intended audience is management

  4. Takes 1.5 hours (on average)

  5. Needs a skilled facilitator

  6. Objective

This game has been designed to get discussions on agile leadership going and to ensure that people start observing behavior that belongs (or does not belong) to an agile organization. It is specifically intended for management teams. The game is focused on agile mindset and agile leadership: what do people and organizations need from management when engaged in an agile transformation?

  1. Outcomes

  2. Participants need some time to figure out how to play the game and how to work with the quadrants on the board.

  3. An ice breaker to start with and a small warm up round increases effectiveness and actionable outcome of the game.

  4. Making sure the topics in the discussion round are precisely those that matter most to the organisation and the participants, adds greatly to the usefulness of the session.

  5. You need a skilled facilitator.

  6. Instructions

Participants are asked to very rapidly (! ten seconds per card on average :) !) divide forty-two cards with 'characteristics' of organizations, over one of the quadrants on the board. As a participant you are to decide how the characteristic manifests itself in your organization at this moment. The game board consists of the quadrants "LET GO, IGNORE, CREATE and KEEP" as you can see in the image below.

If the characteristic on the card is behavior that the organization DOES HAVE at that time but that you DON'T WANT, the card gets sorted in the quadrant "LET GO". If the participant perceives the characteristic on the card as a behavior the organization DOES HAVE and that you DO WANT, it ends up at "KEEP" and so on. An example of a characteristic is "management spends a lot of time putting out fires".

There is no right or wrong: the game provides insight in the current state of affairs. The characteristics are labelled in types of behavior belonging to types of organization. So you could end up with lots of characteristics belonging to agile organizations in the "CREATE" quadrant. :)

After the time box for sorting the cards ends, the participants will discuss the characteristics that seem most relevant to them and their organization. Each participant gets the chance to enter at least one card/characteristic into the discussion. This needs to be (well) facilitated by an experienced coach/agile master. You can take as long as you like for the discussion and could do several discussion rounds, but we would recommend not to have it last for too long (1.5 hours max).

After the discussion round it is useful to add an extra step in the game as to make the outcome more actionable: the participants priorities the top three of characteristics/topics they would like to let go or create. These are the topics they can start working with the very next day! This way you also prevent the session being perceived as just fun, irrelevant and/or without consequences. Because there are forty-two cards in the game and you won't discuss them all, the game is most suitable to be played again at a later time -- it won't lose its value.

  1. Conclusion

  2. Videos

Generic Questions to ask after each game

  1. What did you think of the game?
  2. What are some conclusions you can draw about how you are currently working?
  3. Notice that in the second attempt you completed all three tasks before you completed the first one in the multi-tasking round. What do you think about that?
  4. For the two rounds, notice your time to market.
  5. How different was the quality of your product in round one and two?
  6. What did you notice about your stress level in round one and two?
  7. What does this game teach us about sustainable pace?
  8. Describe your discipline level in each round. How much did your team cheat or ignore the manager's orders?
  9. How does that affect how you will work?
  10. What happens when you task switch?
  11. What are the costs to juggling tasks?
  12. How can we change the way we work to take advantage of this?
  13. What are the barriers to making this happen?
  14. How can you respond to someone who is asking you to switch to another task or to split yourself between two or more projects
  15. JWorks - Agile Leadership Game

References

  1. Lithespeed - The name game a multitasking game for agile teams
  2. Tasty Cup Cakes - the penny game
  3. We Are Teachers - Proving the myth of multitasking with a simple experiment
  4. Winnipeg Agilist - Multitasking game handsnumberssong
  5. Trifork Agile - exercise introducing story maps
  6. XP123 - movie retrospective
  7. XP123 - Agile 06 workshop example based specifications
  8. Agile42 - kanban pizza game
  9. Linkedin Teaching learning scrum agile values puzzle game ignaciopaz