AI doesn’t remove organisational constraints. It accelerates exposure to them.
I’ve seen this with Agile adoption before.
When Agile arrived in earnest, the promise was faster delivery, tighter feedback loops, smaller batches of work shipped more frequently. And to be fair, the delivery engine did get faster. Sprints ran. Stand-ups happened. Velocity metrics climbed.
What nobody anticipated was what faster delivery would surface underneath.
At ANZ, one of the wholesale development teams adopted Scrum to make their development work more productive. The sprints ran. The stories got written. The cadence held. And then the team hit the same wall, every cycle: the production team, the backend that actually implemented and released the code, was the bottleneck. You can’t release on a two-week cadence when the deployment pipeline is controlled by a separate team operating on a different rhythm entirely. Scrum didn’t create that constraint. It just made it impossible to ignore.
That’s the thing about faster feedback loops. They take the problems you’d been working around and drop them onto a schedule.
Governance bottlenecks that had been invisible suddenly became obvious, because the team was now waiting on approvals that used to take weeks, and the wait was now a sprint event. Procurement delays, executive indecision, fragmented ownership between teams, overloaded support functions, the kind of organisational friction that had always been quietly present, all of it became visible, quickly, repeatedly.
Agile didn’t create those problems. It exposed them. The delivery engine ran faster than the surrounding operating model could handle.
There’s a second version of this, and it’s less about the gap between teams than about a gap inside one team, a gap between the method and the work itself.
Back then, in the early years of Agile adoption in New Zealand, there weren’t many people who knew how to run it well. The training existed. The certifications existed. What didn’t exist yet was depth, people who’d been through a full end-to-end Scrum implementation enough times to know where it actually breaks.
So what happened, more than once, was someone attended a few days of certification training, came back with a freshly printed credential, and was treated, by the team and often by themselves, as the expert in the room. At ANZ, I watched this directly. Two staff were sent away for a five-day Scrum course, back at their desks the following Monday, expected to design how the team would work and then run it, as if five days in a classroom had given them everything a real implementation actually needed. They weren’t being dishonest about it. They simply hadn’t done it long enough yet to know what they didn’t know. It was an honest version of the blind leading the blind, well-meaning, certified, and still learning on the job in front of the people they were supposed to be guiding.
There’s a third version too, and it’s less about people than about fit, a gap between the method and the work itself.
Stats New Zealand’s technology function isn’t structured the way a bank’s is. At BNZ, BNZ Digital was purely a development outfit, building the future of online retail banking and parts of wholesale. Production issues were limited, and when they happened, they got folded into the backlog as a future release. One focus, one rhythm. The team ran a blend of Scrum and Kanban that worked because the work itself was singular: build things, ship things.
At Stats NZ, each technology team was both a development unit and a production support unit for its own applications, at the same time, every sprint. Development work fits Scrum naturally, you can estimate it, size it, accumulate story points toward a sprint goal. Production support doesn’t work that way. An outage doesn’t wait for the next sprint planning session, and you can’t put a story point estimate on “the census database fell over at 2am.”
So which method do you run? Scrum says commit to a sprint goal. Kanban says manage flow, work moves through states as it arrives, no fixed commitment. Both are legitimate. Neither one, on its own, matches a team that is doing both kinds of work simultaneously. What I saw at Stats NZ was teams trying to run Scrum and Kanban at the same time, in the same team, without anyone resolving which one governed which kind of work. That’s a fit problem. The method didn’t match what the team actually was.
We did try to fix it. A Kanban coach came in to help shift the technology operation toward something more workflow-based, more adaptive to the support side of the work. I’m not saying it solved the problem. What it did, immediately, was create tension between the people who had built their identity around Scrum and a coach whose entire philosophy ran in a different direction, workflow versus story points, two ways of seeing the work that don’t fully reconcile. Some teams adapted well. Others carried on reluctantly, doing what they were told without believing in it, which is its own kind of cost, quieter than resistance but not really different from it.
In the end, the team managers carried it. They were still accountable for what they’d promised the business and its customers, and that didn’t change just because the method underneath them did.
And there was a layer above all of this that nobody at the team level controlled. Around the same time, there was pressure from outside the organisation, government agencies signalling that SAFe was the direction Agile adoption should take across the public sector. Another flavour, another framework, arriving with its own philosophy and its own assumptions about what “good” looks like, and requiring dedicated leadership to steer it properly, leadership that was already stretched thin steering the first change.
Fixing a fit problem doesn’t happen in a vacuum. The fix creates its own friction, and external pressure arrives with its own opinion about what the fix should have been, usually without much interest in what’s already underway.
This is where AI is heading, and faster than Agile ever did.
AI increases analytical speed, automation, report generation, content production, decision support, all at once, across every kind of organisation, regardless of what that organisation is actually for. A bank building new digital products and a statistics agency keeping the national data infrastructure running will both get offered the same AI tools, the same vendor pitches, the same “transform your organisation” programme. Neither tool knows which kind of organisation it landed in. Neither does the implementation plan, usually, because nobody asked the question first.
And the same expertise gap that hollowed out early Agile rollouts is already showing up here. There isn’t enough deep AI experience to go around yet, the kind built from actually deploying these tools inside a real organisation and watching what breaks. What there’s no shortage of is the credentialed version, a course completed, a badge on a LinkedIn profile, a confident voice in a steering committee. None of that is dishonest. It’s just early, the same way Agile was early once, and the gap between the credential and the experience is exactly the gap that costs an organisation real money once the rollout actually starts.
And when an organisation does try to course-correct, bringing in an AI lead, an AI coach, a new framework, expect the same pattern. New tension between the people who’d built expertise around the old approach and whoever’s now steering the new one. Some teams adapting well, others complying without believing it. And somewhere above all of it, an industry body, a government directive, a board that read something in the Financial Times, arriving with an opinion about which AI framework or governance model the organisation should really be using, usually with no visibility into what’s already half-built underneath.
And AI, unlike Agile, has a bill attached to every experiment. If an organisation hasn’t worked out what it’s actually for, before it starts pointing AI at its problems, and before it layers a fix on top of a fix while external pressure adds a third opinion, it will spend heavily finding all of this out the hard way. At least a wasted Scrum sprint was just time. A wasted month of AI experimentation, run at scale across a team, shows up as a number someone in finance has to explain.
So before any AI rollout, the question worth asking goes deeper than “what is actually slowing us down,” though that matters too. What is this organisation actually for? Does the thing we’re about to deploy match that? And are we steering it ourselves, or about to hand the wheel to three parties at once?
Most organisations skip that question entirely. They go straight to the tooling.
I’d rather know what I’m building before I see the bill for it. Most organisations find out the other way round.