Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Pattern of the Month: Kanban Sandwich

DZone's Guide to

Pattern of the Month: Kanban Sandwich

In this article, we talk about a development pattern where teams go from Kanban to Scrum, and then back to Kanban during an SDLC.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

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.

Of course, project and operational support work must be conceived of, validated, prioritized, and funded in such a way that it aligns with enterprise strategy. Transparency over this is often attained through a "pipeline" which may, in turn, feed a Kanban which is managed at program or portfolio level. The stations that should feature in such a pipeline are of course situation-dependent, but they may include: Agreed backlog, Allocated portfolio, Work In progress, Working with capability BA’s, In engineering, Post-implementation review, and Future idea.

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.

Kanban Sandwich is Pattern of the Month at agilepatterns.org

Image title

Kanban Sandwich

Intent: Have an appropriate agile way of working at each of three enterprise levels.

Proverbs: Different sores must have different salves.

Also Known As: Agile Scalability Model.

Motivation: An Agile enterprise transformation affects the entire business. Kanban teams are best suited for technical support, while projects are more likely to be run in Scrum fashion. At the business level, we often find "project pipelines" that become Kanban-like once Agile practices are embedded in the boardroom.

Structure: Portfolio and Support levels are both run as Kanbans, while Project level work is run in Scrum fashion. Both methods support inspection and adaptation.

Image title

Applicability: This pattern is applicable across most verticals. It should be noted that technical support teams will need representation at the project level if they are to participate in large scale technology roll-outs.

Consequences: Use of this pattern may help to facilitate release planning if the delivery cycles are synchronized.

Implementation: This pattern can be found in the Scaled Agile Framework. It can also be correlated to the agility@scale approach where such issues have been framed in the context of DevOps and a business-driven project pipeline that supports architectural visioning.

See Also:


Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

Topics:
scrum (development) ,kanban ,strategic planning ,agile development

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}