The Bronze Age: Waterfall and the Iron Triangle

Once upon a time, there was Waterfall. Everybody hated it, the management, in particular, because the company-supplier was the sole responsible for unreliable estimates and any delay was impacting the profitability. Full stop. It was the iron triangle, and no one ever dared to question it: if you commit to a particular scope and you want to grant the right level of quality, any imprecision in the estimate is going to translate directly into a deviation of either cost or time (or both).

Iron Triangle

The Silver Age: Agile

Then it came Agile and the promise of a new world where supplier and client shared the responsibility for the delivery. It sounded more engaging to the developers, less risky to the management than the traditional model. Except, clients would not buy it. It is of course too risky for them, and since most of the people selling Agile do not have a proper knowledge of Agile, they cannot properly steer or educate clients.

The sales guys then start shuffling cards, writing and rewriting contracts still they end up agreeing on fixed-price, fixed-scope (maybe even fixed deadline) projects. The perfect recipe for a death-march.

If we are talking about Agile, that is just not Agile. How can the team commit on a Sprint if somebody else already committed to delivering the whole backlog by a particular date? How could the project manager not focus on 100% utilisation when he knows that the team should burn the effort sold by the “agreed” deadline? Why do you even bother prioritising if the MVP is the whole backlog?

Whatever the methodology, a fixed-scope / fixed-price project is very likely to end up delivering a very low-quality product (or kill the profitability – if that is even an option). Moreover, somebody will call it an Agile failure.

Nobody is against a valid fixed-scope contract, as long as we call it with its name: Time & Materials.

The Golden Age: Agile (working Agile for real)

If you want to succeed with Agile, embrace it at the company level, not only at delivery level, and consider all its principles, not just a subset of them.

A few extra pieces of advice:

  1. Educate your clients to the (many) advantages and the (few) drawbacks of Agile.
  2. Rephrase your contracts to make crystal clear that you are not committing on delivering a precise scope but the best possible set of features for the releases they have in mind.
  3. The first two sprints are just enough to understand team’s velocity and specific project dynamics, and thus the release plan should not be considered reliable before the end of the second sprint.

Note: Agile works with a different triangle

Agile theorists just refuse to apply the iron triangle to Agile: the whole idea of prioritising the scope over the business value sounds incompatible with the Agile principles by definition. The Agile Triangle projects value, quality and project constraints instead:

Agile Triangle

Honestly, this is already two steps further. Just start with baby steps!

 

Share This