Scrum v Kanban

Scrum v Kanban? It's the most frequently asked question in training classes. People want to know which is better, or when to use one method over the other. Well, it's a flawed question. Or at least a question based on a flawed premise. Read on if you would like to find out why.

In the context of agility, Kanban refers to The Kanban Method - a management method for managing all types of knowledge work and professional services. It is perceived as an "agile method", but in reality, it is a method for catalysing evolutionary change and improvement within an organisation. Organisational change is difficult, but The Kanban Method is designed to reduce resistance to change while bringing beneficial improvements in line with the organisation's goals.

Knowledge work is inherently invisible. It exists as ideas, conversations, messages between individuals or information captured in an electronic tool. The Kanban Method strives to make such intangible work visible so that workflow challenges, problems or bottlenecks are seen. After all, it is tough to change or improve something invisible.

The Kanban Method also prevents too much (or too little) work from being worked upon by implementing a Kanban System. A Kanban System limits the amount of work in progress (WIP) by using visual pull signals, called Kanbans, thereby improving the flow of value to customers. By limiting the amount of work in the system, new work is "pulled in" only when work is completed and capacity becomes available - in contrast to new work being "pushed in" when it is demanded.

To understand the difference between The Kanban Method, a Kanban System and the Japanese word Kanban, check out this article; Kanban - what does it actually mean?

So, The Kanban Method is a change management method that utilises the power of Kanban Systems to improve the flow of value to customers whilst making work visible, thereby creating the impetus to improve.

As a method for change, it has a set of principles and practises to guide evolutionary improvement. There are six principles, three of which focus on change management. The three Change Management principles of The Kanban Method are;

1. Start with what you do now

2. Gain agreement to improve through evolutionary change

3. Encourage acts of leadership at all levels

The Kanban Method is often called the "Start with what you do now method". As a change management principle, the starting point for the change is whatever you are doing right now. Unlike other change management approaches, a new idealistic world is not designed in advance with new roles & responsibilities, new teams, new meetings and artefacts. The Kanban Method rejects that traditional approach to change due to the amount of resistance it provokes. When a change starts with what you do now, resistance is reduced. But starting where you are now is not enough. More is needed, which is principle 2.

"Gain agreement to improve through evolutionary change". This principle tells us that as we begin with The Kanban Method, we should all agree that we can continually improve no matter how good we think we are. So even though we do not make any significant changes initially, we should agree we can improve and evolve from here. And unlike a more traditional approach to change, it is not left to one person to be responsible, hence principle 3.

"Encourage acts of leadership at all levels" reinforces that we are improving and evolving together, where everyone can and should play their part. As we evolve, everyone is encouraged to speak out and be courageous as the evolutionary change continues.

Looking at The Kanban Method from the perspective of it being a change management method but one with a unique approach to change, perhaps it is now clear why the Scrum v Kanban question is based on a flawed premise.

The Kanban Method is the "start with what you do now" method, so it does not matter what you are doing right now. You can apply the six principles and the six practises and then begin to evolve and improve. It is a compelling approach as a coaching tool, notably where Scrum has stalled or has not provided the anticipated benefits. Layering the principles and practises on top of the current way of working is a powerful way to evolve and improve.

So, rather than the question being "Scrum v Kanban?", the statement should be Kanban plus... (whatever you are doing now).

Q & A

• What are some specific industries or types of projects where Scrum might be more advantageous compared to Kanban, and vice versa?

Specific industries or project types where Scrum might be more advantageous compared to Kanban, and vice versa, can vary based on factors like project scope, team dynamics, and customer requirements. For instance, software development projects with rapidly changing requirements and a need for frequent feedback loops may find Scrum more suitable due to its iterative nature and regular sprint reviews. On the other hand, maintenance projects or continuous improvement initiatives may benefit from Kanban's focus on flow and visualization of work, especially when the work items have varying priorities and sizes. However, this is more the conventional thinking about Kanban. The reality is, Kanban can be applied to any existing method by utilising its principles. In doing so it does not mean Kanban has "taken over" as the method of choice, but rather a way to improve the current situation has been adopted.

• Can you provide examples of how teams have successfully combined elements of both Scrum and Kanban methodologies to create a hybrid approach? How do they manage the potential conflicts or overlaps between the two frameworks?

Examples of successful combinations of Scrum and Kanban, often referred to as Scrumban or Kanplan, can be found in various industries. For instance, a software development team might adopt Scrum ceremonies like sprint planning and retrospectives while using Kanban boards to visualize workflow and manage work in progress (WIP) limits. This hybrid approach allows teams to capitalize on the strengths of both methodologies. To manage potential conflicts or overlaps between Scrum and Kanban, teams often establish clear communication channels, define roles and responsibilities, and continuously adapt their processes based on feedback and lessons learned.

• How do factors such as team size, project complexity, and organizational culture influence the decision to adopt either Scrum or Kanban, and are there any guidelines for determining which framework is more suitable for a particular context?

Factors such as team size, project complexity, and organizational culture play significant roles in determining whether Scrum or Kanban is more suitable for a particular context. Larger teams or projects with complex dependencies may find Scrum's structured framework beneficial for coordination and alignment, whereas smaller teams or projects with simpler workflows may prefer Kanban's flexible approach. Additionally, organizational culture, including aspects like tolerance for change, willingness to experiment, and emphasis on continuous improvement, can influence the choice between Scrum and Kanban. While there are no one-size-fits-all guidelines, teams can evaluate these factors and experiment with both methodologies to find the best fit for their unique circumstances.

Interested to learn how The Kanban Method can help you and your organisation begin the journey of continuous evolutionary improvement? Sign up for one of our training courses or get in touch to discuss our coaching services. We will be happy to help.