Several years ago Corey Ladas proposed a variant of Scrum which exhibited certain Lean-Kanban characteristics. Known by the portmanteau term “Scrumban”, Corey’s approach promoted leaner practices than Scrum was meant for. He sought “…to incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding”. Corey argued that “if your iteration backlog contains 20 work items, then that’s still about 19 more than it needs to be in a pull system”.
In other words, whereas Scrum batches work into Sprints for time-boxed delivery, and uses Sprint Backlogs to help limit the work in progress, Scrumban tries to minimize batch sizes much further. In the Lean-Kanban terms which Scrumban values, a Sprint Backlog is “inventory" or “stock-on-hand”, and may incur depreciation and other forms of waste. Although the “pull” for work is a team behaviour valued in all agile methods, including Scrum, it receives an even greater emphasis in Scrumban. Rather than delivering work in Sprint increments a technique known as single-piece-flow is encouraged. This means that each work item is brought into progress in response to a clear demand signal, and not because it has been batched into a Sprint Backlog. For that demand signal to be generated, all team members must have finished working on the item that was currently in progress. By focusing on and delivering one item at a time throughput will be increased, there will be less opportunity for depreciation, feedback loops will be tightened, and time-to-market will be reduced.
Since his original proposal though, Scrum-Kanban variants have gained traction in ways that do not quite match Corey's original purpose. These days the term “Scrumban” is often applied to these new hybrids. The key differentiator between modern Scrumban and Corey’s vision is that the term now refers to a type of systemically sustainable operating model, and not merely a journey to leaner ways of working.
In this interpretation, Scrum and Lean Kanban practices are applied at the same time, and with no particular intent to replace one with the other. This new take on “Scrumban” has gained traction because Scrum teams may only be notionally committed to the delivery of a complex product and the associated Sprint Goals. In practice a development team may also be also expected to support other products, emergency fixes, or to handle “Business as Usual” service requests of one type or another.
In order to assuage, manage, or at least expose such competing concerns, a hybrid of Scrum and Lean-Kanban is implemented in which the quality of service is allowed to vary. This isn’t possible in Scrum where each item in a Sprint Backlog must meet a clear Definition of Done and where quality is thus held to be invariant. For example, in Scrumban a “fast track” lane may be added to a team board, where emergency work can be introduced and actioned. This pre-empts work on the Sprint backlog, and it is not necessarily aligned to product value at all. Clearly this way of working may compromise a team’s ability to meet an agreed Sprint Goal, but it does provide an opportunity to balance competing interests, or at least to make them transparent.
- “Scrumban" is November’s Pattern of the Month at agilepatterns.org
Intent: Handle a mixture of project and unrelated work, in an agile manner, by implementing a hybrid of Scrum and Kanban rules.
What is not urgent must be done quickly in order to take care of the urgent things calmly.
Cut your coat according to your cloth.
Also Known As:
Fast Track (when used in a Scrum context)
Motivation: An organization might not have the resources to dedicate a project team to the development of a product. These constraints often lead to Scrum Teams being given work to do that is unrelated to their Product Backlog and/or which may compromise their Sprint Backlog. This work can include maintenance (BAU) activities or emergency incident response.
Structure: A project supports multiple iterations each of which is time-boxed. The team will plan backlog items into each time-box, and with the intention of actioning them at some point in the corresponding iteration. Only a limited number of those planned items can be work in progress at any one time. Each item has a defined Quality of Service that determines how it will be actioned. Items that were not on the backlog, and which were not planned into the time-box, may be done within the time-box if they have a Quality of Service that mandates their immediate attention. However, a suitable backlog item must be traded out of the time-box in order to accommodate it.
Applicability: Scrumban is a compromise to the problem of limited resources and competing demands for project and unrelated work. It therefore finds wide application across the IT industry.
Consequences: Scrum is predicated on the ability of a team to plan their work for a time-box. Pre-empting that plan with other (unplanned) work may therefore compromise a team’s ability to meet their Sprint Goal. All stakeholders must therefore be informed if such pre-emption will be allowed to occur.
Implementation: Many organizations that claim to have implemented Scrum are in fact allowing the quality of service to vary by means of a fast-track lane or similar, and are thereby implementing Scrumban.