An Agile thought leader discusses how dev teams can use Kanban and Scrum techniques in alternating patterns to create their end products more effectively.
One recurring pattern of Agile practice, which many can expect to run into at some point in their careers, is that of using Scrum for “project type” work and Kanban for “business as usual.” The rationale for doing so can be understood in terms of risk management. A good Scrum Sprint will be conducted in order to achieve a Sprint Goal. Each goal will allow a significant risk to be mitigated by delivering an increment of value to a regular Sprint cadence. The goal will make the selection of work during that Sprint coherent in terms of challenging a greater concern.
“Business as usual” work, on the other hand, will not be expected to involve risks of such a magnitude. BAU work, more or less by definition, ought to be repeatable and well-understood. Hence in a Kanban operation, there are no Sprints because there is no need for Sprint Goals. Instead, a team will focus on improving throughput, continuous flow into production, and on the elimination of waste such as that which is presented by excessive batch sizes.
At scale, BAU and Scrum work can be seen as tactical or operational in nature. The wider long-term enterprise strategy may not be visible to Scrum and Kanban teams, and perhaps not even to any product owners. The focus of a delivery team tends to be on a narrow value stream, even if the team follows it all the way from development into production. The intent and visioning behind the wider program or portfolio of work which sets the organization’s strategic course will typically be managed by the higher-ups.
Architectural concerns may also be fed into the Kanban in order to maintain architectural runway and to arrest the build-up of unsustainable levels of technical debt. Scrum is not generally suited for these strategic concerns because each Sprint would have to be time-boxed in terms of several months or perhaps even years. Lean controls and hygienes are nevertheless of great importance if the “pipeline” is to function as a Kanban. These include transparency and the limitation of work in progress across all stations since the organization cannot be allowed to “bite off more than it can chew.” A well-managed portfolio pipeline, like any true Kanban, will function as a closed economy. The organization will not take on any new work until the corresponding resources are made available or otherwise freed.
