What is Value?
A simple enough question. But one that seems to have occupied many folks for countless hours, on Twitter, in blog posts and other media, and in person, over the past couple of years.
Some years ago now, my late esteemed colleague Grant Rule, and I were both working on our own respective models for how software development organisations could work more effectively. His approach, suited in the main to Adhoc and Analytic-minded organisations, he referred-to as “SlamIT”. Mine, as you may know by now, focuses on Synergistic-minded organisations, and goes by the name of “FlowChain”.
Both of us saw the uptick in interest amongst the software development community for a workable means to prioritise e.g. backlog items. If one is delivering software in one “big-bang” – often referred-to as the “Waterfall” approach – then the priorities of the various elements, features, stories, use-cases within that one indivisible set of deliverables is essentially moot. As many people have asserted over the years, with Waterfall a.k.a. “Batch and Queue”, “EVERYTHING is a priority!”.
Grant and I felt that by working together, using his skills and knowledge of metrics and measurement, and my experience in the business of Agile development, we could come up with a teachable method of assessing business value, useful in ranking (prioritising) the incremental delivery of software solutions. And applicable for both SlamIT and FlowChain adoptions/transitions alike.
Grant passed away suddenly and unexpectedly October, 2011. Since then I have been wondering how to tie up the loose ends of our collaboration on this “teachable method of assessing business value”, and make it useful to a wider community. I have not actually tied up the loose ends, but I publish here the core ideas underpinning our work, in the hope that others might find it useful, wish to dig deeper, or even collaborate to add some polish and further depth.
Central to the Agile proposition is the notion of delivery of software – into production and earning its keep - early and often. Implicit in this notion is the need to choose features, stories or such elements for delivery according to some kind of priority. We can imagine many different prioritisation schemes, but one that seems to make sense is prioritisating according to the goal(s) of the people who will be paying for, and using, the software. Let’s call them the “immediate customers”.
Note: The remainder of this post assumes that money (e.g. “throughput-dollar-days”) is the unit of measure for the customer’s goal(s). This may not be the case for some kinds of organisation, such as various not-for-profits, charities, etc.
Customers Do Not Normally Know What is Valuable to Them
Goldratt has show us, through his work with the Theory of Constraints, that people are fairly poor at understanding their collective (organisational) goals, and even worse at understanding what things (bottlenecks, constraints) are preventing their organisation from realising more of these goal(s). Theory of Constraints furnishes us with a number of “Thinking Tools” by which to identify the goals, and then identify and deal with the constraint(s).
Aside: Even though customers can be very articulate, voluble and even convincing about what they want, what they want rarely coincides with what they need to address their current (organisation-wide) constraint. And I do appreciate that few indeed are suppliers who have a sufficiently trusted status to dissuade a customer from the (widespread) practise of commissioning work of no actual, practical value to them (see more on this, below).
A Teachable Method of Assessing Value
Goldratt asserts that there is only ever one constraint in operation, in any given organisation, at any one point in time. Extending this, we assert that there is only one thing that is of immediate value to any given organisation (customer) at any one point in time.
If we undertake to deliver some feature or story which does not directly address this active constraint, then we are failing to deliver anything of (immediate) value. If it is not of immediate value, then it has no utility, and in fact is a negative effort is that it is simply adding to inventory (assuming it has some redeemable value in the future) or becomes a write-off as an Operating Expense (assuming it turns out to have no redeemable value).
Thus, the most valuable thing to deliver to a customer is only, ever, something that addresses their current constraint. Actually, not only the most valuable thing to deliver, but the only valuable thing we can deliver.
It may not be immediately obvious, but a moments thought along this line of reasoning will also show that many constraints in an organisation will never be addressed or addressable by software. In which case it’s better to suspend work on – and delivery of – stories until such time as the current constraint shifts and the software does address the (new) current constraint.
I believe this is in line with what John Seddon refers to when he says “Agile is just doing the wrong things, righter”.
In summary, if you are a software supplier, software house, or in-house software development shop, unless and until you understand your customer’s organisation well enough to know where its current constraint lies, you will never be in a position to deliver real value, except by sheer chance.
And given that few suppliers will ever be in a position to understand the internal working of another organisation, the prospect of finding their (shifting) constraint hinges on either:
- Becoming a “Jonah” (see “The Goal”) and accepting the limitations of that role- including the need to teach the customer how to identify their own constraints (and appreciate when a constraint can be addresses by a software solution, and when it cannot), – hence “A Teachable Method of Assessing Business Value”) or
- Becoming such an intimate partner with the customer that you can identify the customer’s constraint for them (and continue doing so, as their constraint moves and shifts).