A question that I often get while speaking with people is:

What is the difference between Kanban and Scrum?

I know this topic has been explored at length in many places on the internet and also with a variety of different answers, but I’m going to put my thoughts down and share them with you because:

1. I still feel there is a lot of misunderstanding on this topic and I think I have something to add to the conversation
2. People still ask. The more of us who can blog and promote conversation on the topic, the better.
3. Getting my thoughts out and in a more concrete form that I can reference (and send people to reference) should promote better conversations as well.

So. Here it is. Kanban Method. Scrum. I imagine I’m about to step on some toes but I hope we can have some good debates and not conversations filled up with rhetoric.

Similarities

Goals

At their hearts, both methodologies are attempting to do the same thing. They are attempting to advance the state of the art in work management predominately (but not only) in the area of knowledge work.

Value-system Influences

Both are heavily influenced by value-systems. Scrum is primarily influenced by the Agile Manifesto which describes the “Agile” value system. The Kanban Method pulls a great deal of its values from a Lean value system. There isn’t really a “Lean Manifesto” but the works of Taiichi Ono and W. Edward Deming contribute to a common understanding of what it means to be a lean thinker. They are not the only contributors but have made the most significant impressions on the Lean/Kanban community.  The Kanban Method is also influenced by the Agile Manifesto and the values inherent within it.

Increments

Both methodologies believe in delivering software incrementally to maximize the opportunity to get feedback and capture ROI. Incremental delivery of software also mitigates risk and maximizes the opportunity to learn from a business, process, and technical perspective.

People-centric

Both methodologies are striving to make people a central aspect of the system, which they should be. 😀 Scrum strives to “protect” the development team from the influences of “traditional” project management tactics. Kanban suggests that we need to allow solutions to problems emerge from the people in the system. Kanban also believes that changes should not be forced on people, but that people need to own the changes and be supported throughout the transition. Both systems try to give people the time and space required to improve.

Similarities with Significant Differences

Learning

Both approaches promote an intent to learn and improve. In Scrum this is primarily achieved through the retrospective tactic which is an Inspect and Adapt-based tactic. The team will get together (frequently) to discuss processes and tactics that have been going well and should be continued, things that haven’t gone well and should be changed for the next sprint. I do not believe that Scrum teams put sufficient emphasis on this aspect of Scrum and that the common understanding of Scrum doesn’t promote this aspect strongly enough. I also believe that the scope of the area under review primarily focused on the team. Again, this may not be the intent but it is, in my experience, the way it is implemented.

The Kanban Method has learning at the core of the methodology. There are several reasons for this, but the primary reasons for this are:

1. Do nothing without understanding the current situation
2. The current situation is always changing
3. New challenges (technical and business) are always arising
4. People, who are at the heart of the system, need to be learning constantly in order to be improving themselves and the system continuously
5. Without a learning approach to improvement, you can’t use experiments to test improvements

The Kanban Method uses more of a Plan – Do – Study – Adapt (PDSA) approach to learning and this is different from a Inspect and Adapt approach.

Cadences

Scrum prescribes a cadence and that all activities happen within that timebox. If you didn’t guess, this cadence is called the sprint duration. Sprint is just another name for the resulting timebox.

The typical Scrum cadence now a days seems to be 14 days (2 weeks) and follows the following sequence of:

Sprint Planning -> Execution (daily Scrum meetings) -> Iteration Review -> Retrospective -> repeat cycle 

Scrum’s Sprint duration is a great innovation over the traditional approach to managing work. Because the guidance on duration has never been longer than 30 days, Scrum teams have always been guided to strive for shorter feedback cycles than traditional projects. Scrum teams have also been guided to produce increments of software at the same rate. In order for Scrum teams to do this, work has to be decomposed and understood by the development teams. Work gets prioritized more frequently and this prioritization allows these teams to be agile from a business perspective. Risk can also be explored and mitigated within the sprint and that knowledge feeds back into the prioritization loops of the team.

In the Kanban Method, cadences are just as important as they are in Scrum. Many Kanban teams have a Queue replenishment cadences. This is effectively the same as the Sprint Planning activity in Scrum. Many (most?) Kanban teams have a daily stand-up meeting where the team discusses the current state of the kanban system, looking to remove impediments and manage work at risk of taking longer to deliver than expected. Many Kanban teams will have product demos (iteration review) that coincide with an opportunity to deliver or deploy the product being built. And many Kanban teams will have Operations Reviews which are an opportunity to discuss the Kanban teams progress and improvements with the rest of the organization.

The significant difference between the two systems is Kanban does not typically use timeboxes and all of the cadences in a kanban system can happen when it is best for the organization to do them.

Timeboxes are a mechanic that Scrum uses to minimize disruption to the development team. In Scrum, changes to the Sprint plan are strongly discouraged. Plan the two weeks, then let the team work uninterrupted. This has allowed for great improvements in productivity in software development, but what if we could apply that protective attitude to a single piece of work. So while a team was working on an item, they were not disrupted but they could be counted on to pull the next highest priority item on the queue as soon as they were ready to pull some work. The business could prioritize as much as needed while the team had work in progress.

Timeboxes are also used to provide a consistent interval that external parties can interact with the Scrum team. Business can plan around a 2 week cadence to injecting new requirements into the system, and downstream partners (IT, Sales) can count on getting new work or increments of software every 2 weeks as well.

In Kanban, the cadences that are most appropriate for the external partners can be allowed to emerge and do not need to be enforced (or tied together) by the development team. There are advantages for shorter cadences, but what if we could get all the way down to Just In Time and we no longer had cadences on replenishment and delivery? We can still have cadences on Ops Reviews or any other ritual that benefits from these cadences. What if replenishment happened every week, or daily, and delivery happened every 4 weeks? Or on the 25th day of each month? That is an advantage that many organizations benefit from when adopting a kanban system as a way to manage work.

Pull-based , WIP Limiting Systems

Both Scrum and Kanban ARE Pull-based, WIP Limiting systems. Scrum uses, in many senses, a kanban system at the heart of how they manage work. The Scrum team PULLS only the work they can manage into the iteration. The iteration planned work is the maximum amount of Work In Progress (WIP) that the Scrum team will be expected to deal with. The limit of the amount of work in the iteration is set by the team’s previous velocity measurements. But then we will start to encounter the limitations of the Scrum work management system. Scrum teams can still start a lot of work and suffer from the inefficiencies of multi-tasking. Having a lot of work in progress (started) but not finished is a significant source of waste in our industry. Humans cannot multi-task, we context switch and we all know that context-switching is expensive. Scrum does not have specific guidance to limit multi-tasking within a team. (Note: Please correct me if I’m wrong here. Haven’t read the Scrum Guide recently)

In a Kanban Method implementation, the focus is to limit WIP at a more granular level. Preferably at the work item level but we can also let the most appropriate granularity emerge by leveraging the learning aspects of the method. We use WIP limits to guide our intent to finish work before we start more work. We also use WIP limits to reduce overburdening. WIP limits are a great way to fine-tune your Kanban system and how and what to set them to would require a lot of explanation. Suffice to say that Kanban’s WIP limiting tactics allow for significantly more tuning that Scrum’s Sprint Planning tactic.

Work Items

Scrum teams tend to categorize work into two types, User Stories and Bugs. Both can be decomposed into tasks. Scrum actually provides guidance that there are “product backlog items” and that User Stories and Bugs may be types within that backlog. Additionally, Scrum allows work items to be of the same type but vary in size. This size is often described in Story Points.  So one User Story may be 3 points, another may be 13 points. And there is no common interpretation of a point between different Scrum teams. What a story point actually means is specific to a Scrum team.

Kanban Method teams tend to have numerous types of work. Requirements, User Stories, Use Cases, Bugs, Defects, Improvement Activities are all examples of work items I’ve seen on Kanban boards. Whatever makes the most sense for the organization. Kanban differs from Scrum in that it generally does not try to categorize work by a size. The size of the work items in a Kanban system don’t really matter from a management and monitoring perspective. Once the item has been committed to by the Kanban team, they should finish it within the expected timeframe given how big they think it is when starting. It is when it starts to exceed expectations that the Kanban team should start to pay closer attention to it and take corrective actions if possible. But other than setting an expectation when the work is committed to, sizing isn’t important from a work management point of view. It should be noted though that smaller work items are usually easy to manage from a development point of view because the larger a work item is, the more likely that item is to contain significant unknowns and lots of uncertainty.

Metrics

Both Scrum and Kanban use metrics to help drive behaviour and decision making.

There is really only one metric in Scrum. Velocity. Teams will assign a estimated value to a work item that is used to indicated how “big” it is. The team will work as many items as they can in a sprint. Once the sprint is completed, the values of all completed work items will be summed up and that was the teams velocity for the sprint. This velocity will be used to determine how much work is pulled into the next sprint during sprint planning. You can create burn-down or burn-up  charts based on the velocity metric as well. Typically, this is as scientific as a Scrum team will get. The summing of a subjective measure of size on a work item.

In The Kanban Method, all measurements are intended to be quantitative. Something that is measured and the value is (usually) not really debatable. In Kanban, we tend to measure time (lead/cycle) and quantities of things (work items) at various points in the workflow. These are all concrete, measurable attributes of work in the system. All that is needed is start and end-points and you can now start the clock when work gets into a state and then leaves the state. This can be as simple as started and finished or much more complicated with numerous states and parallel activities steams within a workflow. We also measure how many of something are in a particular state as well at a time as well. Ultimately in Kanban, we measure how long it took something to get somewhere. With these measures, we can determine rates, quantities, and speeds of work items and establish a deeper and more meaningful understanding of the system.

Differences

Workflow

Generally speaking, Scrum prescribes a set of activities that are performed within a Sprint. There is not any guidance on particular daily development activities but generally you should be analyzing, developing, testing, user acceptance testing throughout each day as applicable. But most Scrum teams will always do Sprint Planning, Development for the rest of the sprint, Iteration Review and Retrospective.

The Kanban Method does not prescribe any workflow. The workflow that you model in your Kanban system should be YOUR WORKFLOW, and it should evolve as required based on things that are observed and needed by the organization. A kanban system is expected to evolve and change over time as the organization (and it’s needs) change over time.

This also includes cadences. Scrum generally prescribes that the workflow happens within a cadence. Kanban does not prescribe cadences. It does appreciate the value of cadences but feels they should emerge where needed and the interval should be as long as needed, but Just-In-Time as much as possible.

Roles

Kanban does not prescribe any roles. Roles and responsibilities (and changes in them) should emerge based on the organizational maturity and understanding of the development process.

Scrum generally prescribes three roles, Scrum Master, Product Owner, and Team Member. If you’re on a Scrum team, you’re normally categorized as one of these things. I think that this can be a good thing, but it can also backfire as people try to find their place on the team. The individual esteem system of a person is influenced by what they think their place in the world is. Changing that place in the world can shake a person’s esteem and confidence, which tends to diminish their acceptance of a system or change.

System Thinking

Most people’s interpretation of Scrum is team-centric. This isn’t a necessarily a bad thing, but at some point it may become a limiting way of thinking when trying to scale Scrum or work with upstream and downstream partners of the Scrum team.

The Kanban Method takes a system thinking approach to process problems and expects the impact of changes to ripple throughout the entire workflow of the organization as business need/idea goes from inception (idea) to realization (software). Generally speaking, the kanban system is intended to protect the “work” (and therefore the team) from being disrupted so we don’t have to have a team-centric view of things. We can take a system thinking view of things and understand that every interface to our “team” system is actually an interface with a larger system that could benefit from The Kanban  Method implementation.

Final Thoughts

This post has been much longer than I expected and I’m not sure I’m even done, but I think I’ve covered off what I think are the similarities and difference between Scrum and Kanban.

What I want to leave you with though is that neither approach is wrong, nor do they need to be exclusive of each other. There are teams that have started with Scrum and arrived at a Kanban Method implementation, and there are Kanban Method teams that have arrived at a very Scrum like (or Scrum exactly) implementation because that set of tactics and tools were the best way to manage work for that organization. It should never be a Scrum vs. Kanban conversation, but rather a question of what is the best from both methodologies that I could use.

I believe there are aspects of The Kanban Method that Scrum doesn’t adequately address in our quest to better manage knowledge work workflows, so I do think that while you can always have a system with “No Scrum”, you should never have a system with “No Kanban Method” in it.

Thanks for following along on this rather epic article. I hope to hear from you, both positive and negative comments are welcomed.