& Continuous Learning

I facilitated my own rendition of the #NoEstimates Puzzle Experiment for the September 2013 Agile Iowa user group meeting. This experiment was created by Chris Chapman to generate critical thinking and conversation concerning whether estimates are necessary to produce quality software. The meeting had a great turnout, with around 40 people attending during a Midwest thunderstorm that left over 20,000 people without power.

Setup

The experiment calls for two teams to build the same puzzle, with one team using a lean approach and the other team using scrum. For the puzzle I chose a Ravensburger 500 large piece format No. 149483. I encouraged the attendees to self-organize into two teams of six members. Both teams were made up of novice and experienced agilists.While the teams worked on the puzzles the remaining attendees mingled and observed the teams' progress.I kept track of the time and coached both teams as necessary.

Puzzle Experiment

Running the experiment took about an hour. The first 20-minute sprint started with each team sorting the puzzle pieces and building the majority of the border. During the second 20-minute sprint, there was a significant divergence in what the teams did. The Scrum team's product owner decided to work from each side toward the middle of the puzzle, while the lean team's product owner decided to build the mast of the main sailboat. Regardless of their approach, neither team completed the puzzle by the end of the experiment.

Post-Experiment Discussion

True to this experiment's goal, it spawned another hour of great discussion. Everyone was very engaged and I had to interrupt the discussion to let everyone know we were approaching the end of the meeting.The discussion topics included estimating, delivering value, accountability, and return on investment. I look forward to discussing these topics at future Agile Iowa meetings.

Observations

There were a couple of things that I might change the next time I run this experiment. One change was recommended by an attendee: to have the product owners ask the attendees what would be valuable to deliver. Another change would be to reduce the length of the sprints to 15 minutes or even 10 minutes. Shorter sprints would help large groups like ours. In hindsight, having non-participating observers watch for 40 minutes was too long.

Conclusion

We had a great turnout, considering the weather, and an excellent discussion. This puzzle experiment served its purpose of generating critical thinking and conversation concerning whether estimates are necessary to produce quality software. I would highly recommend this exercise to any group interested in discussing #noestimates.