In January, Ipek Ozkaya, Nanette Brown, Robert Nord, Philippe Kruchten and I spent a few days together at the SEI in Pittsburgh, PA to brainstorm and develop a game to teach the concepts surrounding technical debt. As a starting point, we participated in Chris Sims’ Creating Agile Learning Games workshop to learn about the elements involved in game design. There, we came across the “Short Cut” game by Quality Tree Software Inc., which we found contained a lot of the basic elements that we wanted to use to communicate about technical debt. As good software engineers would do, we adapted, evolved, and improved on the “Short Cut” game to give birth to our own board game, “Hard Choices.”
The purpose of Hard Choices is to help players recognize, develop, and learn strategies for managing uncertainty, risk, options, and technical debt. Each player’s goal is to finish the game with as many points as possible. Players can collect points in one of two ways: by landing on a square marked with a tool (1 point) or by not finishing last (1-5 bonus points). As the players traverse from start to finish, they are faced with the decision of taking shortcuts (marked as bridge squares) and incurring penalties (subtracting one move from every subsequent dice roll until the end of the game), or taking the longer route, finishing more slowly, but increasing the chances of landing on tool squares and collecting more points.
Recently, on March 1, 2010, I facilitated a “Games Night” for sixteen members of Agile Vancouver who came to the University of British Columbia, in Vancouver, Canada, to play Hard Choices. The players that night ranged from software engineers to project managers. Armed with only the knowledge of the rules of the game, the participants divided themselves into groups of four and began playing the game. As the game play progressed, it was great to hear conversations shifting from double-checking that certain actions were allowed in the game to discussions and debates about strategies for finishing and winning the game:
“I’m so close to the end, if I take a shortcut now, I’ll finish faster”;
“Gah! I’ve got so many penalties accumulated, I’m not going anywhere!”;
“Wait, it doesn’t matter if I take the long route now because so-and-so has already crossed the finish line and the difference in reward between first place and second place is so small, it’s not worth it.”
Afterwards, I hosted a debrief session to gather feedback from the players and to discuss the strategies that they learned from playing the game. One player commented that he decided to play aggressively and to take as many shortcuts as possible so that he could finish first and collect the extra bonus points. At the same table, another player decided to play conservatively, avoiding all the shortcuts but collecting points instead. When the game was finished, the conservative player ended up winning the game over the aggressive player because, over time, the aggressive player became paralyzed by all the penalties he had accumulated from taking shortcuts. Another player observed that his decision to take shortcuts was relative to the position of the other players on the board. Someone else recognized that luck also played a huge part in the game as she was having difficulty rolling high values on her dice. For her, even though she “did all the right things” by avoiding shortcuts and collecting points, her progress through the game was so slow that she eventually changed her strategy to start taking shortcuts in order to “keep up” with everyone else in the game.
Most interestingly, almost all the participants were in consensus that they were really curious to have business managers play Hard Choices. The participants were eager to see what the game would reveal about how business managers viewed and handled risk and uncertainty. Several participants pointed out that this insight would be beneficial because software engineers and business managers ultimately have very different goals on a project – one aims to produce a quality software product while the other aims to produce a software product with as many features included as possible.
Playing Hard Choices stimulated a lot of discussion and reflection on the current real-life strategies for balancing quality, budget/schedule, and features on a project. Over the course of the next few months, we will be playing Hard Choices with different groups of software engineers and gathering their feedback and comments. In particular, we will be playing Hard Choices as a COOL event at the upcoming SATURN conference in Minneapolis, MN from May 17 to 21, 2010. I’m looking forward to it!
Erin Lim – University of British Columbia
Member of Communicating the Value of Architecting within Agile Development project