Scrum Versus Kanban

10 July 2014

Vandana Roy
Visa Inc.


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 a 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 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 requirements, even change the requirements. At the same time, it gives power to the team to commit to the requirements per their capability. All the work done in Scrum is iterative and incremental, and it timeboxes the process. Scrum also emphasizes feedback: The team can get feedback from business as early as possible and deliver a working product that will actually be used. It also allows the team to retrospect on their performance and improve upon it within short cycles.

What is Kanban?

The Kanban blog says, "Kanban is 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 work flow, so as to observe the flow of work moving through the Kanban system. Making the work visible, along with blockers, bottlenecks, and queues, instantly leads to increased communication and collaboration.
  2. Limit work in process
    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, the 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. Continuously improve
    Once the 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 more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and their commonalities in delivering quality products.

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 have 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 will work best for them. More recently, some teams have combined both frameworks and used the best practices from each to achieve better team synergies and improve productivity.

There might be teams who feel comfortable with Kanban and others who are more comfortable with Scrum. A better approach could be to coach teams on both frameworks and leave the decision to them to use best practices from both. 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 teams to explore practices from both that enable them to function as highly productive teams that continuously improve.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.7 (33 ratings)

Comments

Thanigaimalai Thangavel, CSM, 7/10/2014 6:32:32 AM
Good & Simple one. Are we not covering change of requirements during WIP in Kanban..Is Kanban has flexible time boxed for delivery..
Vandana Roy, CSP,CSM, 7/10/2014 1:13:27 PM
Hi Thanigaimalai,
I am not sure what you meant by "Are we not covering change of requirements during WIP in Kanban". But Change requests, enhancements, maintenance, operations all software development projects can be done by Kanban.

Kanban has no specific rule for timeboxing, though projects do use timebox with Kanban.

Thanks!
Zach Bonaker, CSP,CSM,CSPO, 7/10/2014 1:20:42 PM
Nice article! One point to highlight is that Kanban is not a process, framework, or method. It is a commitment to the principles you highlighted.

ANY system can use Kanban and doesn't require change from your current mode of working. A waterfall business, for example, can start using Kanban today with immediate benefit.

There is no reason to choose Scrum over Kanban and vice versa... if you're doing Scrum, the question might be "What additional value can we gain by using Kanban, too?"
Tim Baffa, CSM, 7/10/2014 3:33:24 PM
Agree w/Zach regarding Kanban use with any process. Also curious about statement that Scrum does not have hardcore processes to follow. Core Agile may have that flexibility, but Scrum is a flavor of Agile that is indeed fairly rigid in its ceremonies and methods.

At least that is how I view Scrum out of the box. Certainly the "Ri" stage of Shu-Ha-Ri can allow for adaptation and modification of Scrum practices, but one must become an expert of the Scrum process first.
Vandana Roy, CSP,CSM, 7/10/2014 9:21:16 PM
@Zach - Agreed Kanban is commitment to the Principles and Kanban is more flexible and can be started from current mode and yes the right question would be to find out how to gain more benefit by using Kanban.

@Tim : Yes Scrum is not very flexible and recommends following rules and ceremonies strictly. In comparison Kanabn is very flexible it does not enforce Timebox and can be blended with any methodology be it waterfall or Scrum
Ashvin Gondalia, CSM, 7/11/2014 9:13:42 AM
As Kanban is not time boxed what exactly we mean by 'Limit work in process'?
Ebin Poovathany, CSP,CSM, 7/14/2014 7:31:03 AM
In my understanding, Limit WIP is all about limiting tasks worked on simultaneously. The funda is Stop Starting Start Finishing!
Vandana Roy, CSP,CSM, 7/14/2014 11:49:57 AM
@Ashvin, WIP is number of items that are worked upon. Limiting WIP is not time boxing but to identify bottlenecks in the kanban system. By limiting WIP we make sure that we do not have too many items being worked upon simultaneously and creating bottleneck for the next team. For e.g. if there are 2 developers and 3 testers in a team then the amount of work delivered by developers will be less as we might not need 3 testers to test the 2 items which developers have completed. This shows that developers are creating bottleneck. Based on this we might add more developers or remove some testers from the team to ensure smooth flow of work.
Thanigaimalai Thangavel, CSM, 7/16/2014 5:48:00 AM
Little more ... Are we handling Change requests, enhancements, maintenance, operations during WIP. If those are priority first.
Vandana Roy, CSP,CSM, 7/16/2014 11:49:52 AM
@Thanigaimalai - Yes the priority is decided by the stakeholders and then you can handle Change requests, enhancements, maintenance, operations. WIP is just putting limit on the work in progress, and the limit could be based on anything you feel is the deciding factor for e.g. number of resources.
Gene Gendel, CSP,CSM, 7/17/2014 8:13:41 PM
Great writeup Vandana. I had something related covered a while back: http://www.scrumalliance.org/community/articles/2014/june/scrum-kanban-enterprise-and-team-level

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.