Fixing Slow Software Delivery

Factories are designed to execute the same operation repeatedly, achieving efficiency through standardization and predictability.

However, in software, copying is virtually free, making the initial act of creation and problem-solving the primary activity, not mass production. The core activity of software development is discovery, as engineers continually navigate uncertainty and innovate solutions.

This continuous process of exploration and problem-solving means that treating software engineering like a manufacturing line, where outputs are predictable and tasks are identical, inevitably leads to failure and inefficiency.

Organizations should shift their primary objective from increasing the speed of delivery to accelerating the speed of learning. Focusing solely on delivery speed often creates undue pressure on teams, leading to rushed work, increased errors, and ultimately, lower quality outputs.

Conversely, an emphasis on learning involves verifying development direction, correcting course as needed, and iterating rapidly based on new insights. When quality is prioritized, the need for rework significantly decreases, which inherently results in faster delivery as a valuable byproduct.

Research presented in the book "Accelerate" by Nicole Forsgren, Jez Humble, and Gene Kim empirically demonstrates that high-performing teams achieve both speed and stability. This extensive research disproves the common misconception that there is a trade-off between how fast software can be delivered and its inherent quality.

Instead, the data consistently shows that teams delivering the fastest also produce the most stable and highest-quality outputs. This indicates that speed and quality are not a zero-sum game, but rather characteristics that rise and fall together, reinforcing the idea that robust development practices lead to both.

To improve software development, it is essential to work experimentally, treating every meaningful change as a hypothesis. This approach means formulating a clear expectation, such as "I think this will do that," and then rigorously checking if the predicted outcome materializes.

Embracing the scientific method allows teams to navigate the inherent uncertainty of software development more effectively. Rather than simply working harder in pursuit of speed, this method encourages systematic testing and validation of ideas, ensuring progress is driven by verified learning.

Long feedback cycles significantly impede learning; for example, a three-month feedback cycle provides only four learning opportunities per year.

In contrast, a 20-minute feedback cycle can yield 20 learning opportunities in a single day, drastically accelerating knowledge acquisition. Tools like deployment pipelines and automated testing should therefore be viewed not merely as mechanisms for tidiness, but as crucial instruments for rapid learning and validation.

When only one thing is changed at a time, and something breaks, the cause of the breakage is immediately clear and identifiable.

Conversely, if a large quarterly release involves changing a hundred different things simultaneously, and then something breaks, it becomes nearly impossible to isolate the root cause, leading to minimal learning. Small steps are not merely about caution but about ensuring isolate-able feedback, as big batches inherently represent experiments with too many uncontrolled variables.

A committee glancing at a change it doesn't fully understand is likely to catch almost nothing, merely adding unnecessary waiting time to the development cycle.

Research from the "Accelerate" book unequivocally confirms that change approval boards perform worse than having no formal process at all, demonstrating their counterproductive nature. True control in software development should be integrated into fast, automated feedback loops, allowing for immediate validation and correction.

Measuring metrics such as utilization, velocity, or lines of output often encourages busy work rather than genuine progress. When teams are incentivized by these metrics, they tend to focus on appearing busy to hit targets, leading to wasted effort on tasks that don't contribute to the overall goal.

Instead, it is crucial to prioritize measuring the time it takes for an idea to reach the end user. Optimizing for the time to validate results ensures that efforts are directed towards meaningful outcomes, ultimately aligning the team's focus with the right goals.

The speed that organizations desire in software delivery is not something that can be directly commanded or demanded from employees. Instead, it is an emergent outcome that naturally arises when the learning system within the team is effectively optimized.

The best teams do not simply work harder; they focus on being exceptionally proficient at learning and adapting. This strategy involves shifting the core organizational question from "How do we deliver faster?" to "How do we learn faster?", allowing speed to be a consequence of efficient learning rather than a source of pressure for already tired employees.