What is Value?
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.
Background
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.
Incremental Delivery
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 the 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 given 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’s not of immediate value, then it has no utility, and in fact it’s a negative effort – in 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 moment’s 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 – all 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”.
Summary
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).
Any other approach is simply an invitation to waste your time – and the customer’s money.
– Bob
Further Reading
The Goal ~ Eliyahu M Goldratt
Necessary But Not Sufficient ~ Eliyahu M Goldratt
It’s Not Luck ~ Eliyahu M Goldratt
Systems Thinking and IT ~ John Seddon (pdf)
Throughput Accounting ~ Thomas Corbett
Think Different 
Goldratt material isn’t bad. But this single constraint thing, albeit useful, looks like too much like a golden hammer to me.
(I have Goldratt books and more over here).
Delivering value these days is first and foremost: get the basics right. There is much mess on how specs are done, on how deliveries are handled, and how customers are “milked” instead of catered for that doing the basic job just right may open the doors to heaven and business nirvana.
Hi Philippe,
Thanks for joining the conversation. Your proposed ‘basics’ sounds more like a recipe for doing the wrong things righter, to me.
– Bob
I like the line of reasoning… I’ve worked for some organizations that provide multiple value streams, not a single one. From what I remember of that organization, each value stream may vary in importance over time, but all were assigned by policy, law, and organizationally (they were a part of a much larger organization, the US Navy) to them. Each one of these streams could have a single constraint to be answered.
I’d be interested in your thoughts on this…
Hi Paul,
Thanks for joining the conversation. Goldratt admits to the possibility that there may, very occasionally, be more that one concurrent constraint – in complicated networks of systems. I’ve never seen it. Typical organisations seem unlikely to cope with that kind of complicatedness.
I find it best to proceed on the working assumption that there is only one constraint – although it’s never quite where folks expect it to be.
– Bob
In thinking more on the Navy organization I had in mind, there probably is only one true value stream, just segmented poorly into different ones. Focusing on those constraints would most likely lead to some form of local optimization of effectiveness as opposed to an organizationally wide one.
My feelings are that the missing part in Agile is Customer Development, so Agile is building in the right way something that nobody wants, as well described by Steve Blank in his books and divulged by Eric Ries (http://www.startuplessonslearned.com/2008/11/what-is-customer-development.html).
Does this fit in your ‘teach the customer’? Market fit, business models are definitely contraints imo.
Hi Antonio,
Thanks for joining the conversation. I agree that Agile tends to assume that the Product Owner is competent and has a grip on what things the team should build and the priority order in which the team should build them. This post does not assume that there will necessarily be a Product Owner, but whoever is making those decisions, they could benefit from understand the idea of addressing the customer’s current constraint. Of course, as the post points out, it can be difficult to get close enough to the customer to understand what their current constrain it, and when it shifts.
– Bob
Isn’t is better to prioritize according to “value to producer”? In other words, what is the value of my work to *my* business? Isn’t “value to my customer” just a proxy for what I’m really trying to accomplish? Yes, I still must initimately understand what my customers truly need (perhaps better than they do!), if I really want to keep getting paid. But “value to producer” better normalizes all of the investments I need to make that are only indirectly related to customer needs. I need to consider my own constraints!
Hi Kerry,
Thanks for joining the conversation. Yes, I find it useful to distinguish between the various “customers” that we are intending to serve. THe more common term for this is “stakeholders” and I use the term “covalence” to refer to the idea of balancing the needs / demands of all stakeholders, for an optimum outcome.
I would not however, focus primarily or solely on the internal customer (your term: producer), as this only increases the likelihood of making the wrong products, providing the wrong services, and generally doing more wrong things.
– Bob
I’ve been struggling with mapping the concept of throughput-dollar-days to the sphere of control I have in my organization. We provide a data warehouse to several other groups, and the projects we take on are intended to increase their ability to study our data. These groups sometimes discover things that enables our company as a whole to make more money.
It is likely that every single project on our backlog will increase inventory or expense, since I am nearly certain that our stakeholders are not using the Thinking Processes to determine what we should do.
Assuming that a data warehouse (and the tools around it) can produce insights that make the company money, how might we identify our customers’ constraints so that we can use the five focusing steps?
Good point, Bob.
Whole-heartedly agree.
Most of us don’t dare to pull that far, we are too confident explaining that “everything is prio one” doesn’t work.
Like the connection between the goal (focus on the one constraint) and prioritisation. Will use that in the future! Thanks:-)
Keep up your inspirational challenges!
Take care
Olaf
Understanding system constraints is key but many don’t even know where to begin and so they look for software solutions. That said, if a software solution is needed, do you think you can still look at constraints within the solution to determine value and hence priority?
Hi Ebenezer,
Thanks for joining the conversation. Yes, I do so think. In fact, FlowChain is predicated, in part, on just this belief.
– Bob
Excellent post, nowhere near enough discussion going on about the “why”. Far too much productization/frequent delivery of mass quantities of stuff without a focus on whether said stuff makes customers’ lives better or worse.
Sadly, in my past experience when I bring up the conversation about defining value to our users I am told KPI is the way. When I delve further into them I discover the KPIs are stacked to confirm that the work we’re doing is great.
Unfortunately those KPI are rarely tied to what actual users want. They serve to reinforce existing cultural dysfunction.
Keep up the great posts, this is important work you’re doing, red pill distribution. 😉
Hi Adam,
Thanks for your contribution to this conversation. And for your continued support.
– Bob
Pingback: Five Blogs – 7 May 2012 « 5blogs
Pingback: The Value Impact | AvailAgility
Pingback: What is Value? | lean IT novice's Blog
Pingback: What Value Do People Have In The Digital Business? | Digital Business Transformation