You don’t need a dedicated “AI team” that does all of the AI work. You need clarity about how AI fits into the value your teams deliver, and who’s responsible for making that value real, reliable, and resilient. Otherwise, even the most promising experiments will fade into the background, another initiative lost to structural ambiguity.

The most effective AI work doesn’t start with flashy ideas. It starts with a clear, painful need, and ends with a quietly powerful improvement. These projects may not get the loudest applause at first. But they’re the ones that stick, scale, and strengthen trust. Tech-first thinking starts with a hammer. People-first thinking starts with purpose. If you want to use AI well, don’t just ask what the model can do. Ask what people need, where the flow is broken, and what capabilities are holding them back.

AI is fast at a lot of things, but in most organizations, the system around it isn’t. That’s the real risk I see. Not that AI will fail, but that it will succeed just enough, in the wrong places, for the wrong reasons, and with little ability to scale or sustain. When teams don’t understand where the current friction or tension in the system really lies, AI will become an accelerant of those dysfunctions; it won't solve them.

AI can amplify human capability, streamline operations, and uncover insights we could never see before. But there is a problem playing out in boardrooms and backlog review sessions across the world: Organizations are reaching for AI without fixing the foundations that make it effective.

The result? Fragmented pilots. Shadow tools. Confused ownership. Duplication. More noise, not more value.

Agile has helped teams adopt better ways of working. We plan more collaboratively, reflect more frequently, and adapt more easily. But across many organisations, the same underlying question keeps surfacing:

“Why does delivery still feel so slow?”

This series has explored a few common answers to that question, not rooted in broken process, but in deeper structural and interactional frictions.

Agile gave us a better way to manage work. But many teams are still working within structures that were never designed for flow. Team boundaries are often shaped by legacy systems, old reporting lines, or the last big re-org. And while the way we deliver has evolved, the shape of the organisation often hasn’t. When that happens, friction persists, not because Agile isn’t working, but because the environment it’s working within isn’t supporting it.

As delivery scales, so does coordination. What begins as healthy collaboration across a few teams can quickly turn into a web of meetings, approvals, dependencies, and shared decisions. And before long, the organisation feels like it’s spending more time aligning around the work than actually doing it.

When delivery slows, the conversation often turns to team velocity, backlog prioritisation, or developer tooling. But in many organisations, the real constraint isn’t inside the product team, it’s upstream or alongside it. Platform teams, infrastructure teams, shared services. The groups meant to enable delivery quietly become the thing that holds it back. And not because they’re underperforming. Because they’re overwhelmed.

When delivery slows, it’s tempting to look at the backlog, the sprint, or the team. But often, the real issue sits between teams, where ownership is shared, fragmented, or unclear.

Many teams adopt Agile in the hope of moving faster. They introduce sprints and stand-ups, visualise the work, and improve discipline at the team level. The process brings rhythm, visibility, and a sense of progress. And yet, delivery is still slow. Work gets done, but the value takes too long to reach users. Dependencies multiply. Coordination becomes a constant effort. Every step forward seems to rely on waiting for someone else. "We're doing Agile", but are we really being agile?