Kanban vs Scrum: which one is better for your product development?
At today’s pace of change, the complexity and dynamics of the business environment forces a fresh approach to creating products that meet customer expectations. In this context, agile, user-centered approaches, including scrum and kanban, are even more applicable and important. In this article, you will learn about both of these approaches, their similarities, differences and the ways you can use them when working on your digital products.
Table of contents
A brief introduction to Kanban
Kanban, in its simplest sense, is a method to manage the work of a software development team (mostly, but it can be used in other environments as well). To help you understand its characteristics, let’s first focus on its foundations. Kanban is based on six general practices, three change management practices, and three service delivery principles.
Kanban’s 6 general practices
The first of the practices is visualization of work and its flow. All teams working in kanban should build a model that will reflect how they work. Usually, the so-called kanban board is used. It may take a physical or virtual form. A simple example of such a board would have three columns (however, number of columns depends from team’s needs):
- to do,
- in progress (WiP),
- done.
The next practice is dedicated to setting a maximum number of tasks that can be ‘work in progress’ (WIP). This is usually limited to three tasks, and a new job can only be started when a current task is completed or cancelled. The effect is to reduce ongoing work and maximize the effectiveness of the workflow.
When the flow is visible you can start to manage work to improve predictability. You can use data and metrics such as Lead Time (the time needed to move one task through all stages and finish it) and Cumulative Flow Diagrams (charts that help to visualize the most important metrics). This is the third practice.
Making policies explicit will help the team to cooperate. This is why each kanban team should have written rules that describe when something can be considered done (definition of done) or when a task is ready to start work on it. This is the fourth practice.
Everything should be subject to continuous improvement, introducing feedback loops supports this process. In kanban you do it by establishing so-called cadences. For example, a Team Retrospective with a focus on how the team manages their work and how they can improve, or an Internal Team Replenishment Meeting which focuses on selecting items from the pool of work to do next. This is the fifth practice.
The last, but not the least important practice is to continuously improve collaboration and evolve experimentally. The whole team should be involved in making their work better using a hypothesis-driven change process in a safe-to-fail environment.
Change management in Kanban
Change management is part of the kanban method. There are three principles describing how the team should approach change.
- Start with what you do now - Experience shows that an evolution of current processes is much more efficient and successful than taking a big bang approach that involves getting rid of the current status quo and setting up new processes from scratch.
- Gain agreement - The whole team should be involved and understand why a change is introduced.
- Encourage acts of leadership at all levels to unlock hidden potential, regardless of the seniority, job title or position of team members.
Kanban service delivery principles
Kanban promotes a service-oriented way of thinking about work in organizations, based on three key principles.
- Each team should understand and focus on customer needs and expectations. In the end each team delivers value for someone and keeping their needs in mind will allow us to optimize our work to deliver even more value.
- Manage the work, and let team members freely self-organize around it. Instead of focusing on keeping people busy, the team should focus on the flow of work, and delivering that work continuously and smoothly.
- Each kanban team should also regularly review its policies to continuously adapt and improve outcomes.
Kanban is a management method that can be introduced to improve how the team is working. It helps to evolutionarily improve what and how things are being done, instead of replacing it with something completely new and introducing new roles, meetings, and processes.
A brief introduction to scrum
Scrum is a framework that uses an iterative approach to build products in a complex environment. It is based on empirical process control theory, which assumes that knowledge comes from experience and decisions based on what is already known will optimize processes and better control risks.
Scrum teams consist of no more than 10 people. There are three types of accountabilities in each scrum development team: Product Owner, Scrum Master and Developers. It is possible to combine accountabilities but usually it is not recommended.
- The product owner is focused on maximizing the value resulting from the work of the whole team. They do it by establishing and communicating a product vision and strategy. Product owners are also accountable for creating and ordering things that will be delivered by team.
- Developers are accountable for all work that is necessary to deliver usable increments each sprint.
- The scrum master is accountable for the team’s effectiveness.
Scrum teams work in sprints. At the end of each sprint a new potentially releasable version of the product should be delivered. Sprints are usually timeboxed for one or two weeks, but no more than four. Each one starts with sprint planning during which the whole team discusses what value the sprint should deliver and collaborates on defining the Sprint Goal which should be achieved by the end of it. With a sprint goal in mind, the work can then be planned.
Each day of a sprint, the developers have a “daily meetings” to review progress towards the sprint goal, adapting the sprint plans if needed. Each sprint ends with a Sprint Review and a Sprint Retrospective. The review is a meeting to which stakeholders are invited and together with the team they discuss what was delivered during the sprint and the plans for upcoming sprints. The retrospective is an internal team meeting to monitor and optimize the team’s processes and methods of collaboration.
Scrum teams are autonomous and cross-functional, with the team’s different units working together, with all the competencies needed to build working products. Depending on the product’s needs and requirements, a scrum development team can be assembled with software developers (frontend and backend), a scrum master, product designer, content or UX writers, devops and QA engineers. This cross-functionality helps to optimize productivity, flexibility and creativity.
Scrum is a framework which means that it is a backbone to which other practices, processes and tools can be added. Thanks to this, scrum has broad applicability.
Agile Kanban vs Scrum – which one to choose?
Traditional project management methods are great to deliver products in simple domains. However building digital products is generally a complex process. Consequently, changes to requirements are a normal occurrence due to the need to respond quickly to shifting market needs. As a result, the product is continually evolving, responding flexibly to signals from the market.
If you are wondering which approach your team should choose - scrum or kanban - it is worth answering a few questions:
- What type of work will the team be doing?
- Do your team members have any experience in working with either scrum or kanban?
- Does your team own the whole process of product development or only part of it (e.g. design or QA is done outside of the team)?
- Will there be a community of work or teamwork, or can each team member perform their tasks independently?
- Will the team have full authority to decide about the product?
Both approaches have lots in common. They are compatible with agile and lean startup. They allow a self organizing-team to continuously adapt the way it is working and respond to new learning. Both frameworks are open to late changes in requirements, and they allow a team to quickly pivot the product development roadmap when necessary.
Scrum establishes a timeboxed sprint with sprint goals, and broader product goals that should be achieved within a few sprints; all with a focus on fostering the team’s creativity. Frequent team meetings allow for the free exchange of ideas, and reviews after each sprint give a clear view of the product development.
Kanban can be applied to any existing product development process. Kanban provides relatively high flexibility, which is helpful for evolutionary improvement. There are no revolutionary changes, so the risk of failure is reduced. The lack of strictly defined boundaries and accountabilities requires a deep understanding of kanban, and agile in general, by the whole team.
However, the basic rule when choosing a product development method is to be flexible. Many teams working in kanban establish product owner roles or similar, some scrum teams, on the other hand, limit the number of tasks at the Work in Progress stage, which is inspired by kanban. At Boldare, we are big fans of working with hybrid approaches. Most of our teams work in scrum, using the kanban method to boost their flow and deliver even more value. The most important thing is to adapt the selected elements to the specifics of the product.
An example here is Nexus Scrum - a solution dedicated to large teams working on multiple applications or large platforms. At Boldare, we help implement this framework, and we have experience of cooperation based on this model with several clients.
What are the advantages of Scrum vs Kanban in software development?
Both scrum and kanban have many unique features. Choosing one depends on the nature of your projects and goals. If you need flexibility in operations, kanban will likely be the right solution. If you need a more robust approach with strictly defined tasks and schedules, scrum will probably be the best way to maximize productivity. However, both methods can be mixed to some extent and used simultaneously.
In this article we refer to the kanban definition created by David Anderson.
Share this article:
