{"id":21208,"date":"2018-11-09T08:00:07","date_gmt":"2018-11-09T14:00:07","guid":{"rendered":"https:\/\/blog.planview.com\/what-flows-through-a-software-value-stream\/"},"modified":"2018-11-09T08:00:07","modified_gmt":"2018-11-09T14:00:07","slug":"what-flows-through-a-software-value-stream","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/what-flows-through-a-software-value-stream\/","title":{"rendered":"Project to Product: What Flows Through a Software Value Stream?"},"content":{"rendered":"
\n
\"Project<\/div>\n<\/figure>\n

Throughout this Project to Product series<\/span> I’ve explored how we need to bring the same rigor to architecting our software delivery value streams as what we’re witnessing in advanced manufacturing plants. Once we agree on what flows, we can analyze those flows to identify bottlenecks and opportunities to remove them. However, every time I’ve asked an executive-level IT leader where his or her bottleneck is, I’ve received either a blank stare or a vague answer, from otherwise extremely capable people.<\/span><\/p>\n

To look for a bottleneck in a production system, we must first understand what flows through that system. We’ve seen many measures of software delivery<\/a> flow proposed and analyzed, including lines of code (LOC), function points, work items, story points, deployments, and releases.<\/span>1 <\/sup>Each captures a notion of value flow from a different perspective, but each has its limitations, especially when you consider the end-to-end flow of business value through a delivery pipeline. If my experience talking to IT leaders is a guide, from a business perspective, we simply don’t have enough consensus on this core question of what flows through a software value stream. Yet this should be the most fundamental question to answer if we are to apply lean principles to software delivery.<\/span><\/p>\n

That lack of agreement means that the vast majority of enterprise IT organizations don’t have a well-defined productivity measure for what flows through their software production process. Contrast that with the automotive industry, where the number of cars produced is a clear measure of automotive value streams. Another measure is <\/span>lifecycle profits<\/span><\/i>, which Donald Reinertsen proposed in his seminal book <\/span>The Principles of Product Development Flow<\/span><\/i>.<\/span>2<\/sup> Reinertsen warned of proxy metrics for value and productivity. Measures such as LOC and the number of deployments per day fall into that category because they’re proxies for value delivered to the software consumer, not direct representations of that value. For example, a one-line code change could deliver as much value as a 1,000-line code change. But without a clear agreement on what’s flowing and what the units of production are, we’re far from delivering on anything like the lifecycle profits measurement that Reinertsen suggested.<\/span><\/p>\n

Business leaders know productivity when they see it—for example, through products that drive market adoption or revenue results faster than others. But correlating development activities to those results has been more of an opaque art than a disciplined activity. To define productivity in a value stream, and where the DevOps bottleneck<\/a> lies, we must first define what flows.<\/span><\/p>\n

\n
\n

Table of Contents<\/p>\nToggle<\/span><\/path><\/svg><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n