Value streams are not a new concept, having been talked about over 30 years ago by Dr. Allen Ward, the author of “Lean Product and Process Development,” but until the last few years, there has been tremendous variability in how people define value streams. With the rise of the Scaled Agile Framework (SAFe), more and more large organizations are adopting value streams into their business architecture in an attempt to deliver value to their customers more efficiently.
The process of value stream identification as laid out by SAFe starts with identifying your operational value stream, the workflow that your business follows to deliver value, and then breaking that down into the systems that support that value stream. Once you understand the systems, you can look at the people who build and support those systems and organize them into development value streams that deliver those systems to support your business. It’s a solid and worthwhile process for software-oriented companies. The challenge is that it goes straight from Step B to Step G without any regard for everything that needs to happen from C to F. In order to understand how to support your development value streams, you have to understand the purpose for which your business exists, what exactly is the value that it delivers, and how do you measure the successful delivery of that value (hint: it’s not ROI).
Once you know what your currency of value is and how you measure it, you still shouldn’t go straight to what systems you use to create that value. Before you go to systems, you have to look at what business processes you use to execute your operational value stream. Once you know what business processes you have in place, then and only then should you start to look at how the people that execute those processes do their work. What systems do they use? What organizational partners and vendors support their delivery? Then you can move on to the rest of the traditional value stream identification exercise.
But what happens if you don’t do this first?
I have seen it repeatedly. Organizations organize around systems that lead to massively siloed functional teams and programs. One large financial group I was brought into had organized themselves into 127 teams of teams called Agile Release Trains (ART), each with a specific system that it maintained. And then as investments were made into large initiatives, projects, and programs, we found that the average initiative required dependency coordination across 70-80 of those ARTs. The amount of overhead and dependency management was staggering, and led to them being less efficient than before, even with the greater understanding of their operational value stream. And this isn’t uncommon! Bad agility is worse than no agility at all. If this organization had taken the time to understand the connections between business processes inside their value stream, they would have realized they didn’t need dedicated ARTs for each system and could have better organized around groups of people aligned to achieving specific business purposes.
Starting with your business processes also allows you to eliminate the single most common roadblock to successful value stream implementation: corporate functions getting left behind. When you don’t talk about business processes, you forget to include functions like supply chain, procurement, HR, legal, accounting, and finance into your development value streams and ARTs. Over and over we see organizations implement new ways of working only to discover that the role matrix doesn’t support it, or that no one invited procurement to strategic planning and so the entire roadmap has to be delayed or emergency authorizations have to be granted. When you start with business processes, and break those down into systems, you end up including those functions as part of the global view you apply to your value streams.
Not only does aligning around business processes enable faster flow of value — which is the whole reason most organizations choose to do value stream identification — it’s also a more complete picture of your organizational and strategic context. The Lean-Agile SAFe approach to value streams is great, but it’s incomplete until you bring the business along for the ride.