Agile + postponing decisions

Published: 25.7.2019
Categories: Delivery
Reading time: 2 min
People sitting around table having a meeting.

Most companies seem to offer agile development at least on some level. Most customers say that they have at least some experience with Agile. However many suppliers are using agile mostly as a sales pitch without really understanding it and many customers still insist on “fixed everything” contracts (fixed scope, price, schedule).

Instead of trying to cover all aspects of why agile is so great I will just concentrate on a single one: Postponing decisions to the last responsible moment.

At the beginning of a project, we know as little about it as we ever will

Vice versa at the end of a project we know as much as we ever will (during the project). Do you want to make important business decisions with a minimum or maximum amount of knowledge at your disposal?

Naturally, it’s impossible to decide everything at the end of the project. It’s wise to postpone them to the last responsible moment. Responsible here means a point after which not making a decision will start causing problems to the project. Some times it can be worse not to decide than to make a bad decision. We can learn from bad decisions and fix the problem, but indecision can just stop everything including the learning.

In traditional project models, we start by doing the most important decisions at the very beginning of the project. The same is true for “agile” projects with fixed everything contracts.

This means writing a detailed requirements definition that has to be met before the project is done. This means that we will do the most important project decisions even before we have started the project. Many trivial details are left for the initial design phase, but most major things are already listed as an appendix of the project contract.

This also means that we don’t really have any reason or even opportunity for learning during the project. In real life, we will of course always learn things during the project, but applying them in a meaningful way would mean changes to the project contract. Even if the supplier would like to add something in order to make the end result better there is still the worry of completing all requirements listed in the original contract.

In agile, we don’t fix the scope of the project in the beginning

While this requires a lot more trust between the customer and the supplier it definitely means better results as well. Agile means higher risk of not meeting the initial scope of the project but much lower risk of not meeting the goals for the project.

When doing an agile web development project with Drupal we can actually see a partially completed web site, use it, learn from it and do decisions based it what we have learned. This often leads to major changes to our original plans, and to much better end results.

Even if there were no additional benefits to agile this would be big enough reason on its own to use agile instead of traditional “design first” methods.

Related content