Only Usage Can Create Value

There is something quite myopic in the way agile software development views the end result; the delivery of software. The fulfilment of an order (stories or whatever) is always considered to be when the software is deployed on a production server. I agree, this is important, but it’s not enough. This is a serious mistake, because that’s not where value materialises.

Lean/Agile Methods Fall Short

Let’s look at how a few agile methodologies view deliveries and value. Scrum, currently the most popular agile process, talks about each sprint (iteration) ending with a “potentially shippable product increment”. In other words, it is not even delivered. Original Scrum even recommended a short, specific “release sprint” to actually get the release out. XP, perhaps the most detailed and technically accomplished agile method, is slightly better. In the 1st edition of the book “Extreme Programming Explained”, Kent Beck talked about releasing after a few 1-week iterations. In the 2nd edition this was changed to the practice of “Daily Deployment”. Very ahead of its time, but still nothing about what happens after that. Even Mary & Tom Poppendieck in their landmark books on Lean Software Development [1] only talk about getting to production. I find it amazing that even the foremost, world-renowned Lean experts, in their book about how to quickly realise value from software development, still don’t get it right!

Gotta Get to Using

Isn’t the notion of value appearing kind of strange, even magical? I mean, why would software suddenly be valuable just because it landed on some server? Yes, it is accessible to users but so what? Does anybody believe business value suddenly appears, by a swift swoop of the wand, after you put a new and shiny version of your application in production? I believe there is definitely something missing in this Harry Pottery picture.

What’s missing is “just” that little thing of getting our users to find our cool new features, understand what they’re for, know how to use them, and understand how they can use them to achieve their goals (if that is at all possible). Furthermore, these goals would have to be in line with the company’s goals, helping serve customers better or more cost-effective. Then, maybe, we could start attracting more customers or free people to do innovative work. Hm, that’s quite a mouthful. Maybe that isn’t such a small task after all…? Come to think of it, isn’t this just a great example of waterfall thinking? We just throw something over the wall and then… it’s somebody else’s problem.

What I’m getting at is this: Value is not created until a feature is used [2]. It’s the usage to achieve the right business goal in an efficient manner that is important. That’s were we bring home the dough. If you think about it, it is readily apparent. It the result that matters most.

Targeting Effects

If we understand this and start thinking that way a lot of things fall into place. Most importantly, we would need to change how we view the development cycle and how we steer our actions towards creating value. Perhaps we could start by setting up some goals for the effects the system should have on our organisation? We could identify a few target groups and, in turn, study how their goals relate to higher goals. From there we could suggest some usage scenarios that would enable users to reach these goals. And lo and behold, we would have a draft initial backlog, a really relevant one as well. Then, of course, we would try and steer the whole development effort towards these effect goals. Or update the goals, when we find better ones.

This means we are not done when we dropped some release into production. We still have a distance to achieve value. And that distance is keeping us from being truly effective today.


[1] “Lean Software Development: An Agile Toolkit” and “Implementing Lean Software Developmen: From Concept to Cash”

[2] The idea behind this is neither new nor mine, see for example “Effektstyrning av IT” (“Effect Managing IT”) by Ingrid Ottersten and Mijo Balic.

7 thoughts on “Only Usage Can Create Value

  1. Yes, Joakim! This why the whole organization has to adopt Agile not only the development team. Business strategists and tacticians must engage with the SW development team by defining desired effects (what some of us call Management Tests), then take part in ensuring effects are achieved. No throwing requirements over the wall to dev and no throwing production ready software over the wall. Successful result includes involvement of the whole system beyond developers and PO’s/onsite customers.

    • Thanks for your insights, Diana! I agree that it’s much more than development, which is not mirrored in the current literature. However, I still don’t see any users, or people talking to users, in your description, which is also what I’m getting at.

    • Ah, thanks! I didn’t know. I updated the post. Please note I’m not endorsing their method, that is just one way of doing it. Most people in strategic usability do the same things, perhaps using other words and variations.

  2. Pingback: What’s Missing from Agile? « Den bloggande terriern

  3. Pingback: The Design Flaw of Agile Methods « Den bloggande terriern

Comments are closed.