Scrum Vs. Kanban

[Vandana Roy]

Lately, I hear these questions a lot - “Is Scrum better or Kanban?”, “What is more suitable for my project - Kanban or Scrum?”. These questions and sometimes the responses to them put managers in dilemma about which framework to embrace. Each has its own benefits and tales of success stories.

What is Scrum?

 

Scrum Alliance defines Scrum as an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

 

Scrum emphasizes on team collaboration and provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

 

Scrum gives power to business to prioritize the requirement and even change the requirement. At the same time it gives power to team to commit to the requirement as per their capability. All the work done in Scrum is iterative and incremental and it time boxes the process. Scrum also emphasizes on Feedback, where the team can get feedback from business as early as possible and deliver a working product which will actually be used. It also allows team to retrospect on their performance and improve upon in shorter cycles.

 

What is Kanban?

 

Kanabanblog describes “Kanban as a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.”

 

Kanban primarily follows four core principles

1. Visualize Work

Create a visual model of work and workflow, so to observe the flow of work moving through Kanban system. Making the work visible along with blockers, bottlenecks and queues instantly leads to increased communication and collaboration.

2. Limit Work in Process

To limit how much unfinished work is in process and reduce the time it takes an item to travel through the Kanban system. Problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP.

3. Focus on Flow

By using work-in-process (WIP) limits and developing team-driven policies,Kanban system can be optimized to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.

4. Continuous Improvement

Once Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times and more. Experiments and analysis can change the system to improve the team’s effectiveness.

 

Both Scrum and Kanban are unique and emphasize on more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and the commonality in both is  to keep delivering quality product.

 

Advantages of Scrum	Advantages of Kanban
Transparency	Flexibility
Improved credibility with clients	Focus on Continuous Delivery
High Product Quality	Increased productivity and quality
Product Stability	Increased efficiency
Team members reach sustainable pace	Team members ability to focus
Allows client to change priorities and requirements quickly	Reduction of wasted work/wasted time

The question Organizations face is which framework should be used with the teams, Scrum or Kanban? But instead the question Managers should be asking is which aspects of Scrum and Kanban can they use to effectively develop products and services.

Given the advantages of both approaches, it should be up to the Development and Product teams to choose which framework would work best for them. More recently, some teams have combined both frameworks and used the best practices from both approaches to achieve better team synergies and improve productivity.

 

There might be teams who feel comfortable with Kanban and while there might be others who are more comfortable with Scrum. A better approach could be to coach teams on both frameworks and the decision be left to them to use best practices from both Scrum and Kanban. As we have seen both Scrum and Kanban are flexible and do not have hardcore processes to be followed, so it could be easy and worthwhile for the teams to explore practice from both that enables them to function as highly productive team and continuously improve.