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  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 . 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.
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.
 The idea behind this is neither new nor mine, see for example “Effektstyrning av IT” (“Effect Managing IT”) by Ingrid Ottersten and Mijo Balic.