Agile Methodology: Manifesto, Values & Principles

The Agile Manifesto (2001) was written by 17 software practitioners as a reaction to heavyweight, documentation-driven methodologies like Waterfall. It defines a set of values and 12 principles for iterative, customer-focused software development.

Four Agile Values

We 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

"While there is value in the items on the right, we value the items on the left more."

12 Agile Principles

• Customer satisfaction through early and continuous delivery of valuable software

• Welcome changing requirements, even late in development. Agile processes harness change for competitive advantage.

• Deliver working software frequently — weeks rather than months. Prefer shorter timescales.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them.

• The most efficient way to convey information is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. Sponsors, developers, and users should maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity — the art of maximizing the amount of work not done — is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective and adjusts accordingly.

Agile vs Waterfall

Waterfall:                          Agile:
  Sequential phases                   Iterative cycles (sprints)
  Requirements frozen upfront         Requirements evolve
  Deliver at the end                  Deliver incrementally
  Change is a problem                 Change is expected
  Big design upfront                  Emergent design
  Works well when:                    Works well when:
    - Requirements are stable           - Requirements uncertain
    - Regulatory compliance             - Innovation / exploration
    - Physical systems                  - Most software products
    - Construction, manufacturing

Common Agile Misconceptions

• "No documentation" — Agile values working software OVER comprehensive docs, not zero docs. Write what adds value.

• "No planning" — Agile plans continuously at multiple horizons (sprint, release, quarter), just not all upfront.

• "No deadlines" — fixed-date releases are common. Agile adjusts scope to meet dates rather than extending dates.

• "Self-organizing means no management" — teams self-organize around the work, but still need leadership and facilitation.

• "Agile means fast with no quality" — XP practices (TDD, CI, pair programming) explicitly address quality.

Agile Frameworks: Scrum, Kanban, XP & SAFe

Scrum (high-level)

Scrum is the most popular Agile framework. Work is organized in fixed-length Sprints (1-4 weeks). Three roles, five ceremonies, three artifacts. See the dedicated Scrum note for detailed coverage.

• Roles: Product Owner (what to build), Scrum Master (process), Development Team (how to build)

• Artifacts: Product Backlog, Sprint Backlog, Increment

• Ceremonies: Sprint Planning, Daily Standup, Sprint Review, Retrospective, Backlog Refinement

• Key: Sprint commitment is protected — no scope changes during Sprint without team consent

• Definition of Done (DoD): shared agreement on when work is truly complete (coded, tested, reviewed, deployed)

Kanban

• Continuous flow — no fixed iterations. Work moves through stages as capacity allows.

• Visualize work: board with columns (To Do, In Progress, In Review, Done)

• WIP Limits: maximum items per column — prevents multitasking and exposes bottlenecks

• Pull system: team pulls new work when capacity frees up (not pushed by manager)

• Lead time: time from request to delivery. Cycle time: time from start to delivery. Both are key metrics.

• Cumulative Flow Diagram (CFD): visualize WIP, throughput, and lead time trends over time

• Kanban vs Scrum: Kanban suits operations/support teams with unpredictable incoming work; Scrum suits product development with planned features

Extreme Programming (XP)

XP focuses on engineering practices that enable Agile at the code level. Less about process, more about technical excellence.

• Test-Driven Development (TDD): write failing test → write code → refactor (Red-Green-Refactor)

• Pair Programming: two developers at one machine — driver writes code, navigator reviews in real time

• Continuous Integration: integrate and test multiple times per day; broken builds block the team

• Refactoring: continuously improve code design without changing behavior

• Simple Design: do the simplest thing that could possibly work (YAGNI — You Aren't Gonna Need It)

• Small Releases: deploy to production frequently — get real feedback fast

• Collective Code Ownership: anyone can improve any part of the codebase; no code silos

• Sustainable Pace: 40-hour weeks; overtime consistently leads to quality problems and burnout

SAFe & Scaling Agile

• SAFe (Scaled Agile Framework): most popular enterprise scaling framework. Adds Program Increment (PI) planning at the portfolio level.

• LeSS (Large-Scale Scrum): minimal additional framework on top of Scrum. One Product Backlog, multiple teams. Keeps Scrum integrity.

• Spotify Model: squads (autonomous feature teams), tribes (related squads), chapters (skill communities), guilds (cross-tribe interest groups). Informal, often misunderstood.

• Nexus: 3-9 Scrum teams working on one product. Adds Integration Team and Nexus Sprint Review.

• Scaling pitfall: applying SAFe process overhead to a 10-person team. Scale only what's needed.

• Key scaling challenge: dependency management between teams. Use a dependency board or "Scrum of Scrums" sync.

Agile: Estimation, Metrics & Common Pitfalls

Estimation Techniques

• Story Points: relative measure of effort/complexity — not hours. Fibonacci scale (1, 2, 3, 5, 8, 13) reflects uncertainty growth.

• Planning Poker: each team member secretly picks a card; reveal simultaneously; discuss outliers; re-estimate until consensus.

• T-Shirt Sizes: XS, S, M, L, XL — quick relative sizing without false precision.

• Three-Point Estimation: (Optimistic + 4×Most Likely + Pessimistic) / 6 — good for time estimates when needed.

• #NoEstimates: count stories instead of estimating. Works when stories are consistently small.

• Affinity Mapping: silently group user stories by size on a wall — fast for large backlogs.

Key Agile Metrics

Velocity        — story points completed per sprint. Use for sprint planning, not comparison between teams.
                  Track trend, not single sprint. Expect variation of ±20%.

Burn-down chart — remaining work (points or tasks) over sprint days. Should trend toward zero.
                  Flat line = blocked. Sudden drop = scope reduction.

Burn-up chart   — completed work + total scope over time. Shows scope changes explicitly.

Lead Time       — request to delivery. Indicates responsiveness to customers.
Cycle Time      — start of work to delivery. Indicates team throughput.

Throughput      — stories/features completed per week. More reliable than velocity.

NPS             — Net Promoter Score from customers. Outcome metric, not output.

Escaped defects — bugs found in production. Quality indicator.
                  High escaped defects → improve DoD, testing, review process.

Retrospective Formats

• Start / Stop / Continue: what should we start doing, stop doing, keep doing?

• 4Ls: Liked, Learned, Lacked, Longed For — structured reflection

• Mad / Sad / Glad: emotional temperature check — surfaces team morale issues

• Sailboat: wind (helps), anchors (slows), rocks (risks), sun (goals) — visual metaphor

• Timeline Retro: plot events on a timeline; rate team mood per event — for longer retrospectives

• Key rule: one actionable improvement item per retro. Many retros produce long lists that are never acted on.

Common Agile Anti-Patterns

• Wagile / Scrumfall: Scrum ceremonies applied to Waterfall planning. Sprints exist but requirements are frozen. No real iteration.

• Fake Product Owner: PO is a proxy with no authority to make decisions. All decisions escalate. Bottleneck.

• Sprint as mini-Waterfall: days 1-3 design, days 4-7 code, days 8-10 test. Testing compressed, quality suffers.

• Velocity as a management target: "this sprint we must hit velocity 40." Teams pad estimates; velocity becomes meaningless.

• No Definition of Done: "done" means different things to different people. Technical debt accumulates.

• Skipping Retrospectives: "we're too busy to improve our process." Teams never inspect or adapt.

• Ignoring technical debt: feature pressure suppresses refactoring. Velocity declines over time. The system becomes harder to change.

• Hero culture: one person owns critical knowledge. Bus factor of 1. Blocks collective code ownership.