Agility does not scale around the budget. Whoever releases eight figures needs a statement of work. And that is exactly what contradicts what „agile“ promises.
I once resolved the contradiction in practice, in a large program. Only after a sponsor who micromanaged out of fear and political cover had cleared the field could we move into a mixed design. The rough plan stood: when design, when build, when test. But design and build ran in part-agile cycles. Feature by feature, module by module was estimated, discussed, aligned, built, checked, refined. That costs more resources on all sides, in the project team, in the business units, externally. But it can be focused well on the critical areas and pays off at acceptance: no surprises.
Where „we’ll do it agile“ breaks
Whoever sets up a large agile framework at eight-figure sums ends up cutting the monolith back into small, non-agile pieces. It is budgeted, planned, aligned and approved, and only beneath that, at the smallest level, is development done agilely. There is hardly another way, because the core idea of the agile manifesto aims at exactly this execution level. The principle „we involve the customer from the start and re-steer completely if we must“ is important and right. But it prevents what a corporation needs for the sensible use of its means: predictability.
What I advise a board
First I let the air out of the buzzword. „Agile“ sounds nice, but it is not an end in itself. Then I explain that agile delivery in a large corporate project without a stable steering frame quickly fails at budget, dependency and decision boundaries. So it is always an and, never an or. Control over the sum and agile execution do not exclude each other, as long as you know at which level the one applies and at which the other.
When a board wants to control the sum and still work agilely, the honest answer is no either-or: the rough frame is planned and approved, agile comes only beneath it, feature by feature. Whoever reverses that trades predictability for a buzzword.
