Category Archives: games

Agile Games at Agile Open Southern California

Our very own Laura Powers recently participated in Agile Open Southern California, where she was interviewed by Scott Dunn. Laura talks about the power of games to help executives understand the changes they need to make in order for their organizations to become more agile.

The video was put together by Cliff Rosa of Rosa Media Productions.

Share it!

Dixit Sprint Retrospective Game

Dixit Game BoxI was inspired to create a retrospective game for agile teams, based on the game Dixit. Dixit is a game that makes use of picture cards. Each of these cards has an unusual drawing on it. The Agile Learning Labs team used it recently in one of our sprint retrospectives and it worked well. Give it a try with your team and leave a comment to let me know how it works for you.

Materials required:

A full set of Dixit picture cards is used. The rest of the supplies from the standard Dixit game are not used.
Each team member should have at stack of index cards, at least five.
Each team member will also need a pen.

Game Play

The team sits around a table. The deck of Dixit cards is shuffled and each team member is given six cards (this can be adjusted up or down as desired). The rest of the deck is placed in the center of the table face-down. Players will take turns being the leader. The tallest person (or shortest, or what-ever) is the first leader.

The leader looks through their six cards and chooses one that represents something that happened during the sprint. For example, let’s say that the team had to create a lot of documentation this sprint and so the leader selects this card from their hand.
Pile of books Dixit card

The leader places this card face-up in the center of the table.

Each player, including the leader, writes what they think the card represents on an index card, and then the index cards are placed face-down in front of each player. When each player has an index card in front of them, the player to the left of the leader turns their index card over and explains what they believe the Dixit card represents. That player leads a brief discussion of the event on their index card, and the discussion concludes by recording any potential action items for the team to consider.

The next player to the left then reveals their index card and the process repeats until it is the leader’s turn. The leader then reveals what they intended the card to represent. If the topic has already been identified by one or more team members, then each team member that correctly guessed the meaning of the picture gets a point and so does the leader. If no team member guessed the intended meaning of the Dixit card, then the leader facilitates a discussion about the topic and potential action items are recorded; no players receive points in this case. The leader then discards the Dixit card and draws a replacement from the top of the deck. Now the player to the left of the leader becomes the new leader and the process repeats. Continue for as many times around the team as feels productive.

Once the main game play is completed, the team considers the various action items that they have collected and selects one or two of these to schedule into the coming sprint as the outcome of the retrospective. Oh, and the player(s) with the most points win a fabulous prize.

Team playing Dixit retrospective game

Share it!

How to play the Team Estimation Game

The Team Estimation Game is the best technique we have found to get a scrum team up-and-running with useful estimates. It plays like a game, but it accomplishes valuable work: assigning story point estimates to user stories.

Teams using this technique are typically able to estimate 20 to 60 stories in an hour. The game was invented by our friend and colleague, Steve Bockman. Here is how one team plays the game:

Team Estimation Game Part I: The Big Line-up

Frank, the team’s scrum master, has cleared space on a long section of wall in the team room, and now the team assembles in front of it. Brad, the product owner, has brought a stack of 30 user stories from his product backlog, and the team is going to size them by playing the Team Estimation Game.

“Kira, why don’t you go first?” Brad says, passing her the stack of story cards. Frank, who is holding a roll of blue painter’s tape, peels off a small piece and hands it to her.

Kira starts the game by taking the top story from the deck, reading it aloud, and taping it to the middle of the wall. Then she hands the deck off to Kai, who goes next.

Kai picks the next story off the top of the deck and reads it to everyone. “I think this one is bigger than the one Kira just placed,” Kai says, affixing his story to the right of Kira’s story.

Mark goes next. The story he reads strikes him as a small one, so he places it just to the left of the others.

Now Jeff picks a story off the pile. “This one is pretty small, too.” He hesitates, then moves Mark’s small story further to the left to make room for his. “But not as small as the one Mark just placed.”

The team continues to take turns placing stories. On Kira’s third turn, she doesn’t take a new story off the pile. Instead, she repositions one that is already on the wall, moving it further to the right. “Trust, me,” she says, “the legacy code for this one is a mess, and we are going to have to make it all thread-safe for this story to work!”

Soon enough, all of the stories have been placed on the wall—but the team continues to take turns. Now, instead of placing new stories, they are fine-tuning the order by moving them one at a time, sometimes silently, sometimes with a few words of explanation.

“Pass,” Malay says when his next turn comes, indicating that he is satisfied with the order of the stories. Justus passes during this round as well. Kira and Mark each move one more story, but pass on the next round. Eventually there is a round where they all pass. Part one of the Team Estimation Game is over!

The team now has their stories ordered left to right, smallest to largest. The story they all agree will require the least amount of work is farthest to the left, and the one that they believe will require the most amount of work is farthest to the right. What is remarkable is that the whole team has now achieved consensus agreement on the correctness of this ordering!

For those who have been paying close attention, you may have noticed that this game has the potential for an infinite loop. Mark might place a story to right, but then Kira could move it back to the left. Mark, in his next turn could move it to the right again, and so on forever. While the infinite case is theoretically possible, we have never encountered it the hundreds of times we have played the game.

Team Estimation Game Part II: What’s Your Number?

In preparation for round two of the Team Estimation Game, Frank produces a deck of Fibonacci cards. Each card in this deck has one of the Fibonacci numbers on it, from one to 144.

Mick starts off. He goes up to the wall and points to the leftmost story, vamping a bit like Vanna White on Wheel of Fortune. “This, ladies and gentlemen, is about the smallest story we are likely to see.” He tapes the Fibonacci card labeled “1” above the story.

Justus goes next. He holds up the card labeled “2” and considers the wall of stories, searching for the point where the stories on the wall start to be about twice as much work as the story with the “1” over it. He chooses his spot, and places the “2” card above a story that lies four cards in from the left.

Play continues for several rounds, with each team member placing a Fibonacci card above the row of stories where they believe a size break occurs.

When her next turn comes, Kira hesitates, then points to two stories. “You know,” she says. “I think we may want to reverse the order of these two. I think this one is an eight, and the other one is a 13.” She uses her turn to switch the order of the two story cards and hands the deck to Mark.

Mark places the “21” card above a story. Malay is next. He shakes his head, then removes the “21” card Mark just placed. “I think this is actually a 34,” he says, naming the next-highest number in the Fibonacci sequence. He replaces the “21” card with the “34” card.

“He’s right,” says Jeff.

Jeff helps Malay move the story cards just enough to create a blank space between the last size 13 story and the first size 34 story—when the team placed the story cards in round one; they left ample space between them to allow for this, knowing that things can shift during part two.

Malay tapes the “21” card above the blank space in the row of stories, to indicate that there are no stories of that size.

When everyone has reached the point where they feel confident enough in the sizes to pass on their turn, the game is over.

Now the team tidies up, moving the story cards to form columns under the Fibonacci cards. All the stories between the “1” and the “2” are collected in a single column under the “1” card; these are the one-point stories. The next column consists of all the two-point stories, and so on. The team never did put any stories under the “21, ” so that column remains empty.

What we’ve described is the simplest form of the game. When you play it on your team, note that you don’t have to start with a “1” as your smallest story size. If a player thinks there may be future stories that will be significantly smaller than the smallest story that is currently on the wall, they may opt to start with the “2” or “3” above the first story instead of the one. This leaves room for future stories to be sized smaller than the smallest story in the current set. For example, by placing a “2” over the leftmost, smallest story card, a player signals their belief that the team may encounter future stories that are half as much work to implement.

We teach this game to the teams we work with, and many of them tell us that they have never before started a project with the whole team believing that the estimates were correct. This is the way to build a plan that everyone actually believes in!

Excerpted from The Elements of Scrum, by Chris Sims & Hillary Louise Johnson.
©2011 Chris Sims, Hillary Louise Johnson and Agile Learning Labs. All rights reserved.

Share it!

Can agile games save the world?

One of the sessions I regret missing at Agile Open Northwest is one that was titled simply Agile Congress, the session notes for which begin with, “You have just been appointed the first scrum master of the United States House of Representatives…” Well, why not? As it turns out, the City of San Jose is all over that very idea.

Last month Chris and other Innovation Games trainers volunteered to help community leaders in the City of San Jose get a taste for what their city officials go through when tough times demand budget cuts. Hohmann devised a citified version of the agile game he calls “Buy a Feature.” Originally designed to help software teams empathize with business leaders, the city management version of the game uses play money to allow teams of citizens to allocate budget for things like street repairs, firefighting, children’s health services and park maintenance. The day was a huge success, and has been the subject of several interesting write-ups like this one in the San Jose Mercury News, this one in InfoQ, and this one by Jerry Kirk, which includes participant interviews.

The simulation approach reminds me a bit of the conceit in Ender’s Game, the wonderful sci-fi classic by Orson Scott Card wherein real wars are fought by children who think they’re just playing games. Makes me think that maybe city officials themselves should play this kind of game to learn more about their own processes, or maybe we should use games to actually do the budget work. Hohmann is serious about his serious games, and about taking agile methods beyond the realm of software. He told InfoQ: “To what degree is the Agile value of collaboration changing the world? Unlike software, the answer is not so clear cut. What we prove time and again in Innovation Games® is that small group interaction played at large scale is indeed a recipe to change the world.” No wonder the tag line for Hohmann’s company is “The seriously fun way to do serious business–seriously.”

I can see lots of uses for games and simulations in government, and even in the election process. If I were still a small town newspaper editor, I’d be tempted to replace the tired old city council debate we used to hold with a game day, and invite citizens and candidates to play side by side. How better to sort out who really knows their stuff than to actually get to work with them.

If you are in business, you may already play a serious game or two, without even realizing it. I once wrote an article about why business people play so much golf. And why do they? Because the best way to learn about a person’s character and test their mettle is to play an extremely difficult game with them and see how they handle themselves. If you think about it, how else would you vet a high-level executive, where performance comes down to things like grace and intelligence under pressure? Yes, golf is a serious game indeed, in the best possible sense. Don’t play golf? You’re in luck, because you don’t need an act of congress to hire people like Luke or Chris to facilitate Innovation Games at your company, and there’s no telling what you might learn… up to and including how to save the world.

Share it!

Self-Organizing Ball Game at Agile Open Northwest

The Self-Orgainizing Ball Game at AONW 2011 Agile Open Northwest kicked off this morning, and the whole Agile Learning Labs crew is here. Chris hosted a session called “An Experiential Intro to Agile” in the first time slot. Sixteen folks new to agile gathered and we quickly discovered a common theme: participants were about to join agile teams, but didn’t know what to expect. Out came the rubber balls and we dove into the Self-Organizing Ball game.

The topics that this surfaced included:

  • The value of short iterations to to allow productive “trial and error”
  • How effective retrospectives generate continuous improvement
  • Time-boxing can push a group towards productive chaos, while protecting it from prolonged unproductive chaos.
  • The way a shared goal can unite a team, and focus the energy and self-organization

It was a lot of fun, and a good start to one of my favorite conferences.



Share it!

What Does Your Team Need? Girl Power!

By Hillary Johnson

Last weekend, Chris and I attended a marvelous event called Dare 2B Digital, aimed at addressing the gender gap in computer science careers, and at which 7th through 10th grade girls got to play at writing code, crafting business plans, and other techie things.

We held a session called "Teamstorming," leading a group of enthusiastic students in a series of the same learning games we use to teach teams of software developers on big, important enterprise projects to work together collaboratively.

We were completely blown away. The girls weren't just good: they were great. This was the most quick-witted, productive, outgoing and naturally cooperative group of individuals we've ever had the pleasure of teaching, by a significant margin. Chris and I have both mentioned to several people now our experience of finding the teenaged girls smarter, stronger, faster and sharper than their elders of any gender, and have heard a few theories about why this might be, the top three being:

They are unspoiled.
They are female.
They are female and unspoiled.

We laughed, too. But each of these notions has some merit. First, there is the unsullied youth theory: It seems patently obvious that many adults have a great deal of wariness, and weariness, to overcome before they are open to participating freely in a game-based exercise. Our teaching style is based entirely around games and simulations, and the younger a student is, the closer she is to the memory of learning almost entirely though play. It is not, however, particularly true that children are born collaborators, as any parent whose pre-school has a biter enrolled can tell you.

As for the gender question: Are females, by nature or nurture, better collaborators and problem solvers than males? To whatever extent our temperaments are deterministic, my hunch is that girls would respond better to the collaborative exercises, and the boys to the competitive ones. There is research-based evidence that there are gender-based differences in learning styles, but the same research indicates that the variation between individuals is greater than the variation between the genders.

So yes, the girls may benefit from being both female and unspoiled, but this doesn't mean they are superior to the male and the spoiled, it just means they're naturally suited to collaboration and have nothing to unlearn as they encounter collaborative situations.

But by adulthood, we are all engaged in activities that may or may not speak to our true natures. Girls don't tend to play with toy cars, but they grow up to drive real cars in the same numbers as men. And if you believe insurance companies' actuarial tables, they grow up to be the better drivers. On the flip side, I think this means that boys can grow up to be fine collaborators, as good as or better than their female counterparts, despite their greater inclination toward competitive styles.

I am not a big fan of determinism. Things do come out in the wash, and in the long run, even unlearning can be a productive process. As Chris will tell you, part of the reason he values Agile so much is that teamwork and collaboration do not always come naturally to him–he was once a boy who played with cars, after all. He has enjoyed being in a traditional leadership role, and can remember exactly what it was like to resist the urge to "help" a team, instead letting them solve their own problems through self-organization. Which is why he is good at teaching Agile techniques, especially to people who have a lot of un-learning of traditional top-down management styles to do.

The clear outcome, to me, is that the gender bias in the field of software development that persists today is entirely bogus. If boys have an edge when it comes to math–hence their delight in code–and girls have an edge when it comes to collaboration, then it seems stupefyingly clear to me that you're most likely to have a high-functioning team if you have both styles well represented, with plenty of room allowed for something even more important: individuality.

Share it!

Fun & Games & Aha moments at the Bay APLN

A couple of weeks ago, Chris was the guest speaker at the Bay Area Agile Project Leadership Network's monthly meeting. It was an evening of game-playing and simulations. One of the most popular is a simple game that takes under five minutes to play, but always blows the tops of people's heads off by demonstrating concretely and irrevocably just how deeply multitasking cuts into productivity and even quality. This particular exercise led to some insightful conversations and aha moments, including:

  • The majority of aviation accidents that are caused by human error are the result of unexpected context switching
  • Multitasking exercise can make the case for "office hours"

Other highlights from the debriefs around the games included these observations, captured on Post-Its:

  • It's a turnoff to be "worked on"
  • The team has better visibility into a problem than an outsider
  • It's quicker to get into a tangle than it is to get out of one
  • Boundaries are movable, depending on your assumptions
  • The team can iterate faster and better than the manager

The BayAPLN meetings are open to all, so please join us for the next one on August 18, when the inimitable and entertaining David Chilcott will show you how to have a meeting that doesn't suck (hint: "What if you managed your meeting like a sprint?") . And if you want to play games with us, check our hompeage for upcoming classes and other free events where Chris will be speaking. Or turn up for Agile Open California, where there will be lots and lots of games and even more ahas.

Share it!

Fun & Games: Some upcoming events in SF & the North Bay

Children learn best by playing games, and guess what? Adults do too. No reason your agile practice should be a plodding, dreary affair with all the elan of a queue at the parking violations bureau. Lighten up and have some fun–it'll make you smarter.

Chris will be leading a raucous meeting of the BayAPLN in San Francisco on July 21st, on Agile Games & Simulations, so come out to play, won't you?

Chris will also be leading a session of the Great Agile Requirements Showdown at the North Bay Agile Meetup on Tuesday, July 28, in Rohnert Park. This is the gathering hosted by our friends Steve Bockman and Rob Myers, both of whom are accomplished gamesmasters themselves, so it should be a fun time. What's it all about? Here's the teaser: 

Agile evangelists claim that extensive requirements can be dispensed with in favor of lighter-weight 'stories'. It sounds easier, certainly, but can it really be as good?

Come find out!

Share it!

Dogs learn agility with tennis balls; so do we

The very first exercise of our two day Agile Project Management class on Monday taught me a few things about optimization. It's a ball passing game, where the group is tasked with devising a system for passing balls around such that every ball is touched by each person, and has "air time" in between–ie, it's tossed, not passed.

On their first try, this group passed a whole mess o' balls without error. In their second iteration, they did even better–better than any prior group, and we'd run this game a lot. Could they improve on what I percieved as perfection?

They could. Chris tasked them with achieving "revolutionary process improvement," which proved the spur–and as the product owner, he "invested" an extra two minutes in iteration planning. They doubled their productivity in the third and final iteration. Still no errors, I might add. If anyone is looking to hire a crack ball-passing team, I've got one for you.

What did they do so right?
They didn't mess with what worked. "Let's stay in our positions, as we're used to the behavior of the person we've already been passing to." 

At the same time, they did not settle for incremental improvement, but looked for the leap–"Can we keep our process the same, but pass two at a time instead of one?"

During their planning phase, they did more than they talked, trying things out. "Talk is cheap," one of them said.

When they did talk, it was to inquire. "What are the questions we should be asking," another said at the outset of the third planning round.

The debrief elicited a lot of good stuff, too:

"Since we had no drops, I wonder if we weren't being too risk-averse. We might have had more productivity if we'd allowed more error."

"Haven't we all been in places where a lot of attention was given to optimizing writing code, when people spend 5-10% of their time writing code, and the rest looking for bugs."

"It's exhausting to work on a project when your sense of owner is greater than the owner's."

"We all spend a lot of time grousing about what the people upstream are doing, and seldom give any thought to the people downstream from us."

"Is there such a thing as too much optimization?"

Sound fun? Come play on August 3 & 4, when we'll be running the same class at the Alliance Francaise in San Francisco–vous etes tres agile, non?

Share it!