Is the Manifesto still relevant in 2026?

This is part of a series exploring the Agile Manifesto at 25 years old. If you’ve not read the first post, “Is Agile iterative development?” then it might be good to start there.

In that post, I explored that the word “Agile” is often used in business out of context in ways that are different from – even contradictory to – the words of the original Manifesto.

Today, I’d like to talk about the Manifesto itself and whether its ideas are still relevant to software engineering in 2026, since a lot has changed in a quarter of a century.

What’s still the same

Some things in the Manifesto feel like universal constants, just as relevant now as they ever have been… and needing repeating now as much as they did in 2001.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This feels like the principle that is most important to get right, and the one I see most often missed by leadership in places I go. Creating an environment where everyone working is motivated, supported and trusted is really hard. I think often people believe that at “crunch time” this principle can go out of the window, but in my experience that’s the time when it’s needed the most.

It’s interesting to read this in the context of increased awareness of cybersecurity: one of the mantras of cybersecurity is “Zero Trust”. Finding the right balance between removing trust in order to protect people and increasing trust where it can help them produce better work is one of those balancing acts that requires a lot of attention from leadership.

Business people and developers must work together daily throughout the project.

Today we might call this “shifting left”: making sure that business decisions are made with all the relevant people in the room - having engineering and quality assurance teams present during requirements capture and design, but also the culture of “demos” or “playbacks” is necessary to ensure business people are also involved in engineering decisions.

The use of the word “daily” here is particularly notable because so often I see teams who only work together at ceremony time and otherwise stick to their silos.

The best architectures, requirements, and designs emerge from self-organizing teams.

“Self-organizing teams” comes almost at the end, directly before my favourite Principle Twelve. It’s a hard one to explain but it says that giving people the power to choose their own destiny is one way to ensure you end up with a high-quality product. There are lots of practical ways to do this: an example I’ve talked about before now is the Barf-Librarian technique.

And principles 8-10 can all be read in the context of technical debt. I’d like to do a separate post about technical debt some time, but the gist is that I work with the metaphor: sometimes you take on debt in order to fund a big push forward but then if you don’t devote time and energy to paying it off, you’ll be paying interest on it forever. As the Manifesto would say, by paying down your technical debt, you’re “maximizing the amount of work not done”.

What’s changed

But while much has stayed the same since the Manifesto was written, the world has also changed a lot in 25 years. Some big things that have come to mind are:

The “Cloud era”

When the Manifesto was written, most companies still had huge server rooms for storing and processing their data. For consumers, software was mostly something you bought or downloaded from the internet and installed onto your computer.

The way software was produced, sold and maintained was more like that of a manufactured product.

That way of thinking is almost unimaginable now. Today most hardware is rented from a handful of giant Cloud providers. “Software as a Service” was just beginning in 2001 for businesses, but today even most consumer software is also bought on licence (whether monetary or in kind).

The smartphone/social media era, beginning around 2007, consolidated a lot of the world’s software into the hands of a few tech giants, and this caused the rest of the industry to either join them by renting services from them, or to also sell their software online as a service. Browsers and handheld devices got more and more powerful to the point where they can easily do everything the general-purpose PCs of 2001 could do, and way more.

This has changed the way we think about the “customer collaboration” value, since we now have access to other ways of collaborating with our customers, through telemetry and user-generated content.

Open source

Open source was a big deal already in 2001, but it was on the fringes of the engineering world. Tech companies were aware of it but the current situation where Linux is the world’s most prolific operating system and some of the world’s most important software - such as Google Chrome - have open source components at their heart.

Despite open source’s prevalence in the world, most companies don’t think about its main power: that common problems can be solved together with other companies instead of people wasting energy solving problems behind closed doors.

Remote work & distributed teams

Of course there were distributed teams in 2001, but this landscape has changed dramatically with the increase in internet speeds globally, the talent shortage of the late 2010s, and the necessity of remote working during the global pandemic beginning in 2020.

The Manifesto refers to “face-to-face conversation” and it was probably hard for the authors to imagine so many of these would be video calls like the one in 2001: A Space Odyssey.

Outcomes focus

Some teams have started to move away from thinking about “requirements” (a word used often in the Manifesto) and towards thinking about “outcomes”.

The difference between “requirements” and “outcomes” is subtle but profound:

A requirement is something you need a product to do for you
An outcome is a change you want to see for yourself or others

By focussing on what the product changes rather than on what it does, we can have more fulfilling discussions that get to useful results quicker. Often those results don’t have any technical requirements at all.

Accessibility, equity, diversity and inclusion

It’s not escaped my attention that the 17 people who wrote the Manifesto were all men, all white people from the US, Canada and western Europe.

In 2001, it was rare for people to ask to see a diversity of views represented. Today, people would see a document produced by a group like this as deficient because it fails to represent the lived experience of the software engineering community as a whole.

Indeed, something that is woefully missing from the Manifesto is any attention to producing software that works for everyone, nor is there anything about looking after the wellbeing of the people who are working on it.

Thankfully, accessibility of products and equity, diversity and inclusion in workplaces are now hot topics in the industry, even though many (most?) companies don’t actually do a great job at either.

The (re)rise of disciplines

Something else that has changed that I wanted to call out separately is the rise of multidisciplinary working.

The Manifesto reads like team producing software should be engineering-led. They mention “business people” in the sense of stakeholders, but not the idea of disciplines working together to build something.

Modern disciplines like product management and delivery management (interestingly, both often have “Agile” in their job titles), user experience design, user research, content design and more are essential parts of a productive team in modern businesses.

I think this is an interesting quirk of the era the Manifesto was written. I can fully believe that engineering-led teams were the norm when it was written. Indeed, my first engineering job in 2003 was very much in an engineering-led team.

But the idea of multidisciplinary working is not new. The original software engineering manual, The Mythical Man Month (1975) has a whole chapter called “The Surgical Team” that makes an analogy to the way a hospital operating theatre is always multidisciplinary - everyone present is there to do a different job.

I am grateful multidisciplinary working is back and a revised Manifesto should definitely mention it.

Lessons painfully unlearned

I still keep the Manifesto in my mind whenever I work, but time and again I find myself hearing about organisations that aren’t learning the lessons that the Manifesto was written to tackle all that time ago.

I think sometimes the leadership of these businesses think they can pick the bits they like and ignore some of the most important things, like allowing teams to self-organize, trusting and motivating people and paying down technical debt.

And in the age of AI, some leaders are forgetting the most important thing of all: humans are better at this stuff than machines will ever be. AI can help us to move at pace, but it can never take the place of design, innovation or ingenuity, because it is trained on our work. As the Manifesto says:

Continuous attention to technical excellence and good design enhances agility.

Is the Manifesto still relevant?

Yes. Definitely. So many things in this document are essential for modern engineering and, as we’ve seen, they’re still not universally applied.

But it’s also out of date. It’s just one set of guidelines among many, and it’s important to bring other experiences of the last 25 years into the mix.

Coming up next

So… what better way to finish this series with my attempt to update the Manifesto for 2026?

Surely one person can’t be big-headed enough to attempt this by herself?

Well: I can, and I will, and I hope it generates a lot of discussion!

Fish Percolator is a technical leadership consultancy based in Yorkshire.

If your team is not running as smoothly as you'd like, you have long gaps between releases or bugs in production, or your people are not excited about coming to work every day... we can help!