Playing the Specification Game

As part of my ADC experience, I enjoyed being part of Gojko Adzic’s session: The Specification Game.

The room was divided to groups of four – there were 6 teams. Each group included a product owner, developers and testers. Gojko and his team were the customers. They rolled out a product they needed: a Black Jack application. We all received a page with description and requirements. We then needed to plan and perform iteration 1. This was not a coding exercise: The developers created an algorithm, and the testers would run through it.

I was the product owner (Product owners were picked by their familiarity with the game). I selected the most important requirement from the requirement list (as I understood it) – the basic algorithm for the dealer, and discussed it with the developers, who committed to completing it. The iteration took 20 minutes, but we got an extension of additional 10 minutes. Our tester got additional training from the customers (I don’t know what exactly, he was separated from the group at the time), and once he returned he created a test case, then ran it, as the algorithm was completed, then wrote an additional one.

When the iteration ended, we paused, and everyone gave an estimation of how much of iteration 1 was the team able to achieve from what was planned. We wrote this percentage down.

Then we got  a list of acceptance tests from the customers and ran them through the system – not the algorithm, but the entire software. Since our requirement was the algorithm, and did not include taking or giving back money, all the acceptance tests failed (because they included money).

Do you see where this is going?

We then were asked to estimate the value of iteration 1 again. Then we discussed the results.

  • None of the teams, including yours truly, asked the customer what was most important for them. <shame>. If we had asked, they would have told us the simplest thing they needed, which is possible to achieve within a 20 minute iteration.
  • I picked the algorithm as the most important requirement, which did not involve money. As I tried to defend this choice (poorly) Gojko asked me – what is the customer paying for? <shame again>
  • Our team was the only one who wrote and ran tests. Also, they passed.  Making sure that we have tests, communicating between all parties, and making sure that we didn’t write the 2nd test before running the first one, we were able to run it, fix bugs and run it again successfully. <pride>
  • The estimation of the achieved value, varied so much, both between teams, and within the teams. If the customer had asked different people on the same team, he would get all kind of percentage between 0 and 100. In fact, if there was better communication inside the teams, the variance would be much lower. <puzzlement>

Gojko explained that under pressure, we leap forward and try to be the best we think we can. The truth is, there’s the obvious choice of asking the customer what he wants, then commit to the iteration and perform it successfully, therefore winning the game.

This session was an eye-opener for me. I was proud about the things I’ve managed to do with my communication skills, but slammed in the face with the reality that I did not do there, what I do in my everyday life. And no – everyone else failing too, does not make it better.

In my karate past life, we used to call what our training a micro-cosmos of our life. Sometimes going through an intense micro experience like this can really help improve them. I really recommend this session if you’re able to catch it somewhere near you.

Share Button

Leave a Reply

%d bloggers like this: