There is scarcely a business today that doesn't rely on software to compete effectively in their markets. Those who do this best have a competitive advantage. Moreover, the digital disruptors (think Airbnb, Amazon, Netflix, Spotify, Uber, and WhatsApp) have proven that no company, no matter how large or how long they have been in business, is immune to the influence of the disruptors. However, in this blog, I discuss why improving the quality and speed of your software delivery pipelines is only part of the competitive solution.
The Lean-Agile Operating Model
Improving the delivery of customer-centric value is not a novel idea. Both Agile and Lean practitioners have long understood that we must deliver value that addresses our customers' needs and preferences.
In the software community, a specific objective of Agile is to embrace customer and market-directed changes as a fact of life and incrementally deliver new value to address those evolving needs frequently through a series of time-boxed iterations. Each iteration addresses our customers' highest priorities, as defined by the product owner within the product backlog. As a significant side benefit, the iterative and incremental development (IID) model of Agile also allows software teams to identify and fix bugs immediately before they can accumulate and become difficult to isolate and resolve.
Lean software development concepts similarly focus on delivering the value our customers want. However, the Lean approach also involves an end-to-end assessment of the value stream activities that take a concept through to delivery to minimize non-value-added wastes, streamline our processes, and ensure our capacity matches customer demands. The goal of Lean is to deliver what our customers want in the most efficient and accelerated manner possible.
Put together, Lean-Agile-based practices allow software development teams to deliver value more frequently, provide more opportunities for customer input, eliminate non-value-added activities, and address the issue of resolving bugs and defects more frequently by moving testing left in the SDLC pipeline.
DevOps as a Value Delivery Pipeline
DevOps started as a people-oriented approach to get developers and IT staff to work together to evaluate the end-to-end software delivery process. Intentional or not, DevOps implements many of the concepts employed by lean practitioners. For example, the teams had to look across their siloed functions to understand and improve the flow of work and information from concept through delivery.
As part of the DevOps-oriented improvement process, toolchain integrations, activity automation, and work synchronizations all became part of accelerating the flow of value through software. But we discovered we could do better. For example, value stream management (VSM) tools and platforms integrate data across disparate pipeline tools, providing real-time visibility and analytical capabilities to improve decision-making. Together, DevOps with VSM platforms and tools help the organization improve and accelerate the flow of value through software.
Pipelines and the Fuzzy Front End
So, we've gotten really good at accelerating software deliveries as an industry. However, we still struggle to get the best utilization out of our delivery teams and pipelines. Moreover, the investments to implement DevOps and VSM tools and toolchains are daunting on an enterprise scale, requiring executive sponsorship and inclusion in the organization's investment planning portfolios.
We also have the issue that improvements to our software delivery pipelines are downstream from the largest bottleneck in the delivery process, which Smith & Reinertsen (1991, 1998) refer to as the Fuzzy Front End (FFE).
This means that any improvements to our downstream CI/CD and DevOps pipelines have little impact on the organization's ability to accelerate customer-centric and value-based deliveries - defined as the period from identifying an idea or opportunity to when a team understands the requirements well enough to accept the work for construction. Unfortunately, this set of discovery activities is difficult to estimate and automate to this day.
While this problem is not new, it is exasperated due to our increasing ability to accelerate workflow in downstream software development activities. From a system thinking perspective, we refer to the DevOps improvements as local optimization. Therefore, investments in DevOps tooling cannot improve our software value delivery capabilities unless we also address the fuzzy front end to feed our software delivery pipelines.
Some organizations may think they have too much work and can't get it all done. So I'll address that issue in the following subsection.
Managing the chaos of competing interests
Organizations with modern DevOps capabilities can have another problem that seems the opposite of the FFE problem: too many high-priority work items in the backlog. This problem occurs when competing factions all push their change requests with the same priorities.
Gene Kim, Jez Humble, et al. introduce the 'three ways' concepts in their DevOps Handbook as a means to improve software delivery productivity in such situations. The three ways of DevOps include:
- Principle of Flow
- Principle of Feedback
- Principle of Continual Learning
These concepts came from traditional Lean production theories, applied to help the software organization identify and eliminate wastes that hinder productivity. But, none of these three ways directly address the issue of work prioritization. For example, tasks switching is one of the wastes identified in lean software development – meaning it takes time and effort to regroup if we are constantly moving from one task to another before completion. Therefore, we need to have a way to make value-based priority assessments continuingly.
Fortunately, there is a proven strategy to address both FFE and work task prioritization issues. And I'll give you a hint: it's Value Stream Management (VSM) applied as an enterprise-wide strategy. But before we get to that topic, let's take a moment to understand the issues better.
Aiming is more important than speed
The heart of the FFE issues is that we can spend a lot of time, money, and resources to develop our CI/CD and DevOps pipelines and install VSM platforms but not see a justifiable return on our investments. Of course, executives do not tolerate investments that cannot immediately show business impact. But, delivering software faster doesn't guarantee we will deliver business value more quickly.
Much more critical is how we aim our accelerated software delivery pipelines to deliver the highest value in the shortest possible time. If you try to justify your DevOps and VSM investments solely on the speed of delivery, you may not make much of an impression on the executives who control the funding. Instead, you will get much further if you can show how the improvements can accelerate the delivery of the organization's highest priority work items. But to do that, you need to be able to identify the highest value work items prioritized by their economic impact on the business.
In the next subsection, I explain how VSM plays the leading role as a lean-oriented approach to identify and prioritize value stream improvements across the organization.
VSM: it's not just for software
VSM is not simply a tools-based strategy to improve DevOps-based software delivery capabilities. Instead, VSM began as an enterprise-wide approach for continuously improving all organizational value streams as a sustainable process. In this context, work falls into three value stream categories:
One of the most important aspects of Lean thinking is that our systems can be continuously improved regardless of the business type. For example, in a book titled The Goal, Eliyahu Goldratt taught us his Theory of Constraints, which states that all business systems have at least one constraint and that the system's maximal output is limited to the pace of its constraints.
Suppose we attempt to introduce work faster than the constraints can handle it. In that case, the system as a whole begins to break down as bottlenecks form, increasing WIP, delaying deliveries, and hiding defects. Moreover, spending time and money to improve work activities that aren't constrained only exacerbates our delivery problems while adding more costs.
VSM methods and tools allow us to identify the wastes that constrain our organization's value streams and evaluate alternatives for improvements.
Six step VSM methodology
In my book Driving DevOps with Value Stream Management, I introduce a traditional eight-step VSM methodology. But the following six are most critical:
- Commit to Lean and learn how it works
- Choose your value stream
- Map the current state
- Identify critical metrics (Business outcomes, wastes, flow)
- Map desired future states
- Plan and implement identified VS improvements
- Focus on where digital innovations can drive competitive value
These six VSM steps help your organization identify and prioritize critical improvement opportunities across all value streams. They also help you identify areas where digital innovations drive business improvements, thus feeding your DevOps pipelines.
We now know that organizations can spend a lot of time, effort, and money developing mature DevOps capabilities but not necessarily add sufficient business value to justify the investments. Nevertheless, DevOps has become the table stakes necessary to compete in our modern digital economy.
The FFE issue virtually guarantees that your accelerated pipelines are not the bottleneck in delivering value through software to your customers. And even if your organization has a large backlog of work items to complete, you still have the question of which items produce the most bang for the buck.
Fortunately, VSM as a methodology offers a way for organizations to look across all organizational value streams to identify and prioritize the digital improvements that drive the most value from our customer's perspectives while feeding your software-based value delivery pipelines.
Gary is a board advisor at the Value Stream Management Consortium. He's the author of several books, including 'Driving DevOps with Value Stream Management'.