Today I’m finally going to elaborate on what I see as the challenges to incremental software delivery. A quick recap of how I got here:

Two weeks ago I said:

Of course [incremental software delivery] is not without its challenges. If it were easy, there’d be no need for people like me to help teams achieve fast, reliable software delivery.

Then I was asked to explain, but I deferred and asked you instead. Collectively, you had some great responses, and even challenged my thinking.

As I see it, the challenges to either incremental or iterative software delivery are vast. There’s no way I can provide a comprehensive list. But there are two high-level reasons that I think encompass most or all of the other reasons.

1. Incremental development goes against our modern mindset

   The industrial revolution taught us (as humans, particularly in the Western world) how to improve efficiency through large batches. It’s truly done wonders. But now that we’ve been equipped with this “hammer”, everything looks like a nail. We’ve taken this mindset to software development, where it really doesn’t fit. And it’s a hard habit to break.

   Examples:

   • Deploying incomplete features via feature flags contradicts the idea of big-batch efficiency
   • All flavors of small batches defy the idea of efficiency of scale (Trunk-Based Development, Continuous Integration, Continuous Delivery)

2. Incremental development is harder to control

   Incremental development (and to a greater degree, iterative development) doesn’t fit neatly into Gantt charts, or other deterministic planning models. This means that those managing such projects often feel they are losing control when they adopt an iterative/incremental approach. (Whether they’re actually losing control is another question–a strong case can be made that the sense of control is an illusion to begin with, but that’s for another discussion.)

   Examples:

   • The desire for manual testing
   • Traditional command-and-control structures often prefer Scatter/Gather approach over teamwork
   • Autonomous teams defy the concept of command-and-control