Kanban and Scrum are not counter to the other.
It is likely that you would use Kanban strategies while taking part in a Scrum. Equally, there is no reason why you wouldn’t work in short burst with iterative reflections while relying on a Kanban organisation of tasks.
Therefore, here we introduce you to both and consider the strengths and weaknesses of both. Then, for a project manager, it is a matter of deciding the balance within any given project between the strategies.
What Is Kanban?
Kanban started in Japan with Toyota as a system to manage the manufacture and supply of components.
The manufacture is regulated by an instruction card that is sent along the production line. Toyota noticed that supermarkets managed stock by inventory and not vendor supply. In short, the shelf becomes empty – the shelf is filled up – a new order is put into suppliers. It is a just-in-time delivery process that keeps inventory items low and therefore risks low.
So, a new car would be sent for production only when demand dictated – which provides better levels of throughput and reduces waste.
So, Kanban is a way of tracking the million and one jobs that can be open at any one time in a project, with items that might be at different points in a workflow.
It is a better way of communicating work through a visual management system. It is based on the principle that our brains can process visual information 60,000 times faster than the written word.
All of this makes it seem incredibly scientific and clever and the fodder for highly academic professors to give lectures in dusty university halls.
Buy yourself a whiteboard, some sticky notes and some pens. Draw your workflow in a series of columns across the top of the whiteboard. Alternatively, write “to do”, “doing” and “done” as column headings. Now, write tasks on the sticky notes and stick them under the appropriate column – based on the status of the job. When the status of the job changes you move the sticky note along the board, so your team knows what needs to be done now.
Some theorists believe there is a fundamental principle behind Kanban that will mean you are willing to adopt it or not.
This principle is that you cannot get where you are going without first knowing where you are and where you want to go. You need to have a strong understanding of your workflow and therefore can represent this workflow in a chart such as Kanban.
Obviously, you can use a simple board of to do, doing and done but to be thoroughly useful you need to understand the steps of your project production process.
However, some would say ironically, Kanban has become more popular since Agile, and Lean management strategies have gained popularity. Both project management strategies require the flexibility of approach, with an iterative understanding of workflow.
Here are the main ideas behind how Kanban works, which might explain how these alternative views can be held.
How Does Kanban Work?
First, Kanban works visually. You can create a visual representation of workflow – but you can also create a model of the work you need to do. You can make work visible – but most important you can make it clear what are your blockers, bottlenecks and queues.
Therefore, it visualises the problems and risks to your project process and gives you an opportunity to problems solve – or reflect – on how it could be done better.
The second reason Kanban is becoming so popular is that it limits the amount of work in process. The amount of unfinished work can be reduced because you can see what work is being done. It will also mean that a project manager can encourage prioritisation over tasks for team members who are struggling to move tasks through the process
With such a visible representation of your team’s work, you can also track performance easily. You can collect metrics and analyse flow, which helps with reflection.
This means that the Kanban system promotes a potential for continuous improvement of processes and approach – something that makes it appealing to the Agile system of project management.
What Is Scrum?
The term scrum comes from rugby. In rugby, the two teams go head to head and push against each other to gain territory. One of these scrum teams represents the central idea behind this project management strategy. Each member of the scrum has a role in guaranteeing forward progress, and it requires them to all move in the same direction.
You can see why the metaphor is appealing to project managers!
The scrum is part of the Agile framework and can be insanely complicated if you get lost in the vocabulary. However, put simply you have a team of people with mixed skills but who take on all aspects of the project.
You work in short bursts, and at the end of each burst, you reflect and adapt and move the project forward to the next short burst.
The project is led by a product owner who creates a prioritised list of work called the backlog.
The team use this to plan a sprint, which is the short burst of work. They pull out the chunks of work from the top of the list and put these in the sprint backlog and try to work out how to implement these.
Then, the team has a set period – usually about two weeks – to complete the work. This is called a sprint. At the start of each day, the team meets to assess progress in a daily scrum – a pulling together of the team to explore how the work was done by each member is pushing the team forward.
The scrum master guides the work through the sprint. This is a mentor role rather than a leadership role – it is meant to keep the team focused on the goal.
How Does Scrum Work?
At the end of a sprint, there is a period of reflection. Theoretically, the product should be shippable at this point – should the product owner decide.
After the reflection, the team chooses another chunk of work from the product owner backlog to put into the sprint backlog, and so the work begins again.
As the project management strategy was first used in software development, it meant that an app could be delivered to market before it was complete. Then, future sprints would provide updates to the application as each sprint is complete.
This means that the team also receive data from customer experience to inform the production process and potentially the company is earning money while the project is still in production.
The major success of a scrum is its ability to prioritise work. At any one time, in theory, only the most valuable work is being completed until the work of the project ends. With marked milestones, the progress of the project can be easily tracked through metrics.
Read more in Scrum Project Management Methodology.
Should You Choose Kanban or Scrum?
This is not an either/ or situation. Most scrum teams will represent the sprint backlog in a Kanban chart, and the chart will form a central focus on the daily scrum meeting of the team.
The question is: do you need to apply a project methodology beyond Kanban and so include the features of the scrum?
Where scrum offers some benefits is its stress on planning. The backlog and the sprint backlog are structures for working out which work should enter the workflow or not. A simple Kanban chart based on demand is much less directed. It could end up with people switching between tasks in the workflow and therefore lead to much less productivity and less team cohesion.
This difference between Kanban and Scrum is further emphasised by the lack of control the project manager has overestimation of production.
The milestones in Scrum allows for a clear sense of what should be achieved by a team by when. In Kanban, individuals are allocated tasks and may be given individual deadlines – but how this fits into the scheme of the whole project takes a lot more investigation – and usually the help of a Gantt chart and a set of dependencies.
Both strategies focus on the importance of metrics and in both, you can chart progress and performance. Both in their ways promote flexibility.
The main difference is that one is complex in its structure, and one is potentially very simple – but maybe too simple to thoroughly structure a project.
Overall, there is no reason why you cannot use both Kanban and Scrum strategies for the good of the progression of your project.
As with all tools and techniques, it is a process of working out what works for you and your team – and it may be a strange hybrid of the two systems.
You may not want to get lost in what feels like project management geekery of scrum – but equally a Kanban chart might not offer enough structure for the planning, implementation, reflection and improvement of production processes.
The good news is – you really don’t have to choose one over the other.