What Is Scrumban and Why Should I Care?

Like this article? We recommend 

Based on continuing market research conducted by such companies as Version One and others, Scrum remains the most popular (and commercially successful) Agile methodology in the industry. That said, its co-founder (Ken Schwaber) has acknowledged that “75% of the organizations using Scrum will not succeed in gaining the benefits they hope from it.”  Schwaber goes on to highlight this condition isn’t driven by deficiencies in the methodology, but because those organizations aren’t capable of addressing the “dysfunctions” Scrum exposes.

This reality helps explain the growing popularity of what Version One has labeled Scrum “variants” -- Agile approaches that aren’t pure Scrum but retain most of its core elements. Scrumban is labeled such a variant, and has reflected increasing popularity with each passing year. I believe the real numbers behind this trend are hidden, largely because Scrumban remains poorly understood and poorly described by many experts and thought leaders throughout Lean and Agile circles.

This lack of clarity around Scrumban has led to a confused public. Some understand it to be nothing more than the use of visual kanban boards inside a Scrum development framework. Others believe it represents a hybrid development framework that combines “the best” elements of Scrum and the Kanban Method. Almost all believe it necessarily encompasses some form of continuous flow. None of the common understandings, however, capture the true essence of the framework.

Why does any of this matter?  We live in an ever-changing world, and the rate of that change is ever-increasing. Agile approaches to working (like Scrum) were developed to enable organizations to effectively work in this environment. Failure to realize the intended benefits from these ways of working means we’ve failed to adapt to the conditions of the marketplaces in which we operate.

What Scrumban Really Is

Fundamentally, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.

Scrumban is distinct from Scrum in the way it emphasizes certain principles and practices that are substantially different from Scrum's traditional foundation. Among these are:

• recognizing the important role of organizational management (self-organization remains an objective, but within the context of specific boundaries)
• allowing for specialized teams and functions
• applying explicit policies around ways of working
• applying the laws of flow and queuing theory
• deliberate economic prioritization

Scrumban is distinct from the Kanban Method in that it:

• prescribes an underlying software development process framework (Scrum) as its core
• is organized around teams
• recognizes the value of time-boxed iterations when appropriate
• formalizes continuous improvement techniques within specific ceremonies

Perhaps most importantly, the principles and practices embedded within Scrumban are not unique to the software development process. They can be easily applied in many different contexts, providing a common language and shared experience across interrelated business functions. This, in turn, enhances the kind of organizational alignment that is an essential characteristic of success.

A Framework for [R]Evolution

When Corey Ladas introduced the world to Scrumban in his seminal book, Scrumban: Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Press, 2009), he boldly defined it as a transition method for moving software development teams from Scrum to a “more evolved” software development framework. In actual practice, however, Scrumban has itself evolved to become a family of principles and practices that create complementary capabilities unique from both Scrum and the Kanban Method. These capabilities have led to three distinct manifestations:

As a framework that helps teams and organizations effectively adopt Scrum as a development methodology.

As a framework that helps teams and organizations overcome a variety of common challenges scaling Scrum across the Enterprise.

As a framework that helps teams and organizations develop their own set of Scrum-based processes and practices that work best for them -- not to accommodate inadequacies and dysfunctions Scrum exposed, but to resolve them in a manner that was most effective for their unique environment.

I believe these different manifestations have arisen because teams and organizations are acutely aware of all the great things an underlying Scrum methodology brings to the table. These include capabilities like:

• fostering a team-based focus to facilitate the alignment of purpose and vision
• enhancing performance and the adoption of change through cadence and rhythm
• helping to enforce a focus on shorter term planning as compared to more traditional methods
• emphasizing customer participation and the delivery of value from customer’s perspective
• enforcing a focus on smaller sizes of work
• enabling collaboration
• promoting shared ownership and cross functional capabilities

On the other hand, too many of these teams and organizations face challenges in effectively adopting Scrum for which the framework lends little guidance. These include challenges like:

• effectively managing around the variability and unpredictability inherent in the nature of our work (especially, in many contexts, around its arrival)
• deliberately addressing longer term considerations such as architecture
• overcoming psychological barriers to change and implementation
• achieving uniformity in the effectiveness of the Product Owner role and how to scale the function performed by this role across larger enterprises
• relating market risk to Sprint Commitments
• eliminating traditional reliance on deterministic planning
• minimizing reliance on top down/vertical buy-in with affirmations of servant leadership

A Helpful Perspective

Let’s start with how Scrumban helps address psychological barriers to change and implementation. In the early 2000’s, Alistair Cockburn introduced the concept of “Shu-Ha-Ri” to the software development world. Borrowed from martial arts, these words describe the three distinct phases people pass through as they master a new skill or concept. Using Shu, Ha and Ri as lenses through which to better understand how people learn helps us recognize how Scrumban is particularly effective in guiding people to new ways of working.

During our initial phase of learning (“Shu”), we seek to reproduce a given result by following a prescribed set of practices or instructions. Our focus lies on how to perform a task rather than trying to understand the underlying theories and principles. Success in this stage is measured by whether a procedure works and how well we can carry it out.

Though it’s a relatively simple framework, Scrum can be quite overwhelming when first introduced. We are often asked to abandon prior roles (and the personal identification that comes with those roles). We are asked interact differently, as well as to assume different kinds of responsibilities.  If we recognize that new learners will have a natural tendency to focus on the mechanics of Scrum’s roles and ceremonies rather than the underlying functions and purposes they fulfill, it’s easy to appreciate how the path to agility can be fraught with many twists and turns.  

As a change management framework, Scrumban introduces the discipline and concrete structure sought after by Shu-level practitioners at a modified pace. Teams and organizations start practicing Scrumban not to change their current ways of working, but to better understand them. The framework guides teams and organizations to engage in a path of discovery to understand how current ways of working are not satisfying either the business or the team’s needs. It does this through enhanced metrics and flow management practices, among other things. The team engages in an iterative improvement process to address dissatisfactions, introducing Scrum functions as warranted. Scrum evolves over time, through common awareness, and by agreement.

Similarly, Scrumban adds a values-oriented perspective to the Shu stage of learning. Rather than acquiescing to the natural tendency of Shu level practitioners to focus on mastering concrete steps without any emphasis on understanding underlying principles, Scrumban assures new learners at least be conscious about how their ways of working either promote or detract from the core values upon which the framework is based.  This values-based understanding of practices sows the seeds for improved and accelerated understandings in later stages of learning.

Scrumban in Practice

Let’s take a glimpse at Scrumban in practice in the context of creating and managing a product backlog.

In Scrum, the product backlog is developed and prioritized through the role of the Product Owner. Scrum prescribes events focused on refining the Product Backlog for downstream needs (development and delivery by the Scrum team), but does not address the adequacy of the upstream process or capabilities of the Product Owner to deliver the right “raw materials” in the first place.

These purposes can be frustrated when organizations have effectively assigned multiple product owners over a backlog, when limitations in the skills and capabilities of individuals interfere with realizing a full set of capabilities, and by wide variations in subjective assessments.

From a business perspective, there’s a lot of interesting and important things taking place in the upstream process. As a framework, Scrumban provides views and capabilities that enable the business to evaluate and manage these work processes more effectively. It emphasizes measuring real experience to:

• evaluate past outcomes in order to make better decisions about present actions
• compare against common benchmarks as an indicator of relative health
• provide data upon which to base a forecast of future results
• influence the behavior of individuals

One of the arenas where Scrumban’s enhanced capabilities are most pronounced is forecasting and planning. Most organizations rely on “deterministic” models to forecast when work will be complete (we assess work, estimate the amount of effort associated with that work, assess the number of people and amount of time that will be required to complete that work, and provide an approximate date by which the work will be completed. Scrum uses team-based estimation techniques practices to enhance capabilities in this arena, but it doesn’t alter the fundamental approach.

Scrumban, on the other hand, abandons such deterministic estimations altogether. Instead, it enables teams and organizations to objectively measure past performance (in the form of lead time and average work-in-process metrics). It enables us to calculate probable outcomes based on measured distribution patterns. It reminds us that all work carries inherent variability which we can measure but not eliminate. And it encourages us to engage in conversations that set expectations around probable outcomes versus deterministic numbers.

Why Does Scrumban Matter?

The bottom line?  No organization has to be part of the 75% that fail to realize the benefits they seek from Scrum. The biggest impediment to success here lies with individual contributors who are either unable or resistant to thinking about improving how work is done (or in addressing how their work is relevant to creating business value). Similarly, innovation is easily stifled when workers and management are encouraged to pursue “safe” approaches to completing work over the delivery or real value.

Scrumban matters because it provides a simple yet powerful management framework capable of shifting these mindsets and providing pragmatic means of addressing the “dysfunctions” Scrum exposes. Its fundamental principles and practices are universal and easily introduced across the entire organization (not just IT), providing mechanisms that foster greater understanding and alignment in all business functions.

This article only touches upon the tip of the iceberg that is Scrumban. A whole book can be written on the framework’s capabilities and benefits. In fact, it has!  If you’d like to learn more, I invite you to check out The Scrumban [R]Evolution. Don’t be part of the 75%!