Value Stream Mapping is a crucial step in assessing an organization’s DevOps capability. We create a value stream map of the software development lifecycle early in any DevOps engagement, because it helps us to-
- Provide context for our architects and technical experts who are, in parallel, examining tools and technology.
- Establish a performance baseline, against which the improvements delivered by adopting DevOps will be measured. (See my other blog post on Box Scores for more on this).
- Begin the process of winning hearts and minds, and engender cultural change. By working side-by-side in a workshop, Dev and Ops resources, as well as those involved in planning, test scheduling, and other activities, start to gain an understanding of how the work they do is linked to steps upstream and downstream. This lays the groundwork for closer coupling of those activities in the future.
What’s interesting is that the template we use for our DevOps Value Stream Map is almost identical to that which we use for other service processes. It’s been used by IBM Lean Coaches to assess processes as diverse as Marketing Campaign Development, Order-to-Cash, Mortgage Applications, and Production Support to name but a few. This template was evolved from more traditional Value Stream Maps used to capture manufacturing processes, and a slightly different template also exists for innovation or product development processes.
At the start of every Lean project – whether it’s in DevOps, Insurance Claims, New Product Development, or Financial Forecasting, I review the Value Stream Map template. I ask myself and my team if the questions make sense for this process and if the boxes we are seeking to fill are relevant. Some of the language might be slightly different, and the outputs will certainly differ – from a high frequency process where a step takes minutes and seconds, to a creative process where a step could take weeks. But almost without exception, the template remains the same.
We ask the same questions across all these types of processes – and now we ask those questions of the Software Development Lifecycle. Those questions are:
- What activities are being performed?
- Who delivers those activities? How much of their time is dedicated to those activities?
- What is the yield, i.e. ‘right first time’? What % of rework is generated? What causes rework?
- What tools are required to complete the step? And what other inputs are required?
- How many units (e.g. work packages) are ‘work in progress’ within this step?
- How many units are waiting in the ‘inbox’? How will they be prioritized or scheduled? How long will they, typically, wait for?
- How long does the step take? How much of that time is effort, or touch time, versus duration, or in-process lead-time?
When all’s said and done, all Value Stream Maps have something fundamentally common: they are all about flow – and DevOps is no different.
About the Author/ Katie Sotheran
Katie 
is an IBM Lean Master based out of Los Angeles, California. Katie has many years applying Lean principles to processes as diverse as beverage distribution in Spain, lubricant product development in the Netherlands, Insurance Sales in the UK … and IT operations, all over the world.
