With a value-stream map, you create a map that illustrates the process from check in to the version-control repository until the software system is released to production – as a way of identifying process bottlenecks.
A value-stream map can be used to demonstrate the target workflow once the bottlenecks are removed. While you can use a value-stream map to depict the before state, I generally like to use it to show the target workflow as you see in the sequence diagram here. The deployment production line is the implementation of this value-stream map. The value-stream here is a very coarse-grained view of the overall cycle time of a project – in this case, indicating the overall cycle time between when code is committed and when it’s being used by users is 120 days. On typical projects that we’ve worked on, it can be much longer than this but somewhere between 120-180 days is about average. If you consider that you want your cycle time to be approaching zero (not that it’s actually zero, but that the duration is moving closer to zero than getting longer), then 120 days is a very long time for users to be waiting to receive benefit from your ideas.
The reasons for the long cycle time were addressed in the “Learn stakeholder’s motivation” sublesson – to include team Silos, manual instructions tribal knowledge, email threads, etc. These inefficiencies result in weeks to get environments, slow feedback, batching testing and many others suboptimal effects.
After establishing the baseline for the value stream, the goal is to reduce the overall cycle time. You do this by automating the entire software delivery lifecycle so that all processes can run in a headless manner.