Five benefits of switching from Scrum to Kanban

 by Mike Brinker, Software Architect - Team Leader at eFlex Systems

Recently, our software development team made the decision to switch from a Scrum-based methodology to a Kanban-based one.  Specifically, we decided not to plan/commit/execute two week iterations but rather work in a continuous flow, pulling issues from the top of our to do list.  As a result we've found several advantages to "not caring" about sprints anymore.

Decreased Waste

In Scrum world, we would spend part of the days leading up to the beginning of a new sprint planning what would be in the next sprint. We would move issues around based upon priority and our readiness to start them.  Often, we would find our priorities shifting in the first few days of the sprint. Our plan was now stale and we would have to spend time planning again.

In the Kanban mindset, we don't worry ourselves with planning what we are going to do in the next two weeks, we just try to keep our backlog in priority order. The time we would have spent planning out work for the next sprint (waste) is now given back to us to do more productive things with.

Decreased Scope Creep

Any software developer who has worked in a Scrum environment is familiar with the constant struggle of scope creep. As a developer is working on an issue during a sprint, there is a high likelihood that new work is discovered during the development process. With Scrum, your sprint commitments are at stake so the tendency is for the stakeholders to add scope to issues currently being worked on. If the scope is not added, then there is a fear that the business will have to wait another two weeks (or more) before a new issue containing the expanded scope can be picked up.

In Kanban land, the business folks can decide together where the priorities are and place issues in the backlog accordingly.  If something is discovered during development (or otherwise) and is indeed a high priority, this new issue can be placed at the top of the backlog. No need to wait two weeks for a new sprint.

Increased Control for the Business

While living the ScrumLife™ we began to realize that the realities of our industry and business did not fit nicely into two week iterations.  Responding to customer feedback often required us to jettison previously planned work – not because the planned work had become obsolete but because work of higher value/benefit was discovered.

The KanbanPlan™ (that is, to plan as little as possible) allowed us to reflect the reality of our business needs in the backlog. What is most important at any given moment is at the top of the backlog. It can be that simple. This clear representation of priorities creates the opportunity to have an open discussion about what our priorities should actually be.

Other Process Issues are Exposed

Soon after switching to Kanban, we were finding that developers were often picking up issues that had not been groomed yet. This revealed to us that there were instances where priorities would change, new issues were pushed to the top of the backlog, but nothing had "triggered" a grooming session to take place. The problem was that we were very often not grooming far enough ahead, but in Scrum world, this was obfuscated because we blamed the interruptions to the sprint.

Focus on Real Problems than "Meeting Commitments" 

Along with decreasing waste (see the first benefit) the Kanban mindset gives us less to think about in terms of planning and executing development work. We can still look back on how much we have accomplished over the past 2 weeks (or any other unit of time) but we aren't constantly trying to "beat the clock" by meeting our commitment by the end of the sprint. Rather, we can focus on continually delivering value and whatever may be hindering us from doing so. We can also use metrics like the amount of issues we have in WIP to diagnose other process problems.

It turned out that sprinting constantly was not sustainable or beneficial for our team. Instead, working in a continuous flow has reduced waste, given the business more control over scheduling their prioritized development items, and allowed us to focus on what the value is that we are actually trying to deliver.