Updating the Manifesto

The values

The Manifesto starts with four values. These are timeless, of course, but I think some of the wording could be updated a little.

Individuals and interactions over processes and tools

This still feels like the most important value to me, and the one that continues to be the source of a lot of problems in workplaces I go to, and even in many supposedly “Agile” consultancies.

I’d change “Individuals and interactions” to “Human communication”. Naming humans upfront feels ever more important the more we distance ourselves from human communication through telemetry, big data and AI.

Working software over comprehensive documentation

Honestly, this one is still perfect. It reminds us that attention to UX design, paying down technical debt, and testing is always going to beat explaining to customers why they’re using your product wrong.

Customer collaboration over contract negotiation

I think “contract negotiation” isn’t a thing many organisations and teams do. It works in a small agency but this value is a little lost in other places. I’d like to change it to “upfront planning”.

Responding to change over following a plan

I think we’ve all got used to “responding to change” now, so I might downgrade this one from a value, since it’s covered well in the principles. But I’ll add “plans” to the right-hand side of the first value, so that it still contains the spirit of this value.

Removing one value leaves space for another, and I think we need one that encompasses the need to take care of your team, the value of diversity of thought and experience, and creating products that are accessible to everyone. How about:

Empathy for people over delivery velocity

Something that’s often missed by people reading the Manifesto quickly is that the four values are qualified with “while there is value in the items on the right, we value the items on the left more”. It isn’t saying the things on the right (“delivery velocity” in this case) are of no value, just that they can’t take priority over the things on the left.

Twelve principles

As well as the four values, there are twelve principles that help underpin the Manifesto and explain how to achieve these values in practice.

Most of the principles are great and still as true today as they were in 2001. Here are the ones I would tweak:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Changing “the customer” to “every customer” is a small change, but it makes it clear that accessibility is a priority. A hand dryer that only turns on when white-skinned hands are placed under it is not “satisfying every customer”.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

As I mentioned in the last post, I have welcomed the shift in mentality from “requirements” to “outcomes”, so I’d like to remove that word. I also think we need to reword this with telemetry and customer data in mind, since there are now many ways to learn from customers (although we still value human conversations!)

Something like: “Learn from your customers and change your plan accordingly. Being Agile means being able to let go of your assumptions about what the customer needs.”

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

I mentioned the rise of disciplines in my last post, and I think the term “business people” here is too vague and unclear for modern ways of working. It also fails to capture the power of shifting left - bringing people in early so that their perspective is understood before you sink too much effort into a solution that is sub-optimal from their viewpoint.

Maybe something like: “It is never too early to collaborate across disciplines. Bringing stakeholders, designers, researchers, developers and testers together at the beginning — and throughout — ensures their perspectives are never missed.”

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

“Face-to-face” sounds a bit like people need to be in-person and that something like Slack or a collaborative document isn’t ever the most efficient or effective. It’s an easy fix - just replace “face-to-face” with “human”.

And four more

The truth is that the twelve principles are all still important, but we have learnt more in the time we’ve been working in these ways.

I think we can afford to add four more principles and take the number up to 16. Frankly, it should have been a power of two to begin with(!)

I’d like to add principles that cover the following topics:

1. Outcomes focus: what changes for a customer as a consequence of your work
2. Collaboration across team and company boundaries: a nod to open-source working
3. Diversity and wellbeing: as I mentioned before, I felt this was severely lacking from the original document, and I think that is a direct consequence of who was invited to write it
4. Inclusion: a sort of addendum to the old principle twelve that takes the individual lives and needs of team members into account. Meeting people with different needs where they’re at instead of trying to mould them into the same shape as the existing staff.

Although I like that the old principle twelve comes at the end, I think I need to add these four at the end so the numbering isn’t broken. Reorder them in your head if you’d like them grouped more by topic!

OK - are you ready? Here comes my updated version of the Manifesto…

Quinn’s Manifesto for Agile Software Development in 2026

We continue to uncover better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Human communication over plans, processes and tools
• Working software over comprehensive documentation
• Customer collaboration over upfront planning
• Empathy for people over delivery velocity

That is, while there is value in the items on the right, we value the items on the left more.

What do you think?

Is this an improvement over the original Manifesto? Does it accurately capture the best ways of working in a modern, multidisciplinary team?

This is, after all, just the work of one individual. A real update would be a collaborative effort, hearing from many people with varied experience of doing software development in different environments.

I’m really keen to hear people’s thoughts. What would you change? Do you agree? Would you like this on a poster?

I love receiving messages from people who have read my content. Knowing what you are thinking — good and bad — is what keeps me writing!