Kanban vs Scrum—what’s the difference and which should small businesses follow? The two workflow management methods are frequently pitted against each other. In this article, we explore the difference between Scrum and Kanban, and which is best for project management.
Scrum and Kanban are agile frameworks. The goal of both is to define a project management process in which teams can work as effectively as possible.
The role of Agile methods in Australia
‘Agile’ is still a popular buzzword in Australia’s corporate culture, and CEO’s all over the country are applying its techniques to their businesses.
A recent survey by Hays revealed that more than half of Australian employers have restructured their organisation to accommodate for greater flexibility when managing internal projects. As a result, there is a real recruitment focus to hire more talent with experience following agile methods.
Kanban vs Scrum: the similarities
Both of the frameworks support agile methods and are based on the following three principles of lean management:
- Continuous improvement
- Process orientation, and
- Customer and employee focus.
Kanban and Scrum make room for mistakes to happen. Errors are not considered disastrous, but rather as a starting point for improvement. The workflows rely on a continuous and explorative approach to improvement to reduce lead times and minimise wasted work.
Scrum and Kanban rely on the ‘pull’ principle—a method that enables the team to pick up tasks as their capacity allows, and only when there is customer demand for it. The goal should always be to prioritise the requirements with the highest possible value for the customer, rather than the tasks the team like the most!
Agile methods are also characterised by their flexibility. Both variants are not conditioned to adhere precisely to a plan but to make timely changes and adjustments in the customer’s interest.
Lastly, both approaches strive to design the process so that it comes to fast results.
The difference between Scrum and Kanban
Scrum is more rigid than Kanban because it contains a greater amount of rules and procedures.
Scrum is based on doing iterations in a set timeframe (called timeboxes). Although the length of the timeboxes can initially be varied, they should remain constant over a longer period to establish a certain degree of regularity among team participants.
Kanban does not provide a timeline or timeboxes. So it’s up to you when you plan, reflect, improve or deliver the process. However, it proves useful in practice to establish a certain rhythm or flow here as well.
Although both methods look at change as the norm, they have different approaches to it. In Scrum, the tasks are fixed during a sprint length (usually 1-4 weeks), whereas changes in Kanban can be continuously recorded and integrated into the workflow.
The three roles Product Owner, Scrum Master and Development Team are mandatory in Scrum. Kanban does not provide binding roles, but you can also find equivalents in the Kanban environment for the Product Owner role. For example, Flowmaster or Product Manager.
Another difference is found in the measurement of productivity. In Scrum, the team estimates the relative workload per work package, taking into account the complexity and associated risk. This effort is added up for a sprint duration and thus results in a team-dependent speed. The first timeline metric is used as a guideline for the following sprints.
In Kanban, estimating the execution time of work packages is not mandatory. The measurement of productivity takes place in the form of cycle time (the time it takes to complete a work package from start to finish).
Scrum + Kanban = Scrumban, right?
Correct! Under the term ‘Scrumban’, hybrid models have existed since the middle of this decade.
The basic element of Scrumban is an ordinary Kanban board for visualising the process flows. However, the to-do list of the board is arranged according to the backlog principle of Scrum. This means that the entries with the highest business value have the highest priority.
Unlike Scrum, Scrumban has no iterative sprints. The work is carried out continuously within the limits of the team.
The roles in Scrumban are similar to those in Scrum. Product Owners takes care of the backlog prioritisation, the Scrum Master manages the process and the development team is required for implementation and planning. It also regularly includes scrum events, such as the Daily Scrum and Retrospective, within the process.
Scrumban can be useful for teams that are heavily dependent on third-parties. Often agreements with suppliers or external service providers are based on contracts that are not synchronised with an internal sprint cycle. As a result, the team may have a hard time making accurate estimations of a project deadline.
How to decide which agile method to use
1. Analyse your team
Is your team less flexible? Does it need a clear guide with time boxes? Should your team have phases in which it should work undisturbed? Then we would advise you to use Scrum since the tasks for two weeks are firmly fixed and external disturbances aren’t focused on.
2. Consider your environment and processes
Teams that have less defined workflows, start and end work sequentially, and often need to prioritise tasks due to changing needs are better off using Kanban.
Scrum, on the other hand, is suitable for projects with a certain degree of planning security. If you have clients, Scrum also works best as you can provide regular progress updates.
3. Consider corporate strategy
For Scrum to be established in a company, it takes time and, above all, buy-in from management to move towards self-organisation.
If a company wants to be cautious about agility and does not want to make any big, fundamental organisational changes, Kanban is the better strategy to proceed with.
Thinking about applying these techniques to your business? Sticky notes on walls are great visualisers, but make sure you compare some popular online project management tools too, to allow your team to be as productive as possible.