Kanban and Scrum are both recognised as agile methodologies, but many organisations struggle to choose between the two. In particular, the challenge seems to be around understanding whether they are broadly the same, complementary, or mutually exclusive. This review compares the two, to show you the strengths and weaknesses of each, and help you to choose which to use, when and how.
Kanban is a system of tokens that is used to limit work in particular states, usually ‘To Do’, ‘In Progress’ and ‘Done’. There is no limit on the amount that can be ‘Done’, and the restriction is usually placed on ‘In Progress’. This means that no new work is started until at least one part of the work in progress has been completed. This makes work flow more efficient, and reduces the time wasted switching between tasks.
In thought leadership or content marketing terms, this is likely to mean focusing on one topic at a time, and focusing on the flow of work through the system. Kanban is helpful in ensuring that you can manage both work flow and expectations. It can be used in many different ways: by teams, by individuals, and for different types of work and processes. Crucially, Kanban is not a process in itself: it is a tool to improve processes, and can therefore be used very flexibly.
What is Scrum?
Scrum is a process used first in software development. It involves a series of time-limited ‘sprints’, each of which is designed to get an agreed amount of work done. The advantage is that overall project goals can easily change, because each sprint only covers a relatively small part of the work.
Scrum involves defined team roles, including the Scrum Master, who facilitates the process, the Product Owner, representing stakeholders, and Team Members, who do the work. The team is self-organising, which means that each person volunteers for what they feel able to do.
Similarities and differences
Both Scrum and Kanban are agile methodologies, so they share some similarities. However, there are also some crucial differences. Both are ways to break down work into tasks, and to limit the amount that is ongoing at any particular time: Kanban by quantity (the number of tasks that can be ongoing at any one time) and Scrum by time (the sprint duration). Both can be organised flexibly and used to manage a range of different projects, and in different contexts.
Scrum, however, is rather more prescriptive than Kanban. It is very much a process, and not a facilitator. It is also designed to be used in a team, rather than by individuals. Scrum projects have a fixed duration, usually two weeks, whereas Kanban is designed to support continuous flow and improvement.
There are also differences in the attitude required. Kanban-supported processes, because they are continuous, can be changed and therefore improved at any time. Scrum teams, however, are actively encouraged NOT to change the requirements during a sprint, because it upsets the estimations of work to be done. Overall, this can mean that Scrum feels rather less flexible.
Kanban vs Scrum—or both?
Both Kanban and Scrum have advantages and disadvantages for thought leadership and content marketing. Each one may be more useful in particular circumstances. Scrum, for example, might be more useful in preparing work for a big campaign across a large team of contributors and other stakeholders. Daily Scrum meetings will ensure that everyone knows what everyone else is doing, and that work stays on track. Kanban, however, may be more helpful for organising work on an ongoing basis and guaranteeing a steady flow of content.
The good news is that Kanban and Scrum are different enough that you do not have to choose between them. Kanban can be used alongside Scrum to improve and facilitate processes, and many organisations also operate a hybrid system which has become known as Scrumban.
The bottom line
If you are just thinking about dipping a toe in the agile waters, you may find it easier to start with Kanban. It starts from where you are, by visualising your current flow, and helping you to manage it more efficiently. No major changes are required, including to team roles. The team roles are more prescribed in Scrum, so it can feel like more of a change. Ultimately, both tools are proven to improve efficiency and process flow, including in work like content management and thought leadership.