The first six of the twelve Agile Principles are mostly about who. Customers, business people, motivated individuals, face to face conversation. The last six are about how. How progress gets measured, what pace the work runs at, how quality gets built in, where the best decisions come from, and what a team does when it wants to get better.
That shift matters, because how is where the words lose people fastest. A marketing lead can squint at “satisfy the customer” and see their own job in it. Hand the same person “continuous attention to technical excellence” and they are gone.
Do not rewrite the principles. Translate them. Keep the meaning, change only the words that stop people reading.
Working software becomes delivered value
Principle seven: working software is the primary measure of progress.
This one is the easiest translation of the twelve and it takes about ninety seconds. Working software becomes delivered value. Delivered value is the primary measure of progress.
The word delivered is doing real work in that sentence. Value that is planned, designed, half built, or waiting for sign off is not progress, however good the status report looks. Progress is what has reached the people it was meant for. Whatever your team makes, that is the north star, and everything else on the dashboard is noise.
Sustainable was never only about the team
Principle eight: agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is the most ignored principle of the twelve, and death marches did not end when teams adopted Scrum. Two things get in the way.
- The first is the word development. Someone on a legal team reads it and decides it does not apply to them. It does.
- The second is what people think sustainable means. It does not mean 40 hours a week. It means a pace you can hold indefinitely, with the fire drills, the unplanned injections, and the mid Sprint surprises stripped out. Stop thrashing the team and the sustainable pace tends to take care of itself.
There is a third problem that is easier to miss. The sentence names three groups, and most people only remember one. Sustainable pace has quietly become “protect the team,” which is a decent instinct and about a third of the point. A user receiving four product updates a day is not on a sustainable pace. A stakeholder fielding five “what did you mean by this requirement” questions before lunch is not either. Sustainable applies to everyone the work touches.
Which suggests a shorter version. Agile processes promote sustainable value delivery. Full stop. No further debate about whose pace is meant, because the answer is everyone’s.
Technical excellence, and an honest disagreement
Principle nine: continuous attention to technical excellence and good design enhances agility.
Half the executive row switches off at the word technical, so that word goes. Continuous attention to excellence and good design enhances agility.
Whether design should stay is a fair argument, and it is worth having with your own team rather than settling here. The case for keeping it: a marketing team designs a campaign, a finance team designs its close process, a process improvement team designs the process. Design is broad enough to carry all of that, and design thinking and org design are both mainstream phrases now. The case against: to someone in operations, design still lands as a technical word, something an architect does before the real work starts, and the alternatives on offer, approach, planning, method, all lose something.
It is fine to end that conversation without a winner. Someone disagreeing with the current wording while admitting they do not have a better one yet is still more useful than a room nodding at a word half of them have privately filed under IT.
Simplicity stays exactly as it is
Principle ten: simplicity, the art of maximizing the amount of work not done, is essential.
Not a word changes. Someone once said they had to read that sentence five times before it made sense. Good. It did its job. A principle that makes you stop and think is working as intended, and this one is a standing permission slip to cut the noise and do less, which is a permission most teams badly need.
Self-organizing becomes self-managing
Principle eleven: the best architectures, requirements, and designs emerge from self-organizing teams.
In the spirit of principle ten, most of that sentence can go. The best value emerges from self-managing teams. The point was never the nouns. Backlog items, ways of working, technical choices, all of it flows from the team doing the work, because the team doing the work is best placed to decide.
The word swap at the end is deliberate. When the 2020 Scrum Guide replaced self-organizing with self-managing, Jeff Sutherland was asked why in a Q&A. Managing is the broader word. And self-managing does not mean self-supervising, or that nobody needs a manager. It means a team of capable adults who know the work can be told what is wanted and trusted to handle the rest.
Self-managing is also the word that makes leadership nervous. Self-organizing sounds harmless. Self-managing sounds like “what is my job now.” That discomfort is the reason to keep it. It surfaces the conversation about what a manager is for in an organization that trusts its teams, which is a conversation worth having out loud.
The retrospective principle is perfect, so why is it skipped?
Principle twelve: at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Nothing to change. Two of the three pillars of empiricism, inspection and adaptation, live in that one sentence, and a well run retrospective creates the third, transparency, by giving people a safe place to say what is true.
And it is the first event teams drop. Ask a class which Scrum event they struggle with most and the retrospective wins every time.
The reasons are consistent. People have only ever been to bad ones. The same questions and format every Sprint, what went well, what did not, what could we do differently, run by someone who has stopped trying. Nothing changes afterwards, because nobody picked one experiment and put a name next to it. And once nothing changes, leaders decide the hour is a waste, and they are not wrong about that particular hour.
None of this is a problem with the principle. A retrospective is not a recap. It ends with a decision to try something, and it should look different from the last one. Run that way, it is the highest return hour in the Sprint, because it is the only one where the team gets to change how it works rather than just what it works on.
It does not need Scrum, either. Any team can retrospect. Any process, any event, any project. Sit down at a regular interval, ask what you would do differently, and then do it.
The WHO and the HOW
Put the two halves together and the twelve principles read as one argument. The first six say who matters: customers, stakeholders, the people doing the work, and the conversations between them. The last six say how the work should run: measured by value delivered, at a pace everyone can hold, built with care, kept simple, decided by the team, and inspected regularly.
Almost none of that is about software. Cross out a handful of words and it describes any team that makes anything.
If the words do not fit your world, translate them. Then read the twelve together and see which ones your team is quietly skipping. It is usually number twelve.