I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.


Extreme Pictionary

It was Games Night at Agile Scotland last Monday, and I volunteered to help organise a game. Joining forces with Jeremy Nelson, we produced Extreme Pictionary that ended up being the focus of the evening. Extreme Pictionary was inspired by the XP Game, played by many of us during a joint Agile Scotland \ Exoftware event last year. An aspect of that game, that dissatisfied me was that the planning aspect was rewarded within the game: the team that amassed the most "business points" won; the planning side played little role in that, at least during that game. An aspect of "real projects" not reflected, was that accurate planning maximises the "business value" (ie money) delivered by the software. We sought to reward good planning by making the teams buy stories, phrases to be guessed, in advance of an iteration; each story cost £100, and was worth between £110 and £250. Although stories could be carried forward to the next iteration, every third iteration unused stories were forfeit. Teams needed to steer a course between running out of stories during an iteration and running up too much debt. Of course it didn't really work. We all had fun - the iterations were fast paced, exciting, and funny - but the Pictionary aspect had several problems:-
  • teams were split into artists and guessers; the nature of the game meant that the guessers played no part in the planning part.
  • the Pictionary format did not lend itself to estimation. It was reported to be next to impossible to say how many seconds it would take a particular phrase to be guessed.
There were some other lessons learned and suggestions made
  • the planning and estimating needs to be made a part of the game. Left to themselves people will side-step estimating individual stories.
  • separation of customer and developer roles is worthwhile, even if they are played by the same people at different times.
  • the "game retrospective" when we discussed the reasons the game did not work was itself valuable, giving focus to a discussion on Agile Software Development.
Personally I felt that the "buying stories" model worked reasonably well - teams lost points by both over-committing and under-committing. Unfortunately that aspect was over-shadowed by the shortcomings of the Pictionary format. I would like to try the same idea on a different game. Alan Francis suggested feeding it back into the XP Game.

Architects, architects, upfront design, and all that

From Christopher Alexander's pattern language website.
Normally what happens when you build a house, for example, is that an architect, tries more or less or understand what you want and makes a blueprint. But a blueprint and CAD designs are mostly guess work about what is going to be just right for the dimension of a room or the placement of a window. It's like tossing thirty coins all at once and hoping they all land on heads. Never works. A sequence is figuring out which decision has to come first and getting it right and then moving to a second decision. Like tossing one coin at a time, which is actually a much better, faster, and less expensive way to get to thirty coins all on heads. But if you work from a blueprint you are stuck with your guesses and the builders, who aren't the architect, just have to follow the blueprint, even when they know a much better solution. It's a silly way to do things.

subscribe here subscribe

About me

picture

Conference

Scotland on Rails Organiser

Previous blog posts

Blog archive

Other links: