1. Agile (The Philosophy)
Agile is not a process, a tool, or a certification. It is a set of values expressed in a document called the Agile Manifesto, written in 2001 by 17 software practitioners who were frustrated with heavyweight processes. The entire manifesto fits on an index card:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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
That is, while there is value in the items on the right, we value the items on the left more.
Notice the last line — it does not say documentation and planning are worthless. It says that when forced to choose, favor the left column. Agile admits a fundamental truth about software: we don't know everything at the start, and the fastest way to learn is to build something, show it to users, and iterate.
Agile is the umbrella philosophy. Scrum and Kanban are specific implementations of that philosophy, the way Ubuntu and Fedora are specific implementations of Linux.
2. Scrum (The Rituals)
Scrum is the most widely adopted Agile framework. It provides a strict structure of roles, events, and artifacts designed to create a predictable rhythm of delivery.
Core mechanics:
| Element | Detail |
|---|---|
| Cadence | Work is divided into fixed-length iterations called Sprints (typically 2 weeks). |
| Roles | Product Owner (decides what to build), Scrum Master (removes blockers, facilitates process), Development Team (builds the product). |
| Artifacts | Product Backlog (ordered list of everything that could be built), Sprint Backlog (subset committed to for this sprint), Increment (the working software produced). |
The four ceremonies (events):
- Sprint Planning (start of sprint) — The team selects items from the Product Backlog and commits: "We will complete these items in the next 2 weeks."
- Daily Standup (every day, 15 min max) — 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 a manager.
- Sprint Review (end of sprint) — The team demonstrates working software to stakeholders. Not slides. Working software.
- Sprint Retrospective (end of sprint) — The team reflects: What went well? What didn't? What will we change? This is the most important ceremony — it's the team's mechanism for self-improvement.
The commitment model: Scrum's power comes from the sprint boundary. Once a sprint starts, the scope is locked. No one can add work mid-sprint (in theory). This protects the team from constant context-switching and gives stakeholders a clear contract: "You'll see results in 2 weeks."
Velocity: After several sprints, teams track their velocity — the average number of story points completed per sprint. Velocity is not a performance metric; it's a forecasting tool. If a team's average velocity is 30 points and the remaining backlog contains 120 points, you can forecast approximately 4 more sprints (8 weeks) to completion. Velocity is only meaningful when compared to the same team's own historical data — comparing velocity across teams is meaningless because point scales are relative.
3. Kanban (The Flow)
Kanban originated in Toyota's manufacturing system in the 1940s and was adapted for knowledge work by David Anderson in the 2000s. The word "kanban" (看板) is Japanese for "signboard" or "visual card." Where Scrum uses time-boxes (sprints) to create rhythm, Kanban uses WIP (Work In Progress) limits to create flow.
Core mechanics:
| Element | Detail |
|---|---|
| Cadence | Continuous. There are no sprints. Work flows through the system as capacity allows. |
| Visualization | A Kanban board with columns representing stages: To Do → In Progress → Review → Done. |
| WIP Limits | Each column has a maximum number of items allowed. If "In Progress" has a WIP limit of 3, no one can start a 4th item until one moves to "Review." |
| Goal | Maximize throughput (items completed per unit time) and minimize cycle time (how long one item takes from start to finish). |
Why WIP limits matter: Imagine a highway. When it's at 70% capacity, traffic flows smoothly. At 100% capacity, everything grinds to a halt. WIP limits keep your team at 70% — counterintuitively, doing fewer things simultaneously means finishing more things overall. The mantra is: "Stop starting, start finishing."
This is backed by Little's Law from queuing theory: Cycle Time = WIP ÷ Throughput. If your team has 10 items in progress and completes 2 per day, the average cycle time is 5 days. If you reduce WIP to 4 items, cycle time drops to 2 days — even though throughput (2/day) hasn't changed. Less work in flight means faster delivery of each individual item.
A practical Kanban board for a DevOps team might look like:
| Backlog | Ready | In Progress (WIP: 3) | In Review (WIP: 2) | Done |
|---------|-------|-----------------------|---------------------|------|
| item-7 | item-5| item-3 | item-1 | |
| item-8 | item-6| item-4 | | |
| item-9 | | | | |
If item-1 is stuck in Review, the team must resolve it before pulling new work — this surfaces bottlenecks immediately rather than hiding them behind a growing queue.
Scrum vs. Kanban: When to Use Which
| Factor | Scrum | Kanban |
|---|---|---|
| Work type | Feature development with plannable scope | Ops, support, maintenance, interrupt-driven work |
| Team maturity | Teams that need structure and focus | Teams comfortable with self-direction |
| Predictability | Sprint velocity enables forecasting | Cycle time metrics enable forecasting |
| Change tolerance | Changes wait until next sprint | Changes can enter the backlog anytime |
| Best for | Product teams building new features | SRE/Platform teams handling incidents + projects |
A common interview question is: "Your team does both feature work and on-call incident response. Which methodology do you use?" The strong answer: "A hybrid. We use Kanban as the base (continuous flow for incidents) with reserved capacity for planned sprint-like feature work — typically 60% planned / 40% reactive. Pure Scrum breaks down when half your sprint gets consumed by pages. Pure Kanban without any planning horizon lets strategic work get perpetually crowded out by urgent-but-less-important reactive tasks."
Key Point: Methodology choice is a tool-selection problem, not a religion problem. The best teams often use a hybrid — Scrum's ceremonies (planning, retros) combined with Kanban's WIP limits and continuous flow. What matters is that the team has shared agreements about how work enters, flows through, and exits their system. A methodology that the team ignores is worse than no methodology at all.