Agile game design

It was going to be fantastic. 241 game cards and a 24 x 36 inches game board would make the maiden play of the Quadrants of Effectiveness game an unforgettable event. Sure, some minor adaptations would probably be necessary to make it usable in a professional environment, but the final version would not be that much different from what emerged from a scary idea to teach the Eisenhower method in time management.

Yesterday was the big day, the official inauguration of a business game forever reshaping the landscape of dull time management courses, filled with suits rigorously writing down every single sentence escaping the teacher's mouth. From now on, those same women and gentlemen would be standing around a game board, sweat pearls on their foreheads, high heels kicked out, ties loosened, to win a game that would prove them to be the most effective tribe member in the forest of effectiveness. And most important of all, they would remember how to use the winning strategy in their day to day life.

I invited a friend over for the tryout and the first comments were great: "nice board, funny cards, great theme". So we just started playing. But after about 5 minutes, I got the first real feedback. A huge flaw in the rules could neutralize built-in penalties, and fixing that flaw as we continued playing, surfaced another important issue. So I started thinking: Why is it that even the first version my new software usually doesn't contain any show stoppers? And how can I use this knowledge to continue designing the Quadrants of Effectiveness game?

The requirements for the game were carefully written down, acceptance tests defined. However, after carefully writing down the rules and validating them against the acceptance tests, it didn't seem to be even close to ready for production. So how can I prevent the same thing happening in the future? First of all, I extended the test set to find the issues we encountered yesterday, just to make sure that they don't show up any more in future versions. And like with TDD, I will design tests to validate a desired goal even before I start thinking about a rule to reach it.

Let's see how this works out!