Allan Kelly

About Allan Kelly

Allan Kelly has held just about every job in IT, these days he provides training and consulting in development management, processes & products, especially around Agile. He specializes in working with software product companies, aligning company strategy with products and processes. More about Allan at http://www.softwarestrategy.co.uk/allankelly

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.

ThreeDemandCurves-2013-12-21-12-39

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.)
 

Reference: The good Agile demand curve from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


three + = 8



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close