Why Stretched Teams do Scrumban
Join the DZone community and get the full member experience.Join For Free
A few years ago Corey Ladas wrote an article about
an Agile approach he called “Scrumban”. As the name suggests, this is a
variant of Scrum with certain Lean-Kanban characteristics. What he
proposed was a graduation of Scrum teams to leaner and more pull-based
ways of working than Scrum itself allows.
Whereas Scrum will “batch” work up into Sprint Backlogs and potentially releasable increments, a leaner Scrumban approach will seek to minimize the batching of work as far as possible. Each work item will be processed in response to a clear signal for demand, and not because it has been planned into a Sprint backlog. In strictly Lean terms, holding on to such inventory is a form of waste.
The result was an agile approach which makes a Leaner way of working an end in itself. Since then though, Scrum-Kanban hybrids have taken off in ways that were perhaps not entirely foreseeable at the time when Scrumban was floated.
The catalyst has been the need to support Scrum and Lean ways of working at the same time. This is due to the fact that many Scrum teams are theoretically put together in order to undertake new project work, but in practice the team members are also expected to support existing systems. The team aren’t in truth dedicated to the conversion of a Product Backlog into usable and potentially shippable increments, as Scrum demands. They also have to handle “Business As Usual” type requests for minor enhancements and defect fixes, plus emergency patches, none of which were negotiated into a Sprint Backlog, and all of this without adding to the level of technical debt.
How can a team manage these competing interests, or at least make them transparent? The answer has often been to resort to a hybrid of Scrum and Lean-Kanban. This is a new spin on Scrumban, and it arguably represents the most widely used “type” of Scrum that can be found in the field today.
In this new Scrumban, an existing Scrum instance will vary its quality of service in a much Leaner fashion than Scrum itself allows. For example, it is very common to add a “fast track” lane to a Scrum board, where non-project work is introduced that pre-empts the Sprint backlog. Although this potentially compromises a team’s Sprint commitments, it has the benefit of making non-project work transparent to affected stakeholders. Clearly, sprint goals have to become much more fluid.
However there is another context in which Scrumban is to be found…the handover from Project work to Support. Once a Scrum project finishes, then the need to manage (effectively to de-risk) scope diminishes accordingly. Instead, once a system becomes live it will gradually enter a leaner “Business as Usual” support mode of small and repeatable changes. This is the context in which Scrum can be enhanced “with more and more pull-like features until all that remains of the original process is vestigial scaffolding”. Perhaps this comes close to Scrumban as it was first envisioned.
Published at DZone with permission of $$anonymous$$, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.