Developing the Impediments Game

January 16, 2012

I was inspired recently by a twitter post from Elizabeth Hendricks where she said she was working on an impediments game. I thought that was an absolutely wonderful idea, so I wanted to take a swing at it myself. Once I finally managed to summon the courage to try I sat down and put together a preliminary set of rules. Here is my first attempt (first iteration):

Overall the game is organized as a straightforward racetrack, first-to-finish objective. Gameplay is in rounds, where each round consists of a capacity roll and an impediment roll. Capacity is the number of spaces a given team may advance. A roll of 1-3 means a team must take an impediment from the impediments deck. Impediments are subtracted from the teams capacity each turn and have a fixed cost that must be paid in order to remove them. In each turn a team can decide to spend their capacity on forward advancement toward the project finish, or apply some or all of that capacity toward resolving impediments. The team that reaches the project finish line first wins the game.

So there you have it, a set of rules to begin with. They’re pretty simple, but I don’t know anything about designing games so simple seems like a good approach for me. Next, I raided the kids game chest for some dice, playing pieces and a few ideas.

To make a board, I took some 3×5 cards and cut them up and laid them out in a pattern that was inspired by Candy Land. I cut up a few cards and made myself a deck of impediment cards. So now, I had a board, some playing pieces, impediment cards, and a 6 sided dice.

Not a bad start really. It looked like this:

OK, sorry about the table cloth – I know it’s atrocious. So I tried playing out a simple scenario to see how it felt. I had two players, blue and green. Blue was going to take the strategy of always investing in resolving impediments, and red was going to try and plow along without paying the impediment tax. So we started with round one, with both players at the start:

Green goes first and rolls a 5. I moved him five spaces forward and then rolled the dice again to see if he encountered an impediment. That’s two rolls each turn for each player: the first roll determines how many spaces they may travel forward, the second roll determines whether or not the player encounters an impediment (a roll of 1-3 means you draw and impediment card, a roll of 4-6 means that you didn’t encounter an impediment). Green rolls a two, so he pulls an impediment card off the deck:

This impediment card had a value of 2. This means that from now on, when Green rolls the dice to see how many spaces forward he can go, he will have to subtract 2 from the value of each roll. For example, if he rolls a 4 he can only move forward 2 spaces (4-2=2). Now in this case Green is just going to suck it up and try to keep going forward without eliminating the impediment.

Blue’s turn is next. He also rolls a five right off the bat. For his impediment roll, he rolls a 1, so he also pulls an impediment card. His has a value of 4 (that’s a pretty steep impediment). So at this point in the game, after one turn each, our players are at the exact same place on the board, however we haven’t had a chance yet to play our strategies out.

Green has the next roll and  gets a 6 so he moves forward 4 spaces, taking into account his unresolved impediment of 2. He then makes his impediment roll, and wouldn’t you know it? He gets a three, which means he just earned himself another impediment. This impediment is a 5. OUCH!

Blue takes his next turn and gets a 4. Instead of moving forward, he uses those 4 to pay off his impediment and resolve it. I arbitrarily set the price to resolve the impediment as equal to the impact of the impediment. So for this turn, blue doesn’t get to go anywhere, but at least he doesn’t have any impediments to deal with. Nice!

So then it’s Green’s turn again…but wait…Green has accumulated 7 points of impediments! There is no role of the dice that will overcome that (six sided dice anyway). So Green is completely blocked. He rolls a five, but because of his unresolved impediments he’s not going anywhere (5-7= no forward progress).

And so it goes, blue ends up racing to the finish line, resolving the occasional impediment along the way. Green remains trapped, completely impeded and unwilling to resolve the issues blocking forward progress.

At the end of the game I realized a couple of things. First, I had impediment values that ranged randomly from 1 to 5. For green, this meant that they accumulated pretty fast. Green only made it two rounds before he was stopped completely. You could argue that this makes sense. Any team completely unwilling to address their impediments at all is likely to have serious problems. On the other hand, I might argue that in reality, most of the impediments that I encounter on projects tend to slow it down rather than stop it completely. So I’m considering lowering the impediment values in the next iteration.

Perhaps more importantly, I’m not sure that this particular scenario offers a significant learning experience or not. It seems a bit too simplistic to me. Perhaps I need to add some additional elements that might better reflect the chaotic nature of the typical project? I’ve created a set of Risk cards that I’ll also try out in the next round. What else should I try? Next stop: iteration 2.


What I Learned From My Daughter’s First Grade Classroom

September 10, 2009

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied that she was with the dork taking all the pictures of the walls. Here’s what I discovered before I was escorted from the building:

DSC03018-1

The first grade classroom is the prototype for a learning environment. These folks are the undisputed masters of the information radiator.  Everywhere you look there is information being displayed. The variety of different kinds of information displayed is amazing! The density of information here is incredible! In one corner of the room I see the following information:

  • Monthly calendar
  • Weather graph
  • Password(???)
  • The alphabet
  • A tally of how many days they’ve been in school
  • Numbers from 1-10
  • Days of the week
  • A chart of all numbers from 1-200
  • A list of who has lost a tooth (Try that on your team! If the number is greater than five, you may be working in a biker bar)
  • And a few other things I can’t quite interpret

What else can we see going on here? Well for one thing, there is LOTS of color. It catches the eye, calls attention to certain details, and livens things up quite a bit. It’s like an interior decorator went nuts in the place. Next, you may observe that much of the information is presented using multiple modalities. Multiple modalities? OK, they use pictures AND words AND color AND shapes. A lot of effort is being made to transmit information in a variety of different ways. Now, just for giggles, what if you were going to put together this exact same board for your team at the office? What would it contain? Here’s how I might do it:

  • Monthly calendar – team vacations, releases, events, barbecues
  • Release graph – How many releases per week are we doing?
  • Word of the day (“Spurtle” – yeah, it’s a word)
  • A quick reference containing all of the major Ruby commands (pick your API/Language, etc)
  • A tally of how many days they’ve been working on a project/sprint/release
  • Numbers from 1, 0 (hey, it’s computer science, you only need two numbers!)
  • List of major business holidays (they always sneak up on me)
  • A chart of all error codes used in our project
  • A ladder of World of Warcraft names/rankings

Hmmm. That’s actually not a bad list. Give it a little color, play with the “modalities” and I just might have some pretty compelling information there. I wonder what else the first graders have to teach us? How about this:

DSC03023

I see at least three things here that I could try out with my team back at the office. First, there is information about today: we have the date, and then  below it is the day’s schedule. Now, I don’t know about you, but back at the office, I don’t have anything like a daily schedule posted on the wall with my team. We all have outlook, and perhaps some would say that’s enough, but for me it’s not quite the same. Outlook reflects MY schedule, not the team’s schedule. And there are significant team events that could use some advertising: Planning meetings, releases, retrospectives, reviews, scrum of scrums, and so on. I know that where I work, everyone is left to their own devices to manage these things and show up or not. Nothing wrong with that, but what if we had a daily schedule, a reminder if you will, that sat next to our task board at our standup meeting? Frankly, I think it might be useful. As a scrum master, it might be a way for me to rather subtly remind the team of the big commitments for the day. Or not.

Let’s move on from the schedule stuff. What’s up with the bottles of ketchup, mayo, and mustard? OK, it may be a little cheesy, but if you look at the image closely you will see that these are clever little symbols for “Catch-Up”, “May Do”, and “Must Do’s”. Do you track Catch-Up work on your team? No? Me either…wait a second…we do keep a list of technical debt. Isn’t technical debt a kind of  Catch up work? So keeping that list of catch up items makes a lot of sense to me. Also, the “May Do’s” and “Must Do’s” make a lot of sense to me as well. I think that defining work as “Must Do” will help the team prioritize the work that is most important (assuming you don’t abuse it) and the “May Do’s” gives the team the ability to identify the things that are available to be pulled on their own initiative. Adding may do and must do to a team’s daily activities would certainly be interesting to try out. I can see pros and cons to doing it. Maybe we could even use these criteria to categorize our backlogs? It’s a possibility…

How about the noise level trumpet off in the corner there? In the wonderful Agile Open Space that you work in, do you ever have issues with noise? Here is your answer! I wonder how well that actually works in a room full of first graders? OK, I’m not going to give them grief for this – it’s probably an experiment.

Here’s another gem that I captured before being chased out of the room by a rather menacing looking old battle axe with a broom (where DO they get these people?):

DSC03026-1

Would you look at that! They use the “Fist of Five” in first grade too! I was wondering where that technique came from! I need a copy of this poster for my team!

DSC03028-1

Ooh! Look here! They are graphing their moods over time! Cool! I’ve seen other teams do this, but I’ve never tried it myself. It seems like an idea with some real merit. It certainly makes sense to track the teams mood. It would be very interesting to review information like this at team retrospectives. It would certainly provide an interesting metric to compare against recent “improvements” or other team experiments. One other thing I want to point out here: these teachers seem to think that these information radiators are so important that they will try and cram them just about anywhere! Anyplace is game: the backside of a bookshelf, the side of a locker, the face of a cabinet – any place they will fit. Look around your office. Are you using all the space you have available?

Here’s a quick challenge: So what do you think this is?

DSC03027-1

Well, as my daughter ever-so-patiently explained to me, this is their “Job Wall”. I like the beehive image – after all we Agilista’s like to “swarm” don’t we? It seems that everyone has regular tasks that they are responsible for. These are tracked here. I like the way it makes responsibilities explicit for everyone involved. It makes me wonder where the teachers get all this stuff? Of course if I were to show up with this silly little beehive, I’m pretty sure that the team would laugh me out of the room. Of course that never stopped me in the past…

You know, if they ever  lift the restraining order and let me back on school property again, I’m definitely going to take some more pictures of the classroom walls. How come more offices don’t look like this? Why aren’t the environments we work in as information rich as the ones that children work and play in? I presume that in the office we are learning too, right?


Learning Games

June 22, 2009

What’s up with the cupcakes? So there was this wacky little session at Agile Roots 2009 that I really enjoyed that was put on by Chris Sims. It was called “Agile Learning Games”. It was one of those sessions where everyone gets to try out the games as a participant and get a feel for the kind of learning that takes place. I loved the games that he chose to demonstrate, and he was kind enough to provide some references for places that you could look for more learning games – one of which was called, “TastyCupcakes.com”.

I think these learning games are very useful because they allow teams/groups to experience or play with an idea rather than having it preached to them by some sort of expert. I find that I learn things much better when I can participate in a hands on fashion. So as a facilitator and coach, I find these kinds of exercises to be especially powerful when working with teams.

These games can form an important part of any facilitator’s toolkit. I’ve been collecting a list of sites that catalog these learning games for a little while. Here are some references that you might find useful:

http://blog.tastycupcakes.com/

http://uoleadership.uoregon.edu/exercises/energizers

http://www.businessballs.com/teambuildinggames.htm#leadership%20management%20exercise%20for%20teams

http://www.squarewheels.com/scottswriting/mission.html

http://www.nasaga.org/

http://industriallogic.com/games/

http://www.funandgames.org/Games_icebreakers.html#2TruthsAndLie

http://www.isnare.com/?aid=193973&ca=Business+Management

The tastycupcakes site has games that are most relevant to Agile Development, so I would start there first. This list is by no means comprehensive, but if you are looking for some games that might help you get an idea across, this list should get you started.


How I Discovered “Gordon The Guided Missile”

June 18, 2009
Alastair Cockburn gave the opening keynote speech for the conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:
If you live in Utah, you are very lucky to have a high powered group like this around. You can also find likes to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!
Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here: http://www.contextmag.com/archives/199806/innerGame.asp?process=print
The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.
Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I love creativity. Maybe that’s why I like software development so much. Writing code, what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.
So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:
1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.
2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.
3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.
The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!

Fireworks_Rocket

Alastair Cockburn gave the opening keynote speech for the Agile Roots 2009 conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find links to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here:

http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I absolutely love creativity. Maybe that’s why I like software development so much. Writing code – what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!