What Agile actually is — and what it isn't.

Agile is not a methodology. It is not Scrum. It is not Kanban. It is not SAFe. It is not your standup, your sprint, your retro, your Jira board, or the fact that your engineers self-organise. Agile is a one-page document, signed in February 2001 at a ski lodge in Snowbird, Utah, by seventeen software people who had spent the previous decade getting tired of the same arguments. Four values. Twelve principles. That is the entire artefact. Everything else, every framework, every certification, every consultancy practice billing two thousand pounds a day to roll it out, is downstream of, and frequently in tension with, that one page.

The reason this matters in 2026, twenty-five years on, is that almost every team I walk into describes itself as agile and means something completely different by it. Sometimes the team means "we do two-week sprints". Sometimes it means "we don't write requirements docs". Sometimes it means "we have a daily standup". Sometimes, and this is the dangerous one, it means "we don't really plan". None of those are agile. They might be downstream effects of an agile mindset, or they might be the ceremonies that get adopted while the underlying mindset gets quietly skipped. The shorthand has eaten the substance.

The four values, exactly as written.

The Agile Manifesto reads as four sentences, each of the form X over Y, followed by one critical clarifying line: that is, while there is value in the items on the right, we value the items on the left more. Most teams remember the left side and forget the right side ever existed. That's the first failure mode. The manifesto is not a rejection of process, tools, documentation, contracts, or plans. It is a re-ordering of priorities. Both sides matter. The left side matters more.

Read carefully, all four values are about one thing: shortening the distance between learning and acting. Individuals over processes, because conversations adapt and processes don't. Working software over docs, because shipped code reveals what specs hide. Customer collaboration over contracts, because real customers know things contracts can't anticipate. Responding to change over following a plan, because plans, by the time they're written, are already a description of the past.

The twelve principles — and the three that actually bite.

The four values come with twelve principles, and they're worth reading in full once a year. Most of them are obvious in 2026 ("build projects around motivated individuals", "deliver working software frequently", "welcome changing requirements") and have been absorbed into the water of modern software so completely that they no longer feel like a position. But three of them are still sharp, still contested, and still the principles that separate a genuinely agile team from a team running the ceremonies.

Short feedback loops. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Not "ship something every sprint". Ship something that works, that a customer could use, every sprint. The point of the short loop isn't the cadence, it's the learning. If your sprint output isn't usable by anyone, the loop hasn't closed.

The team owns the how. The best architectures, requirements, and designs emerge from self-organising teams. This is the principle that gets most quietly violated. A team is not self-organising if a manager assigns tickets, if a senior engineer pre-decides the shape of the work, or if a PM specifies acceptance criteria so tightly that the build is mechanical. The team needs to be allowed to figure out how. That means accepting that they might choose differently to how you would.

The plan responds to learning. Welcome changing requirements, even late in development. Every word of that sentence is load-bearing. Welcome, not tolerate. Changing requirements, not "scope creep". Even late, especially late, because that's when you've learned the most. This is the principle that puts teams at war with their finance function: how do you commit to a roadmap if the requirements can change? You don't. You commit to outcomes, and you let the requirements move underneath them.

Agile theatre: the four ceremonies that look agile.

Here is what I see in two out of three "agile" engagements:

• The standup as status report. Engineers list yesterday's tickets to a manager. Nobody asks for help, because asking for help in front of the boss is risky. The ritual is fifteen minutes of theatre that the team would rather skip. And they're right.
• The sprint as deadline. Scope set on day one, defended fanatically through day fourteen, delivery slipping into day fifteen because "we'll just push the demo back". The sprint has become a fixed-scope mini-waterfall. Nothing about that is agile.
• The retro as venting. Same complaints, sprint after sprint, none of them ever closed. The action items are theatre too. Nobody believes the retro will change anything, so nobody brings the things that would.
• The roadmap as immovable contract. "We're agile, but the Q3 deliverables are committed." Translation: we run the ceremonies, but the actual flexibility, the thing the manifesto is about, has been quietly removed at the executive layer.

If you recognise three of those four, you don't have an agile problem. You have a leadership-trust problem dressed up in agile ceremonies. The fix isn't a better Jira config. It's an honest conversation about what's actually allowed to change, and who's allowed to change it.

Where agile is the wrong answer.

The other failure mode is applying agile where it doesn't fit. The manifesto was written by software people for software people, and most of its principles assume four things: you can release frequently, the cost of changing your mind is low, the customer can give you feedback, and the work is genuinely uncertain. Strip away any of those and the model bends out of shape.

Hardware doesn't release frequently. Once a chip is fabricated, you've spent your budget. Regulated software (medical devices, payments, aviation) can release frequently in some senses but every release pays a compliance toll that makes weekly cadence brutal. True engineering work with known answers (bridge design, large-scale civil) is not uncertain in the way software is, and the agile cadence buys nothing. Single-deliverable fixed-contract work is the worst fit of all: the customer has bought a specified outcome at a fixed price, and "responding to change" is, contractually, scope creep.

None of which means those teams shouldn't borrow some agile practices: short loops, retrospective learning, working artefacts over heavy documentation are all generally useful. But declaring the whole team "agile" and standing up Scrum on top of it imports a set of assumptions that aren't true, and the team ends up performing the ceremonies while the actual work runs on a parallel, unspoken process. That's the worst of both worlds.

Frameworks aren't the same as the manifesto.

Scrum, Kanban, XP, SAFe, LeSS, Nexus, Disciplined Agile — none of these are agile. They are frameworks that, applied well, deliver agile outcomes. Applied badly, they deliver the ceremonies and skip the values. The framework is the scaffolding; the manifesto is the building you're trying to put up.

The most common mistake at the executive layer is choosing the framework before the values are agreed. "We're going to do SAFe" is a sentence I've heard more times than I'd like, usually with no prior conversation about whether the organisation is willing to honour the four values when they bite: short feedback loops costing predictability, self-organising teams costing centralised control, welcomed change costing fixed roadmaps. Pick the framework without the values and the framework will be hollow within six months.

How we use this at Product Pieces.

We engage agile-shaped, not Scrum-by-default. The diagnostic asks four questions: how short are your feedback loops, who owns the how, how welcome is mid-sprint change, and what does "done" actually mean. If those answers are healthy, we plug into the existing framework and contribute. If they're not, the right intervention isn't a fresh Jira instance. It's a conversation with leadership about what they're actually willing to honour. The framework follows the values. Not the other way round.

Next issue: Scrum. The framework most teams claim to run and almost none run as written. All issues →