It takes about three minutes to read the Manifesto for Agile Software Development. Four values, twelve principles, a couple of hundred words at the top. Most teams working in agile ways today have never read it end to end, and almost none have read it out loud together.
That is a strange gap for a document that sits underneath everything those teams do. It is also an easy one to close, which is the whole argument for going back to basics.
Why basics, and why now
Three things happened at once.
The first is that a lot of experience walked out of the building. Scrum Masters and agile coaches have been cut in wave after wave, and with them went the institutional memory of what good looked like. Organizations are left holding the practices without the people who understood why the practices existed. That is how you end up with a team cheerfully reporting that they hold the Daily Scrum twice a week.
The second is the sheer volume of change. Very few organizations are changing because they woke up feeling ambitious. They are changing because the alternative is worse, and they are doing it faster than their people can absorb.
The third is AI, arriving on top of the other two and demanding attention that the first two already used up.
Put those together and the case for a reset is obvious. Not a new framework. Not another operating model. A reset back to the shortest, plainest statement of what this is all supposed to be for.
The sporting analogy is a good one here. The best players in the world still get taken back to the forehand and the backhand every single year by a coach they pay for the privilege. They know how to hit a forehand. Going back to it is what keeps them grounded. Nobody thinks less of them for it.
The word that expired
The document is called the Manifesto for Agile Software Development. The shorthand dropped the software development part decades ago, and that shorthand hides something worth talking about.
If you strip the manifesto back to its shape, it says: here is how we uncover better ways of doing [blank], by doing it and by helping others do it.
For a long time the answer to blank was software. That is too narrow now, and swapping in product or service is not quite right either. A better fit is iterative.
Iterative delivery of a product. Iterative delivery of a service. Iterative process improvement. Iterative shift in the way a leader thinks. Coaching a leader delivers nothing in the traditional sense, and it is unmistakably iterative. So is teaching a team to run a better Sprint Retrospective. Nobody ships anything, and the work still gets better in small increments over time.
The reason iterative is the right word is that it rules out the thing the manifesto was written against. Not big bang. Not a year of planning followed by a single reveal. Small steps, evaluated honestly, adjusted, repeated.
Look at any object that has been refined over a long period and you can see it. A pocket knife goes from a simple folding blade to a tool with a hundred attachments, and every version in between is a real product someone carried. A bicycle in 1819 and a bicycle today are recognizably related, and there is no moment where somebody invented the modern bike from scratch. That is iterative development, and it long predates software.
The bookends
The four values are usually taught as a flat list. In practice they are not flat, and it is worth asking which of them is carrying the most weight right now.
Ask experienced practitioners today and two rise to the top: individuals and interactions over processes and tools, and responding to change over following a plan.
Values one and four. The bookends.
Responding to change earns its place by looking at the world for five seconds. Change is the condition, not the event. And the framework advantage is concrete rather than philosophical. When a stakeholder arrives with a new priority four days before the next Sprint starts, the answer is not a change control board and a renegotiated date. It is yes, prioritize it, it goes in the next Sprint. Compare that with the gravitational pull of the old way, where the scope creeps and the date somehow never moves.
Individuals and interactions earns its place because everything else runs on it. Somebody wants something from a team. That team needs things from other people. The tools are genuinely good now, and they are still just the pipes. It is people needing things from people.
Which leaves the middle two. Working software and customer collaboration are not less important, they are the reason the whole thing exists. But they only work when the bookends are holding them up, and the middle two are where teams are visibly slipping.
Working product suffers because teams stop releasing and start assembling. Pieces get put in place for some larger future thing, and the muscle of shipping something small that works today quietly wastes away.
Customer collaboration suffers worse. Users get held at arm’s length, and everything reaches the team through a Product Owner playing a game of telephone. Nobody is being negligent. It is just easier, and easier wins by default until somebody notices.
The right hand column is having a moment
Here is the uncomfortable part. Individuals and interactions over processes and tools has probably slid backward in the last two years, and AI is why.
An organization buys ten thousand licenses. Everyone is going to use it. Enormous decision, seven figure decision, and it is a decision about a tool. The question of what it does to how people work, whether they are ready for it, and what happens to the humans in the middle of it can get treated as a change management footnote. Deloitte found roughly half of organizations have implemented something AI native, and far fewer have looked hard at the people side.
The effect on interactions is genuinely mixed, and it is worth being honest about both directions.
On the good side, AI is a gift to the quieter people in the room. Someone who is not confident speaking up can arrive prepared, having thought it through, with better questions. That is a real increase in the quality of interactions, not a decrease.
On the other side, it is easier to ask the machine than to ask a colleague, and every one of those is an interaction that did not happen. The answer is not to ban the tool. It is to teach people to pair the human with the AI rather than replace the human with it.
And then there is what customers are experiencing. People are tired of not being able to reach a person. Order from a screen, get intercepted by a chatbot on arrival, work through a phone tree that has no exit. It would be easier to accept if the systems were excellent. They are not yet, and the trust is not there yet either. As one commentator put it, you have to be smart enough to know when the AI is wrong. That is a lot to ask of a customer who just wants a refund.
Reading it without becoming insufferable
So the manifesto is short, it is free, and it still holds up. The hard part is bringing it into an organization without turning into the person who answers every question by quoting it.
Three things help.
Start at the top, and start with why. Ask the CEO what agility means to them. Not whether they want to do Scrum. What agility means, and why they want it, and whether they need it or are chasing something they read about. Then work out how that answer reaches the next layer, and the layer after that, without being diluted, embellished, or quietly reversed on the way down. Start at the top, start at the team, and meet in the middle. This is a leadership question far more than a framework question, which is why two teams in the same organization can respond completely differently. Their leaders lead differently.
Attach it to what already exists. The fastest way to make agility feel like one more initiative is to introduce it as one more initiative. The better move is to connect it to the values, pillars and slogans an organization already has on its own walls. Most organizations are already doing pieces of this. They just have not called it agility. That reframe turns a big scary adoption into a small honest naming exercise.
Hand it over and read it together. Not a lecture, not a slide about it. Read the words in the room. It takes ninety seconds, it wipes the slate clean of everything people picked up at three previous employers, and everybody starts from the same place.
What that reading does, more than anything, is give people permission. Permission to value the items on the left a little more. Permission to notice that the document explicitly says the items on the right still have value, so nobody has to pretend documentation is forbidden. And permission, written into the first sentence, to go on uncovering better ways of working.
That is not dogma. That is the opposite of dogma. It is a short set of guidelines that trusts the people using them.
Keep it simple. Keep it honest. Keep going back to the basics.