Why Stretched Teams do Scrumban

What Corey proposed was the gradual facilitation of leaner practices in Scrum. He sought “…to incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding”. For example, he 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”.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.