Pivotal Moments in Value Stream Mapping

What's the greatest thing about value stream mapping?

For me, it's not the ability to remove a couple of process steps here or there. For me, it's what happens in a pivotal moment, something that can happen any time in a value stream exercise.

A pivotal moment occurs when the group's mindset dramatically shifts—from merely questioning individual steps to reimagining the entire way work is done.

I was working with a group of people from multiple departments to map out how we deliver customer-specific software. We knew the process was messy and full of suboptimal handovers, but it wasn’t clear where to begin.

So we started by mapping out the current process.

To spare you the intricate details of the flow, what stood out was the realisation that we were planning releases multiple times throughout the process—three times, to be precise. Every time the audience, the scope and the depth of the planning exercise would differ, but it would still boil down to planning the upcoming release. The reasons for this are manyfold. The process grew organically, and because no-one had a clear understanding of how the overall process worked, everyone went for local optimisations.

It was obvious that this was a great place to start looking for improvements. The logical question: Why are there three planning exercises, and how can we consolidate them?

So we went deeper into the topic and discussed the three plannings in detail. What is discussed? Who is there? Why does it happen at that stage? What information is present, what is missing? What assumptions are made? What kind of decisions are taken? Who is informed? How are decisions followed up? By whom? What information is going downstream? What is going upstream?

The group decided to merge the three disparate planning exercises to a single one that is joined by everyone attending one of the separate ones.

That is nice, and will free up some calendar time for people who where required to attend more than one of those meetings, but it isn't really that much of a game-changer in and of itself.

The real game-changer was when someone asked the question we would need an answer for:

How can we make sure this new joint planning session will be a success?

This question created a pivotal change of thinking in the group. In a single moment, the conversation completely changed and created an avalanche of improvements and new ideas.

Jumping off from this question, the group started mapping out a new process, and everything that is needed for it to become a success.

This new process was far more than just the removal of a few unnecessary steps—it transformed the quality of collaboration across departments and teams.

  • With the introduction of one release planning event and bringing every involved department together, the distance between engineering teams and their stakeholders was significantly shortened.
  • Having stakeholders in the planning allows for direct prioritisation and clarification, a process previously done with proxies.
  • With Stakeholders being part of the release backlog building process, they get maximum visibility of the scope of the release.
  • Stakeholders were keeping track of "their" requests in an array of tools that were more or less disjointed from the system where the actual work was tracked. With the visibility of the release backlog and the tool tracking it, they were able to get rid of their own systems, dramatically reducing the complexity of the tooling (no more excel sheets and email! yay!)
  • With everyone following the release from a single source of truth, all reports, dashboards and status updates where correct by default, instead of requiring manual updates and checkins.

Overall, this change in the process led to positive effects way beyond the removal of two unnecessary process steps: The direct collaboration of stakeholders and engineering teams leads to a significant improvement of the quality of both requirements and implementation. The joint release planning processes requires a unified view on both the work-to-be-done and the work progress, leading to a significant and impactful reduction of tooling and data manipulation complexity. This also improves decision making by making sure the relevant data is correct and up-to-date.

And all because someone asked "Hey, why are there three different types of release plannings in our work cycle?".

If you're facilitating a value stream mapping exercise, keep an eye out for those moments when participants shift their thinking—these are the opportunities for meaningful change.

And then go into the topic, go deep, and watch it happen.

True transformation happens when we go beyond tweaking processes and start reimagining them. Value stream mapping offers a unique opportunity to uncover those game-changing moments, where incremental improvements turn into powerful shifts in collaboration and efficiency. Don’t settle for minor gains—aim for breakthroughs. The real potential lies in the bold changes waiting to be uncovered.

(This is part 1 of a larger series about using value stream mappings to overcome silo thinking. To the overview)

Published 2024~10~01

Link Graph

Yeah, I know, the 2000s knocked and wanted to show you their ideas about knowledge navigation, but I really like those graphs, even if they are not the most practical instruments, plus I actually developed a network-based knowledge management system called 'Serendipity' back in the day, so please stop making fun of me.