are not a new concept, having been talked about over 30 years ago by Dr. Allen Ward, the author of “ ,” but until the last few years, there has been tremendous variability in how people define value streams. With the rise of the (SAFe), more and more large organizations are adopting value streams into their business architecture to deliver value to their customers more efficiently.
The process of 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 techniques, you can look at the 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 regard for to happen from C to F. To understand how to support your development value streams, you must understand the purpose for which your business exists, the value it delivers, and how you measure the successful delivery of that value (hint: it’s not ROI).
Once you know your currency of value and how you measure it, you shouldn’t go straight to what systems you use to create that value. Before you go-to systems, you must look at what business processes to execute your 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 to massively siloed functional teams and programs. One sizeable financial group I was brought into had organized itself into 127 units of Release Trains (ART), each with a specific maintained system. And then, as investments were made into large initiatives, projects, and programs, we found that the 70-80 of those ARTs.
The amount of overhead and dependency management was staggering, making them less efficient than before, even with a 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 been better organized aligned to achieving specific business purposes.
Starting with your business roadblock to successful value stream implementation: corporate functions getting left behind. When you don’t discuss business processes, you forget to include functions like , procurement, HR, legal, accounting, and finance into your development value streams and ARTs. When you start with business processes and break those down into systems, you include those functions as part of the global view you apply to your value streams. Over and over, we see organizations implement new only to discover that the role matrix doesn’t support it or that no one invited procurement to strategic planning. So the entire roadmap must be delayed, or emergency authorizations must be granted.
Not only does aligning around business processes enable a faster flow of value — which is why most organizations choose to make value stream identification — it’s also a complete picture of your organizational and strategic context. The Lean-Agile SAFe approach to value streams is excellent, but it’s incomplete until you bring the business along for the ride.