In the Extreme Programming mailing list, Dale Emery points to a simple and interesting game that emerged during the agile development conference. You can read details on The Blindfold Game in Brian Maricks’ blog. I like this game, maybe I’ll try it out at our XP users’ group meeting
Brian relates problems the players are having with steering a car, roleplayed by another person, with voice commands every twenty, five or one seconds to iteration length in an agile software development process. He notes, that many people have problems with one-week iterations (which are then similar to one-second feedback in the game), although they can often be taught to deal with them.
I’ve experienced a situation where a one week iteration was too long. At the end of a four week project, the customers had difficulty of thinking of enough new functionality for a full week, yet there was still work to be done. On the other hand, I also experienced one week iterations being to short, especially in the case a large refactoring has to be made to existing software.
Over the years, I’ve worked on projects with one week, two week, three week iterations, and before that in projects without iterations… Iterations are necessary in my book, to get feedback from the project and steer it, so it stays on course (or changes course if the context requires that). The relation to me between the game and the real-world is, that in real-world projects I find it worthwile to look at the effect the iteration length is having on the project (as Brian does in his reflections on the effect the number of seconds has on the time it takes to get the role-played car to the target). If you think iterations are too long or too short, change the iteration length for a few iterations, and evaluate (e.g. with an iteration retrospective) what difference it makes to your project. After the experiment it will be easy to decide if you want to keep the new length or not.