Coin Sorting with a Twist

pile_of_swedish_coins500x750I went to Budapest last week to do a workshop with the local management team of one of my customers. The goal was to talk to them about how they could move into the agile way of working. This was triggered by a move of some substantial product development from Sweden to Hungary. In Linköping, Sweden, I have been coaching a dozen teams in a transition to Agile, and I was asked to help the management to ensure that the transfer retain as much as possible of the Agile way of working that we have established.

I decided to select a few exercises, and add a set of scenarios that we could analyze together. I was hoping that the exercise would give them first hand expericene in the values of Agile and that this and the scenario analysis would spawn good discussions. And it did. Actually, I did only use one of the exercises I planned.

The exercise that I used was from Tasty Cupcakes and is about sorting coins. We use that exercise extensively in our Agile training, so I knew it would work, but I decided to add a few twists.

The exercise is to ask the group, preferably divided into teams, to estimate how long it would take them to sort a set of coins. The team with the lowest estimate actually get to do the sorting.  This raises the level of competitiveness in the group.

I decided to add a “Requirements Specification” to the game. Instead of telling the team what it was about I had prepared a document stating that they would get a number of coins of various value, how high piles could be, how far apart they where allowed or required to be placed and some other facts. (An unplanned complication was that I had stated distances in millimeters and a couple in the group where actually Irish…)

So after a “pre-study” period the bidding commenced. As often happens one group had a low bid and the others said “Let them do it!”

The team were actually done on time, which is kind of a bonus. Because the kicker is that almost always the coins are sorted according to value although that has never been specified.

I think adding the written “Requirements” shows how easy we are thrown of track by something written. It’s not just the fact that written communication is narrow-band, it is also very often misleading since if someone has spent so much time writing the document, specifically if it also has been reviewed and approved, the truth must actually be in there somewhere. And everything in it must be equally important, right?

Of course, the 10,000$ question that someone should ask is how you actually want them sorted. (Occasionally this question is actually put during the bidding and then you can either try to be undecisive, misleading, or you can just take it from there.)

But the billion dollar question that I really want to hear is “Why do you want them sorted?” I had prepared an answer: I want to be able to sell piles of coins as birthday presents so all the coins should be from their birthyear. I hope that I will someday do this exercise and have to use this answer.

By the way, at the end of the workshop one of the managers said “So I think we cannot wait for the transfer to be done and then start becoming Agile, we must do this now”.

CHAOS or not?

The CHAOS reports from the Standish Group has become infamous, so much so that Sean Hanly made us promise to never quote the figures as evidence against the traditional models. However I recently found an interview that Deborah Hartmann at InfoQ did with the Standish Groups founder and chairman Jim Johnson. In the interview Deborah asks some really interesting questions and Jim’s answers seems straightforward and honest. The relatively fresh statistics presented is interesting, but most interesting of all is the list of success factors, where it is obvious that the Agile values and methods addresses most of the top 10 with concrete techniques.

Coder’s Dojo Sweden is open!

Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.

It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.

My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.

I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.

And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.