Agile Methods
Agile is not a methodology. It is a family of methodologies united by a shared value system: responding to change over following a plan, working software over comprehensive documentation, individuals and interactions over processes and tools, customer collaboration over contract negotiation. The Agile Manifesto (2001) codified these values, but the practices predate it by decades — XP emerged in the late 1990s, Lean manufacturing in the 1950s, iterative development as far back as the 1930s (Shewhart cycle). This skill catalogs the major Agile frameworks, their mechanics, their failure modes, and guidance for selecting the right approach for the problem domain.
Agent affinity: lei (agile/lean), brooks (systems management)
Concept IDs: bus-business-planning, bus-stakeholder-theory, crit-problem-analysis, crit-evidence-evaluation
Framework Overview
| # | Framework | Core idea | Best for | Team size | |---|---|---|---|---| | 1 | Scrum | Time-boxed sprints with defined roles | Product development, stable teams | 5-9 | | 2 | Kanban | Continuous flow with WIP limits | Operations, support, variable demand | Any | | 3 | XP | Engineering discipline as survival | High-change environments, quality-critical | 4-12 | | 4 | SAFe | Scaled Agile across portfolios | Enterprise, 50+ developers | 50-500+ | | 5 | Lean SD | Eliminate waste, defer decisions | Any; strategic overlay | Any | | 6 | GSD | Structured phases + autonomous execution | AI-assisted, solo/small team | 1-5 |
Framework 1 — Scrum
Roles
Product Owner. Single voice of the customer. Owns the backlog. Makes prioritization decisions. Does not tell the team how to build — only what and why. A committee cannot be a Product Owner; the role requires one person with authority to make trade-offs.
Scrum Master. Servant-leader who removes impediments, facilitates ceremonies, and protects the team from external disruption. Not a project manager. Not a boss. The Scrum Master succeeds when the team can self-organize without them.
Development Team. Cross-functional, self-organizing group of 5-9 people. No sub-teams, no titles within the team. Everyone shares accountability for the sprint goal.
Ceremonies
Sprint Planning. The team selects work from the backlog for the upcoming sprint. Two questions: (1) What can we deliver this sprint? (2) How will we do the work? Output: sprint backlog and sprint goal. Time-box: 2 hours per sprint week (4 hours for a 2-week sprint).
Daily Standup (Daily Scrum). 15 minutes, same time, same place. Each person answers: What did I do yesterday? What will I do today? What's blocking me? This is a synchronization meeting, not a status report to management.
Sprint Review. Demonstrate completed work to stakeholders. Inspect the increment. Gather feedback. This is not a presentation — it is a working session. Stakeholders should interact with the software.
Sprint Retrospective. The team reflects on process: What went well? What didn't? What will we change? The retrospective is the engine of continuous improvement. Without it, Scrum degrades into mechanical ritual. (Cross-reference: retrospective-learning skill for detailed formats.)
Artifacts
Product Backlog. Ordered list of everything the product might need. Owned by the Product Owner. Never complete — it evolves as the product and market evolve.
Sprint Backlog. Subset of the product backlog selected for the current sprint, plus the plan for delivering it. Owned by the Development Team.
Increment. The sum of all completed product backlog items during a sprint and all previous sprints. Must meet the Definition of Done.
Worked Example — Sprint Planning
Scenario. A team of 7 has a 2-week sprint. Historical velocity: 34 story points per sprint. The product backlog has 12 stories at the top, estimated between 2 and 13 points.
Planning session. The Product Owner presents the top items and explains the sprint goal: "Users can complete checkout without creating an account." The team discusses each story, asking clarifying questions. They pull stories in order:
| Story | Points | Running total | |---|---|---| | Guest checkout flow | 8 | 8 | | Payment validation | 5 | 13 | | Order confirmation email | 3 | 16 | | Address autocomplete | 5 | 21 | | Cart persistence | 8 | 29 | | Error handling for declined cards | 3 | 32 |
At 32 points, the team stops. The next story is 5 points (total 37), which exceeds their velocity. They commit to 6 stories, 32 points. The sprint goal is achievable.
What can go wrong. The Product Owner pressures the team to take the 7th story ("just stretch a little"). The Scrum Master intervenes: sustainable pace matters more than one sprint's output. Overcommitment is the most common sprint planning failure — it erodes trust in velocity as a forecasting tool.
When Scrum Works
- The product is evolving and requirements change frequently
- A stable, cross-functional team works on a single product
- Stakeholders are available for regular feedback
- The organization respects the sprint boundary (no mid-sprint scope injection)
When Scrum Fails
- The team is pulled across multiple products (fractured attention)
- Work items are mostly small, unpredictable interrupts (use Kanban instead)
- Leadership treats Scrum ceremonies as status meetings
- "Agile" is adopted as vocabulary without the underlying value shift ("Agile theater")
Framework 2 — Kanban
Core Principles
Visualize the workflow. A Kanban board makes invisible work visible. Columns represent stages: To Do, In Progress, Review, Done. Every work item is a card that moves left to right.
Limit work in progress (WIP). Each column has a maximum number of items. If the limit is reached, no new work enters that column until something exits. WIP limits are the mechanism by which Kanban controls flow.
Manage flow. Measure lead time (request to delivery) and cycle time (start to delivery). Optimize for smooth, predictable flow — not for utilization.
Make policies explicit. Definition of Done, pull criteria, escalation rules — all visible on the board.
Improve collaboratively. Use data (cumulative flow diagrams, lead time distributions) to identify bottlenecks and experiment with solutions.
Flow Metrics
Lead time. Time from when a request enters the system to when it is delivered. This is the customer's experience.
Cycle time. Time from when work begins to when it is delivered. This is the team's experience.
Throughput. Number of items delivered per unit time.
WIP. Number of items in progress at any moment.
Little's Law. Lead Time = WIP / Throughput. This is not a heuristic — it is a mathematical law for stable systems. It means you can reduce lead time by reducing WIP without increasing throughput.
Worked Example — WIP Limit Experiment
Scenario. A support team has 5 developers. Their board has no WIP limits. Average cycle time: 8 days. Average WIP: 20 items. Throughput: 2.5 items/day.
Intervention. Set WIP limit of 3 per developer (15 total for the "In Progress" column). Initially painful — developers must finish current work before starting new work.
After 4 weeks. WIP stabilizes at 12. Cycle time drops to 5 days. Throughput remains 2.5 items/day. By Little's Law: 12 / 2.5 = 4.8 days (close to observed 5 days). The team delivers the same volume but faster, because items spend less time waiting.
When to Use Kanban Over Scrum
- Work arrives unpredictably (support tickets, operations)
- Items vary wildly in size and cannot be batched into uniform sprints
- The team serves multiple stakeholders with competing priorities
- You want to improve an existing process incrementally rather than adopt a new framework wholesale
Framework 3 — Extreme Programming (XP)
The 12 Practices
XP is built on engineering discipline, not management process. The practices reinforc