Scrum vs. Kanban

How Kanban is different from Scrum?

Please note: The correct pronunciation of Kanban is “kahn-bahn” not “can ban.”

Scrum is an Agile Framework which aligns to the Agile Manifesto’s 4 Values & 12 Principles. Agile approaches focus on customer collaboration through incremental delivery of value to the customer. The Scrum team constantly inspects what is being built and the process building it, and constantly adjusts and adapts its way forward with customer feedback at the center of what the Scrum team is building and how the team is building it. Kanban is an approach which can be traced back to lean manufacturing and the Toyota Production System (TPS). Lean manufacturing had its inception in in the 1940’s and 1950’s, and recently thought leaders have taken ideas from lean manufacturing and have tried to apply similar concepts to software development. For example, in lean manufacturing, one focus is on ways to eliminate waste.  Similarly, we can apply the concept from manufacturing and eliminate waste in software.

Scrum Roles vs. Kanban Roles

In Scrum there are three roles—Scrum Master, Product Owner, and Development Team. In Kanban, there are no defined roles.  If an organization wants to adopt Scrum, these three roles must be filled.  In Kanban, the organization does not have any requirement to fill any specific roles. Many organizations struggle to implement Scrum because they do not have someone to be the dedicated Scrum Master.  In an attempt to save money, management has a project manager or development lead “fill-in” for this Scrum Master role. While this could work perhaps 2% of the time, most likely it will backfire as it becomes a conflict of interest having this dual-role person exist. The Scrum Master role then becomes something that nobody wants to do, and shortcuts are taken that jeopardize the team’s ability to self organize.

Scrum Meetings vs. Kanban Meetings

There are four Scrum meetings (properly known as Scrum Events) — Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.  In Kanban, there are no requirement to have any specific meeting at any specific time.  However, many Kanban teams, like in Scrum, will meet daily and walk the Kanban board together in a standup meeting. In Scrum, this standup is called the Daily Scrum. Generally, a Kanban team will have a retrospective but it can happen whenever the team decides it needs to stop and reflect. In Scrum, the team is obligated to run a retrospective meeting at the end of every sprint.  It is good to stop and reflect, inspect and adapt and come up with improvement items for the next Sprint. However, this retrospective meeting is often poorly facilitated by the Scrum Master and many teams do not reap the intended benefits, but merely meet for 15-20 min to “check the box” on “doing Scrum” correctly. (Our Advanced Certified Scrum Master (A-CSM) courseprovides a deep dive into facilitation skills for the Scrum Master who wishes to learn how to run an effective retrospective meeting without getting stale.) Many Scrum teams hold ongoing Product Backlog Refinement (PBR) sessions in order to keep the Product Backlog in a state of readiness for upcoming Sprint Planning meetings. In Kanban, a similar meeting can happen any time, and this is often accompanied by a replenishment meeting to bring in new work items (Kanban cards) onto the Kanban board.

Sprint vs. Kanban WIP Limit

Limiting work in progress (WIP) can help a team focus on finishing work.  Imagine you have twenty things on your to do list over the weekend. If you start all twenty things on Saturday morning,  is not likely you would finish all twenty things by Sunday night.  Chances are you may finish one or two but then have a whole bunch of half other started to do’s. In Scrum we limit work in progress (WIP) with the sprint timebox itself—usually two weeks. This means the Scrum team is only focused on enough work from the Sprint Backlog that can complete within the two week timebox.

Scrum Board vs. Kanban Board

The Scrum Board, often only used by a single team, gets reset at the end of every sprint.  Unfinished work does not automatically carry over into the next sprint.  However, in Kanban, the board is persistent and can be used by multiple teams or individuals to manage the flow of work. In looking at some of these comparisons between Scrum and Kanban, one may begin to wonder which approach is the correct one? Why not try both and see?