Scrum vs. Kanban: What to Choose?

Home The Savvy PM Blog Scrum vs. Kanban: What to Choose?

A big thank you to one of our very own Velociteach Instructors, Alan Zucker, for creating the content for this blog. You can subscribe to his blog and see the sources of this content by following this link:

Organizations starting their Agile journey are confronted with an array of choices.  One early decision is, what methodology and process to follow?

The authors of the Agile Manifesto represented many approaches, methodologies, and frameworks.  The common theme was that they had uncovered better ways of developing software.  Consequently, the Manifesto was not a recipe with detailed instructions.  Rather, it represented a list of suggested ingredients.

Scrum is the most common Agile methodology and enjoys almost 60% market share.  Kanban is a less popular as a standalone method; however, its practices are part of Scrum, Lean, and many hybrid approaches.  Kanban is also favored by many leading companies such as Pixar and Spotify.


Scrum is the most popular Agile methodology.  It provides a well-defined approach with clear roles, practices, and ceremonies. Learning Scrum is easy.  By following its practices, teams learn the required behaviors and mindset through experience.

         Scrum Roles 

Scrum establishes clear roles and expectations.  The Scrum Team is empowered and self-managing.  Team are often generalizing specialists.  In other words, the team is interdisciplinary and has the skills required to deliver the product.  The Team is accountable to itself to fulfill its commitments to the customer.

The Product Owner is an integral member of the Team and represents the voice of the customer.  The Product Owner develops the product vision, roadmap, and backlog.  The backlog is the prioritized list of features to be delivered in each development increment, or Sprint.  The Product Owner works with the Team throughout the process to provide input, feedback, and answer questions.  This regular interaction is a key component of Scrum.

The Scrum Master ensures the team follows the Scrum processes and protects the team from external distractions. The Scrum Master is a facilitative leader that guides the team and helps them mature and improve.

Scrum Ceremonies and Practices

Scrum has a number of practices that promote collaboration, customer engagement, and the incremental delivery of value.  Together, these practices create a delivery framework that aligns to the Agile values and principles:

  • Sprint. Teams deliver working software incrementally in sprints that generally last 2-4 weeks.
  • Sprint Planning. At the beginning of each Sprint, the Team meets with the Product Owner and decides which features will be delivered.  This aligns the work to the customers’ needs and business priorities.
  • Daily Scrum. The Team meets daily for 15-minutes to discuss progress.  Each team member shares what they have completed, what they are working on, and anything that is blocking their progress.
  • Sprint Review. At the end of the Sprint, the Product Owner and the Team meet with the customers and stakeholders to show the new features and receive feedback.
  • Sprint Retrospective. After the Sprint Review, the Team meets to identify ways to improve.  The Retrospective supports the principle of continuous improvement which is common to most Agile methodologies.


Kanban is a process with its roots in lean manufacturing.  Lean focuses on providing value and eliminating waste.  Kanban is Japanese for sign-board.

The Kanban board is a visual display that provides transparency into flow of work.  Columns represent each of the process steps and cards depict each work item.  The process is controlled to maximize the flow of work and minimize bottlenecks and other disruptors.  

In Kanban, work is pulled through the process rather than pushed.  Work-in-process limiters are set for each step to minimize multitasking and overburdening of the system.  Though it may seem counter-intuitive, smaller work-in-process limits increases the work that can be accomplished.

Teams using Kanban rigorously collect and analyze metrics on the flow of work.  Through this analysis, inefficiencies are highlighted.  This provides the team with valuable information on how to continuously improve the process—known as Kaizen.

Kanban can be combined with other development methodologies. It is also a great framework for managing routine business operations.   Teams using Kanban often follow practices similar to the Daily Scrum and Sprint Retrospective.

Which Methodology?

Agile is methodology agnostic and is welcoming to an array of practices.  Within the Agile community, there is hearty discussion regarding practices and approaches.  Some believe that Scrum is a better.  Others argue that Kanban is an easier first-step approach.  Several leading companies have moved past Scrum to Kanban which only further complicates the conversation.

Both Scrum and Kanban are solid methodologies.  In my opinion, going Agile is more important than the methodology; and the best path depends on the organization and its needs.  Below are some considerations when picking an approach:

 Getting Started with Agile

Many recommend starting the Agile journey with Scrum.  It offers a prescriptive methodology with clear roles, ceremonies, and processes.  It provides the team with a structure and a built-in coach (the Scrum Master) to assist with the transformation.

Others acknowledge that Scrum requires a significant cultural transformation.  Organizational silos and boundaries are disrupted.  The Scrum Master and Product Owner are new roles that may feel foreign.   Managers may feel threatened by their self-managing teams.

Kanban can offer a less disruptive path to Agile.  You can start implementing the Kanban board with its workflow and work-in-process limits even within a waterfall-like process.  The benefits of transparency, incremental delivery, and flow can be achieved quickly.  Kanban is less disruptive to most cultures and often easier to adopt.

 Customer Engagement

Scrum excels when the problems are complex, and solutions are not clear.  These projects benefit from the regular interaction between the Product Owner and the Team.  The process creates connectivity and regular interaction points.  Engaged customers value iterative and incremental development because they can quickly react and adapt to what they see.

Scrum sets high expectations for the Product Owner.  The Product Owner must represent the entire stakeholder community, be knowledgeable about the product, and have capacity to work with the team on a daily basis.  Many organizations struggle with finding an individual that can meet these requirements.  Empowering the Product Owner with sufficient authority to be effective is also often a challenge.

As a methodology, Kanban does not have an equivalent to the Product Owner because it is focused on the flow of work.  Projects that require significant customer engagement would need to tailor their practice to ensure this need is met.

Well Defined Needs

Well defined projects, such as maintenance, upgrades, or small enhancements, may be well suited for Kanban.  Daily engagement with the Product Owner or regular reviews of working components may not be necessary.  What matters most is the regular and frequent delivery.

Kanban is well suited to this type of work.  The goal is to maximize the flow and deliver value quickly.  The process of continually analyzing and reviewing metrics along with continuous process improvements reduces waste and inefficiency.

Kanban does not artificially time-box development into fixed duration increments.  Changes can be released into production when they are ready.  If teams have the discipline to deliver incrementally and frequently, they may prefer the flexibility offered by Kanban.

One of the great things about Agile is that the different frameworks and practices are mostly complimentary.  So, if you initially choose one approach you can incorporate best practices from another or easily shift as your or project environment changes.

© 2018, Alan Zucker; Project Management Essentials, LLC