Continuous Delivery: Understand your Value Stream - Step 1
If you prioritize outcome over ceremonies then you have made the right choice (and presumably you are at the right place). The first step is to understand your current value stream.
What is a value stream?
A value stream is an ordered sequence of activities required to take an idea/feature from its inception to the hands of the customer.
Each organization, each business unit, each product and each team might have a different process and sequence of steps to put a feature in front of the customer. Many of us are used to working in teams specialized to perform specific tasks. Before I initiated the CD journey, I was part of the team specialized in building software (heard of Dev teams?). Dev teams used to build the software and on regular intervals (mainly quarterly), upon notification, Configuration Management team used to build and deploy the software and on successful deployment, used to notify the QA team. I guess you know the drill :-). While these silo’d teams might be performing their tasks very well, they lack the big picture. i.e. they doesn’t have the complete picture of how work is flowing in an organization. They doesn’t understand the value stream.
Building the Value Stream
Value Stream Mapping (VSM) is the method used to build value stream maps. From Wikipedia
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.
You can find lot of detailed material available on web on building the value stream so I will just list the high level steps (in ordered sequence)
- Select a specific product or product family.
- Build a current state value stream map.
- Build a future state (or ideal state) value stream map.
- Create an action plan to move to the future state
Which product to pick for VSM when you are starting new?
You can apply one (or more) of the following criteria: revenue, volume, strategic, product families, etc.) to pick the first product. I’ve generalized my products into the following three families
- Libraries: These aren’t directly deployed to be used by customers but used as building blocks to build Services and Platforms. E.g. Jars, NuGet packages, C++ libraries etc.
- Services: These are self-contained deployable units and you are in control of directly putting these in front of the customers. E.g. 12-factor apps, WAR’s etc.
- Platforms: These require customization before they can be used by the customer. Customization's can be either through configuration or plug-in’s. E.g. SaaS, Multi-tenant systems requiring customer on-boarding etc.
The assumption behind this categorization is that any software artifact produced in an organization falls into one of these categories and value stream mapping just for these 3 categories saves a lot of time. i.e. you no need to go through value stream mapping each and every product offering of your organization or business unit.
Documenting the Value Stream Map
While there are some products and excel templates that help you to formally document your current and future VSM’s, I would suggest you to whiteboard it with sticky notes and swim lanes. You can use the following template as a starting point for process boundaries (Split/merge them or add new based on your needs) and follow the detailed instructions mentioned here.
The Three Ways
The Phoenix Project describes the underpinning principles that all the DevOps patterns can be derived from as “The Three Ways.”
The First Way, summarized below, emphasizes Systems Thinking.
- Understand the flow
- Seek to increase the flow
- Don’t allow local optimization to cause global degradation
The VSM exercise you went through enables you to understand the entire end-to-end flow of work in your organization. Once you have understood the flow, time spent in each step of the flow, manual steps, manual hand-offs etc., you can start looking into optimization opportunities to increase the flow. The optimization might as well be in another team, outside of your control or influence. Making it a collective effort will encourage teams to optimize the process that they control.
If you haven’t already, you can increase the flow by automating the steps from development to deployment in production. In the next article I propose continuous delivery templates for the three product families I’ve mentioned in this article (Libraries, Services and Platforms).
