Working Software or Customer Value

A few years back when I was still doing hands-on project management work… I used to teach internal classes on iterative and incremental product development. Officially… we were teaching a very light-weight instantiation of the Rational Unified Process. Unofficially… we were teaching agile values and principles within more of an Agile Unified Process framework.

The audience was always full of hard core waterfall folks… developers… testers… business analysts… project managers… one of the main things we’d try to talk about was the idea of frequent delivery of working software. I’d explain that charters and market requirements documents and detailed design specifications were not what provided value to our customers… all our customers really cared about was the working software.

Inevitably… someone from the audience would raise their hand and ask the question: Are you telling me that these detailed requirements documents… the ones I spend months and months creating… are not valuable? Are you telling me that the only one delivering value on the team were the developers?

I’d have to carefully explain that while those things were valuable… to the extent that they enabled communication… to the extent that they helped people understand… they were not the value that our customer’s expected. If we had to kill the project 3 months in… would you rather have a detailed specification or an increment of potentially shippable code?

The potentially shippable code is always going to win.

The same idea holds for organizations with multi-part… multi-step value streams… organizations where it takes the activities of several teams working in coordination to deliver value back to the business. Even the smallest organizations… organizations with the simplest value streams… are going to need sales and marketing and support to deliver a viable product to market. Software doesn’t usually sell all by itself.

More complex businesses… businesses with more complex value streams… are going to need not only sales and marketing and support… but also the ability to integrate the outcomes of many feature teams and component teams to get a product into the hands of their end-users. Does it do us any good to invest in one part of the value stream if the other parts are falling behind? Value is only created when all the parts are integrated into one cohesive whole.

So… when one part of the delivery organization gets too far ahead of the other parts of the delivery organization…. be it by writing all the requirements up front… or by building out one part of the component architecture too far ahead of all the others… it is easy to start confusing valuable activities with real value delivered into the product. It is especially easy when all that activity results in great team velocity and real working… albeit incomplete… software.