An Insider’s View on Value Stream Thinking

Intro

Peter Vollmer spent 26 years inside HP Software and its successor organisations – Micro Focus and OpenText – the last 15 of those in the CTO Office, where he led the SAFe transformation and was responsible for parts of the Software Factory. He has been an SPC since 2014 and an SPCT since 2018. Today he works as an independent Enterprise Transformation Coach and publishes his body of work openly at value-stream-thinking.com.

BACKGROUND

Renaud: Peter, you’re here at the SAFe & AI Summit as the founder of Value Stream Thinking. You spent 15 years in the CTO Office leading one of the largest SAFe transformations in enterprise software – and building what was one of the first Software Factories in the industry. How did Value Stream Thinking emerge from that experience?

Peter Vollmer: It grew out of the transformation – very much so. And I think that’s actually what gives it the credibility it has.

When we started the SAFe transformation, we were solving real coordination problems – bringing cadence, a shared language, a way for large numbers of teams to work together. And that worked. But early on, we started running into questions that SAFe alone couldn’t fully answer. Which value streams do we actually have? Where do they start and end? How do they interact? How do we model something this complex in a way that’s useful for decision-making at multiple levels simultaneously?

So we started developing what were essentially very early aspects of Value Stream Thinking – ways of visualising and modelling the flow of work that went beyond what traditional value stream mapping could handle for our environment.

The Software Factory, including the Application Lifecycle Management tooling, became an incredibly useful vehicle for this. When you can instrument the value stream – when the model is connected to real data flowing from real tools – the conversations change completely. You’re no longer arguing about perception. You’re looking at evidence.

So by the time I stepped out as an independent consultant, I wasn’t starting from scratch. I was taking something that had been developing in a real organisational context for years and formalising it – making it transferable, documentable, and open for others to build on.

THE PROBLEM

Renaud: You’ve named the symptom – nobody can see the whole picture. But before we get to your solution, help us understand why that’s so hard. Organisations have been doing value stream mapping for decades. Isn’t this a solved problem?

Peter: Value stream mapping is a genuinely powerful tool – but it was designed for manufacturing. Stable, linear, repeatable flows. Apply it to modern software-intensive product development – which is iterative, feedback-driven, architecturally complex – and you have what I call a model–system fit problem.

I use a simple image for this: it’s like using a flat-head screwdriver on a Phillips screw. You can make some progress, but it takes far more effort than it should, you keep slipping off the real constraints, and the result is never quite right.

Product development is not a linear process. It’s a system of feedback cycles – where learning, integration, and iteration are the core activities, not the exceptions. Traditional value stream maps struggle to represent integration points, feedback loops, the recursive nature of how sub-streams feed into larger streams. So organisations either spend enormous effort building maps that don’t reflect reality, or they abandon the exercise entirely.

There’s a deeper point here too. I love the John Snow story from 1854 – the cholera outbreak in London. The dominant theory was bad air – miasma. Nobody was short of data. Deaths were being counted, streets were being monitored. But nothing changed until Snow drew a different map – one that placed each death at its address and revealed a cluster around a single water pump on Broad Street. Same data. Different model. The pump handle was removed and the outbreak stopped.

The breakthrough didn’t come from more data. It came from a better model. And that’s exactly the situation most large organisations are in today with their value creation systems.

„The breakthrough didn’t come from more data. It came from a better model.“

Peter: In environments like automotive, two worlds collide. Hardware evolves on multi-year cycles. Software can theoretically evolve every sprint. But every software release can silently hit physical constraints: processing capacity, heat management, timing, memory. The hardware sets invisible ceilings that software teams often don’t encounter until very late in the process. Models and Digital Twins promise to bridge that gap – but in most organisations they are still too incomplete or immature to fully deliver on that promise. The invisible ceiling remains invisible for longer than it should. And this challenge is not unique to automotive – it applies equally to aerospace, medical devices, and any complex cyber-physical system.

Then layer on the organisational complexity. You have many domains – each with their own teams, budgets, timelines – all contributing to a single integrated product. End-to-end features cut across all of those boundaries. And when that’s not explicitly designed for, you end up with internal customer–supplier dynamics, conflicting priorities, and problems that surface only at final integration – exactly when they’re most expensive and slowest to fix.

What’s needed is a model that makes those constraints visible early, so you can design, measure, and steer the full system.

THE APPROACH

Renaud: So let’s get into Value Stream Thinking itself. What is it, and how is it different from what people are already doing?

Peter Vollmer: VST makes the end-to-end flow of value visible, modelable, measurable, and continuously improvable. But the key distinction is that it’s a system perspective – not a mapping technique. It doesn’t replace Lean, Agile, or DevOps. It provides the coherent system view within which those practices can align and reinforce each other. Without understanding how value flows across teams, domains, and system boundaries, local improvements risk optimising parts while the overall system stays constrained.

At the technical core of VST is what we call the Assembly Line Model. And this is emphatically not a manufacturing metaphor – it’s a modelling approach suited to the nature of complex product development. It represents stages of work, integration points, feedback cycles, backlogs cascading from a shared product backlog down to team level, and the hand-offs between them. It can zoom into a single sub-stream or zoom out to an enterprise-wide landscape while maintaining a consistent language throughout.

The real power shows up in the room. When you place this model in front of a cross-functional group – engineers, architects, product managers, leaders — people who have never agreed on anything suddenly start seeing the same system. That shared picture unlocks structural conversations that dashboards and status reports simply cannot. You stop asking ‚who is failing‘ and start asking ‚what is the system doing.‘

„You stop asking ‚who is failing‘ and start asking ‚what is the system doing.“

Renaud: You talk about Value Stream Landscapes — plural. Multiple views of the same system. Can you walk us through that?

Peter: This is one of the most important insights in the whole framework. Different decisions require fundamentally different views of the same system. You can’t steer an enterprise from a single map any more than you can navigate a city with only one kind of chart.

We’ve identified four landscape perspectives – Structure, Design, Measure, and Evolve.

The Enterprise Level Landscape is the governance view – how is value creation organised and funded? Who owns what? Where does system-level integration happen? This exposes things that are almost never made explicit: a domain funded in a way that contradicts its actual responsibilities, or integration ownership that nobody has formally claimed.

The Domain Value Stream Landscape zooms into a specific domain – what does it actually look like inside? Is it one coherent product-oriented flow, or ten parallel project-based streams serving different variants? This is where you discover fragmentation and duplication that quietly kills productivity.

The Performance and Observability Landscape is where measurement lives – and this is important: metrics here are not standalone dashboard numbers. They are structurally placed observers. Deployment frequency, defect escape rate, defect resolution time – these are anchored to specific stages in the Assembly Line, so they tell you where in the system the constraint is, not just that something is wrong.

And the Transformation Landscape adds a time dimension – what do we change, and in what sequence? In any large organisation, different domains are at different maturity levels simultaneously. This landscape makes those asymmetries visible so transformation can be sequenced deliberately rather than applied uniformly.

Together, these four shift Value Stream Landscapes from documentation artefacts into genuine steering instruments for leadership.

ORGANISATIONAL DESIGN

Renaud: There’s a significant leap from understanding how value flows to actually restructuring an organisation around it. How does VST bridge that – and where does it connect to, or go beyond, what SAFe already provides?

Peter: SAFe gave us the coordination patterns. ARTs, Solution Trains, PI Planning – these are real solutions to real coordination problems, and I say that as someone who has run these transformations, not just advised on them. But coordination patterns and structural design are different problems.

Here’s the distinction I’ve come to: scaling frameworks tell you how to coordinate teams. Value Stream Thinking tells you which teams should exist, where their boundaries should sit, and why. If the structural design is wrong – if team boundaries are misaligned with the architecture, if integration boundaries are in the wrong place – then the framework coordinates the wrong structure. More efficiently, perhaps, but still the wrong structure.

A simple illustration: imagine you’re on the second floor and you need to closely collaborate and hand off work to someone on the fourth floor. Coordination would try to find the best way to bridge that gap. Structural thinking would simply say – let the two sit next to each other. No further coordination required.

The structural design question comes down to where you place integration boundaries – and we use four lenses for that. The value stream itself shows you how work actually behaves in practice: where queues form, where feedback slows, where integration keeps destabilising. Fracture planes reveal the natural segmentation points where the system can be split with minimum coordination cost. The architecture tells you the technical dependency topology – tightly coupled components need to live within the same team boundary. And Conway’s Law reminds you that your communication structure will become your system architecture whether you design it deliberately or not.

What I’ve found – from personal experience running a large transformation – is that when you combine SAFe’s coordination mechanisms with deliberate structural design based on value streams and architecture, the results are qualitatively different. The trains start running on tracks that actually match where value needs to flow.

„The trains start running on tracks that actually match where value needs to flow.“

PRACTICAL GUIDANCE

Renaud: For a leader – a VP Engineering, a Chief Product Officer – what’s the first concrete step?

Peter: The entry point always depends on your context – the size of your organisation, where the pain is, and how much appetite there is for change. But whatever the context, you don’t have to boil the ocean. Every step delivers value in its own right – each workshop sharpens understanding, surfaces decisions, and creates momentum. You don’t need the full picture before you start acting.

A good first step is often a single value stream. Pick a product or a domain where there’s pain that people feel but can’t explain – slow delivery, integration surprises, constant firefighting – and build one Assembly Line model with the people who live inside that system. The workshop itself is where a huge amount of value gets unlocked. In my experience, a well-run value stream identification session surfaces more structural insight in a day than months of status reporting. You’re not just creating a diagram – you’re building a shared mental model across roles that rarely look at the same picture.

From there, the approach can grow naturally. For larger enterprises, top-down and bottom-up efforts complement each other. Top-down, we run landscape workshops at the domain or sub-domain level, building a high-level view of how value streams relate to each other across the organisation. Bottom-up, we run detailed value stream identification workshops on specific value streams. Because value streams can be modelled at different levels of abstraction depending on scope and purpose, the two approaches gradually connect – over time they meet in the middle and create a holistic view of the organisation.

And throughout all of it – context, context, context. There is no one-size-fits-all approach.

Renaud: You’re an SPCT, you ran one of the largest SAFe transformations in enterprise software, you have built a Software Factory capability – and now you’re doing this independently and publishing it openly. What’s the motivation?

Peter: At some point the natural next step was to take this beyond a single organisation – I could see the potential, and frankly I wanted to keep doing something I am genuinely passionate about. Curiosity played a big role too – not just about how these ideas would evolve in different contexts, but about the industries themselves. Every engagement is an opportunity to understand how others work and what challenges they face. And ultimately it’s about impact – productivity and the day-to-day experience of practitioners matter, and that’s a much bigger playing field than any single organisation.

But there’s a second reason for publishing openly, and it’s one I feel strongly about: things only spread and improve when they’re shared. If you want to develop something that genuinely gets better over time, you need feedback, you need real-world testing across different contexts, and you need a community around it. The site is genuinely a living resource – I treat every piece of feedback as input into the next version. In a way, that’s a direct lesson from VST itself – continuous improvement only works if the system is both open to learning and able to act on feedback quickly. The same logic applies here.