Where the Practices Place the Load
The previous essay handled the common ground: the assumptions Scrum and Kanban share, the failure modes that are structurally analogous across both, the seams at which both practices break for the same reasons. The point of that analysis was to clear away what the choice between them is not about. Where the shared assumptions fail, neither practice will deliver, and which one is chosen does not matter.
This essay handles what is left after that ground has been cleared. The places where the practices genuinely diverge. What each asks of the practitioner. Where each one’s distinctive load-bearing structure sits. And what happens when the choice between them is not really made.
Two bets about what the practitioner brings
The deepest divergence between Scrum and Kanban is not at the level of mechanics. It is at the level of what each practice presumes the practitioner brings to it. The mechanical differences (fixed cadence versus continuous flow, prescribed roles versus offered ones, scheduled events versus event-driven ones) are real, but they are downstream of a more fundamental difference in design philosophy.
Scrum’s bet is that prescription functions as scaffolding. The fixed-length sprint, the defined Product Owner role, the defined Scrum Master role, the prescribed events at prescribed cadence: these are not optional features the team can pick up or put down. They are mandates, and the mandates serve a specific purpose: they force conversations the team would not otherwise have, and impose a discipline the team would not otherwise impose on itself. The bet is that prescription compensates for what the practitioner does not bring.
Kanban’s bet is different in a way that requires care to state accurately. Kanban does not lack prescription; it offers proposals, with reasons, for roles and cadences and operational structures. Service Delivery Manager and Service Request Manager are roles the practice articulates. Replenishment meetings, delivery planning, operations review, strategy review: these are cadences the practice describes, with explanations of why each one matters and what it does. What Kanban does not do is mandate any of them, prescribe their length, or fix their attendance. The proposals are defaults to be adopted or adapted to the team’s situation. The bet is that informed discretion (practitioners engaging with the proposals, understanding the reasons behind them, exercising judgement about which to adopt and how) produces better outcomes than mandate.
These are not two implementations of the same bet with different tunings. They are different bets about the same question: how prescription should function in service of the stance. Both bets are exclusivity assumptions in the technical sense the foundational essay laid out: claims about whether the chosen configuration is the right configuration, in preference to alternatives that were never seriously considered. Scrum bets that mandate is the right answer, compensating for what the practitioner does not bring. Kanban bets that informed discretion is the right answer, serving a practitioner who brings their own discipline. Each bet’s strength is the other bet’s failure mode.
Scrum’s failure mode appears in mature contexts. Where the practitioner brings enough discipline that mandate adds more cost than benefit, the prescription becomes ceremony for its own sake. The events are held because the events are required, not because they produce focus the team would otherwise lack. The Product Owner role is filled because it must be, even when the work would be better served by a different distribution of decision-making authority. The cadence becomes a constraint on responsiveness rather than a structure for it. The practice continues to be executed correctly; the cost has begun to exceed the value, and the assumption that prescription is helping has stopped holding.
Kanban’s failure mode appears in immature contexts, but not in the way the conventional framing suggests. The conventional reading would be that Kanban is for mature teams and Scrum is for immature ones. That reading misses what is actually happening. Kanban’s flexibility delivers benefit only when the practitioner engages with the practice’s proposals as substantive guidance: when policies are formed thoughtfully, WIP limits are held with discipline, operational reviews surface what the system is doing rather than performing the appearance of attention. A team that does not engage in these ways will produce bad policies and call it adaptation, breach WIP limits quietly and call it pragmatism, hold operational reviews that surface nothing and call them done. The practice continues to be executed in form; the substance has hollowed out, and the assumption that flexibility is serving has stopped holding.
The bets are about what kind of relationship the practitioner has to the practice, not about whether the practitioner is generally mature. The asymmetry matters because it shapes everything else.
This is also where one of the patterns described earlier in this series lands directly. Your Current Self May Be Impeding Your Future Self described how professional knowledge fuses, over time, with professional identity: the practice stops being something the practitioner does and becomes something they are. A practitioner whose identity has fused with Scrum cannot readily examine whether mandate is still helping or has become ceremony. A practitioner whose identity has fused with Kanban cannot readily examine whether flexibility is still serving or has become permission for absence. Each practice’s bet about the practitioner’s relationship to the practice interacts with the practitioner’s relationship to their own knowledge, and the interaction makes the assumptions harder to assess honestly, not easier. The practitioner who could most usefully evaluate whether the bet still holds is, by the time they have invested deeply enough to do the evaluation, the practitioner least able to make it.
What each practice asks of the work, the people, and the system
Beyond the difference in design philosophy, each practice carries distinctive load-bearing assumptions that have no real counterpart in the other. These are worth surfacing in their own right, because they are where the analysis of each practice does its most specific work.
Scrum’s distinctive assumptions
Three claims stand out, each carrying weight that Kanban’s structure does not require.
The first is an existence assumption about the work itself: that it decomposes into team-scale units of coherent intent. Scrum requires not just that the work flows, but that it can be sliced for a single, persistent, cross-functional team in a way that makes the team’s outputs aggregate into product-level value. This is a stronger claim than it appears. In organisations whose actual work cuts across team boundaries (which is most organisations doing non-trivial work) the assumption fails before any of the cadence questions get a chance to surface. The team can run a textbook sprint and still produce work that does not aggregate, because the slice it was given was the slice the practice required, not the slice the work admitted.
The second is a second existence assumption, this time about role configuration: that a single person can hold the Product Owner role. Scrum compresses the demand side of product development into one human point of decision-making, and the assumption is that one person can carry enough product context, with enough authority, to keep the backlog coherent. The assumption is reliably broken in real organisations, and the way it breaks is structural rather than individual. People senior enough to have the necessary authority rarely have time for the work the role requires. People with time for the work rarely have the authority the role requires. The role compresses two functions that organisations typically separate, and the compression cannot always be sustained, particularly in larger organisations where the demand side is genuinely distributed across multiple stakeholders, none of whom can be reduced to a single backlog-owner without losing the very signal the role exists to capture.
The third is an exclusivity assumption about the configuration of events itself: that the prescribed events are jointly necessary and sufficient to deliver the stance. Daily Scrum, Sprint Planning, Sprint Review, Retrospective, held at the prescribed cadence, together produce the focus, alignment, feedback, and adaptation the practice claims to deliver. The necessity claim is the easier target, and most criticism of Scrum’s meeting-heaviness is aimed there. The sufficiency claim is the more interesting one. Even granting that each event is individually necessary, are these four events together enough to deliver what the stance requires? The assumption is that they are. Whether they are, in any given context, is a question the practice does not engage with directly. The events are prescribed; the sufficiency is taken as given.
Kanban’s distinctive assumptions
Three claims stand out here as well, each load-bearing in ways the practice’s structure makes specific.
The first is a mechanism assumption about how the practice produces its effects: that the practice’s mechanisms together absorb variability on both demand and work sides without destabilising. The mechanisms are process policies (rules that govern how work items move through the flow) and the operational reviews that examine whether those policies are functioning. WIP limits are often named distinctly, and they are the most visible policy in most implementations, but functionally they are a process policy like any other, governing movement rather than occupying a separate category. The variability-absorption claim is a system-level claim that rests on policies and review interacting. Work-side variability (items that turn out to take longer than expected, dependencies that surface mid-flight) is absorbed because cycle-time discipline and WIP discipline create slack the system can use to adapt. Demand-side variability is absorbed because adherence to WIP limits is what makes the system pull-based: intake is regulated against capacity by the policy itself, not by something separate from it. The assumption holds when the policies function and the reviews examine them. WIP limit breaches are the most visible signal the system produces about itself. They are not, in themselves, a failure of the practice; they are the practice working as designed, surfacing that something has shifted. What the breach means depends on the inquiry that follows. Was it political pressure that the team lacked the standing to refuse? An unrecognised type of work that the policies haven’t yet captured and that needs to be made explicit? A misjudgement of capacity that the limits should be revised to reflect? The breach itself is information; absorbing it without inquiry is what reverts the system to push. Pull was never a separate mechanism that could fail on its own; it was the consequence of WIP discipline holding, and WIP discipline is sustained not by avoiding breaches but by examining them. Policies without operational review become documentation rather than constraint. The practice’s variability absorption is a property of the policies-plus-review system, not of any mechanism in isolation. The bet on informed discretion extends to which policies the practitioner adopts and on what grounds. Classes of Service, for example, is itself a contested pattern, treated by some communities as a useful demand-differentiation tool and by others as a disturbance to stable flow that gets misused as soon as it exists. Choosing among these is exactly the kind of trade-off the bet anticipates.
Get Bruno Baketarić’s stories in your inbox
Join Medium for free to get updates from this writer.
The second is another mechanism assumption, this time about what cycle time itself delivers: that minimising cycle time produces value the work can absorb at whatever rate the work can absorb it. Cycle time and learning loop are related but distinct variables. Cycle time is a lower bound on the learning loop: you cannot learn from delivered work faster than you can deliver it. The Sprint Review couples cadence and learning loop tightly by design: in Scrum the two are the same loop. Kanban does not make that coupling. Cycle time can be driven down to whatever the work supports, daily, hourly, faster, without changing the practice, and reducing it does two distinct kinds of work. It produces standalone value independent of any feedback cycle: shorter feedback on technical risk, faster validation of integration assumptions, smaller in-flight scope that could turn out to be wrong, and more responsive adaptation when the team does receive signal worth acting on. It also enables a shorter learning loop, by removing one of the constraints on how fast learning can occur. Whether the learning loop actually is shorter depends on whether users can absorb the released work and produce feedback on it, an absorption assumption that the practice’s broader machinery already takes for granted at the team-business interface. A team that integrates something in two days inside a quarterly-releasing organisation is not producing wasted cycles even if the external feedback arrives later: the standalone value still holds, and the lower bound on learning has been usefully reduced. Where the assumption fails is at a more subtle level. It fails when the team treats cycle time and learning loop as identical, mistaking faster delivery for faster learning, and stops attending to how learning actually translates into adapted work for the work being done. The two are coupled (short cycle time enables short learning loops) but they are not the same thing, and collapsing them loses the distinction between what the practice controls and what the surrounding feedback dynamics control.
The third is a third mechanism assumption, about how the practice produces improvement: that change is best guided by inspection against the system’s actual data, with direction supplied by external drivers, rather than by commitment to an anticipated future state. This is what Kanban’s evolutionary stance actually claims, and it differs from revolutionary change at the level of what guides the change rather than at the level of step size. Revolutionary change is a bet on an anticipated future state producing massive improvement, made by ignoring or discounting the positive aspects of the current system. Evolutionary change starts from the current state, lets external drivers shape what direction is worth pursuing, and uses the practice’s data to inspect whether what was attempted actually moved the system. The size of the change is not the distinguishing feature: Kanban does not exclude larger jumps. What distinguishes the stance is that change is validated against measured behaviour, not against the appeal of the future state being aimed at. Two failure modes. The first is when the team treats the data as authoritative without asking whether the data points at the right things. A team that optimises Kanban metrics inside a deeply broken organisation will, through inspection-against-data, produce a more efficient version of a process whose direction is wrong, because the external drivers that should have set direction were absent or were not engaged with. The second is when the team has external drivers but lacks the willingness to take larger steps when those drivers call for them. The practice does not exclude larger jumps; whether the team will take them when warranted is a separate question, and one the practice cannot answer for the team. The failure is in how the team holds the relationship between data, direction, and step size, not in the change model itself.
Where the load-bearing structures sit
A pattern emerges from the asymmetric assumptions, and it is worth naming directly.
Scrum’s distinctive assumptions are concentrated in claims about the work and the people. The work has to be shaped to admit team-scale slicing. The people have to admit a single Product Owner. The events have to be jointly sufficient as configured. In the foundational essay’s vocabulary, these are existence assumptions and exclusivity assumptions: claims about how the world the practice operates within is shaped, and about whether the chosen configuration is the right configuration for that world.
Kanban’s distinctive assumptions are concentrated in claims about how the practice produces its effects. The mechanisms have to function as a system, with policies and review interacting. Cycle time has to do the two distinct kinds of work it is asked to do, without the team conflating them. Change has to be guided by inspection-against-data with external drivers shaping direction. In the foundational essay’s vocabulary, these are all mechanism assumptions: claims about how the practice’s machinery produces what it claims to produce.
This is not a coincidence. It reflects what the two bets at the level of design philosophy actually buy. Scrum’s mandate-as-scaffolding bet pushes more of the load-bearing structure onto the world the practice is applied to: the work, the people, the role configuration. The practitioner needs less, but the world has to be shaped a particular way. Kanban’s informed-discretion bet pushes more of the load-bearing structure onto how the practitioner runs the practice’s mechanisms. The world can vary more, but the practitioner needs to bring more of their own structure (operating policies, holding inquiries, attending to data) to make the practice cohere.
What this implies for the choice is something more specific than the conventional framing offers. The reader who is choosing between the practices is, in effect, choosing which set of failure modes their context can tolerate. Where the work is shaped right, the people fit, and the role distribution can support a single Product Owner, Scrum’s mandate adds discipline at low cost. Where the work is more variable, the people are configured differently, or the role distribution is more naturally diffuse, Scrum’s existence and exclusivity assumptions begin to fail, and Kanban’s flexibility, given a practitioner who runs the mechanisms as a system, becomes the better fit. Where the practitioner does not run the mechanisms as a system, Kanban’s mechanism assumptions fail in their own way, and Scrum’s mandate is what keeps a discipline the practitioner would not otherwise sustain.
These are not adjudications about which practice is better. They are observations about where each practice’s load-bearing structure sits, and what kinds of conditions activate which failure modes. The reader does the comparison, against their own situation. The analysis surfaces what would have to be assessed.
When the choice is not really made
There is one further pattern worth surfacing, because it shapes how the practices land in real organisations more than the analysis above might suggest. Both practices have failure modes that are not really about the practice at all. They are about the adoption pattern that brought the team to the practice, and about whether the choice was really made.
The Kanban version is the team that adopts Kanban as an escape from Scrum. The team has experienced Scrum’s mandate as constraint, and Kanban looks like relief: fewer prescribed events, no fixed cadence, no required roles. The motive driving the adoption is rejection of what was, not engagement with what is. This sets the team up for failure in a specific way. Kanban’s bet is on informed discretion, which requires engagement with the practice’s proposals as substantive guidance. A team that is escaping prescription will not engage with proposals; the proposals will be experienced as more of what was being escaped from, in softer form. The team will adopt Kanban in name and practise something else in fact: something shaped by what they were fleeing rather than by what they were adopting. The practice fails, but the cause of the failure was the adoption motive, not the practice.
This is structurally similar to the product/service framing the previous essay dispatched. The conventional reading would be that immature teams cannot succeed with Kanban. That reading collapses two distinctions. An immature team can succeed with Kanban, given discipline: discipline that does not have to come from prior experience with the practice but can come from leadership, individual rigor, an external coach who holds the line. What fails is the adoption pattern, not maturity per se. The team that flees Scrum will struggle with Kanban regardless of their general maturity, because the relationship to the practice they are entering is shaped by what they are leaving.
The Scrum version of this failure is the mirror image, and it is at least as common. Teams adopt Scrum not because the practice fits their work but because Scrum is what is there. The pathway to adoption is paved: certifications are cheap and quick, Scrum Masters are abundant in the market, the language is familiar to executives, the organisational machinery for implementing Agile defaults to Scrum without examination. A team that asks what should we adopt finds Scrum already chosen for them by the surrounding ecosystem: by recruitment patterns, by what consultancies offer, by what Agile transformation has come to mean in their organisation. This is the team-level expression of the industry-level pattern the published essay on Agile described: the same selection mechanisms transmitted one layer down, producing un-chosen adoption at the team level rather than at the industry level.
The structural consequence is similar to the Kanban escape pattern. The team has not really chosen the practice. In the Kanban case, they are choosing what they are not; in the Scrum case, they are not choosing at all. In both cases, the practice that gets adopted is not the practice the analysis is testing. The team that fled to Kanban is practising not-Scrum. The team that defaulted into Scrum is practising whatever-the-Scrum-Master-was-trained-in.
The cures are different. The team that fled needs to examine the motive itself; engaging seriously with Kanban’s proposals requires letting go of the escape posture, which is a deliberate, conscious move. The team that defaulted needs to examine the choice they did not make; the remedy is not necessarily to switch but to ask whether the practice they have defaulted into actually fits their work, whether its assumptions hold in their context, whether it is the practice they would have chosen if they had chosen. Both repairs are about making a choice properly that was never properly made, but the choice that was not made differs in each case.
What unifies both failure modes is that they describe teams whose practice does not fit their context for reasons that are not about the practice or the team’s maturity. The reasons are about how the choice was made, or was not. This is a more general observation than either failure mode on its own, and it connects, lightly, to the foundational essay’s point about claims that have acquired the texture of common knowledge. Both Scrum and Kanban can acquire that texture: Scrum at the industry level, Kanban locally, as the practice-of-relief from Scrum. When a practice has acquired enough texture that adopting it stops being a decision, the team practising the result has not asked the questions the analysis surfaces. The assumptions may hold; the assumptions may not. Without the asking, the team cannot know.
What this asks of the reader
Choosing between Scrum and Kanban, after the analysis is done, is not what most readers will have expected when they began. It is not a comparison between two implementations of the same thing. It is a choice between two bets about what the practitioner brings, two configurations of where the load-bearing structure sits, and two failure profiles that the reader’s context will activate or will not.
The question stops being is Scrum or Kanban better. It becomes the more useful one. Given what is now visible about the situation (the work’s shape, the people’s configuration, the practitioner’s discipline, the surrounding environment’s capacity to receive what the practice produces, the motive that would drive the adoption) which set of failure modes is the situation equipped to handle, and which set would the situation expose? That question has answers. The original one did not.
The choice that most organisations made on the practices’ behalf was made on grounds that had nothing to do with these questions. Scrum was selected at the industry level by certifications, training pipelines, consultancies, and transformation programmes, none of which had any necessary relationship to whether the practice would deliver the stance for the work it was being applied to. Teams that adopted Kanban afterwards often did so as relief from the result, which means they entered the second practice carrying the unexamined posture from the first. The reader who has read this far is now equipped to make a choice the original selection mechanism could not make, and the previous adoption pattern would not allow.
That is the practical value of the analysis. Not a verdict. Not a recommendation. A clearer picture of what the choice actually is, and of what would need to be true of the situation for either practice to deliver what its strongest case claims.
A note from the author: This essay developed the assumption-analysis of Scrum and Kanban without engaging with the Kanban Maturity Model (KMM), a body of guidance that sits in the advanced part of the Kanban University curriculum and addresses several of the Kanban-side failure modes described above. A follow-up essay, One Layer Down on Kanban, revisits those failure modes with KMM in view, examines what KMM’s mitigation rests on, and applies the assumption-analysis move to the model itself.
P.S.: Thanks to Florian Eisenberg for reviewing the Draft and giving substantial feedback, almost all of which found its way into the essay.
