Written by Alex Gray
When I am training Scrum courses, I often like to ask attendees: ‘Is anyone using Kanban’? More often than not, a number of people on the course will say ‘Yes we have Kanban boards’. So I say: ‘Great! Have you mapped your workflow on your board, and are you applying WIP (Work In Progress) limits?’ To which the answer repeatedly is ‘No, we just use a Kanban board’.
What follows next is that I am asked to explain the difference between Scrum and Kanban. Which is when I normally get the question: ‘Should we use Scrum orKanban?’
Let’s look at some of the possible deciding factors.
Need to kick-start an Agile transformation?
Scrum is a lightweight process framework for managing complex product development. It only has 3 Roles, 3 Artefacts and 5 Events that provide the foundation for the Agile way of working. When implemented correctly, it can get you a long way from a standing start.
Kanban does not provide any roles, artefacts, or events to follow. You simply start by visualising the work you are doing and the process that the work is going through, without any changes to it or to the existing organisational structure and roles. You then start to balance the demand and delivery capability by limiting work in progress (WIP) and monitoring the flow of work, in order to identify issues and evolve the process on an ongoing basis.
Kanban is initially less disruptive than Scrum as it starts with the existing process and structure. However, an Agile transformation fuelled by Kanban would typically take more time.
Think about the wider system, not just product development
As already mentioned, Scrum is a process framework for managing product development and it only really deals with improving this part of your end-to-end system. Kanban systems can visualise work from the moment it enters your system (i.e. is requested by the customer), through to the point that the work is done (delivered to the customer).
So you could say Scrum only deals with part of your system, whereas Kanban covers your system in its entirety, from ideation, right through to the delivery to your customer.
Consider the rate of which a team's work changes
Scrum is a timebox-based system. A Sprint length is set in advance and kept stable, and work is planned for that agreed period of time. The Scrum Alliance says a Sprint can be one month or less in duration, but most teams nowadays appear to have standardised on two week sprints. If a new, urgent, requirement were to emerge after a Sprint has been planned, then the customer would have to wait at least until the following Sprint for their work to be started.
Kanban does not have the concept of a timebox. Instead, work flows through the system in a continuous fashion. Kanban can be implemented with regular replenishment cadences, but recognises that the best way to replenish work into the system is on demand. On-demand replenishment in Kanban would mean that the customer’s new urgent requirement could be put into the system as soon as there is available capacity within the agreed WIP limits.
If you cannot commit to a Sprint plan for the next Sprint without there being a need for change, then Kanban may be more suitable for you. We often find that teams responsible for support or business-as-usual (BAU) fall into this category.
We need to stay in control
Many organisations, especially the ones that are larger and more established, appreciate control and are risk averse. Implementing an Agile method like Scrum requires a culture that supports the Agile mindset, and allows the teams to collaborate, take ownership of their work and learn how to work together and improve.
Conversely, Kanban can be successfully implemented in a strong control environment. The initial Kanban implementation is less disruptive compared to implementing Scrum. The Kanban system will then only be changed based on evidence of system behaviour, which a control culture would be more amenable to.
Can we combine Scrum and Kanban?
I often find that implementing Scrum is a good place to start for a team adopting Agile. It provides you with the clear guidance of the minimum you need in order to ‘be Agile’ in terms of roles, artefacts, and process in the events.
Then, as teams mature, using Kanban can be a great way to visualise, control and improve the work a team does during a Sprint. This is often referred to as ‘Scrumban’- a hybrid of Scrum and Kanban.
You can also start to look at the wider system, not just the product development part. Start to extend your Kanban system to look at the work that happens upstream and downstream of the development team. Furthermore, you can use Kanban to start managing the work at the programme or portfolio level in an organisation.
There is no right or wrong way.
It is import to assess your current context, decide what outcomes you are trying to achieve, and make an informed decision of how you are going to design your initial Agile Operating Model (AOM).
Scrum is a great starting point for your AOM, and may be all you need.
Kanban can then be used to visualise the development work to the further level of detail, extend the visualisation to the entire end-to-end system and, most importantly, identify areas of your system that can be further improved.
While there is no single right answer overall, you should look for a good answer for you in your specific context.
At Radtac, we will help you find that answer by following our empirical change cycle. We would start by assessing your current context and your goal, then work with you to generate a number of alternative options to get there. Next, we would select and shape the most promising options, and help you execute them, review the results, learn and repeat. Whether you end up with Scrum, Kanban or a combination of the two, you would undoubtedly be on the path to true agility.