In The Art of Business Value, Mark Schwartz challenges the age-old belief that the customer is always right. By focusing only on what users consider to be valuable, Agile teams could be rehashing old ways of doing things rather than working towards the transformation that the business truly values.
We get into patterns in Agile and can do strange robotic things. We know splitting stories into smaller and smaller chunks reduces risk, so we meet to groom and split, and split, and then meet again a few days later again to split some more, all in an attempt to try to create small packages of commoditized business value. Schwartz compares this to a calculus problem:
…Some organizations seem to be deploying change sets so small that they’re just fractions of features. It starts to feel like a calculus problem — what is the limit of risk as requirements batch sizes approach zero?
Schwartz challenges us to focus on the factory instead; to build a pipeline. Instead of focusing on delivering stories points — those vague abstracted units of work we convince ourselves represent business value because the Product Owner told us so — we should put our efforts into setting up the value delivery factory and use it to ship outcomes.
…if the success of an Agile project is to be determined by the value it delivers, then we have to think of that value in terms of outcomes, not completed stories, and measure it as such.
To fully embrace DevOps, we need to focus on what goes into the pipeline and what emerges out the other end. We need to reduce waste in the pipeline, so that it delivers in a predictability fast cycle time.
DevOps is form without content until we address the question of what goes into the pipeline and what happens when product emerges at the other end.
Schwartz goes on to suggest that releasing code is not the same thing as delivering business value and to truly deliver business value we need to understand what the business values and ensure the outcomes we’ve delivered align with those values.
DevOps, in a sense, is about setting up a value delivery factory — a streamlined, waste-free pipeline through which value can be delivered to the business with a predictably fast cycle time.
In our mad race to deliver story points and code, we forget to stop long enough to consider what the business actually values, and hint: it’s probably not story points or code. A company has a right to declare what it considers business value, and it doesn’t need to be financial in nature.
Schwartz isn’t a fan of the Product Owner (in Scrum) being the only person who can interpret what business value is for the organization. Rather, he feels it’s important that Agile teams take ownership over the discovery and interpretation of business value; that this responsibility should live with the team itself.
Teams might consider setting up reporting mechanisms to measure business results before they begin writing code, in the same vein as Test-Driven Development. This re-focus around business value permits the team to accept responsibility not just to discover and deliver the business value, but also to track it, interpret it, and react.
The views and opinions expressed are those of the author and do not necessarily reflect the official policy or the position of any entity.
