The good Agile demand curve

I’ve been slow with this entry on Agile and the Demand Curve, apologies. Part of the reason for the delay is software demand is not simple.

In my last entry on software economics I discussed why the Software Demand curve for custom software is both high (i.e. people want a lot of software) and inelastic (i.e. increases in costs don’t reduce demand by much.) This time I want to look at how applying Agile changes the demand curve.

In order to explain what happens to the demand for software in an Agile environment we need to consider different possibilities. So lets start with a good news story - the bad new story and analysis will come in later blog posts.

This story is about how, using Agile software development, a team reduced the demand for software and shipped a product sooner. This is the story most Agile advocates will associate with and happily promote. This is the way Agile is supposed to work....

There was once a team who adopted Agile software development. At first they were able to demo their enhanced software to others in the business on a more regular schedule. They made a big thing about this and invited others to come and look. This generated feedback on the thing they were creating: some good, some not so good, some requests for more and some cancellations of things which had been asked for.

A little while later they stated making more regular releases. And because the software was “ready to release” more often the business could decide: “Do we want it now - with any pain that might bring? Or do we want to wait a little longer for more?” (A bird in the hand is worth two in the bush as they say.)

Simultaneously the team were adopting technical practices which improved the quality of their code - they also had the side effect of reducing the amount of code. Not only did this make the team more productive because they had less code to maintain and bugs to fix but it also meant the business had fewer reasons to complain about bugs.

(In my experience, for some teams when the conversations about “Have you fixed it yet?” and “Can we release it yet?” start to disappear it turns out business don’t know what to ask for. They’ve forgotten or never knew what they really wanted.)

The team also adopted User Stories at some point. As they got better at this technique they were challenged to think about “Who actually wants this story?”. With a little time stories advanced from “As a User” to something more specific.

And one day the “Product Owner” realised: they were not building one product but two.

The Product Backlog of work to do would be better throughout of as two backlogs for two products, each with its own user/customer base. User Stories had helped him see this.

When he restructured the backlog he found he had three piles. Product A, Product B and not justified. A chunk of the backlog, maybe as much as a third, didn’t fit in either product. They were nice ideas, things people had asked for, but when you came to analyse them they didn’t belong anywhere and justification was weak.

This diagram shows the Demand Curve graphically. The team start with demand D, Agile supply is Sa. After the restructuring to separate products appear with their own demand curves Da and Db. Each on of these can be reasoned about independently.

At any price point the combined demand of A plus B is less than D (the original total) because some work has gone away. Note: I have not suggested any changes to the slope of the curves, it is possible that different products will have different elastics but that is another discussion.

While the team had been battling lots of bugs and their output was a black hole to the rest of the organization, and while they thought they were building one big product this insight had been hidden from them.

That is the way Agile is supposed to work on the demand side. By being clear, by being delivery focused, by feeding back to users and customers people get what they want.

But, do you know what? All the members of this team are still employed and still work on software. In fact I think the team might have grown a bit. There is still work to do, there is still demand.

Agile reduced the demand in one part but there is still plenty that company wants to do, and much of that means software. Getting demand reduced in one place just leaves the team more time to do other work, other demand.

(OK, if I’m being honest while I have one team in mind while I was retelling this story I’ve simplified it (knocked a few rough edges off) and composited it a bit to include other examples. I don’t think that invalidates the story as this is how it is supposed to be.)