Value Streams

Definition

A value stream is everything that happens from a customer trigger to delivered value. Unlike a process, its defining property is the customer's perspective: it starts when they want something and ends when they have it.

Why it is the sharper frame for architecture

Mapping a value stream reveals whether the organisation is aligned to flow or to function.

If delivering one customer outcome requires six teams, four handoffs and three approval gates, the organisation is functionally aligned and the value stream crosses it repeatedly. Every crossing costs coordination, and the coordination cost — not the work — dominates the elapsed time.

That finding is architectural, because architecture and organisation mirror each other. Fixing it means realigning teams to streams, which usually means realigning the systems too.

The two kinds of team the frame produces

• Stream-aligned teams, owning a value stream end to end and able to deliver customer outcomes without waiting for anyone.
• Enabling and platform teams, reducing the cognitive load on stream-aligned teams by providing self-service capability — not by doing work for them, which reintroduces the handoff.

The distinction matters: a platform team that performs work on request is a functional team with a new name, and the value stream still crosses it.

What to look for when mapping

• Where does work wait? Almost always in queues for another team's attention.
• How many teams must coordinate to deliver one outcome?
• Where is the constraint? One team through which everything passes — a database team, a security review, a shared platform.
• What proportion of elapsed time is actual work? Frequently under 10%, which is the argument for addressing flow rather than productivity.

The architectural response

Reduce crossings. Give stream-aligned teams the capability to deliver without waiting — self-service infrastructure, their own data, their own deployment path. That is what platform engineering is actually for, and it is why a platform is a product rather than a service desk.

Failure scenarios

• Value streams mapped and teams left functional, so nothing changes.
• Platform teams that perform work on request, preserving the handoff they were meant to remove.
• Optimising a team's local productivity while the stream's constraint is elsewhere.
• The stream stopping at delivery, ignoring the operational tail — running the thing is part of the stream.

Interview question

"Delivering one customer outcome requires six teams. What is that telling you architecturally, and what would you change?"