Lately I hear these questions a lot: “Is Scrum better, or Kanban?” “What is more suitable for my project — Kanban or Scrum?” These questions, and sometimes the responses to them, put managers in a dilemma about which framework to embrace. Each has its own benefits and tales of success stories.
What is Scrum?
Scrum Alliance defines Scrum as an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.
Scrum emphasizes team collaboration and provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.
Scrum gives power to business to prioritize the requirements, even change the requirements. At the same time, it gives power to the team to commit to the requirements per their capability. All the work done in Scrum is iterative and incremental, and it timeboxes the process. Scrum also emphasizes feedback: The team can get feedback from business as early as possible and deliver a working product that will actually be used. It also allows the team to retrospect on their performance and improve upon it within short cycles.
What is Kanban?
The Kanban blog says, “Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s ‘just-in-time’ (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.”
Kanban primarily follows four core principles:
- Visualize work
Create a visual model of work and work flow, so as to observe the flow of work moving through the Kanban system. Making the work visible, along with blockers, bottlenecks, and queues, instantly leads to increased communication and collaboration. - Limit work in process
Limit how much unfinished work is in process and reduce the time it takes an item to travel through the Kanban system. Problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP. - Focus on flow
By using work in process (WIP) limits and developing team-driven policies, the Kanban system can be optimized to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work. - Continuously improve
Once the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can change the system to improve the team’s effectiveness.
Both Scrum and Kanban are unique and emphasize more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and their commonalities in delivering quality products.
| Advantages of Scrum | Advantages of Kanban |
| Transparency | Flexibility |
| Improved credibility with clients | Focus on continuous delivery |
| High product quality | Increased productivity and quality |
| Product stability | Increased efficiency |
| Team members reach sustainable pace | Team members have ability to focus |
| Allows client to change priorities and requirements quickly | Reduction of wasted work/wasted time |
The question organizations face is which framework should be used with the teams, Scrum or Kanban? But instead, the question managers should be asking is, which aspects of Scrum and Kanban can they use to effectively develop products and services?
Given the advantages of both approaches, it should be up to the development and product teams to choose which framework will work best for them. More recently, some teams have combined both frameworks and used the best practices from each to achieve better team synergies and improve productivity.
There might be teams who feel comfortable with Kanban and others who are more comfortable with Scrum. A better approach could be to coach teams on both frameworks and leave the decision to them to use best practices from both. As we have seen, both Scrum and Kanban are flexible and do not have hardcore processes to be followed, so it could be easy and worthwhile for teams to explore practices from both that enable them to function as highly productive teams that continuously improve.