How does Kanban streamline your processes? To begin to answer this question, we need to decide to what we are comparing our processes. Are we streamlined compared to our processes before Kanban? Are we streamlined compared to Scrum? Or are we streamlined compared to Waterfall? Well, the answers are yes, yes and heck yes! This article discusses several Kanban advantages when compared with other models. Let’s address each below …
Streamlined compared to our processes before Kanban
One of the beauties of Kanban is its simplicity. Kanban literally means “sign board” in Japanese. So, every Kanban team has a Kanban board that depicts the team’s workflow tracking all work from the initial inception of ideas through turning these ideas into a valuable product for their customers. But Kanban is more than just a visual board. One of the simple, yet powerful, components of Kanban are Work-In-Progress (WIP) limits. By setting WIP limits on the board, teams can easily see when bottlenecks occur. Bottlenecks cause us to slow down – we are not producing value to our customers as quickly as we can. By visualizing and removing bottlenecks when they occur, teams streamline their process. This is a simple yet one of the most powerful Kanban advantages. For more details on how this works, please see the blog, How does Kanban visualize and remove bottlenecks?
Streamlined compared to Scrum
Scrum is a great process for teaching teams to migrate from a Waterfall, sequential approach to an iterative process based on timeboxes. These timeboxes effectively compel the team to learn how to chunk up work into small pieces. While that is extremely important, Scrum has its drawbacks. At a high level, Scrum adds processes and rules that slow the team down. This is why many teams start with Scrum and then migrate to a Kanban approach. It is like learning to ride a bike with training wheels. After a while, we take the training wheels off as they get in the way and we realize we can move quicker without them. Let’s talk about several of the ways Kanban streamlines our processes as compared to Scrum.
estimation
To start with, Scrum requests that teams estimate. The Scrum guide calls for teams to add detail and estimates to the Product Backlog. It specifically states that more “precise estimates” are made based on the greater clarity and increased detail. While estimates can help the team predict when a release might be done, there are actually ways of getting an equally good forecast without spending all that time estimating. Yes, a game of planning poker can be fun (to start with) to pull the team together and engage the team. But it really is unnecessary.
After a while, planning poker can get mundane. Often times teams simply wind up sizing the majority of backlog items as a 3 or a 5 anyway. But there is actually a good reason for this phenomenon. Teams that get good at breaking things down to a small size typically get good at chunking work down to all be about the same size. And, all to be done within a few days. It turns out that simply counting items completed becomes just as accurate when forecasting a release as trying to size each item and using velocity for that same purpose. And while the Scrum guide talks about precise estimates, many of us believe they never are precise. Getting an equally good forecast without having to spend lots of time estimating is one of the key Kanban advantages. For more details on how Kanban supports forecasting without actually estimating please see the blog, The emperor has no clothes – why do we estimate?
product to sprint backlog (and back again)
The second way that Scrum slows teams down is by moving work back and forth from the Product Backlog to the Sprint Backlog and back again. If a team can perfectly predict the amount of work they can complete in a sprint then work would never move back and forth. But how often do we see teams doing that? It is a common occurrence that Scrum teams move unfinished sprint work back to the Product Backlog and then back again to the Sprint backlog when planning the next sprint. What a true waste of time.
And, if a Scrum team is not moving work back and forth, they are probably spending time filling in at the end of the sprint doing something that is of lesser priority than completing product functionality. Increased efficiency is one of the fundamental Kanban advantages. For more details on how moving to a continuous flow model like Kanban saves a lot of time by skipping this unnecessary overhead, please see the blog, Continuous flow saves time over moving work back and forth.
QA bottlenecks
The other advantage of a continuous flow model is that QA does not get dumped on at the end of each and every sprint. Yes, work should be getting completed throughout the sprint. But there are always items that developers finish towards the end. And, unless all testing is automated, QA is left holding the bag to get everything completed on time. The developers may pitch in to get this work done. But often times the developers are not as motivated to do this manual testing each and every sprint. For more details on how a continuous flow model prevents QA from getting dumped on, please see the blog, Continuous flow saves QA headaches.
meetings
The last item worth mentioning when comparing Scrum with Kanban are meetings. There is a lot of overhead when doing a timeboxed sprint. Imagine if your team actually moved to 1 week sprints. By the time the team holds a Sprint planning meeting to estimate and plan their weekly work, the Daily scrum, the product backlog refinement meeting, Sprint retrospective, and Sprint Review, how much time is remaining in your 5 days to get work done? While meetings are important, they should be held at the times and with the intent that provides the most value for the team. Not having strict detailed rules for constant meetings adds to the list of Kanban advantages. For more details on Kanban events, please see the blog, Kanban meetings compared with Scrum.
Streamlined compared to Waterfall
For many years, people have touted the advantages of an iterative development model versus a sequential waterfall model. Yet, even today, I come across countless companies who still use a waterfall model. These advantages include the ability to get continuous feedback from the customer that we are building the right thing; the ability to continually apply technical lessons learned as we build our product; the advantages of not doing big bang integrations; and so on. For more details on the advantages of an iterative model when compared with a sequential model, please see the blog, Why do companies still use Waterfall today?