- A Helpful Perspective
- A Framework for [R]Evolution
- Stop Drinking the Kool-Aid
- Let's Get Started
This chapter is from the book
This chapter is from the book
This chapter is from the book
A Framework for [R]Evolution
When Corey Ladas introduced the world to Scrumban in his seminal book, Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Press, 2009), he defined Scrumban as a transition method for moving software development teams from Scrum to a more evolved development framework. Over the past five years, my own research and work experience have unearthed the many ways in which Scrumban itself has evolved.
Since Corey wrote his book, organizations have layered the Kanban Method alongside Scrum to help them achieve several different kinds of outcomes. For example, I’ve successfully helped organizations apply Scrumban principles and practices in a variety of contexts—from startups to Fortune 50 companies, in industries ranging from professional services to software product development. Across these contexts, I’ve used Scrumban for the following purposes:
- Help teams and organizations accelerate their transitions to Scrum from other development methodologies
- Enable new capabilities within teams and organizations to help them overcome challenges that Scrum (purposefully) causes them to confront
- Help organizations evolve new Scrum-like processes and practices that work for them—not to accommodate the inadequacies and dysfunctions that Scrum exposed, but rather to resolve them in a manner that is most effective for their unique environment
These experiences demonstrate that Scrumban has evolved to become a family of principles and practices that create complementary tools and capabilities. And like any living organism, these principles and practices will continue to evolve as practitioners share their experiences and learnings.
Now, let’s consider the three different outcomes summarized previously within the context of Shu-Ha-Ri:
Scrumban provides the discipline and structure needed by practitioners in the Shu phase of learning. The Scrumban framework enables teams and organizations to manage the introduction of the artifacts and ceremonies of Scrum or the enhanced metrics and flow management practices of Kanban—disciplines and structures that new learners require in limited scope.
For example, Scrum’s ceremonies are essential to creating desired levels of performance and agility. Although it is a relatively simple framework, Scrum can seem overwhelming when it is first introduced. In a misguided effort to ease adoption, many organizations modify or omit ceremonies or, even worse, ignore the importance of understanding the basic principles and values. This rarely, if ever, produces the desired outcomes.
Additional capabilities provided by the Scrumban framework can substitute for the functions served by the modified or omitted Scrum ceremonies. Scrumban’s visualizations and other mechanics improve the effectiveness while reducing the time and effort associated with conducting ceremonies. Scrumban more effectively connects the practice of ceremonies with the principles and values that the ceremonies serve.
Scrumban exposes new tools and capabilities that aid the experiments and discoveries pursued in the Ha phase. Meeting the challenges that teams and organizations commonly face as they implement Scrum or other Agile practices represents one aspect of this dimension.
Consider creating and managing a product backlog. This Scrum artifact, and the events surrounding it (grooming and planning sessions), is intended to manage risk and optimize value by enabling better decision making due to maximized transparency and understanding of work. This can be especially frustrating when organizations effectively assign multiple product owners to a backlog because individual limitations interfere with realizing a full set of capabilities, or because of wide variations in subjective assessments.
The Scrumban framework visualizes information and integrates capabilities other frameworks don’t inherently provide. It helps provide improved contextual understandings and more accurately measures the outcome of different approaches (directly appealing to the Ha phase practice and understanding). For instance, Scrumban visualizes all sources of work demands and a more objective economic impact over time (cost of delay) to help prioritize work, lending greater transparency to the overall picture and expanding ways to adapt.
- Scrumban is flexible enough to provide Ri-level masters with a robust process within which to operate at hyper-performing levels. By emphasizing systems thinking, experimentation, and discovery, Ri-level masters are free to mold their ways of working in whatever fashion will produce the best results—from both performance and worker satisfaction standpoints. It makes no difference whether the resulting process is true to any particular set of practices.
- Scrumban supports both “revolution” and “evolution.” More importantly, it’s structured in a way that strongly supports all levels of learning and understanding—at a level of quality that is greater than that provided by either Scrum or Kanban alone.
All of Scrumban’s added capabilities can be optionally applied to a Scrum context in a variety of ways. They can also be extended across multiple areas of an organization to drive better business outcomes. Scrum’s software development framework lies at its foundation, as does the Kanban Method. However, neither of these frameworks represents a prescribed destination for organizations practicing Scrumban.
Beyond representing a significantly evolved mindset from the framework expressed by Ladas, today’s Scrumban is quite different from the definitions used by other respected leaders in the Lean/Agile community.1 In many respects, these perspectives view Scrumban as a vehicle for moving teams from Scrum to another software development process. While this remains one potential outcome, real-world applications demonstrate Scrumban has come to entail more than this across a broad range of contexts.
Over the years, Scrumban has been used to help teams and organizations accelerate their transitions to Scrum from other development methodologies. It’s been used to help teams and organizations overcome a variety of common challenges that Scrum is designed to force them to confront. When the context requires, it’s been used to help organizations evolve new Scrum-like processes and practices that work best for them—not simply as a means to accommodate inadequacies and dysfunctions Scrum exposed, but rather as a strategy to resolve those problems in a manner that is most effective for that environment. This latter outcome is obviously not something for which Scrum itself provides. These different paths reflect Scrumban’s bottom line—the service-oriented pragmatism that most businesses value.
Ultimately, Scrumban has become a framework of empowerment. David J. Anderson, pioneer of the Kanban Method, recently stated:
- Empowerment isn’t about letting people do whatever they want, or assuming they’ll somehow self-organize to produce the right outcome. Empowerment is about defining boundaries, and we do the same with children when bringing them up; we tell them things like when their bedtime is, where they’re allowed to play, whether they’re allowed to go outside the yard of the house, they’re allowed to swim at the shallow end of the pool, they aren’t allowed to jump from the diving board . . . all these things. So empowerment is about giving people clear boundaries, and then letting them use their initiatives inside the boundaries.2
Scrumban is distinct from Scrum because it emphasizes certain principles and practices that are quite different from Scrum’s traditional foundation. These include the following:
- Recognizing the role of management (self-organization remains an objective, but within the context of specific boundaries)
- Enabling specialized teams and functions
- Applying explicit policies around ways of working
- Applying laws of flow and queuing theory
Scrumban is distinct from the Kanban Method in the following ways:
- It prescribes an underlying software development process framework (Scrum) as its core.
- It is organized around teams.
- It recognizes the value of time-boxed iterations when appropriate.
- It formalizes continuous improvement techniques within specific ceremonies.