Kanban vs Scrum: When Flow Beats Sprints
Teams argue about this as though one method were more advanced than the other, and the argument usually settles nothing because it is being held about the wrong subject. The question is not which method a team has earned. It is how the work arrives at them, and a team whose demand lands daily with short deadlines will break a two-week commitment every cycle no matter how well it plans.
Section 5 of the PMBOK® Guide Eighth Edition holds both among the techniques available to a team. That framing is worth keeping, because it puts the choice where it belongs: these are tools selected to suit a situation, and selecting between them starts with looking at the demand.
What each one is built on
Scrum is built on a protected cycle. The team agrees what it will attempt over a fixed period, the period is defended against interruption, and the value comes from that protection: planning is worth doing because the plan will survive, and the team can be judged on a whole increment. Everything else in the method, the events, the roles, the review, exists to make the cycle work.
Kanban is built on limited work in progress and pull. Items enter the system continuously, the number allowed in each state at once is capped, and nothing new is started until something finishes. The value comes from the limit: it makes queues and blockages visible almost immediately, and it stops a team carrying eleven half-finished things, which is the condition in which everything is late and nothing is finished.
Four signals that point to flow
Work arrives unpredictably. Where the most important item of the fortnight has not been written yet on the day the fortnight starts, a commitment to a fixed scope is a fiction that everybody maintains politely. Support desks, operational change, defect close-out and technical query handling all live here.
Items vary enormously in size. Where the work ranges from twenty minutes to three weeks, relative sizing and cycle-level commitment stop being useful, because the estimate carries no information and the planning session becomes an exercise in dividing the indivisible.
Priorities move inside the week. Where a genuine reprioritisation can arrive on Tuesday and must be honoured by Thursday, a two-week container is being broken continuously, and a method whose discipline consists of protecting the container will spend its energy on something the organisation has already overruled.
The team is shared or interrupt-driven. Where the same people carry operational responsibility alongside project work, they cannot commit to a fixed cycle honestly, and asking them to do so trains everybody to treat commitments as aspirations.
Where none of those hold, and a team is dedicated, stable and working on something that can be planned a fortnight at a time, the protected cycle earns its keep and the rhythm is worth having.
A technical query desk that failed in sprints
A fit-out contractor on a large commercial building ran a small technical support team: two design coordinators and an engineer, handling technical queries from the trades on site. Queries arrived at the site office door all day, about fifteen to twenty a week, and the contract gave the contractor forty-eight hours to answer most of them before the trade could claim standing time.
The team had been put into two-week sprints as part of a wider programme initiative. The intention was reasonable and the result was that every sprint plan was abandoned by the third day. Queries with a two-day clock arrived, they could not wait, and the planned work was pushed aside for them. By the end of the fortnight the team had done a great deal of useful work, none of which was in the plan, and the sprint review had become an exercise in explaining why.
They moved to a flow arrangement and changed very little else. A board on the site office wall with four columns and a limit of two items in progress per coordinator. Queries entered at the left with the date on them, and anything sitting longer than a day in one column got looked at in the morning meeting. The two-week planning session went; a fifteen-minute prioritisation on Monday replaced it.
The visible change was in the standing-time claims, which fell from about five a month to under one. The less visible change mattered more: the board showed that roughly a third of all queries came from two subcontractors and concerned the same two details in the ceiling zone. That pattern had been invisible while the work was being described a sprint at a time. A single coordination meeting with the two trades and the designer removed most of that third permanently.
Keeping the useful parts of both
Cadence without commitment. Much of what teams value in Scrum is the rhythm: a regular point to look at the work together, a regular point to improve how they operate. Both survive perfectly well in a flow system, and a team running continuous flow with a fortnightly retrospective and a monthly stakeholder review has kept the valuable parts of the cycle without pretending its demand is predictable.
Limits in a predictive environment. The work-in-progress limit is the part of Kanban that travels furthest, and it has nothing to do with software. A commissioning team that will not start a fourth system until one of the three in progress is signed off is applying it, and the effect is the same as it is anywhere else: fewer things open, shorter queues, and problems that surface while somebody still has the context to solve them.
For a PMP® candidate, what matters is that the method follows the demand pattern, so a scenario where a team repeatedly abandons its plan mid-cycle is describing a mismatch between the work and its container. A response that reinforces the cycle discipline is treating the symptom. A structured PMP exam preparation course pays close attention to situations where the practice is being followed correctly and the wrong practice was chosen.
A fortnight of history is enough to check this. Look at the last two cycles and count how much of what the team actually did was in the plan at the start. If the figure is below about two-thirds twice running, the container is fighting the demand, and the honest options are to protect the team from the interruptions or to stop planning in containers.
Interested in going further?
Choosing a delivery method is a judgement about demand, capacity and what the organisation will actually allow a team to protect. Omega's PMP® Exam Preparation works through those choices across predictive, adaptive and hybrid settings.
Both methods sit among the techniques described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A180: Facilitation Techniques for Difficult Project Conversations
A179: Brainstorming That Produces Better Decisions
A187: Retrospectives That Lead to Change
A178: SWOT Analysis in Project Management
A182: Multicriteria Decision Analysis Explained
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
