Incremental software delivery makes deadlines (almost) meaningless

May 5, 2022
If you deliver value incrementally, you get scope cutting for free. With or without a deadline.

It happened again. Another question on one of the Slack groups I frequent: How do we estimate a project with a Q3 deadline?

If you believe as I do that software development is inherently unpredictable, the answer is simple, though often baffling: You don’t.

To be clear, I’m not saying it’s impossible to come up with some vague idea of how long a project will take. Instead I’m saying that it’s wasted effort to do so.

In this case, the project was going forward. It wasn’t a question of “should we do the project or not?” Rather, the most likely outcome if the project could not be achieved before the deadline would be to cut scope.

Here’s the wonderful thing about incremental software delivery: Scope cutting is just built in!

Here’s how it works. When you look at the outcome you’re aiming to achieve before the deadline:

  1. Select the single most important or impactful task that will move you toward that goal, and provide some value immediately.
  2. Do that task, and deliver it completely.
  3. Go to #1.

If you work in this way, always doing the most important task which delivers some value, then whenever the deadline arrives, whether it’s tomorrow or at the end of Q3, you’ll be guaranteed to have done the most impactful bits. The bits that weren’t done were the scope that was cut. And you didn’t waste any time at all estimating how long each task would take.

The funny thing is: This is exactly how incremental software delivery works without a deadline, as well.

The goal of incremental software delivery is to always be providing the most value possible right now. Which should almost always be the goal, with or without a deadline.

Share this

Related Content

My Agile Wedding

By focusing first on what we decided was most important, we were able to ensure a successful wedding, despite a few annoying surprises.

How to release 2 years of unfinished code, the "Agile way"

Unfinished code is like old parts in a warehouse.

So do you expect me to write a blank check?

If we don't know when a software project will be done, how do we know if it's worth the investment?