Timing:1 Hour

Overview:

Most of us find ourselves multitasking at some point and are possibly even proud of our multitasking skills. Here is one game that was created by Alan Cyment and introduced to me by Gerry Kirk and Yves Hanoulle at SDEC11 that allows you to simulate the actual costs of task switching. The game involves pairing up to perform three different simple but coordinated tasks and comparing your times and experiences after using both multitasking and single tasking processes. It generates a lot of laughs and a lot of excellent discussion.

Learning Points:

Exposing the myths of multitasking and demonstrating the costs of task switching. Tips and links for avoiding multitasking.

When your team is ready for it, this is a great game for starting the discussion on multitasking (personal and project) and how to change.

Link to Game: http://winnipegagilist.blogspot.com/2012/01/multitasking-game-handsnumberssong.html

Timing:

30 minutes including prep and debrief

Overview:
A simple little game to help Scrum teams learn the importance of having a common understanding of a story.

So a while back I was having seeing a team have different interpretations of a story causing some confusion. Differing interpretations of the feature caused a little backtracking and introduced waste into the sprints.. nothing awful, just not ideal.

I came up with a very simple exercise to help the team understand that we can too easily make assumptions that everyone understand exactly what we mean, and the in fact our mental models are often quite different.

So I asked them to write down how they make Spaghetti Bolognese (or if you prefer, like me, Ragu*), a dish most us were likely to know. So they spent a few minutes thinking about it, and after everyone was done we went round the team reading out the ingredients.

Can you guess what happened?

Everyone had similar ingredients, but not the same. Most people had Mince, Onion, Carrot, Tomatoes.. some extended it into Celery (correct), a few added mushrooms (wrong), I had both Beef & Pork mince as well as Pancetta, Red Wine, Nutmeg, Oregano, Milk and Beef stock and not Spaghetti but Tagliatelle (I was taught this way by an 84yr old Italian Nonna, any deviation was food crime in her eyes ).

Learning Points:

So what did it tell us? We all know what Spaghetti Bolognese (*cough*  Tagliatelle al Ragu) is, but all had different interpretations. The team could draw the parallel from this to the assumptions we were making about other peoples understanding of a feature. It led to some very interesting discussions and a team habit of reiterating to each other the feature under development during sprint planning.

It eliminated much of the confusion and helped the team pull in a single direction.

Link to Game:

Ragu or Bolognese?

*Not Ragu the brand, Ragu is the correct name for the dish we know as Spaghetti Bolognese.

Timing: 30 minutes – 1 hour including prep and reflection.

Materials: One game of Battleships

People: 2 Teams, or 1 vs 1

Overview:

This is a game I use to introduce people to iterative development. The aim is to help the players to understand that upfront large plans are pointless the minute they are created. Helmuth (quoted above), for me, was one of the first proponents of an iterative approach. He didn’t necessarily create grand plans, conversely he didn’t disregard planning altogether, but he was smart enough to plan just enough and adjust his plan to meet the changing reality. Often my experience of working on projects with large up front plans, the opposite is true and the owner of that plan tries to adjust the reality to fit the plan.

So how do you play it?

Simple, one player (Player A) is given 40 pegs and told to place their ships and all their planned attacks up front. The second player (Player B) simultaneously places their ships. Once that has been done, the first player reads out the 40 pre-planned attacks and is given the hits and misses. Player B then get to play each attack (up to 40) separately, getting feedback on hits & misses for each.

It’s pretty obvious what will happen, most of the time Player B’s turn (iterative) based play will allow him to adjust and change his plans as he scores hits. Player A (large plan) will score hits, but is far less likely to sink all the opponents ships. So player B being limited to 40 moves also may sink the whole fleet or not, typically though that player will score more hits than the other.

What does this tell us?

Predictive planning is unreliable and is akin to reading crystal balls, reading tea leaves or any other clairvoyant technique you care to mention. Ultimately you’re predicting the future based on an infinite number of possible outcomes, effects and variables. The iterative approach is empirical, each time Player B hits his opponents ships, he can instantly change plans and target nearby locations to sink it.

Occasionally Player A wins, this is a bit like the fortune teller coincidentally getting something right, it’s often more luck than judgement.

Learning Points:

Iterative development allows you greater flexibility to the changing world, environments and needs of the business.

Often the player with the large upfront plan will score hits but not sink the ships, this could be a metaphor for a testing phase of a traditional waterfall project not being completed before time or money runs out.

Link to Game:

You Sunk My Methodology

Read more here at the conference website.

http://www.agilegames2012.com/index.php/8-news/36-callforgames

• 1 hour

Players (5..8 recommended):

• Project manager or facilitator
• Internal team

Ingredients:

• internet access
• a goal

Directions:
Circles of Influence, created by Deb Colden, can help you achieve your action potential by identifying connections that will lead you to success. Take advantage of this game to expand your network and turn your thoughts into plans.

Clicking on the image to the right will start an “instant play” game at innovationgames.com. Here, these two circles will be used as the “game board,” which will help you organize your connections and support. As a group, define your goals by dragging the blue stars from the upper left corner to the top of the board and describing what each represents. Then, move on to the circles.

• Left circle: “Circle of the Task”
• Right Circle: “Board of Directors”

The “Circle of the Task” represents people who can help you accomplish your goal. “Board of Directors,” is for people who will help you no matter what, and on whom you can rely on to provide encouragement and advice.

There will be two different icons that players can drag onto the circles and describe to represent your network:

• Green people – those in your “Circle of the Task”
• Blue people – those on your “Board of Directors”

All moves can be seen in real time by each participant, so everyone can edit the positions and descriptions of the icons. Also, the integrated chat facility allows you and your players to collaborate to uncover your connections.

Key Points:
This game involves visual organization and extensive collaboration to identify people who will help you reach your destination. By writing specific names, you can turn potential connections into beneficial relationships, and form a more focused approach on how to achieve your objective. Get the job done by expanding your network while utilizing the support of those who know you best.

A physical-participation disentanglement puzzle that helps a group learn how to work together (self-organize) and can be used to illustrate the difference between self-organization and command-control management or simply as a get-to-know-you icebreaker. Standing in a circle, group members reach across to connect hands with different people. The group then tries to unravel the “human knot” by unthreading their bodies without letting go of each other people’s hands.

Why you’d use it:

As a management-awareness game to illustrate required change in behavior and leadership on a management level (e.g., illustrate the change from ‘task-oriented’ management towards ‘goal/value-oriented’ management).

Timing: 15-30 minutes

Materials and environment: space (indoor or outdoor) big enough for a groups of 7-16 people (can scale for up to 200 people)

Instructions (from Holden Leadership Center):

1. If necessary split the entire group into smaller groups of 7 to 16 people (too many people in a human knot becomes extremely difficult). Groups of 10-12 are ideal.
2. Arrange group members in a circle, standing shoulder to shoulder.
3. Tell everyone to put his or her right hand up in the air and then grab the hand of someone across the circle.
4. Everyone then puts his or her left hand up in the air and grabs the hand of a different person.
5. Check to make sure that everyone is holding the hands of two different people and that not holding hands with someone directly next to him or her.
6. Tell group members to untangle themselves to make a circle without breaking the chain of hands.
7. If group members break the chain they need to start over.

Notes: 

• To illustrate the concept of centralized, top-down decision-making vs. self-organizing, run the activity twice: The first time, have a “manager” tell the participants how to solve the knot (they must obey); the second time, remove the manager (or let the manager observe and answer questions for the team) and let the participants solve for themselves.
• You can give teams a time limit on this activity to make it more challenging.
• You can also mute/ blindfold participants throughout the activity.
• Instead of making groups start over when the chain is broken you can create penalties like blinding or muting a group member.

Debrief/ discussion questions:

1. How did it feel to be successful/ unsuccessful?
2. How did it feel to be mute? Blind?
3. What strategy did your team end up using to complete the task?
4. Who were the leaders in this activity?
5. Did the team reach consensus on a plan of action? What process did the team go through to reach consensus?
6. How do you feel your team communicated during this activity?

Links:

• http://leadership.uoregon.edu/resources/exercises_tips/team_builders/human_knot
• http://wilderdom.com/games/descriptions/HumanKnot.html

Timing:

Prep: Printing out the handouts

Activity: 45 – 60 minutes, depending on the size of the group

Materials:

Handouts, pads of paper (# attendees / 2), pens (same as pads of paper)

Instructions:

This activity will occur in two rounds. The first round involves each person in the audience working along. You will ask them to write a story about something interesting that happened to them at work recently. Give them five minutes to write. At the end of the five minutes, ask for volunteers to share their stories. Two or three should be sufficient. Expect that generally they will be somewhat mundane/pedestrian, and also be prepared that someone might be very funny or fascinating.

The second round involves pairing. Each pair will write a short story (fiction), based on “requirements” (see The Requirements below). The pair will take turns working on the story, alternating as indicated below.

Activity will be broken into two minute turns.

During each turn, one member of the pair will write, while the other will watch and ensure that the constraints are met (see The Rules below).

At the end of each turn, you will have them switch roles.

There will be seven turns.

At the end of the time (all seven turns), you will give them two more minutes to “refactor” their stories.  Then you will give as many pairs as possible an opportunity to read their stories aloud to the rest of the class. Expect a mix of boring/mundane (john said and then mary said) and incredibly creative/funny.

1. Introduce the setting: work, geography, industry, weather, time of day,…
2. Introduce character one: gender, name, age, education, single/married/paired/whatever
3. Introduce character two: gender, name, age, education, pet(s), hobbies
4. Introduce character one’s job
5. Conversation between One and Two about a problem at work
6. Manager appears and participates in conversation
7. All three go out for lunch: where, what kind of food, how do they get there

The Rules

• No sentences longer than twenty words – shoot for ten or less.
• Character names no more than two syllables.
• No paragraphs longer than five sentences.
• No “he said” and “she said” – must use names.
• No sentence may begin with “So” or “And” or “But”.
• Use adjectives judiciously.
• Locale must be a real place.

Gomez Goobers was a happy place to work. GG, as it is known in the industry, is in the heart of Chicago’s South Loop. In September, the weather was cooling off and people were walking the streets for pleasure.

GG’s lead programmer, Tim Thomas, loved living in Chicago. After college, he met Mary, whom he married two years later. Tim and Mary have been married for three years now. Tim and Mary live in a small, two-bedroom house in a nearby suburb of Chicago.

Tim’s counterpart was Billie Bliss, the lead QA. Billie, who is an avid dog lover, lives in town in an apartment overlooking the lake with her Beagle named Bugle. Everyone wonders where Billie got the money to afford a place like that. At twenty-five, she’s too young to have accumulated much. Her co-workers speculate, and her family and friends aren’t telling.

After completing both a bachelor’s and master’s degree in computer science, Tim came to work at GG. He loves technology, loves programming, and has progressed rapidly in the year and a half he’s been at GG. He has already worked in several programming languages and on several operating systems. These days, he’s focused on Ruby on Rails on a Linux platform.

Tim and Billie have been struggling with getting their teams to work together more effectively. Unfortunately, they are plagued by…

Decide who is going to write, and who is going to observe for the first turn.

Learning Points:

• Working in pairs produces results that we would never produce on our own
• Creativity is increased by pairing
• Pairing can be fun
• Pairing produces more effective results than working alone

Timing:

• Prep time: 30 – 60 minutes
• Execution time: 45 – 60 minutes

Materials:

One set of LEGO per team. Each set should include the necessary pieces to build a cube (see images in ZIP file) plus some random pieces. You can include base pieces or not. I don’t, because it adds to the challenge and the fun, having them figure out how to make the pieces stick together. Include at least a few flat pieces in each set, though, because it’s almost impossible without.

Instructions:

The participants should be divided into project teams that have between 4 and 8 people (smaller teams are preferable). Each project team should have two halves, call them left half and right half. Each half will have between 2 and 4 people. There should be as many project teams as necessary to include all participants.

Room = 15 people
Project Team = 5 people (3 project teams in room)
Left Half: 3 people
Right Half = 2 people

Here’s another way to split 15 people:

Project Team: 7 or 8 people (2 project teams)
Left Half: 4 people
Right Half: 3 or 4 people

With a group of 10 people:

This exercise will be done in two rounds. In round one (The Waterfall Way), the halves of each project team will build a specific object, using LEGO, based on a set of “specs” – three pictures of their finished “subsystem.”

In round two (Continuous Integration), the halves of each project team will build the same object, but in iterations, performing integration at the end of each iteration.

Both rounds lead to the same goal: at the end of the round, the two subsystems fit together cleanly to create the final “system.”

The pictures below reflect the finished “system.”

Each half of each project team (left and right) receives their specs, and is given 3 minutes to look over their LEGO and to discuss what they’re going to build.

Left Half builds the object specified in the set of specs named left-finished-xxx.pdf.

Right Half builds the object specified in the set of specs named right-finished-xxx.pdf.

• Neither pair gets to see the other pair’s specs
• Neither pair gets to see the other pair’s work in progress
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done
• When both pairs are done, they will try to fit their subsystems together
• They will make modifications until they are successful
• Record the time when both pairs first say they’re done, and then record the time it takes to get the two subsystems to fit together (build time, integration time, total time)
• You will probably need to get the pairs or project teams to track their own times, depending on the size of your group
• Expect that the teams will not finish simultaneously, so track the time per team for build
• Expect that the two subsystems will not fit together properly – let them struggle with deciding which team should make which modifications
• Encourage them to talk about the “specs” and figure out how to get the subsystems to fit together properly
• Hopefully, this will be somewhat painful and frustrating for them

As with the Waterfall examples, the project teams will be divided into two halves.

This exercise will be conducted in five iterations.

Before starting this second half, give the following instructions:

For each iteration, there is a set of specs that incrementally add to the previous iteration’s results.

Iteration one is very simple – just a flat rectangle – in order to get them accustomed to building and working together in pairs, plus giving them their first experience of continuous integration with an easy one that can’t fail.

Before starting this exercise, have the pairs switch – that is, Pair Left becomes Pair Right and vice versa.

Each Iteration follows the same pattern:

1. Receive specs
2. 2 minutes to review and discuss specs
3. Build (they will record the time to build)
4. Integrate (they will record the time to integrate)

Instructions are the same as for the first exercise:

• Neither pair gets to see the other pair’s specs for each iteration
• Neither pair gets to see the other pair’s work in progress during an iteration
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done in each iteration
• When both pairs are done, they will try to fit their subsystems together at the end of the iteration

At the end, they will total their build and integration times.

Learning Points: 

There is a bug in the specs. In the waterfall first round, the two halves cannot come together without a couple of tweaks. The same is true in round two, but they should get there more quickly.

• While it is expected that each Integration stage will take a bit longer than the last in round two, each should still be pretty quick
• One or more teams will not complete their cubes during round one. This is an opportunity for learning.
• Some may not finish in round two, but that’s less likely.
• Learning questions for the final debrief:
  • Did your team feel more confident in the product you were delivering each iteration?
  • How long was the integration phase in Waterfall compared to the total time spent in integration over the several XP iterations? (When overall time is roughly equal, this could be a key insight: XP teams have an easier time integrating even when the overall project timeline appears roughly identical to a waterfall Gantt chart)
  • Were there any features that could not be delivered in Waterfall because integration was too difficult/costly, whereas in XP the same features were delivered successfully?

Handouts and the slide deck I use are here: 

http://www.stevenlist.com/files/ciwithlego/continuous-integration-with-lego.zip