Planning by value

Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort.

An article by Alistair Cockburn includes a story that illustrates the point:

A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.

There are several ways our student could attack his problem. The most obvious and most analogous to how many projects are run would be to read all ten stories, read all the questions and then answer them. With this approach he can get into “the zone” of reading stories and perhaps complete his task as quickly as possible. This plan is based around tasks to be executed, and tracks progress by effort expended.

But now comes a few questions: When he’s read all the stories but answered no questions, how much progress has he made? 20%? 70%? How would he know? And if he runs out of time, how will his final grade look?

Working incrementally?
Working incrementally?

A more agile approach would instead be one of incremental delivery: Read one story, answer the questions. When he’s read one story, he know he’s exactly 10% along toward his goal. His speed might increase or decrease over time, so he doesn’t know how much of the effort he’s expended. But he knows how much value he has delivered. And if he completes only four stories, he will at least get scored on the 40% that he completed.

But, inspired by this thinking, the student comes up with an even more aggressive idea: Start with the questions. Read a question and then read enough of the story to answer it. (Or, more realistically: Read all the questions for a story before reading the story. But that’s not as good of an analogy) The approach is analogous to test-driven development. We start with the desired outcome and do exactly what is needed to accomplish it.

An objection to this approach would be that it seems like cheating. But is it? What do you think, gentle reader?

Can this approach be applied to your current project? Even though I didn’t think so at first, it certainly can to mine.

The full article is worth the read. It tries to cover a lot of ground and is a challenging read at times, but it contains many further insights.

Copyright © 2009 Johannes Brodwall. All Rights Reserved.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in English, Extreme Programming, Java, Software Development. Bookmark the permalink.