“Science and technology revolutionize our lives, but memory, tradition and myth frame our response.” – Arthur M. Schlesinger, Jr., U.S. historian. “The Challenge of Change,” New York Times Magazine (July 27, 1986)
“A myth is an image in terms of which we try to make sense of the world.” – Alan Watts, British-born philosopher, writer, and speaker (1915 – 1973)
“What is the Kanban Method?”
- It’s not about replacing your current software development process.
- It’s not about changing or removing your team’s current titles and roles or adding new ones.
- It’s not about a process that is only for support, maintenance, or “dev-ops” teams.
Does any of the above surprise you?
If so, maybe it would be useful and helpful to take a closer look at the Kanban Method from a different perspective.
Kanban Leaders Retreat (KLRUS)
In November 2012 I attended the Kanban Leaders Retreat (KLRUS) in San Diego. Over two days there I had an opportunity to take part in a number of break out sessions with several other leading coaches, trainers, and practitioners of the Kanban Method. In one of the sessions we focused on identifying some of the “surprising” myths and misconceptions we were hearing about the Kanban Method while coaching, training, and working with others. As summarized by some participating, “there really is a lot of surprising ‘stuff’ out there!” In the context of this post I’ll limit myself to providing a taste of our discussion there at KLRUS. In particular, focusing for the moment on a misconception I hear often, the Kanban Method: It’s just Scrum with tweaks.
If you’re just beginning to learn for yourself about the Kanban Method, I hope this post provides a useful foundational perspective to keep in mind as you continue learning, researching, and reading articles, posts, etc. For others more familiar with the Kanban Method already, I hope it provides a little insight into the misconceptions you’re likely to run into, if you haven’t already run into this one, and how some in the community are discussing them in ways we feel will help others see the Kanban Method from a more useful and different perspective.
Yes, It Starts As Your Current Process with Tweaks, But There’s More!
It’s not all that uncommon for me when listening to others discuss the Kanban Method to hear some variant of “We’re thinking of switching to kanban because then we won’t have to do (fill-in-the-blank)” or “We’ve switched to kanban and now we don’t do (fill-in-the-blank) or “We don’t have (fill-in-the-blank), so we think switching to kanban will be a better fit.” When I hear these types of statements where the context is someone on a team that was using Scrum before applying the Kanban Method, I also often hear their conclusions and some of those “blanks” summarized as, kanban is “just Scrum with tweaks”, or often more specifically it is “just Scrum without iterations”, it is “just Scrum without time boxes”, or it is “just Scrum without estimation.”
Yes, the Kanban Method is about starting with your current process, in your current context, and continually improving it. So, if in a software development context one was using Scrum before applying the Kanban Method, I can see where they may have improved an aspect in their context of their current process by stopping something that is typically considered part of the Scrum process (or by starting something that is typically not considered part of the Scrum process). For example like not continuing to use the same uniformed fixed-length time-box iteration interval across all their process activities. Or, adding the use of lead time and throughput as measures of capability for their current workflow process, then, over time finding they no longer need to do as much upfront estimating using point sizing, ideal days, etc.
When I began learning and applying lean-agile principles in late 2004 and more specifically the Kanban Method in late 2007, my own personal experience, as an active member of teams delivering production software and meeting business delivery targets, included very similar experiences as those mentioned above (see other posts here and here). So, from someone’s off-the-cuff observer perspective of what our teams were doing, I can see how these “just Scrum with tweaks” like statements might come about and make some sense to those saying them.
However, when you learn the “Kanban Method” is not a software development process at all or is not only for IT/IS support, maintenance or dev-ops”, then from another perspective it also makes sense to see how a statement like “just Scrum with tweaks” is limiting in describing the use or reasons for applying the Kanban Method in your context as a way to improve workflow processes. Limiting in the sense of not fully leveraging its benefits. Probably worse though, sometimes, I think this limited perspective results as well in a stunted perspective and leads to misapplying the Kanban Method. There is more!
The Kanban Method – A Change Management Tool, a Process Improvement Lens
When you look closely at the Kanban Method (see here), you’ll not see it specifically requiring or suggesting the use of iterations, uniformed fixed length timebox iteration interval, upfront estimating, specific roles (ex. scrum master, product owner, etc.), or specific technical practices (ex. automated unit testing, test-driven development, pairing, continuous integration, continuous deployment, etc.). A lack of specifically mentioning or prescribing these should not be construed as an indication the Kanban Method precludes any use of them either.
In your context for a software development or other IT/IS related workflow process, many of these practices may and will contribute to improving your ability to predictably deliver valuable and quality services and products for the benefit of your end users, customers, and business stakeholders. However, you may also find some don’t, or over time as you continue to learn more about your context and workflow process, you may find it necessary to tweak some, extend some, innovate on some, drop some, and add some new ones to sustain (not fall back or degrade) and improve your capability.
Ask yourself what about your current workflow process hasn’t improved, that is, changed over the last year or two? While all change is not improvement, all improvement does require change. Could changing from using the same uniform fixed-length time-boxed iteration interval currently used across some set of your workflow process activities allow you to improve some aspect or address some issues in your current workflow process and context? Notice too though the Kanban Method isn’t specific to just IT/IS or software development workflow processes. It can be applied outside of IT/IS and software development workflow processes in your organization as well, and most likely should be. So what is it?
Pull, Flow, and Improve
I like to personally view the Kanban Method as a “lean and lightweight” lens, a tool for viewing a workflow process as it is today, then using this “different” perspective to learn how one might explore, discover, and identify “new” opportunities for improving the process through change, experiments and validation. While a bit more verbose, this personal view aligns and reflects how other leaders in the community describe it, the kanban method itself is not any specific (workflow) process, rather it is a change management tool, a catalyst for continuously improving any current (workflow) process. So, as of late, I’m working on frequently reminding myself and suggesting to others to think of it more as a tool for exploring, discovering, and identifying the most beneficial opportunities for continuously and incrementally changing (tweaking) and improving your current workflow process, starting from where it is today, and to think less in terms of “switching or replacing” any current workflow process.
Try not to let any initial low hanging fruit (tweak) type improvements that you might get simply by simulating (copying) process changes based on observing other teams using it, lure you into the trap of “limited” thinking about what the Kanban Method is and how it can be applied. As you go forward learning more about the Kanban Method yourself, and apply it to your specific context and workflow process, go beyond observing just “what” tweaks (change) other teams are doing in their similar workflow processes (ex. decoupling the cadence or frequency of some set of activities so they don’t all always have to align to the same uniform fixed-length time-box iteration interval).
Get to “how” they came about making those tweaks (ex. the problem, the impediment, the cost, the delay, the quality issue, the pain point, etc. that motivated the change in their specific context and workflow process, and the tool they used to identify these). Get to “why” they thought the tweak would be an improvement, and the criteria and measures they developed and used in validating it (the tweak, the change).
I’ll close with a few more thoughts from elsewhere that I think reflect the comments above and contribute more to developing a helpful perspective and understanding of what the Kanban Method is and what it is not. I don’t recall exactly the source for this first one, but I read somewhere that Toyota, in times past, didn’t worry much about others including “competitors” coming in and “observing” their processes. For similar reasons, simulating or copying the process of a team that is using the Kanban Method is very different from learning how to use the Kanban Method to improve your workflow process.
The source for these next ones are scattered excerpts from book “The High-Velocity Edge” by Steven J. Spear that I’ve captured below. I feel they also resonate with a similar helpful message as you consider, learn, and apply the Kanban Method.
“Though many firms had embraced various tools…they still never caught-up.”
“These firms had picked up the visible tools of high-velocity organizations…but they had not understood what these tools were for.”
“The most compelling theme is that when the solution to a problem is discovered, the discovery process itself must be conveyed along with the solution.”
The Kanban Method is not just Scrum with tweaks, though it might look like that to some, in particular to a casual observer. Again, take a close look at your current workflow process. Does it seem the easy and early improvements have been made and you feel you’ve now plateaued some lately? Is it possible you’ve only simulated or copied what others have done but not figured out how to tweak it appropriately for your own context to get similar improvements that you see in their context? Did you only look closely at their solutions but not dig into the “tools” and the discovery process they used in getting to the tweak they made to their workflow process, be it Scrum or something else? If so, maybe it is time to take another look at the Kanban Method with a new perspective. Maybe it is time to go beyond being a casual observer of the Kanban Method, and if you do, I think and hope that you find, There is more!