The Agile Manifesto and its twelve principles

Seventeen people agreed the Agile Manifesto in 2001, and it is tiny: four values of one line each, and twelve principles on a companion page. It is quoted in planning meetings every day and misquoted nearly as often, usually as “agile means no documentation”, which no line of it says.

Here you will read all four values and what the word over claims, step through the twelve principles with one invented project decision for each, correct the three misreadings that cost teams the most, and see where the text came from. Two programs put numbers on it: what a shorter release rhythm does to finished work waiting for customers, and what twelve observed behaviours of one team say about where that team is weak.

Four values, each a choice between two good things

The ManifestoAgile Manifesto: A one-page statement agreed by seventeen practitioners in 2001: four values that each rank two useful things, with a line saying the lower-ranked item still has value. It names no role, meeting or practice. is four comparisons. Each names something teams were already doing and something the authors found more useful when the two compete. The first puts “individuals and interactions” above “processes and tools”. The second ranks “working software” above “comprehensive documentation”. The third prefers “customer collaboration” to “contract negotiation”. The fourth chooses “responding to change” over “following a plan”.

The sentence that follows those four lines is the one that gets dropped in quotation, and it changes everything:

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

So over is a tie-break, not a ban. Processes, documents, contracts and plans all keep their value; when a team cannot have both at once, the Manifesto says which way to lean. Read the four lines in the authors’ own words, with their seventeen names and the notice about copying the text, on agilemanifesto.org; the page asks that the declaration be copied only in its entirety, so this lesson quotes it a line at a time and explains it in its own words.

The table pairs each value with the habit it asks for and the thing on the right that a working project still needs:

Two of the four values are about people rather than artefacts, which is why an adaptiveadaptive approach: Iterative and incremental delivery at once, in short cycles that each end with a usable result; scope emerges as the team learns. Most teams call it agile. More in “Choosing predictive, agile or hybrid delivery” project can fail with perfect ceremonies and succeed with ragged ones. The other two are about shortening the distance between a decision and the evidence for it.

Twelve principles, and the decision each one changes

The values are short enough to argue about and too short to act on. The twelve principlestwelve principles of the Agile Manifesto: The twelve statements on the Manifesto's companion page that say how its values behave in a project: what to deliver and how often, who works together, what pace to hold, how much technical care to spend, and when to reflect. on the companion page say how the values behave in a project: what to deliver, how often, with whom, at what pace and with what care. Step through the cards below. Each one gives the principle in plain words and one invented project where following it changed what the team did next:

Four themes hold the twelve together. Principles 1, 2, 3 and 7 are about customer value: deliver something valuable early and keep delivering it, welcome a late change, prefer the shorter gap between releases, and measure progress by what works. Principles 4, 5, 6 and 11 are about people: daily contact between business and builders, motivation and trust, conversation as the quickest channel, and a team that shapes its own workself-organising team: A team that decides how it will do its work and how its design is shaped, rather than receiving both from outside it. The 2020 Scrum Guide calls this self-managing and adds choosing what to work on.. Principles 8, 9 and 10 protect the ability to keep going: a pace everyone can holdsustainable pace: A rate of work that sponsors, the team and users can keep up indefinitely, as the Manifesto's eighth principle asks. Overtime that borrows capacity from the following month is not one., continuous attention to technical quality, and simplicity, which the text defines as “the art of maximizing the amount of work not done”. Principle 12 is the loop that improves the other eleven.

Principle 3 is the one with a number in it: deliver working software frequently, “with a preference to the shorter timescale”. The program below takes one invented 48-week project whose twelve features are finished in fixed weeks, and changes nothing except the release rhythm:

"""Two release rhythms for the same finished work, counted week by week.

Invented project: a payments company's "statement portal" team plans 48 weeks of work.
Twelve features are finished in the weeks listed below. Nothing about the building
changes between the two plans; only the day the work reaches customers changes.

  Quarterly plan:   a release every 12 weeks (weeks 12, 24, 36, 48).
  Fortnightly plan: a release every 2 weeks (weeks 2, 4, 6, ... 48).

"Shelf weeks" is the wait between a feature being finished and customers being able
to use it. Everything printed is computed here; no clocks, no randomness.
"""

HORIZON_WEEKS = 48

# (feature, the week its work is finished) - invented, fixed.
FEATURES = [
    ("Download a statement", 2),
    ("Filter by date range", 3),
    ("Refund status page", 5),
    ("Saved card list", 8),
    ("Failed-payment reasons", 9),
    ("Split a long statement", 13),
    ("Search by reference", 14),
    ("Monthly summary e-mail", 19),
    ("Dispute a charge", 22),
    ("Card tokens for repeat pay", 27),
    ("Statement in two languages", 33),
    ("Spending chart", 40),
]


def release_weeks(every: int) -> list[int]:
    """The weeks on which this plan releases."""
    return list(range(every, HORIZON_WEEKS + 1, every))


def ship_week(finished: int, every: int) -> int:
    """The first release week on or after the week the work was finished."""
    return next(w for w in release_weeks(every) if w >= finished)


def report(name: str, every: int) -> dict[str, float]:
    releases = release_weeks(every)
    rows = [(f, w, ship_week(w, every)) for f, w in FEATURES]
    shelf = [ship - done for _, done, ship in rows]

    print(f"{name}: a release every {every} weeks, {len(releases)} releases in {HORIZON_WEEKS} weeks")
    print(f"  {'feature':<28}{'finished':>9}{'live':>6}{'shelf':>7}")
    for feature, done, ship in rows:
        print(f"  {feature:<28}{done:>9}{ship:>6}{ship - done:>7}")
    longest = max(shelf)
    mean_shelf = sum(shelf) / len(shelf)
    live_at_11 = sum(1 for _, _, ship in rows if ship <= 11)
    use_weeks = sum(HORIZON_WEEKS - ship for _, _, ship in rows)
    print(f"  longest wait on the shelf: {longest} week{'' if longest == 1 else 's'};"
          f" mean wait: {mean_shelf:.1f} weeks")
    print(f"  features customers can use in week 11: {live_at_11} of {len(rows)}")
    print(f"  weeks of customer use over the {HORIZON_WEEKS} weeks: {use_weeks}")
    print(f"  first week customers can use anything: {rows[0][2]}")
    print()
    return {
        "releases": len(releases),
        "mean_shelf": mean_shelf,
        "max_shelf": longest,
        "live_at_11": live_at_11,
        "use_weeks": use_weeks,
        "first_use": rows[0][2],
    }


def main() -> None:
    quarterly = report("Quarterly releases", 12)
    fortnightly = report("Fortnightly releases", 2)

    print("Same work, same order, different rhythm:")
    print(f"  releases in {HORIZON_WEEKS} weeks: {quarterly['releases']} -> {fortnightly['releases']}")
    print(f"  weeks until the first customer can use anything: "
          f"{quarterly['first_use']} -> {fortnightly['first_use']}")
    print(f"  mean wait on the shelf: {quarterly['mean_shelf']:.1f} -> {fortnightly['mean_shelf']:.1f} weeks")
    print(f"  longest wait on the shelf: {quarterly['max_shelf']} -> {fortnightly['max_shelf']} weeks")
    print(f"  features usable in week 11: {quarterly['live_at_11']} -> {fortnightly['live_at_11']}")
    print(f"  weeks of customer use: {quarterly['use_weeks']} -> {fortnightly['use_weeks']}")
    gained = fortnightly["use_weeks"] - quarterly["use_weeks"]
    print(f"  weeks of customer use gained by the shorter rhythm: {gained}")


if __name__ == "__main__":
    main()

Quarterly releases: a release every 12 weeks, 4 releases in 48 weeks
  feature                      finished  live  shelf
  Download a statement                2    12     10
  Filter by date range                3    12      9
  Refund status page                  5    12      7
  Saved card list                     8    12      4
  Failed-payment reasons              9    12      3
  Split a long statement             13    24     11
  Search by reference                14    24     10
  Monthly summary e-mail             19    24      5
  Dispute a charge                   22    24      2
  Card tokens for repeat pay         27    36      9
  Statement in two languages         33    36      3
  Spending chart                     40    48      8
  longest wait on the shelf: 11 weeks; mean wait: 6.8 weeks
  features customers can use in week 11: 0 of 12
  weeks of customer use over the 48 weeks: 300
  first week customers can use anything: 12

Fortnightly releases: a release every 2 weeks, 24 releases in 48 weeks
  feature                      finished  live  shelf
  Download a statement                2     2      0
  Filter by date range                3     4      1
  Refund status page                  5     6      1
  Saved card list                     8     8      0
  Failed-payment reasons              9    10      1
  Split a long statement             13    14      1
  Search by reference                14    14      0
  Monthly summary e-mail             19    20      1
  Dispute a charge                   22    22      0
  Card tokens for repeat pay         27    28      1
  Statement in two languages         33    34      1
  Spending chart                     40    40      0
  longest wait on the shelf: 1 week; mean wait: 0.6 weeks
  features customers can use in week 11: 5 of 12
  weeks of customer use over the 48 weeks: 374
  first week customers can use anything: 2

Same work, same order, different rhythm:
  releases in 48 weeks: 4 -> 24
  weeks until the first customer can use anything: 12 -> 2
  mean wait on the shelf: 6.8 -> 0.6 weeks
  longest wait on the shelf: 11 -> 1 weeks
  features usable in week 11: 0 -> 5
  weeks of customer use: 300 -> 374
  weeks of customer use gained by the shorter rhythm: 74

The building is identical in both runs. Releasing every two weeks instead of every twelve turns 4 releases into 24, brings the first customer use forward from week 12 to week 2, and cuts the mean wait of finished work on the shelf from 6.8 weeks to 0.6. Five features are usable in week 11 instead of none, and the twelve features are in customers’ hands for 374 weeks in total instead of 300: 74 extra weeks of use from the same work. That is the whole argument for incremental deliveryincremental delivery: Handing over usable pieces of the result one after another, each adding to the last, so users can use part of it before the end. More in “Choosing predictive, agile or hybrid delivery” in one table, and it is also why the principle prefers the shorter timescale rather than naming one length.

What the Manifesto does not say

Three misreadings do real damage, and all three come from reading the left-hand item as the only item. The table puts each claim beside what the text actually supports:

The principles say the same thing more plainly. Principle 2 welcomes changing requirements, which only makes sense if there was a plan to change. Principle 9 asks for continuous attention to technical quality, which no team achieves without writing some of it down. Nothing in the twelve asks a team to work without an agreement, a budget or a date.

A fourth misreading is quieter and more common in project work: that the Manifesto describes a method. It names no roles, no meetings, no board and no estimate. Scrum, Extreme Programming, Kanban and the rest are methods built on these values; the Manifesto itself is a statement of what to prefer, which is why two teams can both follow it and look nothing alike.

Reading a team against the principles, without a score

The principles are most useful as a diagnosis, one behaviour at a time. The next program takes twelve things a team lead wrote down about an invented delivery-tracking project, without judging them, and reads each against the principle it bears on. It reports by theme rather than as one number out of twelve:

"""Twelve observed behaviours of one invented project, read against the twelve principles.

Invented project: "Parcel view", a delivery-tracking rebuild run by a team of nine.
A team lead wrote down twelve things the team actually does, without judging them.
Each line names the principle it bears on (1 to 12, in the order of the principles
page) and whether the behaviour follows that principle or works against it.

The program groups the twelve principles into four themes, so the score shows where
the team is strong and where it is weak instead of giving one number out of twelve.
Everything printed is computed from the table below; nothing is random.
"""

THEMES = {
    "Customer value": (1, 2, 3, 7),
    "People together": (4, 5, 6, 11),
    "Pace and craft": (8, 9, 10),
    "Learning": (12,),
}

SHORT = {
    1: "Satisfy the customer with early, continuous delivery",
    2: "Welcome changing requirements, even late",
    3: "Deliver working software frequently",
    4: "Business people and developers work together daily",
    5: "Build around motivated people and trust them",
    6: "Converse face to face",
    7: "Working software measures progress",
    8: "Keep a pace everyone can hold indefinitely",
    9: "Pay continuous attention to technical excellence",
    10: "Maximise the work not done",
    11: "Let the team organise its own design",
    12: "Reflect, then tune the way of working",
}

# (what the team does, principle it bears on, follows the principle?)
OBSERVED = [
    ("Ships to real couriers once a fortnight", 3, True),
    ("Shows the working tracking page at each review", 7, True),
    ("Counts progress by tasks moved on the board, not by what works", 7, False),
    ("Takes a new rule from the warehouse team in week 9 and reorders the backlog", 2, True),
    ("Freezes the requirement list after week 4; later asks go to a change board", 2, False),
    ("Has a warehouse supervisor in the team room for an hour every morning", 4, True),
    ("Lets the team decide how the tracking service is split", 11, True),
    ("Has an architect outside the team draw the service boundaries", 11, False),
    ("Replies to design questions only in a ticket queue, never in person", 6, False),
    ("Worked three weekends in the last two months to hold a date", 8, False),
    ("Keeps one hour a day for tests and refactoring, release week included", 9, True),
    ("Holds a 45-minute retrospective every fortnight and changes one thing", 12, True),
]


def main() -> None:
    print(f"Parcel view: {len(OBSERVED)} observed behaviours against the twelve principles")
    print()
    for theme, numbers in THEMES.items():
        rows = [row for row in OBSERVED if row[1] in numbers]
        follows = sum(1 for row in rows if row[2])
        one = len(rows) == 1
        word = "behaviour follows its" if one else "behaviours follow their"
        label = "principle" if len(numbers) == 1 else "principles"
        print(f"{theme} ({label} {', '.join(str(n) for n in numbers)}): "
              f"{follows} of {len(rows)} {word} principle")
        for what, number, ok in rows:
            mark = "follows" if ok else "against"
            print(f"  [{mark}] principle {number:>2}: {what}")
            print(f"              {SHORT[number]}")
        print()

    follows = sum(1 for row in OBSERVED if row[2])
    print(f"Overall: {follows} follow, {len(OBSERVED) - follows} work against a principle")

    touched = sorted({row[1] for row in OBSERVED})
    print(f"Principles this list touches: {', '.join(str(n) for n in touched)}")
    missing = [n for n in SHORT if n not in touched]
    print(f"Principles no observation covers: {', '.join(str(n) for n in missing)}")

    conflicts = sorted({row[1] for row in OBSERVED if row[2]} & {row[1] for row in OBSERVED if not row[2]})
    print(f"Principles with a behaviour on each side: {', '.join(str(n) for n in conflicts)}")
    for number in conflicts:
        print(f"  principle {number}: {SHORT[number]}")


if __name__ == "__main__":
    main()

Parcel view: 12 observed behaviours against the twelve principles

Customer value (principles 1, 2, 3, 7): 3 of 5 behaviours follow their principle
  [follows] principle  3: Ships to real couriers once a fortnight
              Deliver working software frequently
  [follows] principle  7: Shows the working tracking page at each review
              Working software measures progress
  [against] principle  7: Counts progress by tasks moved on the board, not by what works
              Working software measures progress
  [follows] principle  2: Takes a new rule from the warehouse team in week 9 and reorders the backlog
              Welcome changing requirements, even late
  [against] principle  2: Freezes the requirement list after week 4; later asks go to a change board
              Welcome changing requirements, even late

People together (principles 4, 5, 6, 11): 2 of 4 behaviours follow their principle
  [follows] principle  4: Has a warehouse supervisor in the team room for an hour every morning
              Business people and developers work together daily
  [follows] principle 11: Lets the team decide how the tracking service is split
              Let the team organise its own design
  [against] principle 11: Has an architect outside the team draw the service boundaries
              Let the team organise its own design
  [against] principle  6: Replies to design questions only in a ticket queue, never in person
              Converse face to face

Pace and craft (principles 8, 9, 10): 1 of 2 behaviours follow their principle
  [against] principle  8: Worked three weekends in the last two months to hold a date
              Keep a pace everyone can hold indefinitely
  [follows] principle  9: Keeps one hour a day for tests and refactoring, release week included
              Pay continuous attention to technical excellence

Learning (principle 12): 1 of 1 behaviour follows its principle
  [follows] principle 12: Holds a 45-minute retrospective every fortnight and changes one thing
              Reflect, then tune the way of working

Overall: 7 follow, 5 work against a principle
Principles this list touches: 2, 3, 4, 6, 7, 8, 9, 11, 12
Principles no observation covers: 1, 5, 10
Principles with a behaviour on each side: 2, 7, 11
  principle 2: Welcome changing requirements, even late
  principle 7: Working software measures progress
  principle 11: Let the team organise its own design

Seven behaviours follow their principle and five work against one. The themes say more than the total: customer value scores 3 of 5, people 2 of 4, pace and craft 1 of 2. Three principles have a behaviour on each side, which is the useful finding: the team both welcomes a late change and freezes its requirement list, both shows working software and reports progress by tasks moved. Those contradictions are where a conversation starts.

Three principles, 1, 5 and 10, have no observation at all. That is not a pass; it means nobody looked. A principle with no evidence either way is the next thing to go and watch, not a box to tick.

Where the Manifesto came from, and how far it travelled

The text was not designed by a standards body. It came out of two meetings of people who each already had a method that worked. Among the approaches they spoke for were Extreme Programming, Scrum and Crystal, together with DSDM, Feature-Driven Development, Adaptive Software Development and Pragmatic Programming, and they were, by the published history’s own account, surprised to agree on anything. Walk through how it happened:

Two details matter for project work. First, the authors wrote about software, because software was what they built; every principle says “software” or “development”, and applying them to a warehouse move or a merger takes a translation the text does not provide. Frameworks that grew from it did that work later: the 2020 edition of the Scrum Guide removed the terms left over from information technology, such as testing, system, design and requirement, so its framework reads for any complex work. The same edition also stopped describing teams as self-organizing and called them self-managing, choosing what to work on as well as who does it and how.

Second, nothing here is an authority you can cite to end an argument. A predictivepredictive approach: A way of delivering a project that fixes scope, schedule and cost early and works through planned phases with a gate at the end of each; users see the result at the end. More in “Choosing predictive, agile or hybrid delivery” plan is not forbidden by a page that seventeen volunteers put their names to; it is simply the wrong tool when the requirements are still unknown. The Manifesto’s own weight comes from the methods that carried it, not from the page.

Practise: values, principles and misreadings

Decide what each value ranks, read behaviours against the right principle, and correct the quotations teams get wrong. A wrong answer says what it misses, and the idea you find hardest comes back:

Interview questions

Warm-up (fresher to 2–5 years): what does the word over claim in each of the four values?

It claims a ranking, not an exclusion. Each value puts two useful things side by side and says which one to serve when they conflict: people and conversation ahead of process and tooling, something that works ahead of a complete description of it, working with the customer ahead of arguing the agreement, and changing the plan ahead of following it. The sentence after the four lines makes this explicit: the items on the right have value, and the items on the left have more. So a team that drops its documents, its contract or its plan has not applied the Manifesto; it has applied half of one line. In an interview, give the pair and then the case where you chose the right-hand item anyway, such as a regulated handover document, and say why that was consistent.

Warm-up (fresher to 2–5 years): a sponsor says agile teams write no documentation. What do you answer?

That the Manifesto ranks working software above comprehensive documentation and keeps both. I answer with three questions: who reads this document, when, and what do they do after reading it. A document with a named reader and a decision attached gets written; one that exists because a template asks for it does not. Then I name what my team does write: the operations handover, the architecture decisions, the public interface, the things the next team cannot reconstruct from the code. Principle 9’s continuous attention to technical quality is impossible without some of that. The honest summary is that agile work changes the audience and the timing of documentation, not its existence.

Two harder questions follow, about a release rhythm an organisation will not change and a team spread across time zones. Sketch your answer before you open the first step of each:

Key takeaways

• Each of the four values ranks two useful things and says which to serve when they compete, so processes, documents, contracts and plans are kept rather than discarded.
• The twelve principles turn the values into project behaviour: what to deliver and how often, who to work with daily, what pace to hold, how much care to spend and when to reflect.
• Shortening the release rhythm of one invented 48-week project from twelve weeks to two cut the mean wait of finished work from 6.8 weeks to 0.6 and gained 74 weeks of customer use from identical work.
• The three misreadings, no documentation, no planning and no contracts, all come from reading a value’s left-hand item as its only item, and the principles contradict each of them.
• Reading a team’s own behaviour against the principles by theme finds contradictions and blind spots; a single score out of twelve invites ranking and suggests no change.
• Seventeen people representing Extreme Programming, Scrum, Crystal and other methods agreed the text in 2001 about software, and later frameworks such as the 2020 Scrum Guide dropped the information-technology terms so the ideas travel further.