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?
[caption id="" align=“alignright” width=“180” caption=“Working incrementally?”]
[/caption]
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.
Comments:
[Einar] - Mar 29, 2009
Cheating isn’t a problem. Knowing what the questions are is.
jhannes - Apr 3, 2009
Are you sure? I think in real life we often err on the side of more complex solution than what’s really needed.
[Christian Rørdam] - Apr 3, 2009
Regarding the German language home work: If the questions really cover all you need to know about that chapter, then I don’t see any problems with this approach. I real life, however, the end-of-the-chapter questions only cover some of it.
Torbjørn Marø - May 23, 2009
TDD seems like cheating sometimes :)
For your Norwegian readers:I just wrote an article about value vs. effort when prioritizing in agile projects. Would love to get your feedback on it.
http://blog.kjempekjekt.com/2009/05/20/verdi-vs…