The 12 Agile Principles Through a Developer's Eyes
The 12 Agile principles fall into six themes: delivery and feedback, openness to change, collaboration, sustainable pace, technical excellence and simplicity, and self-organizing teams with reflection. We connect each principle to concrete practices such as small PRs, feature flags, CI and YAGNI, show how the principles break in a chain during two weeks of the Bookstore team, and why the unmeasured sustainable pace principle is the sneakiest trap.
Version note: This post is based on the "Principles behind the Agile Manifesto" page on agilemanifesto.org (2001); we summarize the principles in our own words instead of quoting them.
Guess First
The Bookstore team's last two weeks went like this: the Product Owner couldn't make it to Sprint Planning, so the team picked the work based on its own guess. One developer opened a 2,400-line pull request, and the review took four days. In the middle of the sprint the customer asked for a change and got the answer "the sprint is locked". In the last two days the team worked until midnight, and some of the tests were skipped with a "to be written later" note. The retrospective was canceled because the work wasn't finished.
Guess: how many of the Agile Manifesto's 12 principles were broken in these two weeks? Three, five, or more? While counting, notice something: most of the broken principles are connected, and when one breaks, the others fall in a chain.
Why Do the Principles Exist?
The Manifesto's four values say what to prioritize; the 12 principles on the second page describe what those priorities look like in daily work. The values are abstract, the principles more concrete, but still not practices. "Deliver frequently" is a principle; a two-week sprint or a daily deployment is one way of applying it.
Instead of memorizing the 12 principles one by one, grouping them into themes makes them easier to remember and makes their connections visible. In the table below we gathered the principles into six themes and connected each to a developer's daily practice:
| Theme | Principle | Developer practice |
|---|---|---|
| Delivery and feedback | 1, 3, 7 | Small PRs (pull requests), frequent deployments, feature flags, showing progress with a working increment |
| Openness to change | 2 | Code that keeps change cheap: tests, modular design, reversible deployments |
| Collaboration and communication | 4, 5, 6 | Daily contact with the Product Owner, short conversations instead of long threads, trusting the team |
| Sustainable pace | 8 | Measuring overtime, planning the sprint to capacity |
| Technical excellence and simplicity | 9, 10 | Refactoring, CI (Continuous Integration), YAGNI (You Aren't Gonna Need It), not doing work nobody asked for |
| Self-organizing team and reflection | 11, 12 | The team splitting the work itself, regular retrospectives and actions that are actually carried out |
Delivery and Feedback: Principles 1, 3 and 7
The first principle gives the highest priority to satisfying the customer through early and continuous delivery of valuable software. The third principle asks for working software to be delivered at intervals ranging from a couple of weeks to a couple of months, with a preference for the shorter. The seventh principle says that working software is the primary measure of progress.
In 2001 "a couple of weeks" was an ambitious target; today many web teams deploy several times a day. But the principle gives a direction, not a number: prefer the shorter one. A developer's strongest tool in that direction is the small pull request. A 2,400-line PR waits four days for review, and the reviewer can only look at it superficially. If the same work is split into five PRs of 150-300 lines, each can be merged on the same day and bugs are found while they are smaller. The way to merge an unfinished feature in small pieces is a feature flag: the code goes to production but stays switched off for users.
The seventh principle also explains why the sentence "it's 80 percent done" is meaningless in a sprint review. There is no 80 percent in working software; either the user can create a return request or they can't.
Openness to Change: Principle 2
The second principle says to welcome changing requirements even late in development, and to harness change for the customer's competitive advantage. This shows why the answer "the sprint is locked" is a problem. In Scrum the Sprint Goal is protected during the sprint, but the Product Backlog can always change, and the scope of the sprint can be renegotiated between the Product Owner and the Developers. The details of this mechanism are in the Sprint Planning post of the Scrum series.
From a developer's point of view the real meaning of this principle is technical: welcoming change is only possible if change is cheap. In a codebase without tests, where everything depends on everything, every late change is a risk and the team naturally resists. Openness to change is a matter of code quality before it is an attitude; that is why principle 2 depends on principle 9.
Collaboration and Communication: Principles 4, 5 and 6
The fourth principle asks business people and developers to work together daily throughout the project. The fifth says to build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. The sixth says that the most efficient and effective way of conveying information to and within a team is face-to-face conversation.
In the Bookstore example, the Product Owner missing Sprint Planning isn't just one missed meeting, it's the fourth principle breaking. The team picks work by guessing what is valuable, and if the guess is wrong, two weeks go to the wrong work. Today's reading of the sixth principle matters too: in 2001 "face-to-face" meant being in the same room. For a remote team the counterpart is synchronous conversation: a video call or a screen share. What the principle really opposes is not remote work but conveying everything through documents and long message threads.
Sustainable Pace: Principle 8
The eighth principle says that Agile processes promote sustainable development, and that sponsors, developers and users should be able to maintain a constant pace indefinitely. The word "indefinitely" is the key: working until midnight in a two-week sprint may save that sprint, but it starts the next sprint with a tired team.
This is the most often broken and least measured principle. Teams measure velocity and burndown, but not overtime. The Bookstore team made it visible with a simple indicator: the number of commits made outside working hours and the number of weekend deployments are shared as one line in every retrospective. The number proves nothing on its own, but when it starts to rise it starts the conversation. XP's (Extreme Programming) "sustainable pace" practice is the engineering side of this principle; we will come back to it in the third post of the series.
Technical Excellence and Simplicity: Principles 9 and 10
The ninth principle says that continuous attention to technical excellence and good design enhances agility. The tenth defines simplicity as the art of maximizing the amount of work not done, and calls it essential.
The ninth principle is the clearest proof that Agile is not a project management approach. Skipping tests, postponing refactoring and merging while CI is red seem to buy speed in the short term; but each makes the next change more expensive and makes the second principle, openness to change, impossible.
The tenth principle is the manifesto's counterpart of the YAGNI rule from XP. Imagine a developer at Bookstore who was only asked for CSV (Comma-Separated Values) export but writes a generic export framework, saying "we'll need PDF and Excel later". Two weeks are spent, the resulting abstraction has been tested with only one use, and when PDF really is requested, it often turns out to be the wrong abstraction. Work not done is both time not spent today and code that won't need maintenance tomorrow.
Self-Organizing Team and Reflection: Principles 11 and 12
The eleventh principle says that the best architectures, requirements and designs emerge from self-organizing teams. The twelfth asks the team to reflect at regular intervals on how to become more effective, and to adjust its behavior accordingly.
Self-organizing means the team decides for itself how to do the work among its members; the 2020 Scrum Guide expresses the same idea with the word "self-managing". This doesn't mean architectural decisions will emerge at random; it means the people doing the work make the decisions. The architectural side of this is in the Introduction to Architecture series post "Conway's Law: How Team Structure Shapes Architecture".
The twelfth principle explains why the retrospective the Bookstore team canceled should be the last meeting to cancel. Exactly in a sprint where the work didn't get finished, the team should talk about why. The retrospective itself and how to run an effective one are in the Scrum series post "Sprint Review and Sprint Retrospective".
Production Notes
Turning the principles into a checklist and ticking it every sprint turns them into a ritual. A more useful way is to pick one principle in every retrospective and ask "where did we go most against this principle in this sprint?" Over twelve sprints, every principle comes to the table once.
Look at the connections between principles. In Bookstore's two weeks the real root was principle 4 breaking: work chosen without the Product Owner grew, big work turned into big PRs (3 and 7), big PRs got stuck in review, stuck work led to overtime (8) and skipped tests (9), and unfinished work got the retrospective (12) canceled. Instead of trying to fix the symptoms one by one, find the head of the chain.
Measure what you can: PR size and review time (1, 3), the number of items changed during the sprint (2), commits outside working hours (8), how long CI stays red (9) and how many retrospective actions are actually carried out (12).
Common Pitfalls
Never measuring the "sustainable pace" principle is the sneakiest pitfall. Overtime starts once as an "exception", three sprints later it is planned as normal capacity, and the team's velocity is actually inflated by exhaustion.
The second is reading the principles independently of each other. Openness to change (2) doesn't work without technical excellence (9), frequent delivery (3) doesn't work without small work items, and a self-organizing team (11) doesn't work without trust (5).
The third is reading the sixth principle as "remote work isn't Agile". The principle is about the value of synchronous conversation more than about the channel.
The fourth is confusing simplicity with no design. Maximizing the work not done doesn't mean not doing the design that is needed; it means not building flexibility nobody asked for in advance.
A Small Experiment
★☆☆ Reread the two weeks at the start of this post and write down the number of every broken principle. Then draw arrows showing which violation led to the others.
★★☆ Put the line count of your team's last ten pull requests and the time from opening to merge into a table. Do you see a relationship between size and waiting time?
★★★ Design a session focused on principle 8 for your next retrospective: which data do you bring, which question do you ask, and if the team finds the root cause of the overtime, how do you follow up on the action?
Principle 9 says technical excellence is essential for agility but doesn't say how to achieve it. In the next post we look at the most mature answer to that question, Kent Beck's Extreme Programming: test-first, pair programming, continuous integration and small releases.