Agile, Scrum, and Kanban for DevOps teams

Agile is a philosophy. Scrum is a framework that implements it. Kanban is a method that complements or replaces it. DevOps teams must understand all three because how you plan work directly affects how fast you deliver it. A team with a world-class CI/CD pipeline but month-long planning cycles still ships monthly.

Agile in 60 seconds

The Agile Manifesto (2001) distilled four values: individuals over processes, working software over documentation, customer collaboration over contracts, responding to change over following a plan. These values emerged because waterfall planning failed in environments where requirements changed faster than software could be delivered.

Agile does not prescribe specific practices. It establishes priorities. Scrum and Kanban are two popular frameworks that operationalize those priorities differently.

Scrum: time-boxed delivery

Scrum organizes work into sprints, fixed-length iterations typically lasting one or two weeks. Each sprint has a goal, a backlog of work items, and a set of ceremonies.

graph LR
  PB["Product Backlog"] --> SP["Sprint Planning"]
  SP --> SB["Sprint Backlog"]
  SB --> Dev["Development (1-2 weeks)"]
  Dev --> Review["Sprint Review"]
  Review --> Retro["Retrospective"]
  Retro --> PB
  Dev -->|"daily"| Standup["Daily Standup"]
  Standup --> Dev

The Scrum cycle. Work flows from the product backlog into a sprint, through development, and into review. Retrospectives feed improvements back into the process.

Sprint planning

The team selects items from the product backlog to commit to for the sprint. Selection is based on priority (set by the product owner) and capacity (estimated by the team). The output is a sprint backlog: a concrete list of work the team will complete.

Good sprint planning takes 1-2 hours for a two-week sprint. If it takes longer, the backlog is not refined enough.

Daily standups

A 15-minute synchronization meeting. Each team member answers three questions: What did I do yesterday? What will I do today? What is blocking me? The standup is not a status report to management. It is a coordination mechanism for the team.

Common failure modes:

• Going over 15 minutes because people give detailed technical updates
• Turning it into a problem-solving session instead of identifying blockers to solve later
• Skipping it because “we use Slack” (async updates miss the coordination value)

Backlog grooming

Also called backlog refinement. The team reviews upcoming work items, clarifies requirements, splits large items into smaller ones, and estimates effort. This happens mid-sprint so that sprint planning is efficient.

The goal is to keep the top of the backlog “ready”: items are small enough to finish in a sprint, requirements are clear, and acceptance criteria are defined.

Sprint review

The team demonstrates completed work to stakeholders. This is not a presentation. It is a working software demo. Stakeholders provide feedback that shapes future backlog items.

Retrospectives

The team reflects on the sprint process itself. What went well? What did not? What will we change? Retrospectives are the engine of continuous improvement. Without them, teams repeat the same mistakes.

Effective retrospective formats:

• Start, Stop, Continue. Simple and direct. What should we start doing, stop doing, and keep doing?
• Timeline. Map the sprint chronologically and identify peaks (good moments) and valleys (frustrations).
• Five Whys. Pick the biggest problem and ask “why” five times to find the root cause.

Kanban: flow-based delivery

Kanban does not use sprints. Work flows continuously through a board with columns representing stages: To Do, In Progress, Review, Done. The core mechanism is limiting work in progress (WIP).

graph LR
  Backlog["Backlog"] --> Todo["To Do (WIP: 5)"]
  Todo --> InProgress["In Progress (WIP: 3)"]
  InProgress --> Review["Review (WIP: 2)"]
  Review --> Done["Done"]

A Kanban board with WIP limits. The limits force the team to finish work before starting new work, preventing the pile-up that kills throughput.

WIP limits

WIP limits are the single most important Kanban practice. They cap the number of items allowed in each column. When a column is full, no new items can enter until an existing item moves forward. This creates back-pressure: if review is full, developers help review instead of starting new work.

Why this matters:

• Context switching destroys productivity. A developer juggling five tasks in progress completes all five slower than if they focused on one at a time.
• Bottlenecks become visible. When work piles up before a column, the constraint is obvious. You fix it by adding capacity to the bottleneck, not by starting more work upstream.
• Flow becomes predictable. With stable WIP limits, cycle time (how long an item takes from start to done) stabilizes. Predictable cycle times enable reliable delivery commitments.

Measuring flow

Kanban teams track three metrics:

Scrum vs Kanban

The choice is not binary. Many teams use a hybrid (“Scrumban”) that takes sprint cadence from Scrum and WIP limits from Kanban.

How delivery cadence connects to pipeline maturity

Sprint length should not exceed your deployment capability. If your team runs two-week sprints but can only deploy monthly, the sprint cadence creates an illusion of speed. Work “completes” in the sprint but queues for deployment.

The ideal state: sprint review demonstrates features that are already in production. This requires:

1. Automated CI/CD that can deploy on every merge
2. Feature flags that decouple deployment from release
3. Small work items that fit in a single deployment
4. Trunk-based development that avoids long-lived integration branches

As pipeline maturity improves, sprint length often decreases. Teams that deploy continuously sometimes abandon sprints entirely in favor of Kanban, because the sprint boundary adds overhead without adding value.

Common mistakes

Cargo-cult Scrum. Running all the ceremonies without understanding the principles. Daily standups become status meetings. Retrospectives produce action items nobody follows up on.

No WIP limits. Using a Kanban board without WIP limits is just a to-do list on a wall. The limits are what create flow.

Estimating in hours. Time-based estimates are consistently wrong. Story points or t-shirt sizes capture relative complexity, which is what planning actually needs.

Skipping retrospectives. Teams under delivery pressure skip retros first. This is exactly backwards. Retros are how you reduce future delivery pressure.

What comes next

The next article covers branching strategies and explains why trunk-based development accelerates the delivery cadence your Agile process depends on.