Software Engineering, Project Management, and Effectiveness
Continuous Value Delivery helps businesses realize the benefits from their technology investments in a continuous fashion.
Businesses these days expect at least quarterly results from their technology investments. The beauty is, with Continuous Value Delivery they can get it, too.
Continuous Value Delivery is a practice that makes delivering user value and business value a rapid, reliable, and repeatable process. It’s a natural evolution from Continuous Integration and Continuous Delivery. Continuous Value Delivery simply adds a focus on Value Realization, which addresses planning for value, driving adoption, and measuring results.
But let’s take a look at the evolution of software practices that have made it possible to provide Continuous Value Delivery in our Cloud-first, mobile-first world.
Long before there was Continuous Value Delivery, there was Continuous Integration …
Continuous Integration is a software development practice where team members integrate their work frequently. The goal of Continuous Integration is to reduce and prevent integration problems. In Continuous Integration, each integration is verified against tests.
Then, along came, Continuous Delivery …
Continuous Delivery extended the idea of Continuous Integration to automate and improve the process of software delivery. With Continuous Delivery, software checked in on the mainline is always ready for release. When you combine automated testing, Continuous Integration, and Continuous Delivery, it's possible to push out updates, fixes, and new releases to customers with lower risk and minimal manual overhead.
Continuous Delivery changes the model from a big bang approach, where software is shipped at the end of a long project cycle, to where software can be iteratively and incrementally shipped along the way.
This set the stage for Continuous Value Delivery …
Continuous Value Delivery puts a focus on Value Realization as a first-class citizen.
To be able to ship value on a continuous basis, you need to have a simple way to have a simple mechanism for units of value. Scenarios and stories are an effective way to chunk and carve up value into useful increments. Scenario and stories also help with driving adoption.
For Continuous Value Delivery, you also need a way to "pull" value, as well as "push" value. Kanbans provide an easy way to visualize the flow of value, and support a “pull” mechanism and reinforce “the voice of the customer.” User stories provide an easy way to create a backlog or catalog of potential value, that you can “push” based on priorities and user demand.
Businesses that are making the most of their technology investments are linking scenarios, backlogs, and Kanbans to their value chains and their value streams.
If you want to drive continuous value to the business, then you need to plan for it. As part of value planning, you need to identify key stakeholders in the business. With the stakeholders you need to identify the business benefits that they care about, along with the KPIs and value measures that they care about.
At this stage, you also want to identify who in the business will be responsible for collecting the data and reporting the value.
Adoption is the key component of Continuous Value Delivery. After all, if you release new features, but nobody uses them, then the users won't get the new benefits. In order to realize the value, users need to use the new features and actually change their behaviors.
So while deployment was the old bottleneck, adoption is the new bottleneck.
Users and the business can only absorb so much value at once. In order to flow more value, you need to reduce friction around adoption, and drive consumption of technology. You can do this through effective adoption planning, user readiness, communication plans, and measurement.
To close the loop, you want the business to acknowledge the delivery of value. That’s where measurement and reporting come in.
From a measurement standpoint, you can use adoption and usage metrics to better understand what's being used and how much. But that’s only part of the story.
To connect the dots back to the business impact, you need to measure changes in behavior, such as what people have stopped doing, started doing, and continue doing. This will be an indicator of benefits being realized.
Ultimately, to show the most value to the business, you need to move the benefits up the stack. At the lowest level, you can observe the benefits, by simply observing the changes in behavior. If you can observe the benefits, then you should be able to measure the benefits. And if you can measure the benefits, then you should be able to quantify the benefits. And if you can quantify the benefits, then you should be able to associate some sort of financial amount that shows how things are being done better, faster, or cheaper.
The value reporting exercise should help inform and adjust any value planning efforts. For example, if adoption is proving to be the bottleneck, now you can drill into where exactly the bottleneck is occurring and you can refocus efforts more effectively.
In essence, your value realization loop is really a cycle of plan, do, check, act, where value is made explicit, and it is regarded as a first-class citizen throughout the process of Continuous Value Delivery.
That’s a way better approach than building solutions and hoping that value will come or that you’ll stumble your way into business impact.
As history shows, too many projects try to luck their way into value, and it’s far better to design for it.
A Sprint is simply a unit of development in Scrum. The idea is to provide a working increment of the solution at the end of the Sprint, that is potentially shippable.
It’s a “timeboxed” effort. This helps reduce risk as well as support a loop of continuous learning. For example, a team might work in 1 week, 2 week or 1 month sprints. At the end of the Sprint, you can review the progress, and make any necessary adjustments to improve for the next Sprint.
In the business arena, we can think in terms of Value Sprints, where we don’t want to stop at just shipping a chunk of value.
Just shipping or deploying software and solutions does not lead to adoption.
And that’s how software and IT projects fall down.
With a Value Sprint, we want to do a add a few specific things to the mix to ensure appropriate Value Realization and true benefits delivery. Specifically, we want to integrate Value Planning right up front, and as part of each Sprint. Most importantly, we want to plan and drive adoption, as part of the Value Sprint.
If we can accelerate adoption, then we can accelerate time to value.
And, of course, we want to report on the value as part of the Value Sprint.
In practice, our field tells us that Value Sprints of 6-8 weeks tend to work well with the business. Obviously, the right answer depends on your context, but it helps to know what others have been doing. The length of the loop depends on the business cadence, as well as how well adoption can be driven in an organization, which varies drastically based on ability to execute and maturity levels. And, for a lot of businesses, it’s important to show results within a quarterly cycle.
But what’s really important is that you don’t turn value into a long winded run, or a long shot down the line, and that you don’t simply hope that value happens.
Through Value Sprints and Continuous Value Delivery you can create a sustainable approach where the business can realize the value from it’s technology investments in a sustainable and more reliable way for real business results.
And that’s how you win in the game of software today.
Blessing Sibanyoni on Value Realization
How Can Enterprise Architects Drive Business Value the Agile Way?
How To Use Personas and Scenarios to Drive Adoption and Realize Value
Good points, JD. It would be great to have a link to a "tool" that one can use to list some key KPIs and value measures ESP engagements have identified for different verticals for different workloads for various sizes of businesses....
@ Imran -- Thank you. Interestingly I've had KPIs on the mind lately, and I've been working through different simple ways to catalog and sort against the value chain.