Agile in a Waterfall Culture Is a Trust Problem First

The first time I suggested a retrospective to a team that had never run one, I learned something no Agile course had taught me. The objection was not to me, and it was not really to retros. It was a whole way of working telling me, politely, that this looked like ceremony for its own sake.

That happened on one of the high-visibility priority projects, where I was Senior Product Owner. The aim was to give NSW real-time visibility of housing development, tracking residential construction from planning approval through to occupation. Data was fragmented across departments, and councils, utilities and emergency services were working from incomplete information.

The delivery setting was about as far from a startup as you can get: three organisations (2- government departments and one overseas digitisation private partner), legacy systems, heavy regulation and a team based in Bathurst with a long history of waterfall delivery.

Why the textbook version failed

I started by introducing Agile the way it is usually taught, and it caused real friction. Consultative backlogs and regular ceremonies assume people already see value in them. A team used to top-down, project-based delivery reasonably asks what problem these meetings solve.

It is tempting to label that resistance and push harder. I think that is a mistake. When a whole culture resists, the resistance is information. People are telling you the method does not yet make sense in their world.

What worked instead

We kept the intent of Agile and changed its shape. Planning became outcome-based:

• Set a small number of high-level sprint goals.
• Name an owner for each goal at planning.
• Have that owner show progress at the demo.

Nothing about that needs Agile vocabulary. Clear goals, named ownership and a visible result are ideas any delivery team recognises. It landed far better than the full ritual set had.

Trust also needed time and presence. I worked remotely with the Bathurst team and travelled when it mattered, because some relationships are hard to build through a screen. I also set up product guilds from scratch, which gave three organisations a place to surface shared problems and map the dependencies between them.

Protecting the question

Regulated environments have a strong pull towards solutions. A requirement arrives, a deadline follows and everyone wants to start building. So we ran a Double Diamond process end to end, going broad across stakeholders, workflows and pain points before narrowing down.

That paid off. Expression of interest research across 13 councils confirmed that manual checks and moving between systems were the biggest source of delay, and that reducing assessment time was what councils cared about most. We baselined development application assessment at an average of two hours, at around 30 assessments a month, so future improvement could be measured rather than claimed.

The same discipline shaped smaller decisions. We built an accessibility-first symbology framework aligned to NSW accessibility guidelines, so one dashboard could serve planners, ministers and the public. We also ran Dual-Track Agile, with Scrum for product development and Kanban for BAU support, and used BAU trends to feed the backlog.

What came of it

More than 16 councils and two utility providers were engaged and onboarded, with a roadmap to scale to more than 50 councils after UAT. Live co-digitisation with our overseas digitisation partner produced a 50% uplift in QA and digitisation efficiency. The team also won an Excellence in Collaboration Award for aligning business and technical teams across agencies.

I value that award because collaboration was the hard part, and no framework did it for us.

If you are in the same position

• Translate before you introduce. Ask what each practice is for, then find the form your team already understands.
• Treat resistance as data. Find out what it is protecting before you try to remove it.
• Start with ownership and visible results. Rituals can follow once people have seen the benefit.
• Show up in person when you can. Trust moves faster across a table.
• Hold the problem open. In a regulated setting, a product manager's real value is keeping "what problem, for whom?" alive long enough to stop people jumping to a solution.

Process purity is not the goal. A team that delivers the right thing using words it recognises is doing better Agile than one that holds every ceremony and believes in none of them.