Iterating To Acquire Knowledge, Not Just 'Business Value'

Posted by Mike Bria on Oct 22, 2008 11:06 AM

Community

Agile

Topics

Agile Techniques ,

Delivering Value

At first glance, most agile methodologies define simply that stories be developed in order by business value. In many cases though, it is prudent to blend increasing business value with deliberate steps in "knowledge acquisition". Alistair Cockburn describes how to do this blending effectively, and how to leverage it to deliver the right feature set at the right time.

Cockburn introduces the topic by asserting the basic idea that the key output of design activity is knowledge creation:

In any team design activity, we are working with a problem we don’t yet understand, creating a solution we don’t yet understand, and expressing our ideas in languages and technologies we generally don’t yet understand – and all of them keep changing out from under us.

As we work, we learn more about the problem, about the technologies, about the proposed solution...

He goes on to present how the extreme case of a big-bang integration approach characteristic in a Waterfall world prevents any real knowledge acquisition before the very end of the project, inevitably leading to the "big surprise" that there is no time to react to. In lean terms, the accumulation of unvalidated design decisions constitute a growing "inventory". As Cockburn puts it, "in terms of risk reduction, we see that this scenario leaves a big risk until the end, produces knowledge late in the story, and is generally neither fun to live through nor a pretty sight."

Cockburn then describes an agile approach, one in which the team focuses early iterations on the "growth of knowledge", ie. learning:

Teams that integrate early and often take that big surprise and split it over many sessions. By doing this, they discover their mistakes earlier, that is they “learn” what those mistake were, and make it so that later integrations are less likely to fail badly, i.e., the “learning” factor becomes smaller over time. This is a good thing.

To facilitate this, Cockburn advises to ask "What worries/scares us?" and to focus early development efforts on reducing these fears, rather than dogmatically following the "highest business first" mantra. He notes that work during this time may not appear to be occurring in any meaningful sequence, "except the sequence that increases knowledge the fastest for the money spent, the sequence that reduces the project risk the most".

The article's bottom line, work in business value order once the big risks are mitigated:

Once the knowledge curve starts to flatten, then is a good time to develop the features in a business-value-first sequence. This matches the normal agile recommendation. Notice that, in principle, business value was always being developed during the knowledge-acquisition-intensive period, so it’s not as though you weren’t gaining business value, it’s just that gaining business value wasn’t the dominant driver.

Also of note, Alistair takes a moment to explicitly warn readers not to confuse the message of "knowledge aquisition" with "BDUF (Big Design Up Front)".

Cockburn concludes the discussion by explaining how combining this approach with an effective application of Feature thinning can enable teams to effectively "trim the tail", ultimately enabling effective agility:

once the knowledge- and business-value curves flatten out, the sponsor is in a position to deliver on-time (or early! to match a competitor’s move) with a thinned feature set, or to deliver later with the fuller feature set. The choice is where it belongs, in the sponsors hands.

As always, please be sure to use this news only as a summarized teaser. Do visit Alistair's article for the complete story, including some very helpful graphics to back these concepts and a description of Alistair's experience with this approach on two distinct actual projects.

Also, what do you think? Does this fit with your experiences? Could this have helped on some of your past projects? On your current one, or your next?  If so, how? If not, why? Maybe you think this "isn't agile"? Discuss your thoughts here.

• Older >