Most agile writing is written by and for people who already work somewhere agile. That was never my world. I earned PMP and PRINCE2 while running IT for holding companies and an investment firm owned by a bank — places where the board wanted a plan with dates on it, the audit function wanted a paper trail, and nobody was going to bless a team that promised to "figure out the scope as we go." Agile came later, once I'd added PMI-ACP and a Scrum certification. So I learned the empirical stuff standing inside the plan-driven stuff, and I think that's actually the more useful vantage point.

Because here's the uncomfortable truth: for most enterprises, "should we be agile or predictive?" was always the wrong question. The industry has finally caught up to it. The current professional consensus — and PMI's own default now — is that projects are hybrid until proven otherwise. The interesting work isn't picking a camp. It's knowing which parts of a delivery want structure and which parts want iteration, and not getting them mixed up.

1. The backwards order I learned it in

When you learn agile first, in a startup, it feels like the natural state of things and governance feels like something bureaucrats bolt on later to ruin your velocity. When you learn it the way I did — governance first, in an organisation with real regulatory weight — agile arrives as a set of tools you reach for when the plan-driven approach is clearly the wrong shape for a piece of work. That reframing matters. It stops you being an ideologue.

An investment firm's core banking integration is not a candidate for "let's just start and inspect-and-adapt." It has a fixed regulatory deadline, external dependencies you can't reschedule, and a failure mode measured in fines. But the internal portal that firm's staff use every day? That absolutely wants iteration, because nobody — not me, not the sponsor, not the users — actually knew what it should be until they'd used a rough version of it. Same organisation, same year, two completely different delivery shapes. Pretending one method fits both is how projects die.

2. Why "going agile" fails in a governed organisation

I've watched more than one enthusiastic transformation crash into a conservative organisation, and the failure is almost never about the practices. It's about pretending the governance isn't there. A team declares itself agile, stops producing the documentation the audit function needs, drops the stage gates the board relies on to sleep at night — and then acts wounded when the organisation's immune system rejects them.

The mature version of agile, the one I see winning in 2026, is much less theatrical about it. It isn't trying to prove how agile it is. It preserves iterative learning inside the broader structure — the stage reviews, the budget controls, the portfolio checks — rather than treating those as enemies to be abolished. When governance walks into the room, a healthy team doesn't panic. That composure is the actual sign of maturity, far more than any velocity chart.

In a governed organisation, you don't earn the right to iterate by refusing the paperwork. You earn it by proving you can iterate and produce the paperwork.

3. The hybrid that actually works

My default structure, refined over a lot of projects, is simple to describe and harder to hold your nerve on. The spine is predictive: a real business case, defined stages, a phase gate where someone with authority decides whether the project should still exist. Inside each stage, the muscle is iterative: short cycles, working increments, genuine feedback loops with the people who'll use the thing. The gates protect the organisation's money and reputation. The iterations protect the product's quality and relevance. Neither is negotiable, and they don't actually conflict once you stop treating them as rival religions.

PRINCE2 people will recognise this immediately — it's very close to managing by stages with an agile delivery approach inside the stage, which is more or less what PRINCE2 Agile was reaching for. PMP people will recognise it as the hybrid lifecycle the current framework assumes. The point is that both certifications, read generously, were pointing here all along.

4. Rituals to keep, rituals to drop

Not every agile ceremony survives contact with a conservative estate, and you should be honest about which ones you're keeping for value versus for show:

  • Keep the retrospective. It's the single most valuable agile practice and it threatens nobody. A team that honestly reviews its own work every couple of weeks improves faster than any process document can make it.
  • Keep the demo. Showing working software to real stakeholders on a cadence is worth ten status reports. It also quietly builds the trust you'll need at the next gate.
  • Adapt the stand-up. Daily works co-located; across a distributed or part-time team it often becomes a short written check-in. Don't be precious about the format.
  • Drop the theatre. Story points defended like scripture, velocity treated as a KPI, planning poker for its own sake — these earn eye-rolls from serious stakeholders and deserve them. Estimate, commit, deliver, review. That's the loop that matters.

5. Selling iteration to a board that wants a Gantt

The practical skill nobody certifies you in is translating iteration into a language a governed board trusts. When a director asks "when will it be done and what will it cost," answering "we'll inspect and adapt" is a good way to lose the room and the budget. What works is giving them the predictable frame they need — a fixed cadence, a fixed budget envelope, a fixed date for the next decision point — and being honest that the detailed scope inside that frame will evolve as we learn. Boards can live with evolving scope inside a fixed envelope. What they can't live with is open-ended everything.

I frame it as buying the organisation options. Each iteration produces something real, so at every gate the board has a genuine choice: continue, adjust, or stop with something usable already in hand. That's a far stronger position than a traditional project that only reveals whether it worked at the very end. Sold that way, iteration stops sounding like chaos and starts sounding like risk management — which, done properly, is exactly what it is.

6. What ACP and CSM really gave me

People sometimes ask why a plan-driven PM bothered with the agile certifications at all. The honest answer is that they weren't about learning a method — I could have read the manifesto in an afternoon. They were about spending enough structured time inside the empirical worldview that it stopped feeling like an absence of control and started feeling like a different, legitimate way of holding control. That shift is hard to make on your own when your whole career has trained you to plan first.

So I don't present myself as an agilist or a traditionalist. I hold both sets of credentials because real delivery has always demanded both, and the organisations I work in — the careful, audited, consequential ones — are exactly the places where getting the blend right matters most. If you're trying to introduce iteration somewhere that instinctively distrusts it, tell me the situation; I've probably stood where you're standing.