Just Agile Games - Test Driven Drawing

Usually I don’t play games.
Fanny Pittack

Usually I don’t play games. Since Change is the topic of both Alex and I though, I decided to change my attitude about games. It occurred to me that playing games in the agile community is a thing. I wanted to find out why, stepped out of my comfort zone and even volunteered at the Agile Testing Netherland to host a game. Test Driven Drawing. Thank you Bart for all your effort in making the Agile games market happen and for giving me the opportunity to be a part of it.

Let me share the experience with you. Test Driven Drawing has a few simple rules, two iterations and one testphase.

Test Driven Drawing is a game to slow down and focus on one way communication.
The attendees are not allowed to look at each other and are forbidden from supporting their talking with hand signs. To play Test Driven Drawing you need four people. These four are a team. While the team members are introducing themselves they also need to pick roles.
Two product owners and two developers. One developer and one product owner pair.
Chairs are located back to back, so that the pair can not see each other.
The developer gets provided a pen and a paper and the product owner gets his product:
a piece of paper with multiple shapes drawn that differ in size and form.

In the first iteration the product owner describes the shapes (his product) to the developer. The developer listens, asks questions and codes (draws the shapes).
The first iteration stops after 7 to 10 minutes. The pair is still not allowed to look at each other’s papers. The next step is a testing phase. The product owner now writes four tests on a fresh piece of paper.
The developer and the product owner can now compare the “code” and the tests.

Iteration two starts. The product owners remain seated and the developers swap their seats. The new pair is still sitting back to back and are not allowed to compare notes or look at each other. The product owner hands over his tests to the developer and the process starts again. The product owner explains his product (the shapes) and the developer starts coding by drawing on his paper. The iteration stops and
the product owner and the developer compare notes.

I had the honor to run the game twice. The first round was with two teams and the second one with three teams. We shared a workshop room with two other games facilitators. Next to us Mike Sutton was hosting the air plane factory. The teams started to work while paper planes jetted through the room. Totally realistic open office atmosphere.

The pairs needed to focus hard. I was observing that it was an extra effort for them to block the noise around them, communicate by the rules and avoid looking at each other.
All team members had no problem switching to the role of a developer or product owner. Also no product owner “complained” about having to write tests.

The attendees shared their thoughts and we ran a quick retrospective session.

Main learnings were:

  • Preconditions are as important as requirements;
  • Four tests are not enough;
  • Ask more questions;
  • Working with examples helps you understand the requirements;
  • Tests can be confusing sometimes.

What did the attendees miss during the game?

  • Preconditions;
  • Orientation of the canvas;
  • Not knowing the specific word for different shapes like triangle or square e.t.c.;
  • Looking together on the code while pairing.

What did the attendees like about the game?

  • Very easy to misinterpret;
  • Words only, lets you fail faster.

Ring a bell?

I was surprised how familiar the outcome sounds to everyday project life. Let me sum up with my observations. After the two iterations both parties were exhausted. The developers a bit more so, since they had a huge context switch and needed to “code” two different kinds of shapes in a short amount of time. The developers had more issues to concentrate on in the second iteration than the product owners.
The pairs were so relieved when they were finally allowed to look at each other and compare notes. You realize how important eye contact is while working on a difficult task together, when you don’t have the opportunity to smile. Comparing both iterations then, it seemed in the second iteration the product owners got more precise in their descriptions and the developers were asking more questions.

Try it with your team in your own company. Ping me for a complete summary on how to play the test drawing game. Thank you to all attendees who were part of the Agile Games Market.

I will definitely attend the next game session on Agile Testing Day in Potsdam.