A central theme in my business value presentations is the notion of ���measurable business value��� and that agile methods, such as Scrum and XP, don���t have a built-in mechanism designed to provide this. Essentially, agile methods alone aren���t enough to measure the value delivered by teams to their stakeholders.I learned this myself only after years of practicing agile, so I guess it makes sense that this wouldn���t be the first thing picked up by folks new to agile. But for those experienced practitioners in the field or those struggling to show the business value delivered by Scrum, this idea is likely something you���ve arrived at on your own.
But if not agile to measure business value, then what will work?
I���m working on my presentation now for Agile2008 and will be doing a mini-version locally in a few weeks, so I���m trying to organize my thoughts around this topic. I���ve been looking over my slides from Smart Decisions, which has must of the basis for my ideas on this subject. Doing this has helped me come away with the reasons that I think agile alone isn���t enough, but that agile combined with other methods works quite well. I���m going to start the list here and elaborate in future posts.
But first, when I say agile, I mean Scrum and also typically XP, although they differ in slight ways. These are the two methods I���ve implemented, thus my basis. I���m reasonable confident agile also applies to the other methods like FDD or Crystal.
The most important agile metric, Velocity (features or feature points delivered in a fixed-length iteration), is a poor measures of business value delivered. It measures team capacity to do work and is not aligned around business value. While it can tell you how fast or slow your team is creating new features, it���s not a measure of business value.
Product, Release and Sprint backlogs provide nice prioritized to-do lists, but they are not good measure of business value either (potential value or delivered value). The primary reason for this is that their elementary component, a user story, is a functional requirement. Functional requirements are poor measures of business value delivered because while they say what a system can do, they don���t speak to the value delivered to the top stakeholders by the system in terms that matter to them (money and time). Value is a measure of quality and performance, not functionality.
The ���user story��� centric approach to requirements also doesn���t provide a way to measure business value, although one could argue that for large stories or epics, one could calculate the business value at this level. But this practice is not widely taught to ScrumMasters, published or put into use in my experience. But even if you were to calculate business value at the user story level, it would be way to granular or systems of any significant size and quickly could become cost prohibitive to widely adopt.
This is just a start, I���m going to elaborate more in my presentation, but this gives you an idea of what I mean when I say that agile isn���t enough!.
To be fair, I don���t contend that Scrum or XP do anything wrong in their approach. In fact, I���m a ScrumMaster and teach Scrum these days to many clients (I used to teach and practice XP). Rather, I contend that you should augment agile methods to handle the issues mentioned above, not replace them.
It turns out that Evo is a perfect compliment for agile to help cover these shortcomings. In fact, Evo and Scrum share many of the same principles, but work at slightly different levels and with different purposes. While there is some overlap in their thinking, if you take the best of both methods, together you can have an approach that can define and deliver measurable business value using agile.
This is a start, more to come....
