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!


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.


On Human Thought and Planning

January 3, 2010

Over the holidays I’ve been reading “The Design of Everyday Things” by Donald Norman. It’s a wonderful read, but dense – it’s definitely “armchair and a pipe” material – you can’t rush it.  I came across this interesting quote regarding the nature of human thought:

But human thought – and its close relatives, problem solving and planning – seem more rooted in past experience than in logical deduction. Mental life is not neat and orderly. It does not proceed smoothly and gracefully in neat, logical form. Instead, it hops, skips, and jumps its way from idea to idea, tying together things that have no business being put together; forming new creative leaps, new insights and concepts. Human thought is not like logic; it is fundamentally different in kind and spirit. The difference is neither worse nor better. But it is the difference that leads to creative discovery and to great robustness of behavior. [p.115]

In this paragraph Norman is talking about the fickle nature of human thought. When he refers to planning as a close relative of human thought, I couldn’t help but think of project planning. As Norman suggests, human thought is not the orderly process we might like it to be. If that is the case, then project planning is not the neat and tidy system that some people would like to sell you. If thought and planning are truly akin to one another, as Norman suggests they are, then I would suggest that any system that attempts to turn planning into some sort of logical, deterministic process is destined to fail. The intriguing idea here is that planning needs to accommodate creativity, intuitive leaps, non-linear processes.

I think there are a lot of people who grasp this notion, and I think there are many others who have a great deal of difficulty with it. Those who don’t accept this notion tend to try and wrap more and more layers of process around the problem. Those who accept the need for creativity and intuition in planning – people who are more comfortable with uncertainty – are more likely to treat the planning process as a dance: You know what the steps are supposed to be, but you are prepared to change at any moment.


Inspired by Executable Design

December 16, 2008

design

A post on “Executable Design” from Chris Sterling inspired me today. I’ve started running TDD workshops with the teams that I work with. It’s one of the most challenging things I’ve done in a while. Part of the challenge lies in exercising my technical skills – nothing exposes you to a group like coaching directly on coding techniques. Developers can smell your fear…

However I find that technical issues aside, acceptance of TDD lies in doing a lot of listening. And I mean a LOT of listening. As Chris states so eloquently, TDD is not a silver bullet that should always be used regardless of the circumstances. When someone is objecting to using TDD, there is often a darn good reason for it. Sometimes they just fear change, but as often as not, I find that people have realistic concerns about the appropriateness of using TDD in the particular environment they work in. Ignore them at your own peril.

Most of the time people understand the merits of TDD quite quickly – let’s face it, it’s really quite simple: Test. Code. Refactor. Repeat.

The merits of the process are not what people usually have problem with. Usually they are envisioning what happens when they try to apply it to the environment they are currently working in. That’s where the rubber meets the road. You have to be willing to listen to them, take their reservations seriously, and venture into the dragon’s lair (the environment they work in) to understand what they are dealing with. It’s very hand’s on. Very messy. Fraught with challenges.

Very quickly you can discover that TDD is not an all or nothing proposition. If people feel like you hear and understand their reservations and concerns, then they will probably be willing to follow you down a path toward some sort of adoption – if there is measurable  benefit. They may be willing to explore a variety of useful but perhaps imperfect solutions. On the other hand, if you are just regurgitating the benefits of TDD and dismissing fears…well, I’ve tried it and not had much success.