Organizations that don’t understand their value stream typically don’t get overburdening either. Gas pipeline operators want to maximize throughput too, but they also know the physical constraints of their pipeline. Because the flow rate can’t be controlled absolutely, the line is operated under capacity, so that when there is a surge, the line doesn’t burst somewhere. The abstractions of software development make the consequences of operating over capacity less dramatic than a gas pipeline explosion, but the principles are the same.
Value Stream as Pipeline
Value stream is a phrase that has seeped into the business lexicon from Lean practice. It represents the intersection of two Lean principles, understand what creates value from the perspective of the customer and understand the process that creates that value. Sometimes when people say value stream, when they really mean business objective, which is more along the lines of a statement of goals or objectives. Value stream is something more, encompassing the process by which a series of objectives are realized.
To understand overburdening, we need to think of our value stream as a pipeline made of more than just the technical components, including:
The business processes that define objectives, budget resources and measure outcomes, including the strategic plan and product roadmap.
The development process, which includes work scheduling and related quality assurance practices. The card wall is the tip of the iceberg of the development process.
The delivery pipeline, comprising the tooling and protocols needed for a reliable release process, including well defined and rigorously practiced state transitions with comprehensive automated testing.
Determining operational limits results from a study of all of those components in relation.
A pipeline’s capacity is defined by the most constrained segment. When management of the components of the value stream are siloed, there is little appreciation of the constraints of downstream segments, and therefore no way to understand capacity. The inevitable result is that the amount of work put in motion exceeds capacity. How, when and where overburdening will manifest is unpredictable. While smoking embers rising from a postmortem are a reliable indicator, there are some other things we can look for:
Loss of focus due to task switching is an inevitable outcome of overburdening. Task switching always consumes time, and in technical work, interruptions to the continuity of thought can have a more significant cost than task switching for administrative tasks. If the sum of time lost to task switching were applied to work, then capacity would be that much greater.
Delays dues to blocked stories would be an expected outcome of overburdening. One story blocked by a delay in a dependent story can have an outsized effect on the delivery schedule. The criticality of monitoring queue time is often overlooked, and unfortunately, the delays are often attributed to other factors.
Defects passed on due to insufficient review is another likely outcome of overburdening. Time spent on bugs returned for rework is typically more than the time that would have been needed to get it right in the first place. When team members are working too many simultaneous tasks, skimming code reviews and skipped verifications is likely unavoidable.
Low quality means high cost and loss of competitive position
— W. Edwards Deming
There are many other manifestations of overburdening. We can’t remedy a problem we don’t fully understand, so we need to classify and describe our observations so we can provide more context when we evaluate options for remediation. Retrospectives that have reliable information about the nature of our process bugs yield the best suggestions.
Before we can hope to be in control of our delivery process, we need to understand the capacity limits of team and tooling. When the bottlenecks of our value stream are evident, it is a easier to decide on which improvements to technical practices would increase capacity without splitting a seam. Pipeline operators know the principle well that operating over capacity does not yield higher throughput.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.