Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. Game created to help executives and managers understand the importance on investment in sustainable development practices.

Brief Description:
Have you been on a software project where each release gets harder and harder? Many projects fall into the tarpit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt and Stephen Covey’s Production Capability.

Feedback from first run:
* “Fantastic, Magical” - Jorgen Baker
* “Real pressures bottled up” - Alex Aitken
* “Good fun, valuable, opportunity to learn” - Tom Huras
* “Thought-provoking, Fun, Interesting” - Nick Faulkener
* “Lively, Interactive, Team-focused” - Hedi Buchner

Number of participants: 6 to 50 (Has been playtested with 40 at XPToronto User Group Meeting)

Duration: 90 Minutes (!)

Any special supplies requirement: video projector, tables for group work

Game mechanics:
Participants are formed into groups of 4 and the game starts immediately with a shared walkthrough of the first round. Team members cooperate to decide on their teams actions and compete with other teams.

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules. It is also used to inject models relevant to the topic (Stephen Covey Production Capability and Technical Debt). At one point we will show a short video clip.

This game is created by Michael Sahota and Alistair McKinnell.

1. Game Objective
The Whole-Team Game allows you understand the benefits and mechanics of whole-team approach by simulating work in an agile team, first as specialists then as generalizing specialists. The goal is to better understand how whole-team approach works and affects software development.

The object of the game is to iteratively improve to create a cohesive “product” by applying skill cards to complete “user stories.” A team competes against itself to improve upon its previous round.

2. Number of players: Four to 100 (best played in teams of four)
Time to play: 20-45 minutes

3. Brief Description
The game is played in rounds or “iterations.” The game is open-ended or “infinite”; that is, it is played less to win and more for the purpose of continuing the game in order to learn. Teams can play as many rounds as they like, but at least three.
The game contains skill cards and story cards. Play begins with one player from the team drawing and turning over a story card. The team must “solve” the card by bringing the appropriate skills to bear on it; each story is completed by having at least on skill card in each skill (customer/business, testing/QA, programming, user experience/design). In round 1, players play as specialists and simply replace the number of skill cards, but in round 2, each player acquires skill cards through pairing with his teammates. When the team solves a story, they place it into their product board and gradually connect story pieces to each other to form a “product.”
Teams score points for number of stories completed, the length of their product boundary (which measures the cohesion of their “product”) and lose points for work in progress and each time they engage in rework (to change their product layout).

4. Materials
• 1 deck of 72 skill cards, 1-9 in green, blue, red and yellow (use one deck for every four players)
• 1 deck of story cards (use one deck for every four players)
• Product board

5. Setup
1. Divide into teams of 4-6.
2. Choose one person to be scorekeeper. If you have five or more people on your team, you can optionally have someone be an observer.
3. Each team gets a deck of playing cards and a deck of story cards.
4. Draw four story cards and place them face up on the table.

Instructions
Full instructions and materials are available at:

http://mattphilip.wordpress.com/2011/03/01/introducing-the-whole-team-game

The Fair Tradeoffs Game

1. Game Objective
Primary: Learn a technique that highlights decision factors within diverse groups
Secondary: Get the team thinking holistically about the discover/design/produce/
market product lifecycle

2. Number of participants for meaningful play: Minimum Threshold: 5, Ideal number:
15, Maximum number: 20

3. Brief Description

Your company, PierPlus Imports, specializes in finding unusual products from the
far corners of the developing world. These places are typically difficult to get to,
have poor infrastructure, and the producers have little or no experience producing
for a foreign market. In a nutshell, assessing the risk is complex.
Your team must come up with a potentially hot selling product line. To do so they
must travel the world (of their imaginations) discovering and describing exotic
products from impoverished remote areas to sell online. You will be asked to
design, package and ship their creations, secure supply lines for their production,
and then sell them online to the world.
In order to choose the product line intelligently, the team uses a participatory
exercise using a Priority vs. Effort Quadrant to collaboratively examine and decide
which products get financed, fostered and featured online for an upcoming buying
season

4. No special supplies requirements

5. Game Play

Role Assignment:
(Count heads by five until all are accounted for. Split into 2 or 3 groups with as even
a distribution of roles as is possible.)
•Ones: Owner/Investor/Founders
•Twos: Buyer/Merchandisers
•Threes: Local Guides - specific knowledge of the source country (use your
imagination)
•Fours: Local Producers
•Fives: Shipping/Packaging/Logistics

Discover your potential products: Each group represents a different source region
(e.g. Africa, Latin America, China). Each is responsible for coming up with 5 new
product ideas. Prepare a short verbal and visual description of each product

The Graph: While the region teams are busy, facilitator draws a simple graph on
a whiteboard or large poster paper. The X axis is effort. The Y axis is priority.
Lower left corner is labeled “low”. Top and far right are labeled “High”. No numbers
are placed on the axis. See http://www.slideshare.net/aikiden/effort-by-priority-
estimation

Product intro and rough ranking: When all products are ready, a representative from
each group demos their product proposals, placing the ‘product sheet’ along the
bottom of the graph.

Priority negotiation: After all products are demoed, the business owners and Buyer/
Merchandisers from each group position each ‘product sheet’ according to its
relative priority. Discussion will ensue about relative marketability of each product.
Step concludes when everyone can live with the relative priority of all products (no
consideration of effort during this stage)
Effort assessment: The business owner/buyers sit down and the remainder come
up to the board, write the name of each product on a sticky note and discuss what
level of relative effort to position each product sticky. Priorities are not changed.

Quadrant mapping: Facilitator (with guidance from the teams), draws circles around
items within each quadrant, labeling the quadrants as follows:

Upper left: Thankless Slogs (high effort , low priority)
Lower left: Frequent Fillers (low effort, low priority)
Upper right: High Risk Challenges (high effort, high priority) •
Lower right: Easy Wins (low effort, high priority)

Matching Capacity:
Facilitator DRAWS in quantity lines from 0 to 20 assigning numerical effort values,
ADDS up all effort numbers for all products on the board, STATES that production
capacity is half that, asking the teams to work together to decide what the product
line will be for that season.

Discussion Ensues. Tradeoffs are made as needed until production capacity is
matched maybe plus 10%. Keep the quadrant labels in mind. They add much
needed characterization to aid the tough decisions required. Some products are
sidelined.

Celebration: Congratulations! You have a product line that can actually be delivered
for the next season!

Conclusion and Retrospective

Game objective
Practice flow visualization and management

Number of participants
Ideally 20, minimum 5; maximum 25

Brief description
Visualizing the value stream and continuous management of flow serve to realize Agile promises. We will engage into simulation of the work of a typical software development team to understand Pull system and to identify flow issues and waste. Then, take actions to improve the system.

Supplies
I will arrange for special supplies. Please arrange for normal supplies.

Game details

1. 05min: I will present an already constructed board for a software product development team.
2. 05min: Explain rules of the games and divide the attendees across the stages according to predefined skills and overlapping rules.
3. 20min: The attendees from various stages will simulate cards flow from one stage to another till value is delivered. This is based on card written scenarios which the attendees should follow. During this time, attendees will be exposed to:
a. How pull system works
b. Visual bottlenecks
c. Visualize waste
d. Role of the queues
e. Collaboration driven by skills overlapping
4. 10min: Retrospect with the attendees and drive improvement opportunities.
5. Repeat steps 3-4 another time.
6. 05min: Getting all pieces together

Objective: Learn and practice the integration of UX work with Agile development.

Number of participants: 4-24 (Max per game is 8, but we can run multiple games in parallel)

Brief Description: One challenge of Agile development is to integrate UX work with the fast iterations of an Agile project. This board game simulates Agile iterations, enabling players to practice accomplishing both the UX and the development work needed to complete user stories. Players will plan sprints, then work on stories ensuring that neither the UX team nor the development team is blocked waiting for the other.

Supplies: None. The game requires a game board I will bring.

Detailed description: The game is played on a board similar to Monopoly. Each circuit of the board corresponds to a sprint. UX designers and developers alternate, rolling dice to determine how much work they get to do and tracking their work against story cards. “Chance”-style cards introduce an element of randomness and real-world disruption. At the beginning of each sprint, the team works together to plan the most useful work for the next sprint.

The basic aspects of planning a sprint and tracking work during a sprint are practiced by this game, as well as the extra complication of tracking and ensuring UX work happens in time to keep the developers working.

This game aims to explain how the WIP limitation doesn’t reduce the throughput of a system.
7 players will have 7 roles illustrated by Casino functions (Casino Owner, Casher, Lucky woman, Player ...). They will build a sample Kanban (7 steps) on the wall of the room. The objective is to move up to 50 chips thru the Kanban using 2 dices. Each chip is associated to a challenge (ex : Less than 10, More than 5, 2 or more difference ...). Each player is using a closed box with 2 dices in it, so they are able to play in front of the kanban that is on the wall. Participants will play several iterations with different WIP, and during the last iteration they will have opportunity to change the system and make the bottleneck to disappear.
This game is designed in French (I'm the creator) and was played with success in november 2011 during a French Conference (i.e. : Agile Grenoble, 450 attendees, 37 sessions) but I will be happy to translate it in english if the participants to this Agile Games 2011 are interested to play it :)

1. Game Objective
Be the team that completes the project with the largest stakeholder value. Prizes to each team member of the winning team.
2. Number of Players and time
Two to Five competing teams of 3-5 people for 75-90 minutes.
3. Brief Description
Herding Cats is time-tested powerful project simulation that has been extended to Agile projects. Agile Herding Cats is a simulation that will be familiar to all those who work on complex technical projects that are difficult to manage. This experiential learning tool gives you the opportunity to test and apply your understanding of agile project management in a risk-free, yet realistic environment.

At the beginning, you and your team will be given:
• The business background for the project
• The stakeholders' trade-offs among scope, schedule, and cost
• A project plan
• Details on resources available to the project, turnover, learning curves, and overtime
• Details on the product's technical risk
• Information on each team member's range of performance
• A set of overall project risk events that may occur

Then you will be asked to manage your project to deliver more stakeholder value than the competing teams' projects.

UX Smackdown

Objective:
To find small ways to inject good user experience and usability into software projects.

Number of Participants:
In order for this to be effective it is recommended that the team that is implementing the feature be involved. This means literally the cross functional team of programmers, testers, analysts and the product owner. Depending on the product market, it can be useful to play one round independently with a set of representatives from select valued customers, and again with the delivery team to see how both view the impact and benefits of proposed changes. This can provide the business executives a considerable amount of information related to what customers like and don't like, and what internal considerations may impact the future roadmap of the product, surfacing both external and internal views of how the changes will impact the product.

Description:
As a general rule, most business people and most programmers are not good at designing user experiences. The software industry has begun over the last few years to understand this and has started to incorporate User Experience (UX) Specialists into the software process, especially as more application have moved to web based clients utilizing more Web 2.0/Web 3.0 type of interactions.

The goal of this game is to help:
- the development team learn to work with UX specialists
- UX specialists learn to work in an iterative fashion to deliver software based on a iterative or flow model
- the development team learn to think about how UX changes impact the design of the entire system
- facilitate yet another quick, feedback loop to ensure the right thing is begin built
- create a shared understanding and vision for what the potential challenges are, and what the completed functionality will look like

Supplies:
If done manually, typical paper craft supplies work well: colored construction paper, scissors, glue stick, etc. If done electronically, any software that can generate mockups of the proposed user experience: Powerpoint, Keynote, Balsamiq, etc. In order to get the most out of this effort, it is recommended to have a User Experience Specialist generate the mock ups in the tool of their choice, and print out the variations for the team to review.

How to Play the Game:
The game is played in several rounds. The first round is intended to focus on the human aesthetics of the design. The second round focuses on the pragmatic impact of the design. The third round consolidates results from the previous two rounds with an eye on the comprehensive impact to the product.

First Impressions. The idea is to have the team provide the UX specialist as much information about the proposed requirements as possible. The UX specialist will generate as many alternative motifs as he can within a given time box, say a week. Then each option will be given a name or number (purely for reference), the wireframe will be printed out, and each will be posted around a room to mimic an art gallery setting. The team is brought in with a basic understanding of what the proposed functionality is that is under consideration. The team is given three votes to cast on any of the proposed options. This typically will last about 10 - 15 minutes depending on how many options there are to consider and how large the team is.

First Impressions Post Processing. The results of the votes are tabulated. Any options receiving no votes are discarded immediately. These had no resonance with the audience. The options receiving votes are rearranged and reposted in the gallery for the second round.

Second Chance. The team enters the gallery and each team member has a pen and paper. They are asked a small set of questions intended to cause each person to consider the practicality of why they voted the way they did in the previous round, and if they should consider changing how they are perceiving the remaining options. Sample questions are:

1. Why did you pick the 3 options you did? What was it about those options you liked?
2. How do you see each of the options you picked being used? Under what circumstances would each be used?
3. What would you add to each option in order to make it more usable? How could it be improved?
4. A) What were the 3 initial options you selected of the 6 options to get votes from Round 1?
B) What are the top 2 options for you now?
C) If any of the top 2 options were not in your original 3 options, why did you change?

Second Chance Post Processing. Gather the teams feedback and tabulate. A strong pattern should emerge. The team will likely have gravitated to between 1 and 3 of the options by at least 80% of the votes. Some of the key design and usability considerations will likely also have been exposed. In addition, the team will have a shared vision of what the problem is they are working together to tackle. It is even possible that the team may be convinced not to implement a feature based on this exercise. This can save a lot of development cost, training and support costs, and maintenance costs building a feature that is either too complex, or just not usable.

Final Round. All the feedback from the previous two rounds are incorporated into expanded versions of the most popular 1 - 3 options. These are then presented to the team in an in depth review, where final business analysis and system design considerations can be identified and discussed with the team. Once decisions are made on which option to move forward with, the UX component, functional details and possibly test data can be used to create stories for the product backlog.

The objective of Open Space Technology is to allow people drawn by a tough challenge - in groups from 15 to 500 or more - to come together and self-organize discussions around critical issues and opportunities.

Minimum 15, no upper limit

OST is a meeting method that thrives when most meeting methods break down. It is best used in situations where: the challenge is complex, and no one knows the answer; a broad diversity of views is critical to understand the challenge; time is limited, and finding a solution is urgent; and for all these reasons, controversy is likely

Space is needed for a large group and for breakout groups. Wall space is needed for the list of spaces and times available for discussion groups. Wall space is also needed for a community marketplace at which discussion ideas are posted. An Open Space facilitator is needed.

The rules for Open Space are detailed at the web site www.openspaceworld.org

Should we play with this at Agile Games 2011, we would focus on using Open Space to solve tough business challenges.

1. Game Objective: Unlike other workflow simulation games, this is about *designing* the set of jobs and ensuring they fit together in a balanced way. It also demonstrates how leadership emerges and shifts around the group.

2. Number of Players: About 8 to 14.

3. Brief Description: Players design a workflow method to sort a double deck of playing cards, and measure its efficiency. They get several trials where they can redesign the flow pattern and see its effect. Then variation is introduced to test the robustness of the workflow design. Only by utilizing everyone can you achieve top results, but you must carefully balance each role to avoid chaos! Just like you have to do in an agile team.

4. Supplies needed: Spoiler alert! For those new to the game, seeing the supplies list in advance will give away some of the elements of surprise. I'll supply all the info afterward. (Nothing expensive or bulky is needed.)

5. Detailed Description: Starting conditions - Session leader places the shuffled double deck of cards face down, as a single stack, on one end of the table. This starts the timer clock. The deck will initially have only the regular cards, no jokers, just 104 cards.
Goal - Get the cards sorted by rank and suit as quickly and accurately as possible. End up with one pile for each suit (8 piles in all) with Ace on the bottom and King on top, and the intervening cards in rank order.
Rules - The team can organise themselves any way they wish to sort the cards as fast as possible. Some or all of the group can participate. When the team is finished, someone must shout “stop the clock” as a signal to the session leader to stop timing the work. For each error in the sorted cards, 5 seconds will be added to the team’s time. The team will do two practice runs on their own before the official run. Ask the team at the start of each run to estimate how long it will take them. You want one estimate from the whole team. Record that and the actual run time. Afterward do a debrief. (Longer description will give some debrief questions, and records of other teams' times.)