Kanban
A flow-based method that visualises work on a board, limits how much is in progress at once, and pulls new work only when there is capacity, with no fixed iterations.
Kanban has two core ideas: make the work visible, and limit work in progress. You put every item on a board with columns for each stage (to do, in progress, review, done), and you cap how many items can sit in each active column at once. When a column is full, nobody starts new work until something moves out. That cap is the whole point: it forces the team to finish things before starting more.
The contrast with Scrum is the cadence. Scrum batches work into fixed sprints and re-plans at each boundary. Kanban has no sprints. Work is pulled continuously as capacity frees up, and you can change priorities at any moment without waiting for a sprint to end. There is no commitment ceremony, no sprint review, no artificial two-week box. Both are implementations of the same agile goal: tight feedback and the ability to change course on evidence.
Pick Kanban when work arrives unpredictably and interrupt-driven (support, operations, platform teams), or when a team is mature enough that the sprint scaffolding has become pure overhead. Pick Scrum when a team needs the rhythm and the forced review to build delivery discipline, or when stakeholders need a predictable demo cadence to plan around.
Worked example of what a WIP limit actually does to a team: an “in progress” column capped at three, on a team of five, means two people will sometimes have nothing of their own to start. The instinctive reaction is that this is waste, idle engineers. It is the opposite. Those two are now forced to help finish the three things already in flight, review a teammate’s work, or pair on the blocker, instead of opening a fourth task and spreading the team thinner. The discomfort of a full column is the mechanism working: it converts “everyone busy, nothing shipping” into “fewer things in flight, things actually finishing”. Teams that cannot tolerate that brief idleness quietly raise the limit until it stops constraining anything, and then wonder why throughput did not improve.
The honest version: WIP limits are where the value is, and they are also the part teams quietly ignore. A Kanban board with no WIP limit is just a to-do list with extra columns. If the team is starting five things and finishing none, the limit is the fix, not a bigger board.