Developing Games Fosters an Experimental Mindset

January 21, 2012

So, for the past week or so, I’ve been developing the Impediments Game. You can see some of my efforts: interation 1, iteration 2, Interlude, and Iteration 3. Now I have no experience or expertise designing games, so as you might imagine, there has been a great deal of trial and error involved in this process. Whenever you add a new element or change an existing rule or component of the game play you are doing it with some sort of hypothesis in mind. For example, If I add “Accelerator cards” it will give the players a way to overcome the negative impact of impediments. That’s the kind of hypothesis I’m talking about. How do we actually run an experiment to test the hypothesis? We play the game!

Game play gives us the tangible feedback that we need to validate our hypothesis. Playing the game gives us both subjective and objective data. How does the game play feel? Was it fun? How long did the game take? How many cards did you use? Which strategy won out?

What I’m experiencing as I play the game is a lot of different questions – questions that can form the foundation for the next experiment:

  • How would the game work without cards (I could try using points…story points? The person with the most story points wins?)
  • What could I add to the game to promote teamwork? Would there be some sort of benefit accrued by helping your opponent?
  • Should elements like risks, impediments, and accelerators have a limited lifespan?

Of course the real joy of games is that you can run your simulations over and over and tweak things until you are happy with them. That’s what I mean by an experimental mindset. I see all too many teams that seem unable to come up with meaningful experiments to try and modify their performance. They have a hard time coming up with the “What if…” part of the mindset. Perhaps they should be playing, or even better, making their own games.


Developing the Impediments Game – Part 4

January 20, 2012

So today was a day to make a few changes and take stock of where things are at. The first change I wanted to make was to double the length of the game from 20 spaces to 40:

Changing the board like this actually raised a few interesting questions about the game for me. First, what does each space on the board represent? It could be:

  1. A square, just like on the sidewalk, just a position to advance to…
  2. It could represent a unit of time, like a day, or a sprint
  3. It could represent a position in a queue or a backlog

In this case, for right now I’m going to just keep it simple. I haven’t assigned any particular meaning to the spaces (although the astute observer might notice that they are now arranged in rows of ten, just like some sprints…). All I really want to do right now is insure that the game is sufficiently long enough that I can guarantee that whatever strategies each player of the game uses has a chance to fully play itself out in the duration of the game. In the first iteration of the game, with only 20 spaces, the game could play itself out in 4 rolls of the dice. That seemed too short, so I’ve switched to 40 spaces.

The other thing I felt it was important to do was to spend some time just playing the game and question the value that I was getting out of it. So I played this longer version, but just with the impediments, not with the risks. I learned that if I played two players with equal strategies – in other words both doing the best they could to win given the circumstances of each roll of the dice, the game felt a little frustrating. You spent your time trying to move toward the finish and were constantly being assaulted with impediments. It felt pretty tedious.

That brings up an important point: in most board games there are both positive and negative things that can happen to a player, even if they all just occur by chance. The classic “CandyLand” is like that. Playing with just impediments is kind of depressing. Especially when you can’t do anything other than pay their price. That’s where adding an element like risks to the game allows you to start doing something to proactively avoid impediments. Integrating risks into the game makes it feel much more interesting. Apparently dealing with impediments doesn’t feel nearly so bad when you have a strategy to deal with them. I think there might be some keen observations on learned helplessness lurking under that observation someplace.

What else can I do to give the player ways to deal with impediments? How about some Accelerator cards?

What would accelerators be? Here are some examples:
  1. TDD
  2. Pair programming
  3. Continuous Integration
  4. Continuous Deployment
  5. Automated testing
  6. Retrospectives

Each one of these things are the types of activity that a team can use to mitigate the impact, or even completely avoid some kinds of impediments. Time for more cards! I’m going to have to hit the office supply store soon!


Developing the Impediments Game – An Interlude

January 18, 2012

I know what you’re probably thinking by now: MORE on this silly game? Well, yes (I’m so embarrassed). You see, it just gets more interesting as I continue to play with it. Today I decided that I needed to improve the impediments cards in the game. In previous iterations, the cards had the word impediment printed on one side and the impact or cost of the impediment was printed on the other side. I thought it would make the impediments much more interesting if I used some real world examples. So, using the list of 100 impediments that was compiled by William Wake, I added an impediment description to each card. Now they look something like this:

What I like about having actual examples of impediments on each card is that players now get familiarized with different kinds of impediments while they play the game. Players actually might learn about different kinds of impediments! That’s kind of a nifty idea.

You see I have a confession to make: so far the game has been a way for me to try and model my own hypothesis about how impediments and risks impact teams. For example:

Hypothesis: A team that deals with impediments will have a higher velocity than at team that doesn’t address their impediments.

Hypothesis: A team that deals with Risks will have fewer impediments to deal with and subsequently higher velocity.

I confess that these are not complicated hypothesis, but they pose the kinds of assertions that I would like to validate. It turns out that constructing a game with rules that define the boundaries of the problem is a really fun and engaging way to test the validity of those assertions. But as I build out the game further, I’m starting to realize that games can also have learning objectives as well. Perhaps I ought to define some of those. For example:

  • People who play this game will learn about different kinds of impediments – some that they may not have ever considered before

Well, that sounds like a pretty good thing to me!

So now I’m thinking about the game a little differently. I’m looking at the games not only validating my own hypothesis about how impediments and the way we manage them (or fail to) impacts teams, but also providing a tool for teaching others about what impediments are and how they work. I think more people should create games!