What the Agile manifesto got right that many still get wrong

The most common complaint I've heard over the years is that the Manifesto is too vague. However, I'd say that's the wrong way to look at it. We weren't trying to prescribe a way of working or a series of steps. We were trying to support a mindset or a framing of how we tackle problems. The structure of the Manifesto isn't "do this". It's "do this over doing that." This displays humility in that you need to think about your context.

As a quick reminder, at the heart of the Manifesto is:

Now, I'm a process and tool nut. I sold tools and mentored teams on software processes for a living. But only in the right places. Context is always crucial. The Manifesto doesn't say throw your processes away. It says: when you're forced to choose, here's where the emphasis should fall.

Some people read "working software over comprehensive documentation" and decided it meant they didn't need to document anything anymore. That's not what it says. Creating excessive documentation without any working software is what I was fighting against in my Department of Defence contracting days. But if you need some documentation, you need documentation.

Don't use the Manifesto as an excuse to do the wrong thing.

Use the Manifesto as a sounding board to ask whether you are doing the best you can at any point in time.

The reason it had to stay abstract is that the work it's talking about isn't simple. The more the challenge you're facing creeps from complicated to complex - where it's ambiguous, uncertain, you can't plan it, you don't know everything - that's exactly when you need a mindset, not a prescriptive method.

Sticking to a prescribed process or some 'best practice' handed down from someone who doesn't know the specifics of what you're working on and who isn't facing the challenge alongside you is a mistake. It's precisely the problem we were trying to solve as "lightweight" practitioners.

The hard truth is: if your mind can hold competing perspectives in the face of uncertainty, if you approach software development with humility, then the Manifesto probably resonates with you. However, if you need someone to hand you step-by-step directions laid out in a beautiful website with lots of graphics and certifications, it might not seem all that useful.

When we were debating the Manifesto, I remember Martin Fowler handing out index cards. We'd each write a word on a card, toss it in the middle, and the group would start talking about it. The word I put on mine was something like 'honesty'. Why? Because that's what the heavyweight processes were asking you to give up, in my humble opinion. They gave you the illusion of control: detailed schedules, exhaustive plans, the false certainty that you knew exactly what you'd be delivering in 12 months' time (or longer).

Early in my career, I'd spent years watching the illusion of control fall apart in practice, especially in research and development work, where the whole point is that you don't know yet. The more complex the problem, the less likely your plan and all that upfront documentation would be correct. The honest thing to do is to stop pretending otherwise.

One of the mantras we had back then was "frequent tangible working results." That's working software, bullet number two. Not a document that describes what the software will eventually do. The thing itself, working, in front of the customer, so you can find out what you need to change. That's not just good practice; it's honesty about the nature of the work.

I'll be straight with you: I checked out of the part of the agile industry that turned into a certification mill. Get this certification, and you're now anointed. That leaked into hiring practices as a gatekeeper. Follow this process, and congratulations, you're capital-A-Agile. For me, that just leads to 'buyer beware'.

The irony is obvious, or it should be. We wrote the Manifesto specifically to push back against top-down processes defined by people far removed from the actual work. Within a decade, the Agile industry had built exactly that structure, just with different branding. The 800-pound gorilla had a new name.

But I don't think that's the Manifesto's fault. The document is still as clean as it was in 2001. At the tenth anniversary, the twentieth, and now the twenty-fifth, people ask: Would you change anything? And honestly, the answer is "no." It captures the essence of how teams can come together to deliver value to their stakeholders. It's abstract enough to hold competing perspectives - which is precisely what complex work demands of you - and specific enough that people who were already thinking this way recognised it immediately. It hit a resonant frequency.

It is a remarkable, timeless, and almost miraculous document.

People who couldn't put their frustration into words suddenly had the ammunition to say: Yes! This thing I've been feeling is real, and here's why I should stick to my guns.

Here's what I think people still get wrong: they think the Manifesto only applies to software development. Though that was the original framing and purpose (it's in the preamble), it doesn't have to be limited - if you can open your mind.

Erase "software" and replace it with something else. It's still likely applicable. The four values are about how people collaborate to create things when the outcome is uncertain. That's not a problem unique to software. It's a mindset for navigating complexity, wherever you find it.

I came to all of this from the aerospace and defence industry. I worked on flight simulation to research enhanced fighter manoeuvrability (X-31). If there's a more literal definition of agility than a fighter aircraft's ability to bring its weapons to bear faster than its adversary, I don't know what it is. The lesson from that work was the same lesson as the Manifesto: the small, nimble, adaptive approach beats the big, lumbering, plan-everything-in-advance approach. Not always. But more often than people think, and especially when the problem is genuinely hard and complex.

I stopped worrying about the certification industry a long time ago. What I do is go out and work with teams. I practise working in an agile manner to achieve business results and make customers happy. That's what I was doing before February 2001, and it's what I'm still doing now. The Manifesto didn't tell me how to do that. It gave me (and a lot of other people) the words, permission, and shared mindset to keep doing it. Sometimes, that's all you need.