Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question
Note: This blog is co-written by Al Shalloway and Jim Sutton.
Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.
This is the third in a series of blogs on how Why Understanding Lean Is Essential in an Agile Transformation.
Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.
One way to get a better match between the available approaches and our organizations is to apply the idea of patterns. Patterns are like dances; while there are a nearly unlimited number of songs, there are relatively few choreographed sequences of dance steps to use with them. Likewise, there are a nearly unlimited number of situations an organization can be in…but a relatively limited number of patterns that describe how to address them reasonably well.
The idea of patterns breaks us out of this impasse with a way to make decisions that are both best for our organization, and understandable by all. “Patterns are solutions to recurring problems in a context” according to Christopher Alexander, the architect who introduced the concept of patterns in his book A Timeless Way of Being.
Patterns are actually clues to what’s at work underneath the surface, hidden realities that Alexander calls “forces.” Reaching the end of his book Alexander states “at this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real"…i.e., the forces that must be dealt with.
Patterns are based on the forces or issues that are acting in and on our organizations. Knowing what forces are in play in our own organization points us to which aspects of Scrum and Kanban (and other sources) best meet our actual needs. Like a semi-tailored suit, this gives us essentially a custom fit for little more than the effort of an off-the-shelf solution (often less effort because where the off-the-shelf solution does not fit well, we must expend extra effort to force it to work). One can best understand the forces patterns deal with by the myriad of ways traffic intersects with each other yet it only requires a handful of methods to deal with them (traffic lights, yield signs, stop signs, 4 way stops, round-abouts and a couple of others. The “forces” involved in traffic are: the amount of traffic in each direction, speed of traffic, time of day, proximity of pedestrians and bicyclists amongst others. By considering the forces present, one can take a relatively small number of preset solutions and combine them to create fairly customized solutions.
We gain insight into an organization’s forces by looking at software development as a collection of mini-challenges. On the smaller scale the forces become more clear. These forces point us back to the patterns which suggest what elements of Scrum and Kanban (for instance) will be most helpful in our real-world, nuanced situation. This walks us naturally into “hybrid” solutions that are more effective than take-it-or-leave-it Scrum or Kanban. We also gain a deeper appreciation of how the principles of software development apply to our actual situation, so we can also create new practices if need be.
“Should I Use Scrum or Kanban?”
A common question we hear is “should I use Scrum or should I use Kanban?” Some motivations for asking this question include:
- Scrum doesn’t appear viable because the situation doesn’t allow setting up cross-functional teams and iterations, or doing so would be disruptive
- People have heard that Kanban is more advanced and the latest, greatest thing
- Simply being unsure about which approach to take
Conversely, many Agilists are already committed to a course of action; be it Scrum, Kanban, or, in relatively few cases, keeping their options open to select practices flexibly based on their appropriateness for the situation.
Scrum and Kanban devotees often use rather limited arguments for why their favorite is better; e.g., “cross functional teams are great” (Scrum) or “managing WIP improves flow” (Kanban). Others justify their preference by dogma such as “it’s not in the Scrum Guide” (justifying not using Kanban) or “iterations are wasteful” (justifying not using Scrum). Choices however, may be challenged, particularly by more-senior management. Then they are often difficult to defend: The principles that define Scrum and Kanban are rightfully not of great interest to senior management in the same way a person who wants a luxury car may not need to know how the engine was designed.
The needs of your software development may be best served by Scrum, or by Kanban, or by some combination of elements of the two. The only way to know for sure is to understand the forces at work in your organization. They will lead you to the best solution for you.
How to combine these two approaches is not obvious, however. Each of their belief systems have some aspects that are contradictory to those of the other. In our next blog post, we’ll first consider why the Lean mindset should be used to combine the two. Then we will consider some of the most-important forces at work in software organizations. We’ll also look at how these can point you toward (among other things) the aspects of Scrum or Kanban you can apply most effectively to your organization.
Al Shalloway, CEO, Net Objectives
Jim Sutton, Sr Consultant, Shingo Prize Winner
Note: If you are interested in learning more about Net Objectives' approach to Scrum and Kanban, we recommend watching Al Shalloway's recorded webinar Leanban: The next step in the Evolution of Agile