The votes are in and five games have been selected for the Agile Games 2012 Open Games sessions on Day 2. Here's the rundown:
- Self Management: 5 Games with Motion with Richard Kasperowski
- More Retrospective Games from the Team Movie Retrospectives with John Martin
- Three Pair Programming Games with Moss Collum
- Lean Workflow Design Game with Nancy Van Schowenderwort
- Agile LEGO Game with Conrad Benham
Self Management: 5 Games with Motion with Richard Kasperowski
These five games with motion show the benefit of self management over command and control. Most of these games run in two rounds followed by a retrospective. In the first round, a manager commands one or more other players. In the second round, players manage themselves and get better results. In the retrospective, players discuss what happened and why; it's usually obvious that self management trumps command and control.Games with Motion are kinesthetic learning games. Players learn by carrying out physical activities. These games create a social atmosphere and a full body experience that make it easy and fun learn. The five games are...
- Line Up: Players sort themselves in a line from left to right based on criteria like, "How far did travel to get to the conference?" or "How much do you like ice hockey?" A manager takes a long time organizing the group, but players have no trouble sorting themselves quickly.
- 60 Paces: How many steps can you walk in 60 seconds? The controlled player can't walk as far as the self managed player. (tastycupcakes.org/2009/06/60-paces/)
- Mirror: One player mirrors the other, but only when the manager tells him what to do. The manager has a hard time reacting and keeping up with the first player's actions; the self managed mirror player has no trouble. (improvencyclopedia.org/games//Mirror.html)
- Triangles: Form an equilateral triangle with your two secret friends. Then shield a secret friend from his secret enemy. Imagine how hard it would be for a manager to command all this complexity. (agilethinking.net/agile2005/TriangleGame.html)
- Human Knot: Players join hands, forming a knot, and attempt to unravel themselves into a circle. A single manager cannot solve this complex problem, but a self organized team unravels the knot.
More Retrospective Games from the Team Movie Retrospectives with John Martin
Here are a few retrospective games that seem to be working well:
- Retrospective Draw Poker: Generate a deck of cards from nearly-random images taken from the indicommons project. Deal five to each player. Player's goal is to describe the iteration/release/event using the images in their hand, placing the images in order and trying to make the longest straight possible. After first deal, players review their cards and can discard 0,1,2 or 3 cards for replacement. This works a good shortcut & timeboxer for gathering information to pull out the memorable events.
- Event-enhanced Starfish: Make a starfish diagram where each segment is something to be delved into: e.g., scrum values, team working agreements, definition of done, etc. Each team member is encouraged to make as many stickies as possible with negative and positive examples of the sectors. The team discusses and thinks about the responses. Based on this, make a vote of 1-5 on each sector, then use an adjacent arm to plot the points and make a nice radar plot.
- Retrospective House Plan: Have team generate a set of memorable events from the timebox under review, then have them place the events into rooms on a rolled-out house plan. Discussion generates around the reason for each room being used, what it represents, why the event goes there, etc.
Three Pair Programming Games with Moss Collum
I've been experimenting for a couple of years with the use of games to structure pair programmings sessions, and to develop specific pairing skills. There are three in particular that I've found helpful in various situations, and which I'd like to try playing with people here:
- Questions: A game to use when working with unfamiliar code. One pair asks questions about the code, what its purpose is, and how it works. The other investigates, and then responds by refactoring the code to express the answer to the question. This keeps both pairs actively engaged in code reading and research tasks -- ordinarily hard ones to pair on -- and has the side effect of leaving the code more readable for future developers.
- Farsighted Navigator: Useful for people who tend to forget their pairs when driving, or to lose interest when navigating. One person (the navigator) directs development, but can't describe specific code details on any level more precise than, say, stating the purpose of a class. The other (the driver) translates the navigator's design into code, but can't do anything that wasn't requested by the navigator. The limitations on both roles force the driver and navigator to cooperate if they want to get anything done.
- Silent Code Improv: Useful for avoiding excessive up-front discussion and analysis, and also (surprisingly!) for keeping both pairs actively involved in programming. There are three rules: (1) No talking. (2) Switch who's at the keyboard at least once every three minutes (I generally keep a timer running as a reminder). (3) The Improv "Yes, and" rule: you aren't allowed to delete code your partner has written; instead, you must build on it either by adding to it or by refactoring. This was inspired by some of Lyssa Adkins's demonstrations of silent working techniques at the first Agile Games conference, and it surprises and delights me every time I try it. Somehow the requirement of silence, and the need to communicate through code, keeps people engaged in pairing in a way that's rare when they're allowed to talk. It's hard to explain, but exciting to see in practice.
Lean Workflow Design Game with Nancy Van Schowenderwort
The challenge: A dozen people work as a team to sort a double-stack of playing cards into rank and suit order. Can you do it without errors, faster than prior teams? You must make decisions quickly as a team. You have to choose a process that uses all the hands and minds without going at cross-purposes.
This game explores the balance between planning and doing. You'll use multiple runs of the sorting to explore questions such as: Do you specialize into specific tasks? Which tasks? Should the jobs flow in a hierarchy, or exist in a "flat" structure? How robust is your system when the unexpected happens? How does the group decide whose idea to use?
Agile LEGO Game with Conrad Benham