Let’s say your team is given 3 months to complete a software project. Let’s say it’s a regulatory project, mandated by the government—a favorite example for those who favor traditional project management for software projects. How do you approach this?

Here are two possible approaches:

1. Make a list of requirements, plan who will work on each part, accounting for any cross-component dependencies, and ensure that everything will be ready to deploy before the deadline.

2. Determine the single most important thing you can do to move toward the project’s goal, then do that thing and deploy it. Repeat, until you reach the deadline.

Which approach has a higher chance of success?

Well, assuming that the project actually can be completed in 3 months, and there are no big surprises*, both approaches ought to have a reasonable chance of success.

But what if we don’t make those assumptions? What if the project simply can’t be completed in 3 months? Or what if we do have big surprises, like a sick teammate, or a weeks-long software outage?

In this case, when we reach the deadline, the situations look a bit different.

1. The project is not deployed. We pay a fine.

2. The most important 3-months worth of functionality have been deployed. We’ll likely pay a government fine for non-compliance, but it’s going to be a much smaller fine than if we hadn’t completed anything.

The iterative approach has the benefit of working for practically all projects, with or without a deadline. If you always do the most important thing at the moment, you’ll eventually do all the things anyway.

*Of course, we know there are always surprises.