Quadrants version 1.0

Last Monday, the Quadrants of Effectiveness game was officially introduced at XPDays Benelux. About 25 participants were brave enough to sit around five carefully designed game boards, digest version 1.0 of the game rules and try to become the most effective tribe member in a 15,000 BC setting. In three rounds, they learned to apply the Eisenhower method, around which the game has been designed.

After overcoming a fairly steep learning curve during the first 10 minute round, the teams really got into the game and gradually started becoming more effective, using the built in benefits, decreasing quadrant I activities. I was pleasantly surprised to find out that 4 teams out of five finished at least one full game, reaching the last field on the game board. The feedback was mainly positive.

When we played the game again during the games night on Monday evening, the discussions and additional feedback led to an idea for version 2.0, on which I will focus during the next couple of weeks. In an attempt to transform the delegate action to something that is more alike delegating in real life - i.e. giving less important work to someone who it is more important to - the point system will be redesigned to take into account five different scales, one for each player, without adding significant complexity to the game rules. While in version 1.0, gold, water, food, etc. have the same value for everyone, in the next version, each type of point will be more valuable to one specific player.

Although it adds a bit of complexity and needs a carefully redistributed set of cards, it will definitely bring some extra benefits to the game and the session. No doubt the most important feature is that it encourages team play. Instead of delegating crap to another player, you will actually be able to delegate useful activities to someone else, being a lot more aligned with the real world. This adds a collaborative aspect to the game, which it is currently lacking. It will also add to the possible game plays, and keep it interesting, even after many games. Not sure yet if the game can have fewer cards because of the redesigned point system, but if so, it will definitely contribute to how it advances.

All in all, I'm very happy with how the game was received, and even more with the valuable feedback that I soon hope to incorporate in an even better version. So stay tuned for more news on the Quadrants of Effectiveness.

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!