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