More than once yesterday, I ended up explaining value-stream mapping. Wikipedia says:
Value-stream mapping, also known as “material- and information-flow mapping”,[1] is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from the beginning of the specific process until it reaches the customer.
I tend to describe it as “figuring out how you build what you’re selling, and seeing if you can do it better”. A lot of my take comes from my own interpretation of Mik Kersten’s book Project to Product. It seems deceptively simple, working in software. We have instrumented and measured our processes to a fare-thee-well. But have we actually looked at them together? In Making Work Visible, Dominica De Grandis shows us how we might have optimized each step of a process, but the gaps between the steps can hide a multitude of process and communication flaws. There’s a lot more to be said about push- and pull-based systems, and how software sometimes misunderstands value delivery, but that’s another post.
Instead I was thinking about why it felt like I kept bring up or encountering “value-stream mapping”. Here was a thing I had never heard of two years ago, and now it’s 3-4 times in a day, in entirely different contexts and conversations. It’s a frequency bias, or Baader-Meinhof phenomenon, one of the many cognitive biases human brains are just set to do. I learned about it from a humorous column in the St. Paul Pioneer Press, from long enough ago that I was reading a newspaper in paper. Back then, before a college professor catalogued it, it was a cute observation about how the world was full of coincidence. Baader-Meinhof phenomenon requires that the references be both obscure and not seasonal, so my Day of Value-Stream Mapping doesn’t really count, but it felt like it counted anyway. When you learn something new, it float around on the top of your brain soup, and when you encounter it again, it feels very relevant, and like this thing that you’d never known before is now everywhere.
I feel that way about value-stream mapping, like the place I am in my career and my thinking about software delivery, and my recent immersion in the DevOps Enterprise Summit environment have all made me grasp toward an understanding that we are not just software factories producing products, we are delivering a stream of value, from the headwaters of business need to the alluvial delta of customer need.
When I talk about progressive delivery, I’m not just talking about the part of delivery that exists at the mouth of a company, the swampy brackish zone where the freshwater of product mixes with the salinity of users. I’m talking about the entire riparian system, the entire value stream. In my ideal conception of value stream, consumers are a vital part of the whole, not an endpoint. The river doesn’t just empty into the sea, it is part of the water cycle of evaporation, precipitation, and collection. The value is not just in what we make, but how we make it, who we make it for, and what they can do with it. If we really want to progressively deliver, we need to break down the wall between what we make and who we make it for, just as we are breaking and remaking the wall and communication between development and operations.
If you read this post, I want you to look around, see where there may be value streams running past you, and ask yourself what part of the river you’re in.