Agile Fundamentals

Agile Is Not What You Think It Is

24 Mar 2026·8 min read
Agile Is Not What You Think It Is

I've spent the best part of a decade coaching teams across pharmaceuticals, finance, education, and the public sector. In that time, I've heard agile described as many things. "Do more with less." "Deliver faster." "We need a Scrum to fix this." "No more documentation." "Just get on with it."

None of that is what agile means. And the gap between what people think agile is and what it actually is explains most of the failures I've seen.

The Three Misconceptions That Cost You the Most

"Agile Means Scrum"

This is the most common one. A manager decides the team needs to be agile. Someone books a two-day Scrum training course. The team starts doing Sprints, stand-ups, and retrospectives. They call themselves agile.

Six months later, nothing has meaningfully changed. The team is doing Scrum events but still being told what to build, when to build it, and how long it should take. The stand-up is a status report to the manager. The retrospective produces action items that nobody follows up on. The Sprint Review is a demo that stakeholders don't attend.

This is not agile. This is legacy project management wearing a Scrum costume.

Scrum is one framework among many. It's a good starting point for teams building complex products who need a structured cadence. But using Scrum doesn't make you agile, any more than owning a piano makes you a musician. Agile is a mindset. Scrum is one way to practise it. There are others: Kanban, DSDM, XP, and increasingly, no named framework at all. The framework is the vehicle. The mindset is the driver.

For more on choosing the right framework, see Part 2: Choosing the Right Approach in 2026.

"Agile Means Faster"

Agile does not mean faster. It means sooner. There's a difference.

A legacy approach tries to deliver everything at the end. An agile approach delivers the most valuable things first, in small increments, so you can learn from each one. The total time to deliver everything might be the same. But the time to deliver something useful is dramatically shorter.

This distinction matters because when managers hear "agile means faster," they expect the same scope delivered in less time. That's not the deal. The deal is: we'll deliver the most important 20% first, get it into your hands, learn from the feedback, and then decide together what to do next. The Pareto Principle usually applies: the top 20% of requirements deliver 80% of the value.

If things take longer or there are unforeseen difficulties, lower priority work drops off. This is not a failure. It is a deliberate trade-off to protect what matters most. The moment I explain this to a senior stakeholder and they genuinely accept it is usually the moment agile starts working in that organisation. Until then, it's theatre.

"Agile Means No Planning"

This one makes me wince. Agile teams plan constantly. They just plan differently.

Legacy planning tries to define the entire journey upfront: every requirement, every task, every milestone, locked in before work begins. Agile planning defines the destination and the first few steps clearly, then replans as new information emerges. The further out you look, the less detailed the plan becomes, because the further out you look, the less you actually know.

Think of it like the difference between a GPS route and a paper map. The paper map shows you the whole route before you start. The GPS shows you the next turn and recalculates when conditions change. Both are planning. One adapts to reality. The other hopes reality cooperates.

Agile teams plan at multiple levels: a product vision and roadmap at the strategic level, a prioritised backlog at the coordination level, and detailed Sprint or iteration plans at the team level. If anything, agile teams do more planning than legacy teams. They just do it in shorter cycles, more frequently, and based on evidence rather than assumptions.

What Agile Actually Is

Strip away the frameworks, the jargon, and the certifications, and agile comes down to five things. None of them are new. None of them require a framework. All of them are harder than they sound.

Solving Real Problems for Real People

All agile approaches are customer-centric. The team's job is to understand a real problem and find a solution that delivers real value. If the team doesn't understand the real problem, it doesn't matter how fast they deliver or how many Sprints they run. They'll build the wrong thing efficiently.

This sounds obvious. In practice, it's rare. Most teams I coach start by building what they've been told to build, not by asking whether it's the right thing to build. The shift from "deliver the specification" to "solve the problem" is one of the hardest and most valuable changes an agile team can make.

Trusting the Team

The people doing the work are best placed to decide how to do it. Agile teams are cross-functional, with all the skills needed to deliver the product. They pull work rather than having it assigned. They organise themselves rather than being managed in detail.

This is where most organisations hit a wall. Middle managers feel threatened. Senior leaders worry about losing control. The instinct is to add oversight, approvals, and status reports, which is exactly the opposite of what agile needs.

I'll be direct: if your organisation is not willing to trust teams with meaningful autonomy, agile will not work. You can do the events, use the tools, and hire the Scrum Masters, but without trust, it's just process.

Delivering in Small Steps

Value is delivered in small, frequent increments rather than one large release at the end. Each increment is usable. Each one generates feedback. Each one reduces risk.

Some teams deliver every two weeks. Some deliver continuously, multiple times a day. The cadence matters less than the principle: get something real into the hands of real users as early as possible, and learn from what happens.

Making Work Visible

Agile teams make their work, their progress, and their problems visible to everyone. Kanban boards, Sprint Reviews, burn-down charts, product backlogs. These are not bureaucratic overhead. They are transparency tools that enable honest conversations about what's happening and what needs to change.

Transparency requires psychological safety. If making a problem visible leads to blame, people will hide problems. If it leads to support and problem-solving, people will surface them early. The culture around the tools matters more than the tools themselves.

Learning and Improving Continuously

Periodically, the team reflects on how they're working and makes small adjustments. This is the retrospective, and it's the most underrated practice in agile.

The compound effect of consistent small improvements is enormous. A team that makes one small improvement every two weeks has made 26 improvements in a year. After two years, they're unrecognisable from where they started. But only if the improvements actually happen. The retrospective where action items go on a list and are never mentioned again is worse than no retrospective at all, because it teaches the team that their input doesn't matter.

Why This Matters More in 2026

The fundamentals above haven't changed since the Agile Manifesto was written in 2001. What's changed is the stakes.

AI tools have made it possible for small teams to build things at extraordinary speed. Code generation, automated testing, AI-assisted analysis. The build step of any delivery cycle has been dramatically compressed. A three-person team can now produce what used to require a full department.

This makes every other agile principle more important, not less. If you can build faster, the cost of building the wrong thing is lower in time but higher in opportunity. You waste less calendar time but you still waste the chance to build the right thing. Short feedback loops, customer focus, and the discipline to measure what actually works are the difference between using AI to move fast in the right direction and using AI to move fast in the wrong one.

Teams that apply agile thinking to how they adopt AI will get more value from it than teams that either resist it entirely or accept its output without question. Inspect and adapt. It's been the answer for twenty-five years. It's still the answer.

What I've Actually Seen Work

After years of coaching, here's what I believe.

Agile works when leadership genuinely trusts teams. Not trusts them to follow a process, but trusts them to make good decisions about how to solve problems.

Agile works when the team is allowed to say "no" or "not yet." If every request from a stakeholder is treated as mandatory, there's no prioritisation, just a queue.

Agile works when failure is treated as information. The retrospective where someone admits "that didn't work" and the team adjusts is worth more than a hundred successful Sprints where nobody learned anything.

Agile fails when it's imposed without explanation. When teams are told to "be agile" but not why. When the framework is adopted but the culture doesn't change. When managers interpret agile as permission to ask for more, faster, with fewer people.

The framework is never the problem and never the solution. The thinking is.

Next in this series: Choosing the Right Agile Approach in 2026 - a practical guide to Scrum, Kanban, DSDM, SAFe, and working without a framework.

Related reading:

Alun Davies-Baker is an agile coach, trainer, and the founder of Altogether Agile. He has spent a decade helping organisations across pharmaceuticals, finance, education, and the public sector navigate complexity using empirical approaches grounded in Business Agility.