Iterating To Acquire Knowledge, Not Just 'Business Value'

| by Mike Bria Follow 0 Followers on Oct 22, 2008. Estimated reading time: 3 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you