Jan 302014

Agile practitioners talk a great deal about the importance of breaking bad old habits and replacing them with muscle memory. Since you’re breaking down programmed, reflexive responses, you need more than words. You don’t reason with a habit.

That’s why I often inject serious games as training exercises when I’m working with someone in the midst of an Agile transformation project. For one client, specialization within teams was a serious stumbling block to Agility. As long as Bob (not his real name) was the only person who could build a particular kind of critical component, Bob would be a choke point in every sprint. Other team members had similar specializations in platform issues, data formats, and other matters.

The team was afraid to take the time to cross-train other team members into the mysteries of these domains, for the stated reason of incessant, crushing deadline pressures. While that may have been true, I also wondered if Bob and other team members got some personal satisfaction from being the keepers of arcane knowledge.

Their unwillingness inspired me to design a simple Agile planning game. Three people took the roles of developers (not a big stretch for them), each with his or her specialization. Each story in the backlog required some specialized skill to address. The “moves” in the game consisted of taking actions (code, test, etc.) needed to complete the story. All the stories were fairly small, since I wanted the game to be short, and complexity wasn’t the point of the game anyway.

I then asked them, “How many days do you think it will take to finish these backlog items?” They estimated two days. When they finished playing the game, it had taken them five days to finish these stories.

They had not factored in the unexpected, the inevitable escalations, sick days, underestimation of story size, and other wild cards that exist in the real world. Their ballet of uninterrupted work and perfect efficiency turned into something that looked more like my own hilarious, unsyncopated attempts at line dancing. (I will not try again, so you’re all safe.)

They made matters worse by scheduling every available minute each day, leaving no cushion. Therefore, when Tarvinder needed Bob to help him with an issue, Bob was still struggling to finish one of his stories.

Coaching is the right forum to really fix these problems, but I had to make a point before they got started. My monopoly of knowledge in a particular domain might slow down the team’s velocity, cause more defects to get assigned to me, and generally make my life harder, but I’ve been living with this code and this domain to see the situation as anything but inevitable. Just like drama helps us step outside ourselves long enough to recognize our foibles, games sometimes help us see that the way we’re working isn’t the inevitable denouement.

I’m now working on another game to address a related challenge, getting people to see that promising less more reliably is better in the long run than committing to do more less reliably. The primary audience for that game is managers and executives, who are often the people responsible for overcommitment. I know that I’ll have a chance to use it; it’s just a matter of when.


  One Response to “Agile games versus force of habit”

  1. avatar

    Hey Tom,

    Seems like an interesting game.

    Is there any place where the script of this game is documented? Is on Tastycupcakes.com?

    BTW – The annual Agile Games (2014) conference is in Boston in June. It is a fertile ground for you to polish this as well as other games that you have designed or are thinking of designing.

    Would love to have you here and play Agile games with us here.

    With Best Regards


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>