But we’re already doing…agile
Lots of people think this, but aren’t seeing results because they’re not delivering increments of learning and value through regular, small iterative cycles.
They might look like a flavour of agile: daily stand-ups, a kanban board, Jira, retros, a roadmap and regular complaints that management is waterfall. But they’re not shipping regularly. And whether the unit of value is learning through experiments with real users, changes to non-digital parts of the service, or actual usable code — an agile team is not agile if it isn’t shipping regularly.
I mean in days. Or weeks. Or fortnights.
So what do teams actually need to get there — especially when looking through the lens of a test and learn approach?
First, they need exposure to what actual agile ways of working look like up close. It’s so much more than the ceremonies and lingo - and it takes effort to get it working well and keep it so - so even those teams who have seen what good looks like need psychological safety to push for it, and retros deep enough to draw out such meta concerns and fix root causes rather than just surface irritations.
They need commercial models that support iterative delivery. Some Government departments lack the knowledge, skills or confidence to buy anything digital without extremely detailed specifications and high costs of change — so all the requirements get articulated upfront (i.e. made up in advance of any real assumptions testing) - and so are trapped in a model they can’t escape. "Working software over comprehensive documentation" comes a cropper when you can't commission a supplier without a traditional procurement spec listing everything including the kitchen sink. Teams need commissioning approaches that allow requirements to evolve as they learn.
Teams need user stories that are conversations, not requirements. When stories are just requirements handed over, the people building the service lose the connection to why they're building it, and much of what they need to judge whether it'll actually work. A team that can evolve what they're building as they learn is agile, because responsiveness to change is the heart of these ways of working. Without that, you end up delivering in high-frequency waterfall — planning in two-week chunks but not iterating based on feedback, metrics or observed impact. Not continuous improvement.
Orgnisations need leaders who protect space for learning and course-correction. When a politician or leader announces a deadline, teams end up with a "roadmap" that's actually just a Gantt chart working backwards from a publicly committed launch date. As the stakes rise, leaders retreat to their comfort zone: shoehorning work into traditional waterfall programme management, demanding detailed (largely fictional) business cases upfront, monitoring progress against pre-specified delivery plans (milestones and deliverables, not progress towards strategic outcomes). Teams need leaders who give them space to pivot, to learn, or to prove something unnecessary and just stop — not just deliver what was committed.
And they need governance and infrastructure designed for small, low-risk, easily reversed releases and continuous delivery. Not stage-gated processes designed for big scary releases. Without that, you get Wagile teams, not agile: you’re destroying hard-won momentum if shipping means no automated testing, 14 approvals and 4 change boards before anyone can hit go.
By the way those delivery deadlines — even the public ones — are never truly immoveable. There's always an option to push back or remove entirely; usually it's just a question of whether leaders are willing to pay the reputational cost. I've a lot of respect for those who decided to reset the entire programme, or rolled over an incumbent contract for a year to buy time to truly understand what they needed. Far more common is getting spooked by a contract expiry you somehow didn't see coming, and replacing it with another rushed waterfall enterprise platform procurement — probably with remarkably similar requirements to the current one, favouring the incumbent. One possible explanation for how Fujitsu and Oracle keep winning contracts. So departments need less last-minute desperation and better commercial pipeline management to give teams get the space to explore and deepen their understanding of user and business needs which ultimately leads to better buying and better building.
What else? They need the skills to slice big things small. Teams need to know how to break the big thing — a CRM, a whole service — into smaller increments of value. They need to be able to imagine narrow-but-still-useful elements that could ship early and deliver value early. Without this, teams end up not expecting to deliver a working service, or any part of one, for months or years. They'll still claim they're being agile, though.
They need their focus to be protected. Agile teams build momentum by limiting work in progress — we know it boosts quality, productivity and speed when teams stop working on everything simultaneously. So teams need leaders who won't split members across multiple projects, who won't pile a day job on top of team work. They need leaders who actually prioritise rather than keep adding to the backlog and pulling focus before tasks are complete.
Teams and their leaders also need to be comfortable delivering imperfectly. The price of momentum and pace means getting some things wrong —it’s impossible to get everything right first time - so leaders need to be willing to accruing debt they’ll need to address. Teams need to trust they'll be allowed to iterate once something ships, and that money will be available to pay down debt rather than fund the next shiny thing. They need the psychological safety and emotional regulation to cope with imperfection and failure — because if they wait for perfect designs, nothing will ever get delivered. Teams also need confidence in their ability to put things right — continuous improvement is a feature, not a bug. Mistakes and missteps are inevitable - those pragmatic leaders willing to moving forward with incomplete, imperfect plans will be delivering and continuously improving anyway. And of course small bounded failure is a powerful, efficient way to learn quickly. The best leaders are searching for opportunities to tell stories of smart failure, not the ones trying to avoid it.
Agile is a mindset, sure — but it's a mindset that guides a way of working. It has to be more than a buzzword or an intention.
If you have the ways of working, set out above, in place and you’re still not getting results, let me know. I’d love to help you figure out why.