Is Incident Management a Value Stream?

This article was originally written as a contribution to a collective post for the VSM Consortium blog (find the full article using the link below):
https://www.vsmconsortium.org/blog/is-incident-management-a-value-stream (February 6, 2022)

“In this, the first of a series of blog posts from the Value Stream Management Consortium, our experts weigh in on, “Is THIS a value stream?” First up, we’re looking at Incident Management.”

Patrice Corbard, Founder of SD ReFocus and Influencer Member of the Value Stream Management Consortium:

As defined by ITIL, Incident Management is a process or a service management practice that aims to manage the lifecycle of all incidents (unplanned interruptions or reductions in quality of IT services).

On the other hand, Incident Resolution can be viewed as a value stream (or a value streamlet) with :

  • A clear trigger event: incidents or system outages 
  • A clear value delivered: incidents resolved
  • Its own flows of work, material, and information
  • Performance metrics: MTTD and MTTR (one of the four key metrics of Accelerate)

A “Software Delivery Value Stream” can be mapped as a sequence of steps from Customer Requests to Delivery of a software product or service. We can also visualize the extended value stream with pre-request and post-delivery works.

Usually, we associate the “software delivery value stream” with its main objective of delivering new features.  But, this is only one of the several types of customer requests and types of work that the value stream has to manage. Feature requests are only the tip of the iceberg!

Fixing bugs, resolving incidents, anticipating and fixing vulnerabilities, responding to support requests, reducing technical debt, etc. are works that, when accomplished, bring value to users and whose flows are different from features.

To address this complexity and visualize this reality, a “software delivery value stream” can be decomposed into ‘value streamlets’:

The “Incident Resolution value streamlet” can be mapped using the same visual representation as the “Feature Development value streamlet”.

We can use the power of the value stream mapping technique to make visible the specifics of these types of work: their own input rate, information and workflows, timeline, and performance metrics.

Finally, the different value streamlets form a network that contributes to the whole software delivery value stream and to the delivery of value to its customers :

“New feature development” and “incident resolution” are two external value streamlets directly delivering value to customers, while “vulnerability remediation” is an internal supporting value streamlet serving others value streamlets and processes like “App Security Testing” and  “Incident Management”.

Because the value delivered by our software is not only measured by the features deployed to users but also by the quality, security, and reliability of the systems running in production, we need to seriously consider “incident resolution” as a value stream(let). 

Picture by Obi – @pixel8propix on Unsplash

Leave a Comment

Your email address will not be published. Required fields are marked *