The Agile Manifesto needs an upgrade: replace 'over' with 'AND'
Article content
Article sections
There is a moment that happens in nearly every team I have worked with for the past two decades, somewhere around month two or month three of an engagement. The team has read the Manifesto; they have done the training; they understand, in some intellectual way, what they are supposed to be becoming. And then their reality runs head-first into a quarterly planning meeting, or a fixed-bid contract, or a regulatory documentation requirement, and they discover that the Manifesto, as written, did not prepare them for what they are about to do next.
I used to think this was a transformation problem, the kind of friction you ride out while the team grows past it. Years of watching the same conversation in different rooms convinced me it is something else; the friction is not the team failing to live the Manifesto, it is the Manifesto being one word away from telling them how to live it. That word is over.
The word over, in the four value pairs of the original Manifesto, quietly hands every reader an either-or instruction. Each pair becomes a contest with a winner; the right-hand side is acknowledged, then deprioritised, then in practice ignored. The fix is to change one word in each of the four lines. Replace over with over AND. The left-hand pole keeps its emphasis, and the right-hand pole stops being optional. The teams I have watched suffer most under the original Manifesto are the ones who took the word over at face value; the teams that thrive have already, quietly, been reading it as over AND.
What the Manifesto actually said, and what we heard
The Agile Manifesto is short enough that I can quote the part everyone fights about. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. The closing line was meant to keep the right-hand side in the room. In most organisations I have visited, it does not.
What the room hears, after a year of practice, is the rule of thumb without the qualifier. We value individuals over process, so we stop documenting the process. We value working software over documentation, so we stop writing anything down. We value collaboration over contracts, so we stop holding the contract. We value responding to change over following a plan, so we stop planning. Each of those moves, taken alone, is a reasonable response to a Manifesto with the word over in it. Each of them, taken together, produces a team that cannot scale, cannot answer to a sponsor, and cannot show a regulator how it ships software safely.
Was that what the original signatories intended? Almost certainly not. On the Agile Uprising podcast retrospective with several of the Manifesto authors, you can hear them say, in different ways, the same sentence; we wrote what we wrote, twenty years on we would phrase parts of it differently, please build on it. We have taken that as permission, and over the past several years, in our A-CSM and CSP-SM classes and our coaching engagements, we have been quietly testing one specific edit. Replacing over with over AND.
A polarity, not a problem
The reframe holds together because each of the four Manifesto pairs is a polarity rather than a problem; the technical distinction matters. A problem has a solution; once it is solved it stays solved, until the next problem arrives. A polarity is an interdependent pair of poles that need each other over time; you cannot solve a polarity, you can only manage it. Barry Johnson, the practitioner who has spent the most time on this in the leadership-development world, has a definition that has stayed with me since I first read it.
Interdependent value pairs that need each other over time with predictable and leverage-able dynamics, but are inherently unsolvable.Barry Johnson, on the structure of a polarity
If you are not sure whether the thing in front of you is a polarity, there are four diagnostic questions that almost always settle it. Is the difficulty ongoing rather than a one-time event? Are the alternatives interdependent rather than independent? Are the upsides of both alternatives necessary for the system to function well? And will over-focusing on one alternative undermine the greater purpose the system serves? Run any of the four Manifesto pairs through those questions and the answer comes out the same way every time. Documentation is interdependent with working software; one without the other is either an unreadable codebase or a binder nobody opens. Planning is interdependent with responding to change; without a plan there is no road to deviate from, and without responsiveness the plan ages into fiction before the quarter ends.
The metaphor I keep coming back to in this material is breathing. You cannot inhale your way out of needing to exhale; you do not pick one over the other, and you do not merge them into a single act of bre-haling. You move between them, in rhythm, all the time, without thinking about it, and the rhythm is the thing that keeps you alive. Polarities work the same way; you move between the two poles in a rhythm that the situation in front of you calls for, and the health of the system is the rhythm rather than the position.
What happens when you treat a polarity like a problem
There is a specific failure pattern that shows up in transformations where the team has tried to solve a polarity instead of managing it. We call it the polarity two-step, and it looks like this. The organisation notices the downsides of the left-hand pole and swings hard to the right; everyone documents everything, every meeting has minutes, every decision is captured. After a year the team is buried under their own paperwork; throughput drops. The organisation notices, panics, and swings back to the left; documentation is now a dirty word, meetings stop being captured, decisions stop being recorded. Six months later the team cannot remember why they made any of last quarter's choices, and a new transformation is announced. Repeat.
I have seen the two-step pattern in software teams, in HR transformations, in a school district leadership team, and in the church board I chair. The shape is the same in every case; what gives it away is not the content of the swing but the speed of the swing combined with the surprise on people's faces each time the other set of downsides shows up. A well-managed polarity feels different from the inside. It is quieter. There are small corrections rather than violent reversals. The team is paying attention to early warning signs in the pole they are currently emphasising, and the moment the warning signs appear, they make a small move toward the other pole, before the swing has to become large.
How do you know which kind of polarity-management your team is doing? You can usually tell by listening to the language. Two-step teams talk in absolutes; we are an agile shop, we do not document, we do not plan, we do not negotiate. Well-managed teams talk in conditions; right now, on this product, with this stage of the company, we are leaning into individuals and interactions and the early warning sign we are watching for is whether decisions stop being repeatable for someone who was not in the room. The grammar is different, and you can hear it before you can see the throughput change.
The Integrated Agile Manifesto
If the Manifesto's four pairs are each a polarity, then the one-word change matters more than its size suggests. We have taken to calling the result the Integrated Agile Manifesto, and the only edit it makes to the original is the word AND, inserted right after over. The result reads like this.
The Integrated Agile Manifesto
The left-hand pole keeps its emphasis; the original Manifesto's intent is preserved. The right-hand pole stops being permissible-to-ignore; the team is given language to defend the documentation it does write, the contract it does honour, the plan it does follow. In coaching engagements I have used this reframe with leaders who were embarrassed to be asking their team for a plan, and watched their shoulders drop when they realised the reframe gave them permission to want what they had always wanted; both poles, in proportion, in rhythm.
The downside of teaching this is small but real. Some practitioners hear over AND and conclude that the Manifesto was wrong; that is not what I am saying, and it is not what the reframe says. The original Manifesto was, and is, a remarkable piece of writing produced by people thinking under pressure in 2001. What I am saying is that it has been read, in tens of thousands of rooms, as license to neglect the right-hand pole, and the consequences of that reading are visible in every transformation that stalled before it finished. The reframe is a piece of editorial care on top of the original work, not a replacement for it.
How to use the reframe this week
The simplest way to use the Integrated Agile Manifesto is to print it next to the original and put both up in the room where your team plans. The two posters next to each other do most of the work; the team starts to notice the right-hand poles they have been quietly neglecting, and they start to defend the ones they were ashamed to defend. After a few weeks the language changes. The team stops talking in absolutes and starts talking in rhythms.
If you want a deeper version of the move, pick one of the four pairs this week and run the four-question diagnostic in front of your team. Is the difficulty ongoing? Are the alternatives interdependent? Are the upsides of both necessary? Will over-focus on one undermine the greater purpose? When the team agrees on yes-yes-yes-yes for the pair they have been arguing about, the argument stops being about whether to do A or B and starts being about how to keep both. That is a different kind of conversation, and it is the one I have seen most teams quietly want to be having.
The site we built for the longer form of this argument lives at IntegratedAgileManifesto.org. It includes the full reframed text, a longer treatment of each of the four pairs, and the four-question polarity diagnostic in a form you can run with a team. If polarities are new for you, I would suggest reading Barry Johnson's work next; if the move from problem-thinking to polarity-thinking is what you want to sit with, our coaching-mindset piece is a good companion, and the related five-stance map Erkan put together is what the polarity work looks like when it lands inside the coaching conversation itself.
One last note. I have been chair of a board of elders at my church for some years now, and the polarity work has changed how I read scripture as much as it has changed how I read the Agile Manifesto; there are very few writings worth reading that do not contain at least one unmanaged polarity in their popular interpretation. The Manifesto is in good company. Replacing over with over AND is, in the end, an act of care toward both the original authors and the people still trying to live by what they wrote. Write back when the welcome email lands if you want to talk about the pair your team is currently swinging hardest on; the replies reach Erkan and me directly.