From Domains to Value Streams
The 2010s were a turning-point in the history of software engineering. At the start of the decade, Eric Ries disrupted traditional approaches to building digital products with The Lean Startup. At the end of the decade, Matthew Skelton and Manuel Pais laid the foundations for the next decade of digital operating models with Team Topologies.
Both of these approaches have strongly influenced the evolution of how companies organize their teams in order to better discover value and accelerate delivery with improved flow. Empowered, product-mode teams have become mainstream, and the antiquated project-centric model continues to disappear.
Two iconic concepts from this era are the MVP (minimum viable product) which was popularised by The Lean Startup, and Value Streams which are a core concept in Team Topologies.
While MVPs have been mainstream for a long time, the concept of Value Streams and Value Stream Architecture is still in the early adopter phase in the DevOps world. Even though value streams are decades old, they’ve recently re-gained popularity in DevOps with the move to product-centric operating model.
This can sometimes lead to a little bit of confusion resulting in questions like “If teams are aligned to domains or products, how can they also be aligned to value streams?” or “How do software architecture, domains, Conway’s Law, Team Topologies, and value streams all fit together?”.
If you’re looking for guidance on how to define domain boundaries, you may find my kata useful as a practical introduction.
Empowered Product-mode Teams
An empowered, product-mode team is responsible for both discovering and delivering value in a specific area of the business. They might be responsible for user-facing parts of a product, like a mobile-app, or internal-facing APIs. In any cases, the team must discover unmet needs of their customers and deliver product improvements to meet those needs.
The area of the business a team is responsible for is a domain. And the steps the team goes through to discover potential value in their domain and deliver value in the form of new/improved product enhancements is their value stream.
A value stream at the level of detail above isn’t particularly useful. The utility comes from zooming in and visualizing the real complexity using value stream maps which show more granular steps combined with the processing time of each step and the wait time before each step.
The image above is a small extract of the type of value stream I would typically create with a team. The details can vary quite a lot. Some teams have complicated branching and testing processes which need accentuating, especially when legacy systems are involved or deploying to app stores.
Value stream maps also get interesting when you really unwind the process into strategic management and budgeting steps to reveal patterns like WaterScrumFall.
Team Flow Event Storming is also a great technique for mapping out and visualizing value stream-like processes collaboratively.
A single team can be responsible for multiple domains and value streams, although cognitive load must be managed.
From Domains to Value Streams… and Back
The relationship between domains and value streams is bi-directional. In an ideal world, starting from a blank canvas, it’s logical to first define the domains that each team will be responsible for (DDD can help with that).
Even when domains and value streams are established, there is a need for continuous evolution. One of the best signs that the domain and software boundaries are wrong is problems in the value stream, like high wait times caused by high WIP or external dependencies.
High levels of WIP in a team are an indication that cognitive load is too high — the domain might be too large for a single team to own and needs splitting.
Regular cross-team dependencies is a sign that two parts of different domains are regularly changing together. Maybe the domain boundaries should be changed so that they are part of the same domain and owned by a single team.
I discovered Kanban and WIP limits in 2012 and I’ve been a huge believer ever since. WIP limits accentuate value stream problems and force you to address issues before they get out of control. But it’s not like you can just sprinkle on WIP limits — teams also need to be empowered to address value stream issues they encounter.
A Quick Note on Value Streams
Over the years the concept of value streams has been picked up by different communities. I believe it originated in Lean Manufacturing in the 70s or 80s. Since then it has been picked up by Six Sigma, enterprise/business architecture, and more recently agile and DevOps communities.
As a result of value streams being applied in different contexts, they come in different flavours and different clothing. Sometimes it better to be specific about the type of value stream you are referring to.
In this article I’ve been referring to what Emily Peterson refers to as Development Value Streams. These are values streams that turn ideas into new product and capability enhancements. There are also Operational Value Streams which are the sequence of activities needed to deliver a product or service to a customer.
In other communities and frameworks these concepts go by different names such as internal and external value streams.
Looking Ahead…
Momentum is clearly building around the concept of value streams and the discipline of Value Stream Architecture. It’s definitely something that I pay attention to because architecting organizations requires a focus on domains, software architecture, and value streams. They’re all pieces in the same puzzle.
I think it’s inevitable that we’ll have better ways of understanding, analysing, and improving how we deliver value, and the DevOps community seems to be leading the charge in this space.
If you would like to learn more about the relationships between value streams, teams, software architecture and Conway’s Law, then I would recommend starting with Team Topologies.
For more information on value streams, the self-styled “Value Stream Guy” Steve Pereira has lots of interesting content on the topic.
