Kanban and Scrum: Comparing the Incomparable

By Joshua Render on February 22, 2019 • ( Leave a comment )

There are a lot of differences between Kanban and Scrum. I would even argue that they aren’t truly comparable. I attempt here to explain simply what they are and why they don’t exactly have the same uses and capabilities.

When I think of ultimate organizational agility, I imagine an organizational Kanban system with a strong cultural presence of human-centered values. Scrum doesn’t have that same level of versatility. Scrum can’t go everywhere; Kanban quite possibly could just about go anywhere.

What is Kanban?

Kanban in Agile is a continuous workflow system that relies on pulling work into the next process. Where most Agile frameworks discuss iterative and incremental delivery of the work product, Kanban stresses a continuous flow of work through all of the processes in a controlled and organized way.

Kanban isn’t designed to take over your workplace. You aren’t likely to need wide sweeping changes to roles, responsibilities or role name changes. Kanban has no defined roles. It isn’t really a framework so much as it is a method for tracking work and controlling the workflow/work output. It is more for complementing the existing way you work and brings a focus to doing what is needed.

Kanban controls the workflow by limiting Work in Progress (WIP). Here, we can get all technical and discuss line theory and Little’s Law – but instead, I will ask you to think of your own house. How much food do you have around? Varying amounts I would imagine depending on what type of food, expected usage, and expiration dates. How do you get this food into your house? There are two primary ways of moving goods and services around – the pull system and the push system.

Books on Scrum, Kanban, and Scrumban

Push System / Pull System

Most of your food probably relies on what is called a pull system. When you start to run low or run out, you buy some and replenish your stock. The grocery store you buy from doesn’t have an unlimited supply. They try to keep enough on hand for the expected demand. This works well most of the time and helps limit loss from expired food or maybe clothes that go out of style. It limits the loss of obsolete goods. This is how Kanban works.

There is another way to get your food. It is more similar to a push system. Amazon has a feature called “Subscribe and Save” that lets you set up regular delivery of items you want. What happens if you don’t use up all of your food and a new shipment comes? What happens if you run out before the new shipment comes? If you want to stockpile food, this may be one way to do it.

I use a subscription system for wine and shaving razor blade cartridges from different companies. The wine I can never consume enough of, so I always have to move back the delivery date. When it comes to the shaving razors, I work from home and don’t shave regularly. This has given me like 20 packages of razor blades shoved into various nooks and crannies in my bathroom. I found some rusted razor blades once, wasting my $6 for that month that was probably spent four years prior (It’s still cheaper than buying them in a store, which is why I haven’t stopped it). This is how a push system works – you have to do something with the items being pushed on you whether you need the items or not.

I have heard some argue that Kanban isn’t really Agile because of its lack of defined principles, roles, and iterative cycles. They aren’t necessarily wrong and they aren’t necessarily right either. That lack of definition I think can make it more agile, but I present to you my own more defined Kanban version, The Mercurial Perspective, if you want a Kanban with principles and some possible methods of doing work on an organization-wide level.

The “Kanban isn’t really Agile” people are right because Kanban is Lean. If you have some familiarity with manufacturing then you know about kanban and the visual system there. Kanban in Agile is not that, although it includes that.

Kanban in Agile is really Just in Time Manufacturing from Lean. A better name for Kanban might be Just in Time Delivery. Now, if you have worked in manufacturing as long as I have (about 12 years total), you might have had some bad experiences with JIT Manufacturing. Usually, for me, those experiences involved errors or manufacturing problems mixed with not enough Work In Progress. Just in Time Manufacturing doesn’t mean no inventory, it means a more controlled inventory level (Little’s Law).

Kanban/Scrum Board Tool Set

What is Scrum?

Where Kanban is loose, Scrum tends to be more strictly defined. Scrum defines new roles and creates a product development team. That team has a core focus – creating a product or an output and continuously evolving through iterative and incremental development.

On a Scrum team, there are three primary roles:

Scrum Master
Product Owner
The Development Team

Each team is made up of those roles and very little is defined outside of those teams. In recent years, Scrum has worked to define organizational agility. This mostly focuses on how managers and leaders should work with a Scrum team.

Scrum can work in product development or project management. Scrum’s primary role is product development but it also interprets projects as developing a product (fairly accurate description). There are probably better-suited frameworks for project management such as DSDM.

For continuing, ongoing product development, Scrum can be a good choice. Often in product development, you don’t always have as clear of an end-goal in mind through continuous advancement like you would with a project that is expected to last 6 months or a year. This is one reason why long-term product teams seem to adapt to Scrum better, but a lot of Scrum project teams still get led by a Project Manager that brings in some of the Scrum practices – thus making most of my Scrum experience horrible (I tend to work projects).

Scrum works in little iterations – like mini-projects. These iterations last about 1-4 weeks. Scrum calls these iterations Sprints and for each Sprint the Scrum team will plan out what work they want to perform to enhance or add features to the product. This makes Scrum an iterative and incremental way to do work. Iterative and Incremental workflows are not as versatile as a continuous flow of work and they require a strong commitment to maintaining each structured iteration and subsequent incremental release. This is not a very natural way for most people to work or think.

This would be like planning your cooking schedule and grocery store visit in very specific time increments. You plan out what you are going to cook for meals during the two weeks, and you go grocery shopping every two weeks. You want to be prepared for each shopping trip so you make sure to set up some time for planning out your list as well. You might confer with the stakeholders (your family) some when planning the meals and a grocery list.

Then at the end, you hold a meeting with your family and ask them what they liked about the meals you prepared and what you could do better in the next two weeks. You adjust your future meal plans accordingly.

Most people don’t function like that, although it can be a very nice and streamlined way of doing things. Product development can benefit greatly from the structure that Scrum brings to the table. Grocery shopping and meal planning… it probably requires more work than needed to use it. I don’t really recommend you use it for meal planning.

Scrumban

Scrumban is a hybrid framework of Scrum and Kanban. Having limited to no experience with the Agile framework Scrumban, I am rather skeptical of how a system like that would work and truly embrace Kanban. The only way I can explain it is that they just shove in a kanban board for use in Scrum.

You can find more information about Scrumban from the Agile Alliance.

Scrum and Kanban Side By Side

	Kanban	Scrum
Iterations	Continuous flow.	1-4 weeks.
Incremental Delivery	Incremental development possibility exists. No standard structure defined.	Released each iteration
Target Work Environment	General – everyday work, product development, project management, any process that can be visualized and streamlined with a continuous flow.	Product development and project management primarily.
Roles	Works with existing roles, or you can modify the roles.	3 core roles: Scrum Master, Product Owner, and the Development Team.
Teams	Works within the existing teams or you can modify teams.	Scrum Team with the 3 roles filled.
Meeting Schedule	Regularly suggested meetings of a Prioritization Meeting, a Daily Stand-up among teams, and Retrospective Meetings aimed at continuous improvement.	Defined schedule of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Versatility and Adaptability	Highly versatile and adaptable. Conforms to the organization.	Fairly rigid with low environment adaptability. Requires organization to conform to it.
Delivery Method	Pull System.	Push System – The Increment is coming on a set schedule whether you need it or not.
Hybrid/Scalability Uses	Can be used within other Agile and non-Agile frameworks. Scrumban is Kanban placed into Scrum. Scalability is theoretically infinite as long as team sizes are kept within controllable limits.	Hybrid uses – reportedly it can be used within the Agile Project Management Framework DSDM, and the Agile Development Framework XP (XP is pretty much Scrum with software development best-practices built-in). Merging it with Waterfall PM techniques seems to create a poorly utilized version of DSDM. Scaled up Scrum (like Nexus) is used in scenarios where more people are needed to do the required work.

In Conclusion

I lay out in more detail what Kanban is here in the post What is Kanban? and here in What Types of Meetings Should you Have in Kanban?. I also try to explain what I have dubbed the Mercurial Perspective here Kanban: The Mercurial Perspective. (*more information on the Mercurial Perspective can be found here at https://mercurialperspective.com/.)

I also have a growing library of Scrum articles and even a video: Video: What is Scrum?.

Hopefully, it is fairly clear what Scrum and Kanban are, at least on a general level. They are really two different ways of doing different things.

Sources:

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

IBQMI (2017), “Certified Kanban Coach; The Official Training Material” International Business and Quality Management Institute. Cheyenne, WY.

Toyota: Toyota Production System- http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/