Posts by Don:
- At least 3 teams of 3-9 people.
- Multi-colored paper (at least 32lb paper stock)
- Enough sharpies for everyone
- A folder with 3-hole binding and a transparent cover
- 3-hole punch
- A Definition of Done & Non-Functional Requirements (printed out or written on flip chart) – here is an example
- A Product Backlog (on cards) – here is an example
This is a fun and effective way to replicate the challenges of scaling product development across many teams.
It puts teams into a situation where they need to turn their individual features into one collective increment within a Sprint. They need to work out how to manage dependencies between teams as well as cross-team requirements and constraints. Consider running this exercise right before introducing a group to a scaling framework, such as Nexus.
Setup: Teams are presented with a Product Backlog and constraints (Definition of Done & NFRs) for a bound booklet about animals in the Nexus Zoo. Each Product Backlog item represents a page in the booklet (along with some acceptance criteria).
Cover Page : Zoo logo and name centered on top of page ; Map of the zoo ; Images of at least three animals
Narwhal Page: Show both common and scientific name; Three sentence description of animal ; Sketch of the animal ; Same color paper as Unicorns ; Small zoo logo on top right
Plan: Teams have 4 minutes to select at least one item from the Product Backlog and plan their Sprint.
Sprint: Teams have a 10 minute Sprint to create a complete increment. The increment must meet the Definition of Done.
e.g.: Common copyright, center bottom of every page; 1 color Sharpie per page; Text should be clear and readable with no crossed-out wording (errors); One-sided page; Integrated into the booklet; No more than 3 of the same color paper; No 2 consecutive same color paper.
Observe: Just step back and let it happen. As a facilitator you really shouldn’t have to do anything else. The point of it is to see how separate teams self-organize to deal with dependencies. You can give your honest opinion about things they are making, but if you are asked any questions about how to proceed, just play dumb.
For example, we were asked what the copyright should say exactly, we just said ‘Oh wow, never thought of that. What do you think?’. The participant then looked up copyright laws on his phone and presented us with options. We picked one and he then asked how the other teams would know to use the same copyright text. We just shrugged our shoulders. So he grabbed a mic and made an announcement to the rest of the room.
Some things to look out for:
- How do the teams coordinate between the animals that share page colors?
- How do they work out restricting how many same color pages end up in the booklet?
- How do they agree on what the copyright should be? How do they communicate it to all the teams?
- How and when do they integrate into the main branch (the binder)? Do they wait until the end and create a bottleneck? Or add pages continuously?
- Do they form any new roles or groups? Do certain people take responsibility for integration? What about cross-team constraints?
Debrief: Stop the Sprint promptly at the 10 minute mark and examine the increment with everyone.
Debrief the exercise by pointing out many of your observations. Discuss pros & cons of their scaling practices and start to tie it to the Nexus framework (or any scaling solution).
This is a great facilitation exercise for quickly seeding a Product Backlog or anything else that requires collaboration. It is a technique that I’ve used for years and was originally inspired by Lyssa Adkins’ Silent Work Techniques
- Divide participants into groups of 4-8 people.
- Provide each participant with 3X5 cards and a sharpie.
- Seed the product backlog by using the first 15% of your story writing timebox for silent writing.
- Then, have each participant take turns reading one of their stories.
- After the story is read, the group discusses and decides whether it is suitable or not. If so, put it in the middle of the table. If not, rewrite it or destroy it.
- If any participant has a similar story as the one being presented, they alert the group and then destroy one of the duplicates.
- Continue in this manner until all the stories are either in the middle of the table or destroyed.
The team will quickly have an initial Product Backlog that is ready to be ordered and sized. It takes the emphasis off of any one facilitator or manager and engages ALL participants. This method also appeals to people that think better by themselves than in large groups (introverts).
Fellow game players, facilitators, and creators,
For the past 4 years, the city of San Jose has used Innovation Games’ “Buy a Feature” game to help balance their budget.
The goal is to bring citizens into the budget building process and to get them engaged in the community. They have also done this in Kortrijk, Belgium.
For those of you that don’t know, Innovation Games is a collection of very practical “serious games” for producing work and it was founded by Luke Hohmann, an active member of the agile game community and author of the Innovation Games book.
This year, the San Jose Budget Games plan to go from involving hundreds of citizens to TEN THOUSAND citizens! The only way they can achieve this is by playing online… and they need help.
Would you be willing to donate an hour of your time to facilitate one of the online games Jan 23, 24, or 25? If so, you can sign up here.
Check out this video of a previous budget game session.
If you would like to know a little more information about what is expected, please read the information below from Innovation Games.
Facilitation will mainly consist of making sure participants understand the system, keeping the conversation moving and on track, and coordinating with other volunteers if the in-person group requests a SME.
Because the game is typically fast paced, the facilitator might have difficulty writing down notes. The observer is there to capture game dynamics and interactions that the game cannot capture. Observers will be critical to the in-person games because the participants will be much more likely to talk to each other instead of using the chat functionality. The conversations will be important for processing the data after the game. It is best practice to have both roles at each table.
A training session will be held January 17 to give people new to facilitation and observation an understanding of the do’s and don’ts, along with training on the online tool.
About Budget Games:
This is our 4th year working with San José to produce the Budget Games. The goal is to bring citizens into the budget building process and to get them engaged in the community. San José has had its share of financial difficulties and has squeezed its spending to get things under control. Because this affects the citizens directly, the City wants to understand how the citizens prioritize items (such as parks and crime prevention units) within the budget. The results of the Games feed into the budget discussions held by city officials and bring a greater understanding of the city services the people hold in the highest regard.
The Game consists of 8-10 people ‘buying’ the services they like. This year, we hope to gather preferences for potentially spending ~$34 million dollars gained through a proposed sales tax increase.
In previous years, we have used in-person games with physical money and calculators. We are pleased to expand the games to an online format this year! Community leaders invited to the in-person game will have tablets allowing them to play the game. Another addition to the normal Game is the expansion to the greater San José public via the online platform. We hope to get 10K citizens involved!
January 18 has been designated for in-person play and online play will occur January 23 – 25.
We are looking for facilitators and observers for the in-person and the online game slots, which are 1 hour long. It would be fantastic if you could tell your friends and colleagues about this event and encourage them to get involved! Please click here to sign up to facilitate!
A yard stick for each team
Ask teams for estimates on how long it will take them. They will usually estimate somewhere around 8-10 minutes.
Pick one ‘tiger-team’ and tell them you really believe in them and you believe they can do it in half the time: <4 minutes. (It is practically impossible to get it done in 4 minutes… we’ve tried)
Then tell another ‘slack team’ to take it easy and give them 15 minutes.
Leave the other team at the original 8-10 minute mark.
Start the timer and watch the fun.
The ‘tiger team’ will have a lot of tension as they rush to stack the dominoes. They will experience frustration and it isn’t unusual to see some in-fighting.
After the 4 minutes are up, examine their work and voice your disappointment. Give them an extra 2 minutes and tell them that they better get it this time. They won’t. So give them another 2 minutes and be sure to mention what a nice manager you are.
By this time the 8-10 minute team should be pretty much done. In our testing, 8 minutes is a good amount time to build the tower.
What is interesting is that the ‘slack team’ almost always uses most of their 15 minutes, demonstrating Parkinson’s Law.
Debrief by asking each team how they felt during the exercise. Which had the best team dynamics?
- Teams pressured to deliver “faster” are often less productive and deliver less than those with reasonable expectations.
- Teams under stress get stuck in the ‘Storming’ stage and cannot perform to their potential.
- Trust team’s estimates (and other decisions) and see them gain more ownership and performance.
- Work expands so as to fill the time available for its completion (Parkinson’s Law)
- In Session 1, we of course kicked things off with a game and then introduced our five step approach and shared some guidelines. The five steps are Problem, Lead objectives, Aspects, Invent, Debrief – PLAID (pronounced PLAYED ). We ended the first session by forming teams around the most popular Problems, who then presented their Lead objectives to the rest of the group.
- Session 2 was all about Invention. While keeping in mind the principles of Inspiration, KISS, and Courage, teams collaborated and innovated until the beginnings of a game emerged.
- The main goal of Session 3 was to provide a safe environment for teams to present and play their games with the other participants and receive feedback.
When the dust settled, we had 4 great games:
- Don’t Blow It – Lead Objective: Trust is important, yet hard to earn and easy to lose.
- The Big Payoff – Lead Objective: Maximize portfolio value by finishing smaller projects earlier to gain value sooner.
- Timebox Box – Lead Objective: The value of timeboxing.
- Pizza Portfolio – Lead Objective: Prioritize your portfolio to optimize the business’ ROI.
The next day, each incubator game was entered in the AgileGames Game Tournament. And out of all the excellent games played that day, ‘The Big Payoff’, conceived just the day before, won ‘Most Creative Game’! Congratulations to the creators, Alex Boutin and Erwin Van Der Koog!
Mike and I will be facilitating another Game Incubator at Agile 2011. Hope to see you there!
TastyCupcakes is excited to be a part of this year’s Deep Agile 2010, where the topic is ‘Empowering Teams with Agile Games’.
Come Join Don and Mike, along with other game guru’s like Tobias Mayer, Lyssa Adkins, and Portia Tung as they take you through a two-day deep dive into using collaborative and interactive games to enable Agile teams.
- Copies of the twelve principles of agile software (http://agilemanifesto.org/principles.html)
- White-boards and/or flip-charts
This is an exercise that we came up with to better communicate the twelve principles behind the Agile Manifesto. In their existing form, it is challenging for people to read and understand each principle and, just as importantly, to easily refer to them later.
- Divide participants in to groups, each with a white-board or flip-chart and markers.
- Have the teams write down the numbers 1 through 12.
- Challenge each team to, within a 15 minute time-box, come up with three words maximum that effectively capture each of the twelve principles.
- To avoid ‘analysis paralysis’, make sure to give the teams time updates throughout (e.g. 10, 5, 2, 1 minute warnings). You will find that teams will speed up towards the end.
- When time is up, go through each principle and discuss which are the most important words. Sometimes I like to ask people what their most and least favorite principles are.
- Post the condensed principles somewhere visible, so as to make it a regular talking point.
Here is an example:
- Produce Value Early
- Welcome Change
- Iterative Delivery
- Daily Business Collaboration
- Trust Motivated Team
- Face to Face
- Working Software
- Sustainable Pace
- Technical Excellence
- Reflect and Adjust
- This is an effective way of capturing each principle in a much more concise and memorable way.
- Probably the most valuable part of this exercise, is in the discussion that the teams have when trying to come up with the words. They need to first understand the principle before breaking it down.
- Teams can establish a collective understanding and ownership of each principle.
- This also makes for a good review exercise in a classroom environment.
Check out our new article with the Agile Journal!
Fun-Driven Development: Building Momentum Through Games
Note: If you haven’t heard of White Elephant Gift Exchanges before, read this.
- Sizing board (a whiteboard or flip-chart or the like; divided into 5 columns: XS, S, M, L, XL)
- A set of prepared stories
- A set of 5 X 3 cards
- Tape for attaching the cards to the board
Have the team stand-up in a half circle facing their sizing board.
Shuffle a deck of story cards and place them face down on a table in front of the sizing board. Place a timer next to the cards.
The game begins when the facilitator starts the timer, which is the signal for the first member to perform the following steps:
- pick the top card off the deck
- attach a piece of tape to the card
- read the story on the card out loud
- assigns the card to one of the five columns on the board (XS, S, M, L, XL)
- provide a reason to the group
- start the timer for the next player
It is important assigning the card to one of the five columns has to be the player’s own decision, without any external interference. This is why the player should provide the reason for his or her decision after the card has been assigned. If the player does not assign the card within one minute, the card will be assigned to the column in the middle. The player then restarts the timer for the next player.
After sizing the card, the player presents his or her reason. The reason may be based on expert knowledge, from past experiences, or observations from other projects. It is essential that the rest of the team observes and listens carefully to understand the overall context and development of the board. All other team members are therefore silent without discussions or judgment.
After a few rounds, there should be enough cards on the board to give the team members the option to, on their turn, move an existing card on the board into a different column instead of picking a new card from the deck. As before, the player reads the story out loud followed by a reason which supports the decision to re-size.
Once all user story cards are on the board and sized, each team member, on their turn, can either continue moving cards between columns or simply “pass” if they are satisfied with the current results. If a player does not make a decision within the one-minute time-limit, it will be interpreted as a “pass”.
The game ends when the pile of story cards is gone and every member of the team signals “pass”.
The biggest challenge in the beginning is the lack of a reference story – the Chihuahua (see Doggy Planning). Because no card has been assigned yet, the first player will not have something to compare his or her story to. And since the cards will be shuffled, we won’t know if the first stories are really small, medium, or large until we uncover more stories. This is OK and and important lesson of the game. Every player will have the opportunity to change their mind in future rounds, so the important thing is to just get started. Remember, the game does not stop until all players signal “pass”.
It is quite typical that two or more players disagree about a few assignments, and the card may end up endlessly moving up and down the board. If this happens, just take the card and place it on the bottom of the deck. That way, the sizing can continue and the card should have more context after all the other cards have been sized.
- Group user stories according to their relative size/effort
- Reach a democratic consensus quickly
- Ensure that each team member has a say
- Learn how user stories are captured
- Actively collaborate in a fun way
- Play with 3 (S,M.L) columns instead of 5 (XS, S, M, L, XL)
- Begin with 3 columns until the team requests more granularity, then the moderator adds additional columns
- Assign the Fibonacci sequence to the columns (1,2,3,5,8)
CREDIT: Jochen Krebs
Timing: 10 mins
- A good-sized audience – 10 or more (the bigger the better)
- Pens & paper for all
It is best to sneak this exercise in when it is least expected.
Start by selecting something in the room that is not easily counted or estimated. Take the time to write the exact number down and hide it from the audience.
Then, have each individual quickly and privately write down their own estimate.
Gather all of the estimates and calculate the average.
Cross your fingers and unveil the number that you wrote down earlier. It should be relatively close to the group average.
I have done similar exercises about a dozen or so times and the results are usually spot on. However, there is always a chance that the results could be off, so always make sure to start by announcing that you want to perform an experiment together. Participants will understand if the results are not perfect.
Some things you can use to estimate:
- Your weight – although people tend to be generous and the estimates are usually low.
- Number of books available on Amazon.com
- Number of words on a page – I’ve had the most success with this one. In a class environment, I’ll use the lab write-up and have the students write their estimate on the back.
- Number of steps it takes to walk from one side of the room to the other – this one is fun, but you could get accused of rigging the outcome.
- Balloons in the room – only works if you played the 99 Test Balloons game earlier.
- Please leave a comment to share some of your ideas and experiences.
Other helpful hints:
- To keep things quick, open a spread sheet to type in everybody’s estimate as they show them to you. This also makes it easy to calculate the average in front of everybody.
- Analyze the data with the class. You will likely get a very wide variance. I often find that no one individual estimate is as close as the average. This speaks to the true wisdom of the crowd and of the importance of diversity.
- To make it even more interesting, give a prize to whomever had the most accurate estimate.
- The accuracy of the group estimate is usually stronger than any one individual’s.
- The larger and more diverse the crowd is, the better the estimate.
- Agile embraces this principle by involving the whole team in estimating and planning and by encouraging the creation of cross-functional teams.