# Agile Principles & Methodologies

Core values, principles, and major frameworks for iterative, adaptive software development.

---

## Agile Manifesto (2001)

### Values
> **Individuals and interactions** over processes and tools  
> **Working software** over comprehensive documentation  
> **Customer collaboration** over contract negotiation  
> **Responding to change** over following a plan

### Principles (Selected)
1. **Early and continuous delivery** of valuable software
2. **Welcome changing requirements**, even late in development
3. **Deliver working software frequently** (weeks, not months)
4. **Business people and developers** work together daily
5. **Build projects around motivated individuals** — trust them
6. **Face-to-face conversation** is most effective
7. **Working software** is the primary measure of progress
8. **Sustainable pace** — sponsors, developers, users maintain constant pace indefinitely
9. **Continuous attention to technical excellence** and good design
10. **Simplicity** — maximize the amount of work not done
11. **Self-organizing teams** produce best architectures/requirements/designs
12. **Regular reflection** on how to become more effective

---

## Common Practices Across Frameworks

| Practice | Scrum | Kanban | XP |
|---|---|---|---|
| Small batches | ✓ | ✓ | ✓ |
| Self-organization | ✓ | ✓ | ✓ |
| Daily coordination | ✓ | ✓ | ✓ |
| Estimates & velocity | ✓ | | ✓ |
| Focus on finishing | | ✓ | |
| Make work visible | | ✓ | |
| Explicit workflow | | ✓ | |
| Manage WIP explicitly | | ✓ | |
| ATDD (Acceptance TDD) | | | ✓ |
| Continuous integration | | | ✓ |

**Insight**: These aren't competing — they're complementary. Effective teams blend them.

---

## Scrum

### Roles
| Role | Responsibility |
|---|---|
| **Product Owner** | Maximize value; own Product Backlog; decide *what* |
| **Scrum Master** | Coach team on Scrum; remove impediments; facilitate events |
| **Developers** | Build the increment; own Sprint Backlog; decide *how* |

### Events (Time-boxed)
| Event | Duration | Purpose |
|---|---|---|
| **Sprint** | ≤1 month (fixed) | Container for all other events |
| **Sprint Planning** | ≤8 hours | What + How for this Sprint |
| **Daily Scrum** | 15 min | Inspect progress toward Sprint Goal |
| **Sprint Review** | ≤4 hours | Inspect increment; adapt Product Backlog |
| **Sprint Retrospective** | ≤3 hours | Inspect process; plan improvements |

### Artifacts
| Artifact | Description |
|---|---|
| **Product Backlog** | Ordered list of everything needed; single source of truth |
| **Sprint Backlog** | Sprint Goal + selected PBIs + plan |
| **Increment** | Sum of all Done PBIs; usable, potentially releasable |

### Key Concepts
- **Definition of Done** — Shared understanding of "complete"; applies to every Increment
- **Sprint Goal** — Single objective for the Sprint; provides focus
- **Product Goal** — Long-term objective for the Product

### When Scrum Works Well
- Complex adaptive problems
- Cross-functional teams (2-10 people)
- Work can be planned in Sprint increments
- Product Owner available and empowered

---

## Kanban

### Three Principles
1. **Visualize** — Make work and workflow explicit
2. **Limit WIP** — Stop starting, start finishing
3. **Enhance flow** — Optimize for smooth, predictable delivery

### Core Practices
| Practice | Description |
|---|---|
| **Visualize workflow** | Kanban board (physical/digital); columns = workflow states |
| **Limit WIP** | Explicit limits per column/state; creates pull system |
| **Manage flow** | Monitor WIP, throughput, cycle time, work item age |
| **Explicit policies** | Clear entry/exit criteria per column; documented |
| **Feedback loops** | Regular reviews (service delivery, operations, risk) |
| **Improve collaboratively** | Evolutionary change; scientific method |

### Kanban Metrics (Mandatory Flow Measures)
| Metric | Definition |
|---|---|
| **WIP** | Work items started but not finished |
| **Throughput** | Items finished per unit time |
| **Work Item Age** | Time since item started |
| **Cycle Time** | Time from start to finish |

**Little's Law**: `WIP = Throughput × Cycle Time` — More WIP = longer cycle time

### When Kanban Works Well
- Maintenance/support work (unplannable)
- Continuous flow preferred over iterations
- Teams respecting current roles (evolutionary change)
- Need for explicit workflow visualization

---

## Extreme Programming (XP)

### Values
**Communication, Simplicity, Feedback, Courage, Quality Work**

### Core Practices (Interconnected — do together)

| Practice | Description |
|---|---|
| **Planning Game** | Customer prioritizes stories; developers estimate; plan weekly/quarterly |
| **Small Releases** | Working software every 1-2 weeks; production frequently |
| **Metaphor** | Shared system metaphor guides design vocabulary |
| **Simple Design** | Passes tests, reveals intent, no duplication, fewest elements |
| **Testing** | Test-first (unit + acceptance); all tests pass always |
| **Refactoring** | Continuous design improvement; remove duplication |
| **Pair Programming** | Two developers, one machine; all production code |
| **Collective Ownership** | Anyone can improve any code; no silos |
| **Continuous Integration** | Integrate + test on every commit; 10-minute build |
| **40-Hour Week** | Sustainable pace; overtime = process problem |
| **On-site Customer** | Real customer available full-time for questions |
| **Coding Standard** | Shared style; code looks like one person wrote it |

### XP Lifecycle
```
Quarterly Cycle (Release)
    │
    ├── Weekly Cycle (Iteration) × N
    │       │
    │       ├── Monday: Plan week (customer picks stories)
    │       ├── Tue-Thu: Develop (pair, test-first, refactor, CI)
    │       ├── Friday: Demo + Retrospective
    │       │
    │       └── Slack: Low-priority tasks to drop if behind
    │
    └── Spike: Time-boxed research for unknowns
```

### When XP Works Well
- Co-located teams (2-10 people)
- High change rate, unclear requirements
- Team embraces discipline (pairing, TDD, CI)
- Customer available full-time

---

## Choosing / Blending

### Decision Factors
| Factor | Favors Scrum | Favors Kanban | Favors XP |
|---|---|---|---|
| **Work predictability** | Plannable | Unpredictable | Plannable but changing |
| **Team structure** | Cross-functional | Specialist-heavy | Cross-functional |
| **Change frequency** | Sprint boundaries | Continuous | Continuous |
| **Engineering discipline** | Moderate | Variable | High (TDD, pairing, CI) |
| **Customer availability** | Sprint Review only | As needed | Full-time on-site |

### Hybrid Approaches (Common)
- **Scrumban** — Scrum events + Kanban board/WIP limits + flow metrics
- **Scrum + XP** — Scrum framework with XP engineering practices
- **Kanban + XP** — Flow-based with XP technical practices

### Disciplined Agile Insight
> "Scrum and Kanban are not merely different sets of practices, they are based on different models of transformation. Scrum urges big changes; Kanban involves small evolutionary changes. DA takes a guided continuous improvement approach."

---

## Scaling Frameworks (Brief)

| Framework | Approach | Best For |
|---|---|---|
| **SAFe** | Prescriptive, heavy | Large enterprises, regulated |
| **LeSS** | Minimal, Scrum-based | 2-8 teams, product-focused |
| **Nexus** | Scrum + integration team | 3-9 Scrum teams |
| **Spotify Model** | Squads/Chapters/Tribes/Guilds | Autonomous teams, culture-first |
| **Team Topologies** | Team types + interaction modes | Org design for flow |

---

## Anti-Patterns

| Anti-Pattern | Fix |
|---|---|
| **Cargo cult** — ceremonies without purpose | Understand *why*; adapt to context |
| **Fixed scope + fixed date** | Agile fixes time/quality; scope varies |
| **No Definition of Done** | Define and enforce DoD |
| **Product Owner as proxy** | PO must have authority + availability |
| **WIP unlimited** | Set WIP limits; manage flow |
| **No technical practices** | Scrum needs XP practices for sustainability |
| **Estimation obsession** | Estimate to plan, not to commit; use forecasts |

---

## Related Notes

- [[Methodologies/Scrum-Guide]] — Detailed Scrum reference
- [[Methodologies/Kanban-Method]] — Kanban deep dive
- [[Methodologies/Extreme-Programming]] — XP practices detail
- [[Methodologies/Team-Topologies]] — Team structure for flow
- [[Methodologies/Engineering-Culture]] — Blameless, learning organization
- [[Testing/Test-Driven-Development]] — TDD as XP practice
- [[DevOps/CI-CD-Best-Practices]] — CI as XP practice

---

*Sources: Agile Manifesto, Scrum Guide (scrumguides.org), Kanban Guide (kanbanguides.org), Extreme Programming Explained (Kent Beck), Agile Alliance, PMI Disciplined Agile, Software Engineering: A Modern Approach, Martin Fowler*