Scrum vs Kanban. Both are used in Agile practice to help teams visualize and significantly improve processes in order to help them to build better products and services.

Google, Apple, Facebook or Yahoo are using Scrum. On the other hand, HP, Pixar, Zara or Spotify are using Kanban. But note that they are not in opposition, it’s not one or the other. In fact, there are a lot of companies that believe to most benefit when using them in tandem. So, let’s look at both Scrum and Kanban and analyze the most important differences between these Agile Methodologies.

But first, Scrum vs Kanban, the origin stories… 

Scrum and Kanban are two terms that are incorrectly used interchangeably or thought to be two sides of the same coin. In reality, they are two different Agile methodologies. And their origin stories can show us exactly this:

What is the history of Scrum?

The story starts in 1986 in Harvard Business Review. Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in ‘The New New Product Development Game’ article. The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries.

Scrum and Rugby. Takeuchi and Nonaka borrowed this idea from rugby, hence the name. They called this the rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, in which the team ‘tries to go the distance as a unit, passing the ball back and forth’, similar to rugby where each team interlock with their heads down and attempt to gain possession of the ball. Takeuchi and Nonaka later authored the Scrum Guide, in 2010, which is recognized today as the official Scrum Body of Knowledge.

What is the history of Kanban? 

Kanban’s story originates decades earlier, when Japanese shop owners used sign boards in crowded streets to advertise their wares and differentiate them from competitors. The name comes from two Japanese names, Kan meaning ‘sign’ and Ban meaning a ‘board’. Years later, one of the most important Japanese companies, Toyota, created in 1956, through its engineer Taiichi Ohno, a system that used paper cards for signaling and tracking demand in his factory, naming the new system Kanban. Fast forward to 2004, David J. Anderson was the first to apply Kanban to IT, software development, and knowledge work.

Scrum vs Kanban: principles behind each of these Agile Methodologies

Scrum is a tool that cross-functional teams use in order to organize their work into small, manageable pieces that can be completed within a prescribed time period. They work in sprints that are generally a period of 2-4 weeks. Scrum is founded by the idea that knowledge comes from experience and making decisions based on what is known. And it’s based on three pillars: 

  • Transparency: significant aspects of the process must be visible for those involved in the outcomes.
  • Inspection: those involved must frequently inspect the artifacts and progress towards the goal.
  • Adaptation: if any aspect of the artifacts or progress is unsatisfactory, adjustments must be made as soon as possible.

On the other hand, Kanban, like Scrum, is also a tool used to organize work for the sake of efficiency, breaking it down into manageable pieces. But, if Scrum limits the amount of time allowed to accomplish a particular amount of work, Kanban limits the amount of work allowed in any one condition like only so many tasks can be ongoing or only so many can be on the to-do list. And has four foundational principles:

  • Start with what you do now.
  • Agree to pursue evolutionary change.
  • Initially, respect current roles, responsibilities, and job titles.
  • Encourage acts of leadership at all levels.

Read also: The Main Differences Between Angular, React, and Vue. And Which Framework to Choose

Scrum vs Kanban, how do they work

As we said before, both Scrum and Kanban allow for large and complex tasks to be broken down and completed efficiently. And both share the very similar focus on a highly visible workflow that keeps all team members in awareness of the current status of the work, as well as, what’s to come. But each of them works differently. 

Scrum has 5 steps that help the team to manage product delivery, while maximizing opportunities for feedback:

  1. Sprint Planning, where the team decides what and how to deliver in the coming sprint. 
  2. Sprint, a timeframe of a month or less where the team delivers what was agreed in the sprint planning session.
  3. Daily Scrum, a 15-minute daily meeting to inspect progress and identify blockers.
  4. Sprint Review, a four-hour meeting at the end of the sprint to present the work and gather feedback.
  5. Sprint Retrospective, a three-hour meeting before the next sprint planning, where the team reviews their work and identify opportunities for improvement.

Kanban has six core practices:

  1. Visualize the Flow of Work. Use cards or software to visualize the process activities.
  2. Limit Work in Progress. Encourage your team to complete their task before taking up new work. The idea is that they only pull in new work only when they have capacity to handle it.
  3. Manage Flow. Observe and analyze the work on the go and address any bottlenecks.
  4. Make Process Policies Explicit. Visually diagram the process rules and guidelines for managing the flow of work.
  5. Implement Feedback Loops. Incorporate regular reviews to gather feedback.
  6. Improve Collaboratively, Evolve Experimentally. As a team, look for and incorporate improvement initiatives, including through safe-to-fail experiments.

3 important differences between Scrum and Kanban

  1. Team Roles. In Scrum you have 3 very important roles: the Scrum Master (a servant leader responsible for helping the team understand Scrum theory, practices, rules, and values), the Product Owner (the sole person responsible for managing the Product Backlog) and the Team Members (self-organizing group of 3-9 professionals responsible for delivering the products). On the other hand, in Kanban no set roles are defined and they are not required to be cross functional. However, there are two roles that can be found within this tool – Service Delivery Manager, the person who ensures work items flow and facilitates change and continuous improvement activities and Service Request Manager, the person who orders and prioritizes work items and improves corporate governance with the process.
  2. Work Boards. In Scrum, you have labeled columns to reflect periods in the workflow from beginning through the team’s definition of done. In Kanban, the columns are likewise labeled to show workflow states, but also publish the maximum number of stories allowed in the column at once.
  3. And finally, scheduling or cadence. As we said before, Scrum puts teams to work in sprints, focusing on schedules with a prioritized list of story points. This process enables accurate estimations of work flow and effective management of multiple projects. On the other hand, in Kanban there are no required time boxes or iterations. In this tool, continual improvement is expected to occur in an evolutionary fashion as work is continually completed.

How to choose the right one for you

Both Kanban and Scrum were created to help teams to increase their efficiency and productivity. On one hand, the Scrum framework is better suited for managing complex projects. These are the ones that include multiple resources, tasks, team members, milestones, and stakeholders. For short, light-weight projects that don’t face constant changes or risks, you can stick with Kanban.

But, note that no matter what you choose, one thing is sure: companies must go Agile. Companies must deliver digital services quickly and they must align with customers’ ever-changing needs. We live now in a fast quality delivered era and we can no longer wait for monolithic and bureaucratic change procedures. This is the reason why most successful companies choose to use Scrum and Kanban in pursuit of this agility. Some of them use one Agile methodology, others use a combination of these two. 

To decide what to choose, you should look at your business requirements. Having your team onboard with that Agile methodology you use is essential. So talk to your team, ask questions, listen to their needs and their way of work and find out what they need to do their jobs.

We are looking for Project Managers, Quality Assurance and Developers who can change the future with us. Are you the one? Drop us a line and let’s meet! Check our Careers page and apply now.