Value Stream Mapping the DevOps Void

Ever wonder why your releases take so long?

After all,  your company just invested a “zillion” dollars on a whole bunch of great ‘agile’ tools and a cloud framework. Tools that allow you to automatically provision your infrastructure, applications, data, and ensure that all your security obligations are met.

Hey! With this new” DevOps toolchain”, we should be moving our releases, from request to delivery, in a matter of minutes. You know … full push-button automation! … environments on demand! … And all that stuff!

Yeah! Right! But no! That’s not how it typically plays out.

In fact, a more realistic example might follow a storyline as follows:

• Project manager raises a request for a Test Environment
• Request sits in its service management queue for a few days
• Gets approved and assigned by Test Environment Manager and distributed to engineering teams
• Sits in the team ITSM queues for another few days
• Apps team build the package in 5 minutes but can’t deploy as infra not ready
• Infra team provisions
• Test team can’t start testing as data not ready
• Data team ensures Data secure and Compliant
• Data team provisions
• …
• Sorry, testing now too busy with another test cycle
• Test teams spot a defect with the build
• Higher priority project comes along and acquires environment
• Go back to go

I think one gets the point, the issue with DevOps efficiency is rarely down to a single atomic task.

In fact (as illustrated in the diagram below), if you were to take a step back, you would probably realise the inefficiency is not in the operations themselves (like a build task) but in fact the “void” (or the wastage) in between.

In the above multi-process diagram, we can see the Data team takes:

• 180 minutes of operations (real value)
• 5 days of waiting (wastage)
• Or 2.5% Efficiency (Value Operation / [Value Operation + Wastage])

Not exactly something you want to write home about. However, not an “untypical” in-efficiency, and a serious opportunity for improvement.

Imagine if for each team could move from 2.5% to just 25%. The benefits would be enormous, and over the lifetime of a project we could be saving weeks, maybe months, of time which translates to early “time to market” and significant IT project cost savings.

Enter Value Stream Mapping

Originally employed in the car manufacturing space, Value Stream Mapping (VSM) is a lean method that helps you better define a sequence of activities, identify wastage and ultimately improve your end-to-end processes. A set of methods that can be applied to any type of operation, including of course Test Environments and DevOps.

Wikipedia Definition: Value-stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer.

How do I go about implementing a simple* Value Stream Mapping for DevOps?

1. Select the Product e.g. CRM application
2. Select the Delivery Process of Interest e.g. Build a test environment
3. Gather the SMEs, as VSM is a team event.
4. Visually Map Current State (material flow / operational steps)
5. Identify Non-Value between steps
6. Add a timeline for both Operations (green line above) + Non-Value (red line above)
7. Review Value Stream
8. Design Future State (Optimize)
9. Return to (3).

Tip: When getting started, steps 4 to 8 may initially be completed on whiteboards and simply use guesswork (in place of real data). However, for ongoing improvements, consider using tools that allow you to model your DevOps processes, track the operations and report on stream actuals.

Benefits of DevOps Value Stream Mapping

• Baseline existing Operations
• Standardise Operations
• Identify Wastage
• Highlight Operational Bottlenecks *non-automated
• Lift Efficiency *continuous improvement