Scrum vs. Kanban: Is it really one or the other?
I recently met again with one of my very first Agile teams, a team who I helped transform from Waterfall to adopting Scrum. I always felt that at the time I left them (about eight months ago); they had become a truly high-performing, Agile team with a lot of excitement for the overall product development. They followed Scrum ‘to-the-tee’ and were really utilizing the process to fire-up software development. However, this meeting was different.
Their product had now been in production for a year and they were working mainly on client requests, enhancements and support items. They were ‘scrumming’ along – following the ceremonies monotonously. Most importantly, they felt their Sprint plans were always disrupted by critical support and client requests. Everything seemed to be more important than the Sprint plan that the team had committed to. While time-boxing had been a clear advantage when they first adopted Scrum, it was now a list of items that always had somebody ‘cutting-in-line’. I asked them, ”Have you all thought about moving further on the ‘Agile spectrum’, maybe adopting a much leaner approach like Kanban?”
So, what is Kanban?
Kanban is a visual mapping of all the work that needs to be done, a method that could help identify bottlenecks in your development cycle, and force the team to minimize the work in progress to create a continuous flow of work items. Although it is based on the same Agile principles as Scrum, it is a much more non-prescriptive methodology.
As a transformation consultant, I am constantly asked – you helped us implement Scrum and now you are talking about Kanban, so, when do we actually use Scrum versus Kanban? I believe this is really not a choice you have to make – it’s a transition you have to allow to evolve. Here are some factors to consider when implementing Kanban systems or looking for areas in Scrum where Kanban principles can be applied.
Frequent re-prioritization: If your team constantly has to disrupt Sprint plans due to ‘emergency’ requests coming in during the Sprint, it is time to move to a more visual approach to determine the impact of such changes. Kanban systems allow you to delay setting priorities until the team capacity becomes available. This delays commitment to work until the last possible moment and leads to shorter cycle times.
Faster response time: In Scrum, the response time for a feature is at least one and half times the length of the Sprint. If your customers are looking for faster response times or the nature/stage of your product is such that it needs very frequent releases, use Kanban instead of Scrum. In Kanban the principle of Minimum Marketable Feature (MMF) is used and you should release as soon as you have MMFs ready. The inherent nature of the process is to minimize Work in Progress (WIP), complete selected features, and get them out the door.
Work-items of almost the same size: If most of your requests (usually in support/maintenance mode) tend to be of the same size, it’s much more efficient to implement a Kanban system and optimize the flow of these work items through the board. This allows for building predictability by measuring lead times within the WIP limits set in the system.
Multiple teams, one product: If you have multiple teams or large teams working on the same product, Kanban boards allow for visual representation of all the contributions and cross-dependencies and create an easy display of work items and their progress towards the end-product.
Multiple products, one team: If you have one team working on several different products, Kanban boards help manage all the diverse tasks in one system. Using swim lanes for each of the products, the team can self-manage themselves across multiple products.
Agile Portfolio Management: If you are trying to implement agility up the value chain in your organization, Kanban is better structured for portfolio management than Scrum. Due to the non-prescriptive nature of Kanban, it allows you to prioritize business initiatives in a just-in-time manner with available organizational capacity, prioritize projects, and get a visual cue of bottlenecks in your organization that need to be addressed to create a ‘smoother flow’.
Both the methodologies are based on sound Agile principles. The transition from Scrum to Kanban is the natural transition towards leaner approaches and is guided by our efforts to continuously improve. Fortunately, we don’t necessarily have to choose one or the other – Scrum and Kanban can go hand in hand. Kanban can be used to visually expose dependencies and synchronization points in a Scrum environment.