In the first post in this series, I introduced the concept of Complex Adaptive Systems (CAS) and how constraints can trigger innovative ideas. In this post, I’ll investigate constraints in more detail and contrast how Kanban and Scrum use constraints to enable successful software teams.
Both Scrum and Kanban use constraints to limit work in progress (WIP), foster decentralized decision making, and focus the team on near-term deliverables. However, the two approaches have significant differences.
Constraints in Scrum and Kanban
| Purpose of Constraint | Scrum | Kanban |
| Limiting WIP | Sprint Backlog | WIP Limits |
| Near-term Deadline | Sprint Review | SLAs for Individual Work Items |
| Focused objective | Sprint Goal | Work Visualized on a Kanban Board |
| Prioritization Buffer | Sprint Backlog | “Ready” Queue |
| Roadmap | Release and Product Backlog | Product and Product Backlog |
Scrum: Timeboxes and Ceremonies
In Scrum, the most important constraint is the timeboxed iteration, or Sprint, and the regular cadence of ceremonies. The Sprint limits WIP through the creation of a Sprint Backlog. This backlog is usually estimated in story points and sized based on past performance. If the team has a consistent velocity (e.g., 30 points per Sprint), capacity planning starts with that number and adjusts it based on circumstances.
The Sprint Planning ceremony ensures agreement on the content of the Sprint Backlog and its size. During the iteration, the backlog serves as a prioritization buffer. Outside of that buffer, the Product Owner can make as many reprioritization decisions as necessary, but the Sprint Backlog should only be adjusted in rare circumstances, so that the team can focus on delivering that Sprint’s Goal.
The Sprint Goal is a clear expression of value, the focus for that Sprint. Daily standup meetings allow the team to self-organize and determine how to progress towards the goal. The Sprint Review gives them—and their stakeholders—feedback on whether that goal was met, and informs the objective of the next iteration.
Kanban: WIP Limits and Visualization
In Kanban, limited WIP and visualization are the main constraints. WIP can be limited in many different ways, but the most common is to cap the amount of work in any given state. A maximum of five stories might be permitted “In Progress,” or a maximum of three in “Test.” The WIP constraint in Kanban focuses the team on flow, and not on time.
Attention is focused on the work by use of a visual Kanban board. On the board, everyone can see what is being worked and what state it is in. This triggers self-organization; the board fosters a collaborative understanding of what is most important. Aligned and decentralized decision making flows naturally from this shared understanding. Scrum teams often leverage visualizations like this as well. Scrum does not explicitly call for them; Kanban does.
Rather than up-front estimates of size and complexity, Kanban uses Service Level Agreements (SLAs) based on historical cycle time. These become a constraint that encourages focus. Note that the SLA is not an estimate; it is a prediction based on past performance. SLAs operate on each and every individual item in a Kanban system, allowing a continual flow; work is not batched up into timeboxed iterations as in Scrum.
Kanban also uses a prioritization buffer, called a Ready Queue. This short backlog contains items that are ready to be worked on, but are not yet in progress. Teams and their Product Owners are free to alter the prioritization of items in the Ready Queue at any time, giving them flexibility to rapidly adjust based on new information.
Although there are no specific ceremonies in Kanban, it is customary to employ daily standups, regular grooming sessions, and demonstrations of new functionality. These can happen on a cadence, or they can be triggered by the flow of work. For example, a team might hold a grooming session once they have only two items in the Ready Queue; they might demonstrate new functionality after five items have been completed. An exception is the Sprint Planning event; Kanban teams have no need for them because there is no iteration.
Finding the Sweet Spot
Is one of these approaches superior to the other? Not in all circumstances; remember, CAS are very sensitive to context. However, if we examine the constraints employed by Scrum and Kanban, we gain some important insights. The ability of a CAS to support the creation of new and innovative ideas is called Emergent Potential. Greater Emergent Potential means a higher likelihood that creative approaches will be discovered; Emergent Potential is maximized in that “sweet spot” between constraints that are too restrictive and too loose.
Scrum is very portable and easily adopted because it provides a well-defined structure. The structure is intended to rest in that “sweet spot.” If it isn’t a perfect fit, teams should Inspect and Adapt, tailoring their specific Scrum implementation in light of experience to better fit their needs. However, this can be very difficult.
In situations where the business is unwilling or unable to leave the team focused for the duration of an iteration, the Scrum process can become a hindrance. If a team is responsible for production support, for example, it may be impossible to work effectively in Sprints. Support cannot always be nicely packaged up into iteration-sized chunks.
Mature Agile teams may also have difficulty with Scrum. The iteration boundaries and associated ceremonies can provide less value as the team becomes more effective at working together. In those situations, more flexibility may be needed to allow a team to maximize its potential.
In both of these situations, Kanban may be a better fit because the constraints in a Kanban system are more sensitive to context. This gives the team greater flexibility and the promise of increased Emergent Potential.
Recommended Heuristics
If you’re uncertain about whether to employ Scrum or Kanban, consider these factors. Scrum, because it is a well-defined, portable framework, will work well for teams that are newly forming or just learning Agile. Scrum is easy to adopt and can quickly deliver value. More mature teams, who are already familiar with Agile, or who have deeply embedded ways of working, tend to be better off with Kanban. The increased contextual sensitivity of Kanban will offer those teams greater potential.
These guidelines are relatively simple and straightforward, but I’ve found them to be a nice set of heuristics that work well with Agile teams. Learn more about what heuristics are and how to apply them in the next post in this series.