Agile & Scrum

Agile is a family of values and principles for delivering software under uncertainty: welcome change, deliver working software frequently, collaborate with customers, and prefer individuals and interactions over heavyweight process theater. Scrum is the most widely practiced Agile framework — a lightweight set of roles, events, and artifacts that create a cadence of inspection and adaptation.

This page covers Agile values, Scrum mechanics, Definition of Done, and — critically — when Agile fits and when it fails. Architecture in Agile teams is evolutionary: decisions are continuous, documented in ADRs, and validated by delivery.

The Agile Manifesto values individuals/interactions, working software, customer collaboration, and responding to change — while still acknowledging processes, documentation, contracts, and plans. The practical reading for architecture and SDLC:

• Working software is the primary measure of progress — architecture must enable frequent integration.
• Welcome changing requirements — modular boundaries and automated tests make change affordable.
• Sustainable pace — heroics are a process smell, not a culture badge.
• Technical excellence and good design enhance agility — refactoring is delivery work.
• Simplicity — maximize work not done; avoid speculative microservices.

There is no separate "architect" role required by Scrum — but architecture accountability must exist. On larger products, an architecture owner or guild partners with teams without becoming a bottleneck approval board.

Backlog items should be INVEST where possible (Independent, Negotiable, Valuable, Estimable, Small, Testable). See Requirements for story vs use case guidance.

Definition of Done (DoD) is the shared quality bar for calling work complete. Without a strong DoD, "Agile" becomes a factory for unfinished work.

Agile architecture practices:

• Make reversible decisions by default; ADR the irreversible ones.
• Budget capacity for enablers (performance, security, modularity) — not only user stories.
• Use spikes to buy information; timebox them; convert learning into backlog items or ADRs.
• Prefer vertical slices that exercise the real architecture early.
• Align team topology with module boundaries (Conway).

• Fixed-scope, fixed-date, fixed-cost contracts with no change mechanism — Agile theater under Waterfall constraints.
• Stakeholders unavailable for reviews — team builds in a vacuum.
• No DoD — "done" means merged, not releasable.
• Velocity used as a performance weapon — teams game estimates.
• Architecture ignored — sprinting into a distributed ball of mud.
• Compliance needs unmet — must graft traceability deliberately, not pretend sprints replace audits.

Mechanics without purpose fail. Anchor on outcomes:

• Every sprint produces a usable Increment — not only 'code complete'.
• Product Goal and Sprint Goal are visible and used in tradeoff conversations.
• Refinement keeps upcoming items ready enough — without requiring perfect specs.
• Retrospectives produce experiments with owners and follow-up.
• NFR and architecture enablers appear in the backlog with PO support.

Multiple teams need alignment without a central bottleneck: shared product goals, clear module ownership, contract tests between teams, and architecture advisory — not mandatory ticket approval for every change. Frameworks (LeSS, Nexus, SAFe) add structure; adopt only what your coordination pain requires.

Agile does not eliminate requirements work — it slices it. Prefer thin vertical stories with clear acceptance criteria; keep a living NFR list; schedule discovery for fuzzy areas. Product Owners who only prioritize UI chrome and ignore reliability enablers create fragile systems.

Next: Kanban. Also DevOps, Waterfall.