Tag: end to end

When it comes to accelerating customer value, it’s dangerous to focus only on the development and delivery of a digital product. For many enterprises, most time is invested before a single line of code has been written. That explains the recent focus on value stream management (VSM)—it’s forcing us to think beyond Agile and DevOps and consider the whole system, not just one stage in a complex process.

By extending our visibility further upstream where work originates, we can begin measuring the value of creating and protect workflows end-to-end to meet business outcomes sooner. Thinking about how software delivery work moves between all teams in the value stream from request to operation leads us to the significant realization that our tooling pipeline is our most important product and we should treat it as such.

The Rise of Value Stream Management

The growth of value stream management in software delivery has emerged because Agile and DevOps are not enough to remain competitive against the breakneck speeds of the tech oligopoly. The progressively maturing practice takes a systematic approach to continuously measuring and improving end-to-end flow to accelerate time-to-value. Consequently, new tooling is emerging as we think end-to-end in how we collaborate and work faster together—and measure our productivity and effectiveness.

Measuring and understanding end-to-end flow isn’t easy. Software delivery is highly technical and creative knowledge work that can span thousands (or tens of thousands) of IT practitioners. Information is scattered across heterogenous toolchains comprising discipline-specific tools. In fact, some 42% of large-scale software delivery organizations use four to 10 core collaboration tools for portfolio management, design, enterprise agile planning, testing and ITSM, and dozens of additional tools to support the CI/CD pipeline and operations. 

Measuring flow, therefore, involves tracing constituent units of value creation and protection as they traverse all team tooling in the form of artifacts such as activities, capabilities, epics, features, stories, bugs and incidents. Yet for too long we’ve been too focused on “the right side” of the value stream, thinking about how products are built and delivered through Agile and DevOps tools, without visibility on how they’re requested, analyzed, processed and designed. Our ability to support customers is hindered because we don’t know where and why work is slowing down outside of development. Our product pipeline is broken, our visibility fractured.

A ‘Broken’ Product Pipeline

Traditionally, CI/CD tools include source code management, build, deploy, quality management and service management. Moving more to the right, you have release management and service management. But too often organizations have ignored integrating tools further to the left such as planning and portfolio management, product management, requirements management and risk management (static and dynamic security scanning tools). This impacts our ability to see and measure end-to-end flow.

In”Accelerate,” lead time is defined as the portion of the value stream from (last) code commit until deployment. While this is essential to improve, it only covers the time from the build being produced through deployment. We need to account for the time that elapses before it hits a developer’s backlog. To shift IT from a project to a product focus, you need to reduce end-to-end flow time by measuring earlier in the delivery life cycle by “shifting left.” As such, you need tooling across the whole value stream through the ideate, create, release and operate phases. A focus only on optimizing the CI/CD tooling and practices is too narrow a view that produces diminishing returns over time.

The Great Disconnect Between IT and the Business

Because of this lack of a holistic view, IT teams don’t feel like they are able to influence the business side of the house, where most of the work in progress (WIP) starts, such as requests for features or application changes. These intake processes many times result in teams taking on too much WIP and neglecting work. Many teams need to “stop starting” and to “start finishing” to deliver business value more quickly. Crucially, this is the area where business leaders have their own processes and where tools are less likely to be used; it’s a world dominated by spreadsheets, documents and PowerPoint presentations. This is where work is least visible and measurable. And this is precisely where we need VSM: to turn the light on starting with the customer needs so we can continuously improve end-to-end flow. This requires a culture shift from both IT and business/product owners. And that requires taking a broader, more holistic view of the tools and practices in the business space.

Architecting for Flow

An end-to-end integrated pipeline product can be architected for flow. For example, tools used for visual system management (e.g. Jira, Azure DevOps) are becoming more of a commodity with the real differentiation becoming how they can be integrated with tools used for portfolio, defect and service management, since those are the sources of work that will flow into product-based teams for development of business value and unplanned work. Teams should think about how they can work more closely with business portfolio teams on continuous flow (and funding) because eventually this work will become the next bottleneck that needs to be addressed on the journey to accelerate business delivery capability.

Keep an Eye on Value Protection Work 

With end-to-end visibility into work across the pipeline, you can abstract that connected technical data into overarching value stream metrics—known as flow metrics—to identify areas where to run experiments to improve end-to-end flow. Here we mustn’t just focus on work that creates value but protects it, too.

We should provide our software delivery teams with the psychological safety to devote time to address debt and neglected work. Debt creates a drag on feature velocity because changes become more complex and take longer to make. In addition, with higher technical debt, more time is spent on addressing defects, which starves the capacity to perform feature work. As debt builds, the following is observed:

• Flow velocity decreases.
• Flow time increases.
• Quality decreases as the code base becomes more fragile/costs increase.

All of these result in reduced happiness for both the customer and the team, increasing the risk of team burnout. There are many cautionary tales of this occurring where market leaders ended up losing considerable market share due to inattention to technical debt. These stories exemplify why it is necessary to observe flow distribution to ensure that prioritization decisions made with the product owners, include providing necessary capacity to address technical debt.

Applying the concepts of value stream architecture to your end-to-end pipeline is the key differentiator for organizations that are trying to make it through disruptive periods such as today, as COVID-19 widens the gap between those who have mastered software at scale and are thriving and the many enterprises struggling to pivot and adapt in the digital-first climate.