The Manifesto: 4 values, 12 principles, 17 people

The Agile Manifesto was written in February 2001 at Snowbird, Utah by 17 practitioners frustrated with heavyweight, document-driven processes. It is deliberately short — four value statements, each of the form "we value X over Y, and while there is value in Y, we value X more." The right-hand items are not dismissed; they are simply outweighed.

The 12 principles, grouped

Interviewers rarely want all 12 recited. Group them into themes so you can reason about them:

• Customer & value (1, 3): highest priority is satisfying the customer through early and continuous delivery; deliver working software frequently (weeks, not months).
• Change (2): welcome changing requirements, even late — agile harnesses change as competitive advantage.
• People & collaboration (4, 5, 6, 11): business and developers work together daily; build projects around motivated individuals; face-to-face conversation is the most efficient channel; the best architectures emerge from self-organizing teams.
• Sustainable pace & excellence (8, 9): sponsors, developers, and users should sustain a constant pace indefinitely; continuous attention to technical excellence and good design enhances agility.
• Simplicity (10): maximizing the work NOT done is essential.
• Measure & adapt (7, 12): working software is the primary measure of progress; at regular intervals the team reflects and tunes its behavior.

Agile vs waterfall: the core mechanical difference

Waterfall runs the SDLC phases once, sequentially, front-loading all requirements and design. Agile runs the phases many times in short cycles, delivering a usable slice each time. The difference is not "planning vs no planning" — it is batch size and feedback frequency.

Iterative vs incremental (they are different)

These two words get used interchangeably and shouldn't be. Incremental = building the product one feature-slice at a time (add the login screen, then the dashboard, then reports). Iterative = repeatedly refining the same thing (rough sketch → detailed → polished). Good agile is both: each iteration adds a new increment AND revisits earlier ones based on feedback.

The classic illustration: to build a car incrementally you'd deliver a wheel, then two wheels, then a chassis — none usable until the end. Iteratively-and-incrementally you deliver a skateboard, then a scooter, then a bike, then a car — every step is a usable vehicle that teaches you something.

When agile fits — and when it doesn't

Agile is not universally correct. Its assumptions (frequent delivery, evolving requirements, an available customer) can be false.

• Fits: unclear or evolving requirements, need for fast market feedback, software you can release incrementally, engaged product owner, co-located or well-connected team.
• Struggles: hard regulatory sign-off gates (some medical/aerospace/defence), fixed-scope fixed-price contracts, systems that cannot ship partially (a bridge, a satellite launch), or an organization with no available customer/stakeholder to give feedback.

Common misconceptions

• "Agile means no documentation / no planning." False — agile plans continuously (release plan, sprint plan, backlog) and documents what's needed. It rejects speculative upfront documentation, not all of it.
• "Agile means no deadlines." False — agile often fixes the date and flexes scope; that is more deadline-driven than waterfall.
• "Agile = Scrum." Scrum is one framework; Kanban, XP, SAFe, and others are also agile. Agile is a mindset/values set, not a process.
• "Agile means going fast / cutting corners." Principle 9 explicitly demands technical excellence; skipping tests is anti-agile because it slows future change.
• "We do standups, so we're agile." Ceremonies without the values is "cargo-cult agile" or "dark scrum."

Scrum in one frame

Scrum is a lightweight framework (defined in the ~13-page Scrum Guide, last revised 2020) for delivering value in short cycles called sprints. It is built on empirical process control resting on three pillars: transparency, inspection, and adaptation. Everything in Scrum — the roles, artifacts, and events — exists to create a regular inspect-and-adapt loop. Scrum is intentionally incomplete: it tells you the skeleton, not your engineering practices.

Its five values: commitment, courage, focus, openness, and respect.

The three accountabilities (roles)

The 2020 Guide dropped the word "roles" in favor of "accountabilities," and renamed "Development Team" to "Developers" inside a single Scrum Team.

A Scrum Team is typically 10 or fewer people. There are no sub-teams and no hierarchy inside it.

Artifacts and their commitments

Each of the three artifacts has a "commitment" that gives it focus and measures progress against it:

Product Backlog items are refined ("grooming") continuously: split, estimated, and clarified so the top of the list is sprint-ready. An increment is only real once it meets the Definition of Done.

The five events

The Sprint is a container event (1 month or less) holding the other four. Every event is time-boxed — a maximum, not a target.

Definition of Done vs Acceptance Criteria

These get conflated constantly. Acceptance Criteria are specific to one backlog item — the conditions that make that story correct. Definition of Done is a checklist that applies to every item — the shared quality bar that makes an increment releasable.

Story: "As a user I can reset my password"
  Acceptance Criteria (this story only):
    - reset link expires after 30 min
    - link is single-use
    - user sees confirmation email

Definition of Done (EVERY story):
    - code reviewed & merged to main
    - unit + integration tests pass in CI
    - no new critical/high SonarQube issues
    - docs updated, feature behind a flag
    - deployed to staging

Work that doesn't meet the DoD is not part of the increment; it returns to the Product Backlog. A weak DoD ("it works on my machine") is where hidden debt accumulates.

Sprint length tradeoffs

Shorter sprints mean more feedback loops and lower risk per sprint, but proportionally higher ceremony overhead. Two weeks is the industry default because it balances the two.

The board and the pull system

Kanban (Japanese for "signboard/visual card") is a flow-based method for continuous delivery — no fixed iterations. Work is visualized on a board of columns representing workflow stages; each card is a work item that moves left to right. The defining property is that it is a pull system: a downstream stage pulls the next item when it has free capacity, rather than an upstream stage pushing work forward. This makes overload visible and self-limiting.

Backlog | Ready | Dev (WIP≤3) | Review (WIP≤2) | Done
  ...   |  #14  |  #11  #12   |     #9         |  #1
        |  #15  |  #13        |                |  #2
"Pull" = Review finishes #9 → pulls #11 from Dev → Dev pulls #14 from Ready

Kanban's four core practices: visualize the workflow, limit WIP, manage flow, and improve collaboratively (evolutionary change). Unlike Scrum, it prescribes no roles and no timeboxes.

WIP limits: the whole point

A WIP (work-in-progress) limit caps how many items may sit in a column at once. It is the mechanism that turns a board into a flow system. When a column is full, no new work enters — the team must finish or unblock existing work first. This surfaces bottlenecks instead of hiding them under a growing pile.

• Stop starting, start finishing. High WIP feels productive but multiplies context-switching and lengthens cycle time for everything.
• A blocked full column forces the team to swarm on the blocker rather than start yet another item.
• Rule-of-thumb starting point: WIP per column ≈ number of people who can work that stage, sometimes minus one to force slack and collaboration.

Lead time vs cycle time

These are the two headline flow metrics and they are constantly confused.

Lead time ≥ cycle time, always — lead time includes the waiting-in-queue portion. If lead time is huge but cycle time is small, your problem is queueing/prioritization, not engineering speed.

Cumulative Flow Diagram

A CFD stacks the count of items in each workflow state over time, as bands. It is the single most information-dense Kanban chart:

• Band widening (vertical thickness) = WIP growing in that state — a forming bottleneck.
• Vertical distance between the "arrived" and "departed" curves at a point = approximate WIP.
• Horizontal distance between the top (arrival) and bottom (departure) curves = approximate lead time.
• Bands should climb in roughly parallel, steady stripes. A ballooning band means work enters faster than it leaves.

Little's Law applied to flow

Little's Law is the mathematical backbone of Kanban. For a stable system:

Average WIP = Average Throughput × Average Cycle Time

Rearranged for planning:
  Cycle Time = WIP / Throughput

Example: WIP = 10 items, Throughput = 2 items/day
  Cycle Time = 10 / 2 = 5 days per item on average

The lever this exposes: to ship faster (lower cycle time) with the same throughput, reduce WIP. You cannot simply "work harder" — with fixed throughput, cutting WIP from 10 to 6 drops average cycle time from 5 to 3 days. This is the rigorous justification for WIP limits, and a favourite whiteboard question.

Scrum vs Kanban vs Scrumban

Scrumban replaces sprint-based planning with a pull trigger: when the "Ready" queue drops below a threshold, hold a just-in-time planning session to refill it.

Why estimate in points, not hours

Humans are bad at absolute time estimates but good at relative comparison — we can reliably say "B is about twice A" even when we can't say how many hours A takes. Story points capture relative size, a blend of effort, complexity, and uncertainty/risk, deliberately decoupled from wall-clock time. This dodges two problems: (1) hours vary by who does the work; a senior and a junior disagree on hours but often agree on relative size; (2) hour estimates invite treating estimates as commitments and get weaponized into deadlines.

The Fibonacci scale and why it's non-linear

Teams estimate on a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100 (plus 0, ½, and "?"). The gaps widen deliberately: as items get bigger, our ability to distinguish sizes drops, so the scale should not offer false precision. There is no meaningful difference between a "16" and a "17," so the scale forces a choice between 13 and 20.

• A big number is a signal, not an estimate: 8+ usually means "split this story." A 13 is a warning that the item isn't well understood.
• "?" means "we can't size this — we need a spike" (a timeboxed investigation).
• Points are only comparable within a team. A Team A "5" and a Team B "5" are unrelated; never sum points across teams or use them for performance comparison.

Planning poker

Planning poker is consensus-based relative estimation designed to defeat anchoring bias.

1. PO reads a story; team asks clarifying questions.
2. Everyone privately selects a card (Fibonacci value) and reveals simultaneously — this prevents the loudest/most-senior voice from anchoring everyone.
3. If estimates diverge (e.g., someone says 3, someone says 13), the high and low voters explain their reasoning — this is where hidden assumptions and risks surface.
4. Re-vote until convergence (not necessarily unanimity — "close enough").

The real value is the conversation, not the number. A 3-vs-13 split almost always means the two people are imagining different scopes; surfacing that is worth more than the final estimate.

Velocity and capacity planning

Velocity = points of Done work completed per sprint, averaged over the last 3-6 sprints. It's an empirical, backward-looking observation used to forecast forward: a backlog of 120 points at a velocity of ~20/sprint is roughly 6 sprints away.

Velocity samples: 18, 22, 20, 19, 24, 21  → avg ≈ 20.7/sprint
Backlog remaining: 120 points
Forecast: 120 / 20.7 ≈ 6 sprints (use a range: 5-7)

Capacity is different: it's this sprint's available hours/days given holidays, PTO, on-call, and part-time allocation. You plan a sprint by checking that selected points fit within both your average velocity AND this sprint's reduced capacity (e.g., a sprint with two people on vacation should commit to fewer points than average).

T-shirt sizing and relative sizing

For coarse, early-stage work (roadmap epics, pre-refinement) teams often use T-shirt sizes — XS/S/M/L/XL — instead of numbers. It's faster, feels less like false precision, and defuses the "points = hours" argument with non-technical stakeholders. Sizes map loosely to point ranges when needed (S≈1-2, M≈3-5, L≈8-13, XL≈"split it").

Both are forms of relative sizing: pick a well-understood reference story as your "anchor" (e.g., "the config-toggle story is our 3"), then size everything by comparison to it rather than from scratch. This keeps a team's scale consistent over time.

#NoEstimates and estimation traps

The #NoEstimates movement argues estimation is often wasteful ceremony: instead of sizing, slice work into similar-small pieces and forecast by counting throughput (items/week) using historical flow data. Proponents say a team shipping ~7 items/week can forecast just as well as one summing points — without the estimation meetings. Critics note that stakeholders and budgets often genuinely need a forecast, and that #NoEstimates quietly reintroduces estimation as "make everything the same size."

Common estimation traps:

• Points as productivity KPI. The moment velocity becomes a target, teams inflate estimates (Goodhart's Law) and it stops measuring anything.
• Comparing velocity across teams. Meaningless — scales are team-local.
• Anchoring & groupthink in poker (see above).
• Padding & the student syndrome — inflated estimates get consumed anyway (work expands to fill time / Parkinson's Law).
• Estimating unrefined stories — garbage in, garbage out; refine first.

The universal SDLC phases

Every SDLC model sequences the same core phases; the models differ only in how often and in what order they run them.

1. Requirements — gather and specify what the system must do (functional + non-functional).
2. Design — architecture, data models, interfaces, the "how."
3. Implementation — write the code.
4. Testing / Verification — confirm it meets requirements.
5. Deployment / Release — ship to users.
6. Maintenance — fix, patch, evolve (typically the longest and costliest phase over a product's life).

Waterfall

The original (Royce, 1970 — ironically presented as a strawman). Phases run once, strictly sequentially; each is fully completed and signed off before the next begins, cascading downward like a waterfall.

• Strengths: simple, highly documented, clear milestones and contracts, easy to manage/audit, works when requirements are truly fixed and well understood.
• Weaknesses: no working software until late; requirements errors surface only at test/UAT when they're most expensive; extremely poor at absorbing change; big-bang integration risk.
• Use when: requirements are stable and known, regulatory/contractual sign-off gates are mandatory, technology is well understood (e.g., a short, well-defined migration).

V-Model

An extension of waterfall that bends the sequence into a "V": the left arm is decomposition (requirements → system design → module design), the right arm is integration/testing, and each design level is paired with a corresponding test level defined at the same time as the design.

Requirements ───────────────► Acceptance testing
   System design ──────────► System testing
      Module design ─────► Integration testing
          Code (bottom of the V) → Unit testing

Key idea: you write the acceptance test plan when you write the requirements, not at the end. This is "verification and validation" made explicit. Still sequential and rigid like waterfall, so it shares waterfall's poor tolerance for change — but it front-loads test planning, which reduces late surprises. Common in safety-critical/embedded (automotive, medical devices).

Iterative, incremental, and Spiral

Iterative/incremental models run the phases in repeated cycles, each producing a more complete version — a middle ground between waterfall's single pass and agile's rapid loops.

Spiral (Boehm, 1988) is the risk-driven model. Each loop of the spiral has four quadrants: (1) determine objectives, (2) identify and resolve risks (often via a prototype), (3) develop and test, (4) plan the next iteration. The distinguishing feature is that the biggest risks are tackled first, and each loop is preceded by explicit risk analysis. It's powerful but heavyweight and expensive — suited to large, high-risk, long-running projects (aerospace, big government systems) where risk analysis pays for itself.

Agile as an SDLC model

As an SDLC model, agile runs all phases inside each short iteration (sprint), delivering a working increment every cycle. Requirements, design, build, and test happen continuously and concurrently rather than as gated phases. It maximizes adaptability and feedback frequency at the cost of upfront predictability of scope and long-horizon documentation. (Covered mechanically in the Scrum and Kanban modules.)

Comparison and when to use which

Why code review exists

Code review serves four distinct goals, and confusing them causes bad reviews: (1) catch defects before they ship, (2) share knowledge so no code has a single owner (bus-factor), (3) maintain consistency with team conventions, and (4) collective ownership — the team, not the author, owns the code. Studies (SmartBear/Cisco) suggest review effectiveness drops sharply past ~400 lines reviewed at once and past ~60 minutes of continuous review — which is the strongest argument for small PRs.

PR best practices

• Keep them small — ideally under ~400 lines / one logical change. Split refactors from behavior changes.
• Write a real description — what changed, why, how to test, screenshots, links to the ticket. The diff shows what; the description must supply why.
• Self-review first — read your own diff before requesting review; you'll catch half the comments yourself.
• Automate the boring stuff — formatting, linting, and style should be enforced by CI/pre-commit, never by a human reviewer. Humans review logic, design, and edge cases.
• Respond to every comment and don't merge with unresolved threads; use "nit:" to mark non-blocking suggestions.
• Review promptly — a PR sitting for days blocks the author and grows merge conflicts; treat review as an interrupt, not a someday task.

A review checklist

Giving and receiving feedback

Review is a social act as much as a technical one; tone determines whether it builds or corrodes a team.

• Critique the code, not the person — "this function could…" not "you always…".
• Ask, don't command — "what happens if this is null?" invites thought; "add a null check" shuts it down.
• Distinguish blocking from optional — label nits, praise good work explicitly, reserve "request changes" for real problems.
• As author: assume good intent, don't take it personally, push back with reasoning (not ego) when you disagree, and if a thread exceeds ~2-3 round-trips, move to a call.

Trunk-based vs GitFlow

Trunk-based development is a prerequisite for true continuous delivery and correlates strongly with elite DORA performance — long-lived branches are the enemy of frequent, low-risk integration. GitFlow shines when you must support multiple released versions in the wild (e.g., an installed desktop app), but its long-lived branches create integration debt.

Working agreements, pairing, and conventional commits

Working agreements are a team's self-authored, explicit norms — e.g., "PRs reviewed within 4 business hours," "main is always green," "no merging on Fridays after 3pm," "two approvals for auth code." They convert unspoken assumptions into shared, revisable rules (revisit them in retros).

Pair programming = two engineers, one keyboard (driver/navigator), continuous real-time review. Mob programming extends this to the whole team on one problem. Both trade raw parallelism for fewer defects, faster onboarding, and instant knowledge sharing — most valuable on complex, high-risk, or unfamiliar work; wasteful on routine tasks.

Conventional Commits is a commit-message standard that makes history machine-parseable and enables automated semantic versioning + changelogs:

<type>[optional scope]: <description>

feat(auth): add OAuth2 login          → minor version bump
fix(api): handle empty payload        → patch bump
feat(api)!: drop v1 endpoints         → MAJOR bump (! = breaking)
docs, chore, refactor, test, perf...  → no release

Types drive tools like semantic-release to compute the next version
and generate CHANGELOG.md automatically.

The testing pyramid

The pyramid (Mike Cohn) prescribes the shape of a healthy test suite: many fast, cheap, isolated tests at the bottom; few slow, expensive, broad tests at the top.

The rationale is economic: a unit test pinpoints the exact broken function in milliseconds; an E2E failure tells you only that "something" broke and takes minutes to run and hours to diagnose. You want most of your signal from the fast, precise layer.

Ice-cream cone and hourglass

Two common broken shapes:

• Ice-cream cone (inverted pyramid): mostly manual + E2E tests, few unit tests. Slow feedback, flaky, expensive to maintain — the most common legacy-project failure mode.
• Hourglass: lots of unit and E2E but a hollow middle. Integration bugs (the seams between components — the most common place real bugs live) slip through because nothing tests the wiring.

TDD and BDD

TDD (Test-Driven Development) is a design discipline, not just a testing one — the red-green-refactor loop:

1. Red — write a failing test for the next tiny behavior.
2. Green — write the minimum code to pass it (even if ugly).
3. Refactor — clean up with the test as a safety net.

Writing the test first forces you to design the interface from the caller's perspective and guarantees the code is testable. BDD (Behavior-Driven Development) raises TDD to business-readable specs using Given/When/Then (Gherkin), so non-engineers can validate behavior:

Feature: Password reset
  Scenario: Reset link expires
    Given a user requested a reset 31 minutes ago
    When they click the reset link
    Then they see "This link has expired"
    And no password change is applied

TDD asks "is the code correct?"; BDD asks "are we building the right behavior?" — they're complementary, not competing.

Coverage vs confidence

Code coverage measures which lines/branches executed during tests — it's a proxy for how much is tested, not a measure of test quality. 100% coverage with weak assertions catches nothing; 70% coverage on the critical paths with sharp assertions catches plenty.

// 100% line coverage, ZERO confidence:
test("adds", () => { add(2, 2); });   // runs the line, asserts nothing

// Real test:
test("adds", () => { expect(add(2, 2)).toBe(4); });

CI quality gates and shift-left

A quality gate is an automated, non-negotiable checkpoint in CI that blocks a merge/deploy if criteria aren't met. Typical gates on a PR:

• All tests pass; build succeeds.
• Coverage doesn't drop below the floor (e.g., no new code under 80%).
• No new critical/high static-analysis or security findings (SonarQube, Semgrep, dependency CVE scan).
• Linting/formatting clean; no secrets detected.
• Required approvals present.

Shift-left is the strategy of moving these checks as early as possible — pre-commit hooks and PR-time CI rather than a pre-release QA phase — because (recall the 10×-per-phase cost curve) a bug caught at commit time is orders of magnitude cheaper than one caught in production. Fast feedback is the whole game.

Flaky-test handling

A flaky test passes and fails non-deterministically on the same code. Flakes are corrosive: they erode trust in the whole suite, and once people habitually re-run red builds, a real failure gets re-run and ignored too.

Common causes: timing/race conditions (sleeps, async not awaited), test-order dependence / shared mutable state, reliance on real network or wall-clock time, and non-deterministic data (unseeded randomness, unsorted collections). Handling policy:

1. Quarantine, don't ignore — move the flake out of the blocking suite into a monitored bucket so it stops blocking others, and file a ticket. Never just add a blanket retry and forget it.
2. Track flake rate as a metric; make fixing them someone's explicit responsibility.
3. Fix the root cause — fake the clock, seed randomness, isolate state between tests, await properly. Retries mask flakes; they don't cure them.

The four DORA metrics

DORA (DevOps Research and Assessment, led by Nicole Forsgren, Jez Humble, Gene Kim; the Accelerate book) identified four metrics that together predict software delivery performance. They split cleanly into two pairs — throughput (how fast you deliver) and stability (how safely). The key finding: elite teams are better at both simultaneously — speed and stability are not a tradeoff.

Elite vs low performers

DORA buckets teams into Elite/High/Medium/Low. Approximate benchmarks (they shift year to year — memorize the orders of magnitude, not exact cutoffs):

CI vs Continuous Delivery vs Continuous Deployment

These three "CD-ish" terms are the most-confused thing in this whole topic. They're a progression, each building on the last:

The one-line mnemonic: Continuous Delivery means every change can be released at the push of a button; Continuous Deployment means every change is released, automatically, with no button. The gap between them is a single manual approval step.

Feature flags

Feature flags (toggles) decouple deploy from release: you ship code to production dark (flag off), then turn it on for chosen users independently of the deployment. This is what makes trunk-based development and continuous deployment safe — incomplete work merges to main but stays hidden.

• Release flags: hide in-progress features; enable canary/gradual rollout (1% → 10% → 100%).
• Ops/kill switches: instantly disable a misbehaving feature without a rollback deploy — cuts MTTR dramatically.
• Experiment flags: A/B testing, targeting by cohort.
• Permission flags: premium/beta gating per user.

How the metrics drive improvement

The metrics aren't a scorecard — they're a diagnostic that points at which practice to fix:

• Long lead time? Look for large batch sizes, long-lived branches, slow CI, and manual approval bottlenecks → smaller PRs, trunk-based, faster pipeline.
• Low deployment frequency? Usually big-batch releases and manual release steps → automate the pipeline, deploy smaller changes more often.
• High change failure rate? Weak testing/quality gates, big risky deploys → shift-left, canary releases, smaller changes.
• High MTTR? Poor observability, no fast rollback, no kill switches → better monitoring/alerting, feature-flag kill switches, automated rollback.

Notice small batch size improves all four at once — it's the common lever. That's why "deploy smaller, more often" is the single most repeated piece of DORA advice.

Measuring team health (beyond the four)

The four metrics measure delivery, not the humans. DORA's later research adds a fifth — reliability (meeting SLOs) — and consistently finds that culture (Westrum's generative/high-trust culture) and low burnout are among the strongest predictors of performance. Complements to track alongside DORA: SPACE framework dimensions (Satisfaction, Performance, Activity, Communication, Efficiency), developer experience surveys, and on-call load.