We should not be debating whether Scrum or Kanban is better. Both have practices and principles to offer. Each has a different mindset towards learning, however. But instead of just blending them, we should look to a mindset that embraces both and enables us to create a more effective approach for our own context. By taking this bigger view and incorporating the practices that work in our situation we can create a more effective team process than either one alone, or even a combination of them based on only one of their mindsets.

Asking the right question

How often have you heard people debate or at least question which is better, Scrum or Kanban? It is easy to get caught up in that conversation. The problem is that it is the wrong question to be asking. It is much better to ask, “In our context, what works?” and then to choose what is most effective in the given situation… like yours!

It starts with Lean Thinking

It starts by looking at the essence of Lean, which I call “Lean Thinking.” By Lean Thinking, I mean the thought process that lies behind all of manifestations of Lean: its essence. While Lean-Manufacturing, Lean-Services, Lean-Product Development, and Lean-Agile Software Development all have different practices and even different intentions, they have are all based on common thought processes including:

• Systems thinking
• Continuous improvement
• Removing delays in workflow and feedback
• A commitment to quality

Both Scum and Kanban can be considered as partial implementations of Lean Thinking. Lean Thinking helps to assess both Scrum and Kanban appropriately and to understand in what ways they would work in a context.

Why Scrum works

The essence of Scrum is to have co-located, cross-functional teams that complete work in sprints of one to four weeks. These practices work to reduce delays in workflow because the people needed to get something done are always present in the team. Teams get the answers they need right when they need them. They also reduce delays in feedback because stories can be completed in a matter of days and Product Owners can provide feedback during the sprint or at least no later than at its end.

What Scrum leaves out

Scrum is great. But Scrum is missing some key elements. Scrum does not take a systems-thinking point of view. It takes a bottom-up approach. Mostly, teams work individually and then try to coordinate with a scheme such as a Scrum-of-Scrums and then finally attend to the business needs across the organization. This bottom-up approach focuses on only part of the value stream. Scrum also does not embrace explicit workflow within the team. Scrum does not explicitly manage work-in-process. Systems-thinking across the value stream and explicitly managing workflow virtually always improve collaboration and efficiency.

How Kanban implements Lean Thinking

Kanban is based on three basic principles:

• Visualize and make explicit how you do your work
• Limit the amount of work-in-process (WIP)
• Enhance flow

Kanban is known as a pull method. It has two mantras, “Flow when you can, pull when you must” and “Stop starting and start finishing.” Kanban’s focus on flow and managing WIP reduces delays both in feedback and workflow. Visualization and explicit policies of the workflow also improve collaboration, even when co-located teams cannot be used. Kanban is sensitive to culture and context and shows respect for current roles, responsibilities, and job titles.

What Kanban leaves out

Because of its sensitivity to culture and context, Kanban emphasizes starting where you are and evolving a solution. While the attention to context is essential, there are often practices and structures that are known to offer immediate improvements and that set the stage for better learning that everyone can agree to. By ignoring these opportunities improvements can be slower in coming than the teams expect.

Scrum and Kanban: Abrupt vs. evolutionary change

Scrum and Kanban are not merely different sets of practices, they are based on different models of transformation. While both work in many situations, they are somewhat extreme in their classic forms.

The transformation model of Scrum has teams adopt a set of practices that will expose all their impediments to efficient product development. This is usually abrupt change and is often disruptive. For it to work, the core practices and roles must be followed. But there are many cases where this is either difficult or not cost effective. Although Scrum’s framework is flexible as to what you put in it, the practices and roles to follow are inflexible (i.e., you must do sprints, …). Learning is supposed to take place by creating great teams and having them figure things out.

The transformation model of Kanban works on creating a better understanding of what work you are doing and following the principles of flow. It is based on evolutionary change, not the abrupt change that Scrum often demands. However, its focus on workflow ignores the value of cross-functional teams in many cases.

An integrated approach

The great thing is that you do not have to make an either-or decision. It is more effective to include both in appropriate ways. Lean Thinking helps you out to create a more effective approach that fits the context of a team. Lean Thinking helps you see that they have much more in common than they have differences. And it turns out that several practices of Scrum and Kanban (and even eXtreme Programming) should be done by all teams. Here are some helpful insights.

Practices that Scrum, Kanban and XP have in common:

• Use small batches of work
• Self-organization
• Daily Standups

Scrum practices that virtually every team should use:

• Use estimation and velocity

Kanban practices that virtually every team should use:

• Have a focus on finishing
• Make all work visible
• Have an explicit workflow
•  Manage WIP explicitly

eXtreme Programming practices that virtually every team should use:

• Use Acceptance Test-Driven Development (ATDD)
• Continuously integrate and use automated testing

The decisions facing you

You are faced with a few primary decisions.

• Will you use iterations? Iterations are useful because they provide discipline – the time-boxing gives you an end-date and creates a focus on completion. It also forces the team to develop in small stories. However, if teams that are doing mostly maintenance or unplanned work, you may find that just working on items that come in and focusing on finishing them doesn’t require sprints. However, even in these cases having a common cadence for input, output, demos, etc., is still useful.
• Will you use cross-functional teams? Whether you can have cross-functional teams or not, they are a good idea. Create them to the greatest extent possible.

Summary

Guide your thinking by focusing on what makes for effective teams: Creating value quickly, sustainably, and with high quality. How to do it depends upon the context of the team and the type of work they do. Trying to pick Scrum or Kanban can result in missing the opportunities that a blended model based on Lean Thinking provides. Each approach provides valuable insights; in fact, several practices of Scrum, Kanban and XP are useful for virtually every team.