tibsfox/gsd-skill-creator/agile-methods

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 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:

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 reinforce each other — adopting some without others weakens the system.

1. Planning game. Customer and developers negotiate scope for each iteration.
2. Small releases. Ship frequently. Smaller releases mean faster feedback.
3. Metaphor. Shared vocabulary (system metaphor) to align understanding.
4. Simple design. Build for today's requirements, not tomorrow's speculation.
5. Test-driven development (TDD). Write the test before the code. Red-green-refactor.
6. Refactoring. Continuously improve design without changing behavior.
7. Pair programming. Two developers, one keyboard. Driver writes code; navigator reviews in real time.
8. Collective code ownership. Anyone can change any code. No gatekeepers.
9. Continuous integration. Merge to mainline multiple times per day. Build and test on every merge.
10. 40-hour week. Sustainable pace. Overtime is a sign of planning failure.
11. On-site customer. A real customer sits with the team to answer questions.
12. Coding standards. Agreed conventions so code reads as if one person wrote it.

TDD Cycle

1. Red. Write a failing test that specifies the desired behavior.
2. Green. Write the minimum code that makes the test pass.
3. Refactor. Clean up the code while all tests remain green.

Why TDD matters. The test suite is a living specification. It catches regressions immediately. It documents intent. It gives developers confidence to refactor aggressively. Without TDD, refactoring becomes terrifying and stops — technical debt accumulates.

When XP Works

• Requirements change weekly or daily
• Quality failures are expensive (financial, safety, reputational)
• The team is co-located or has high-bandwidth communication
• Management supports the engineering investment (TDD and pairing look "slow" to uninformed observers; they are faster over project lifetime)

Framework 4 — SAFe (Scaled Agile Framework) Overview

SAFe extends Agile to large organizations through four configurations: Essential, Large Solution, Portfolio, and Full. The core construct is the Agile Release Train (ART) — a long-lived team of teams (50-125 people) that plans, commits, and delivers together in Program Increments (PIs) of 8-12 weeks (typically 5 sprints of 2 weeks + 1 Innovation and Planning sprint).

PI Planning. All teams in the ART gather (physically or virtually) for a 2-day planning event. Teams identify dependencies, negotiate scope, and commit to PI objectives. This ceremony is SAFe's highest-value practice.

When SAFe is appropriate. Large organizations (100+ developers) building complex systems with significant cross-team dependencies. SAFe provides structure for coordination at scale.

When SAFe is overhead. Small organizations or autonomous teams. SAFe's ceremony load is heavy — if you can achieve alignment with lighter mechanisms (Scrum of Scrums, informal coordination), prefer them.

Framework 5 — Lean Software Development

Poppendieck's 7 Principles

Mary and Tom Poppendieck translated Toyota Production System principles to software: