Mapping the value stream
Once you've picked the stream, the next step is to see it. In any value stream of real complexity, no single person knows all the work — it's spread across teams who are far apart on the org chart, geographically, and by incentive. Mapping makes the invisible visible.
Once you select a candidate application or service for the DevOps initiative, identify every member responsible for working together to create value for the customer. If any of these is missing from your kickoff meeting, the map will lie.
The internal voice of the business; defines the next set of functionality in the service.
The team responsible for building application functionality in the service.
The team ensuring feedback loops exist and the service functions as desired.
Maintains the production environment; ensures required service levels are met.
Responsible for securing systems and data — across the value stream, not at the end.
Manage and coordinate production deployments and release processes.
In Lean terms: "ensures the value stream meets or exceeds customer and organizational requirements, from start to finish."
The goal is not to document every step and minute detail. The goal is to sufficiently understand where the value stream is jeopardizing your targets — short lead time, high quality, motivated workers. You produce two artifacts.
The map of reality, today
- — Every step, in order, including queues.
- — Lead time vs process time per step.
- — %C/A (complete and accurate) at each handoff.
- — Where rework loops back upstream.
The target, with a date
- — What the stream should look like in 3–12 months.
- — Which queue is eliminated, which step is automated.
- — Concrete metric improvement targeted (e.g. lead time 3 mo → 1 week).
- — Used as a target condition; iterated toward, not jumped to.
// critical: assemble the people with AUTHORITY to change their portion of the stream. a map without those people is theatre.
Places where work waits weeks or months — getting production-like environments, change approvals, security reviews, change advisory boards.
Places where significant rework is generated or received. Rework is the quietest waste — it shows up as "we're busy" but produces nothing new.
Handoffs where the next step does not receive usable-as-is work. Low %C/A here is a leading indicator of downstream rework.
Improvements can start small. With a clearer view of the whole stream and where the real constraints live, the team makes targeted improvements — many of them much less expensive and much more effective than originally imagined.
Even if a COBOL environment eventually needs to be migrated — maybe someday it becomes the constraint — you can take smart, targeted steps to speed up the value path along the way. You don't have to wait for the big rewrite.
- step 01 Pick the single metric from the VSM you want to improve. Just one. Lead time, %C/A, queue time on a specific step — choose by impact, not by ease.
- step 02 Observe and measure deeper around that metric. Where does the time actually go? Who's blocking whom?
- step 03 Construct the idealized future-state VSM as a target condition, with a date 3–12 months out.
- step 04 Iterate. Re-measure on a short cycle. The transformation team owns the path between current and target.
A team builds a value stream map and lists every single tool, script, and approval step they could think of — 140 nodes across three whiteboards. What's the most likely problem?
// pick one to verify
During a VSM kickoff, the security team is invited but only sends a project coordinator with no authority to change Infosec processes. Why is this a problem?
// pick one to verify