Which approach works best: Kanban or Scrum? If you are on the verge of a brand new project, I bet this question has posed quite the challenge to your mind. Today Kanban and Scrum have grown in popularity and have taken the place of the previously popular waterfall model. This is no wonder, as both frameworks have proven to be performance boosters by regulating communication and work efficiently.
In this article, we will discover the unique aspects of the question “Kanban vs. Scrum” to help you choose the right framework for your project.
Kanban vs. Scrum: Fundamentals
Let’s start by uncovering what is hidden behind Kanban and Scrum, how they are utilized, and the outcomes of each.
What is Kanban?
Kanban is a system that helps to visualize and monitor workflow. The framework was founded in the 1950s by Taiichi Ohno, the father of Toyota Production System, and served to improve manufacturing efficiency.
The word Kanban can be traced back to the Japanese word meaning “signboard or a visual signal.” This comes as no surprise, as its aim is to optimize the throughput with the help of a board and cards with tasks that visualize the flow of the delivery. The board is usually divided into three main columns visualizing progress. For example, these columns could be: to do, in progress, and done. However, there can be more columns to fit the needs of a specific software engineering company or team (e.g. testing, deploy, review, etc). Cards usually move from column to column based on progress.
Is Kanban Agile?
Kanban is a system built on Agile principles that is transparent, well balanced, and contributes greatly to the organization of the work of even a big team. As it is very flexible, Kanban can be easily adapted to the needs of a team, especially if the priorities quickly change.
What is Scrum?
The Scrum framework was inspired by a rugby game. The founders, Hirotaka Takeuchi and Ikujiro Nonaka, described Scrum as an approach that should increase the speed and flexibility of a development process. However, after a decade, it was fully implemented for the first time by Jeff Sutherland and Ken Schwaber.
Scrum is based on its three pillars: transparency, inspection, and adaptation. Transparency ensures that all parties, responsible for result of work, equally see and understand key aspects of the process. Inspection means checking the progress to make sure nothing hinders the team from a set goal. Adaptation is responsible for adjusting the process based on the inspection results, which helps to improve it.
As well, we should not forget about Kaizen - which means that the team should learn from their experience and strive to optimize the process and the result of their work.
In the Scrum kitchen, you should chop your work into small pieces and “eat” one piece at a time. As well, do not forget to improve the recipe each time by asking for feedback :) There are no limits to perfection.
Are Scrum and Agile the Same?
Scrum is one of the frameworks used in Agile approach. Scrum vs. Agile is like football vs. a game. Scrum is an Agile framework, just like football is a game. However, there is an interesting fact about the Agile model itself. Scrum was successfully used and documented, and eventually became a foundation of Agile programming.
Scrum and Kanban Similarities
Kanban and Scrum are well aligned with the Lean Philosophy and Agile Manifesto tenets. This means that they have some things in common that are unique to the Agile development cycle. Let us name those things:
- Flexibility
The first tenet of the Agile Manifesto is “Individuals and Interactions over Processes and Tools.” Both frameworks provide room for change and are quite flexible. However, considering the question “Scrum vs. Kanban”, you should know that the latter is less regulated.
- Limiting work in progress
Kanban sets limits for the work in progress (WIP). Scrum measures velocity and limits the number of tasks per sprint based on their estimation, e.g. in story points. The tasks are to be developed during the sprint.
- Empirical process
Scrum and Kanban are empirical and encourage continuous optimization. Let’s say, with Kanban, WIP is a dynamic capacity measure. Therefore, you can adapt the framework to optimize your workflow.
- Pull scheduling
Scrum and Kanban use a pull scheduling system. This means that there is a massive amount of tasks that need to be done. In Scrum, they are called a backlog. For each sprint, the dedicated development team, along with the Product owner, pulls tasks from the backlog, prioritizes and estimates them, and adds them to the sprint.
As for Kanban, product backlog is not a must-have, but it is almost always used in projects. Usually, the Kanban team and the client decide on the principle of pulling tasks from the first column (e.g. newer/older or tasks with specific markers first, etc).
- Visualization
In both Scrum and Kanban, boards are used to visualize the progress of work. The question “Scrum vs. Kanban boards” is easy to answer when you how these boards are maintained. In a few words, a Scrum board is erased for every new iteration, whereas a Kanban board with tasks (in different columns depending on a stage) is kept during the whole process of development.
- Early and continuous delivery
Both Scrum and Kanban are focused on releasing potentially “shippable” pieces of work early and often. In Scrum, this can happen at the end of each iteration, usually after a demo.
- Self-organized teams
Scrum and Kanban frameworks presuppose having self-organized teams working on product development.
- Breaking down the work into small, concrete tasks
To eat steak you need to cut it into smaller pieces. It is, of course, also possible to eat the whole steak, even without a knife and fork, but this is not convenient. The same can be said about using Scrum or Kanban. Huge tasks are always broken down into smaller, digestible ones, which can be developed relatively quickly. This is actually one of the factors that distinguishes Agile from waterfall model.
Despite having so many things in common, the Kanban vs. Scrum question still needs to be answered. The time has come to address the distinctive features of both frameworks and how they are different.
Do you have strategic plans in creating a web or mobile app?
Let’s get in touch and discuss how we can help you with developing your project. We can share our knowledge in developing complex and value-giving digital products as well as explain our development processes and approaches.
Difference Between Scrum and Kanban
Scrum vs. Kanban is like sweet coffee with milk vs bitter coffee. The “base” is the same but the “taste” is different. Let’s try to compare these two and highlight the unique aspects of each framework.
The Main Criteria for Scrum and Kanban Comparison
How to choose between Scrum and Kanban? While they have many things in common, Scrum and Kanban also have lots of things that make them different from one another. Understanding these differences can help you choose the right framework for your project. Let us take the following criteria into consideration:
- roles and responsibilities within each approach
- measurement of productivity
- cadence
- release methodology
- types of meetings
- change philosophy
- key metrics
These criteria will help us solve the Kanban vs. Scrum dilemma. Continue reading to learn which framework is better.
Features of Scrum Workflow
1. Roles and Responsibilities
The Scrum Team has three predefined roles: a Product Owner, a Scrum Master, and the Development Team. Some sources name Scrum Master and Development Team a Scrum Team.
- Product Owner is the person who sets the motion vector of the product development, defines priorities, and makes decisions.
- Scrum Master is the person who guides and oversees the process and removes impediments (if any)
- The Development Team is made up of individuals who implement tasks and produce product increments.
2. Measurement of productivity
Scrum measures velocity (i.e. the number of story points a team can develop per sprint). After the first sprints, we can see the velocity and therefore plan more precisely.
3. Cadence
Scrum is iterative by its nature. An iteration is called a sprint. Each iteration can last from one to four weeks (two-week sprints are the most popular). The duration is usually agreed upon at the team’s discretion.
4. Events (types of meetings)
Scrum framework presupposes having four types of Scrum ceremonies: planning, daily, demo, and retrospective.
- Planning - this meeting serves to set up goals for the upcoming sprint. The team, along with a Product Owner, pulls tasks from the product backlog, discusses their priorities, and estimates them. Estimation is usually done in story points. Based on the velocity, the team agrees on the scope of iteration.
- Daily Stand Up - the main purpose of a daily stand up meeting is to synchronize and discuss blockers or dependencies (if there are any). Usually, these meetings should not last longer than 15 minutes. To keep them short, many teams decide to stand (hence the name daily stand up). Pro teams may also use a daily plank to keep meetings even shorter and much more efficient :)
- Sprint Review (Demo) -the name speaks for itself. In a demo meeting, the Scrum team demonstrates what was done during the sprint (ideally some working product increment).
- Retrospective - always striving for optimization is one of the principles of Scrum and Agile. The main aim of the retrospective meeting is to ascertain what was good, what could be better, and what to avoid in the future.
5. Release methodology
At the end of every sprint, a development team should deliver a product increment that is ready for release. Usually, in the demo meeting, the team shows potentially releasable increments and the Product Owner decides whether to release it or not. There is no third option.
6. Change philosophy
In Scrum, the scope of iteration is fixed. Changes are viewed as something undesirable and are restricted during an iteration. It is possible to make changes only if they don’t endanger the sprint goal. This happens because the team commits to some number of tasks to be developed during a sprint; additional tasks can lead to overflow, shifting deadlines, and clutter the sprint.
7. Key metrics
One of the techniques used to measure the progress is velocity, or in other words, the speed with which the team is moving. Based on the velocity, the burndown charts are built. These sorts of charts help to predict and plan future releases.
Unique Aspects of the Kanban Process
- Roles and Responsibilities
Kanban software development is not focused on assigning roles, its aim is to deliver value. However, this doesn’t mean that there shouldn’t be any roles. Very often, there is a Project Manager behind the curtains who saves the team from the routine, resolves questions, leads the process, etc.
- Measurement of productivity
In Kanban, cycle time and lead time are measured. Cycle time means the average time for an item to move through all the stages (e.g. from "to do" to "done"). Lead time measures the duration of the period that starts with a client request and ends when a team delivers a result.
- Cadence
Kanban cadence is based upon continuous workflow. The team can provide releasable increments as often as needed. There are no strict timebox units and the work is completed continually based on cycle (lead) time.
- Release methodology
The Kanban process allows for the release of updates as soon as they are ready. Therefore, there can be a few deployments per day, one deployment in a week, etc.
- Events (types of meetings)
There are no requirements to meetings set out in Kanban software development process, but the team usually meets regularly. Additionally, the communication is done within a Kanban board.
- Change philosophy
Unlike Scrum workflow, Kanban process is very flexible when it comes to changes and priority control. Changes can be made at any time.
- Key metrics
The main measurable units are cycle time, lead time, throughput, WIP, and queues. Based on them, predictions can be made regarding the future releases and how fast the Kanban team is working. In Kanban, there are even more charts than in Scrum, e.g. cumulative flow diagram, cycle time control chart, lead or cycle time distribution chart, etc.
To summarize the comparison, below is a quick Kanban vs. Scrum overview arranged in a table. Let’s take a look at it.
| Criteria | Kanban | Scrum |
|---|---|---|
| Roles & Responsibilities | Kanban roles are not strictly defined, but they are usually assigned | Scrum Team: Product Owner Scrum Master Development Team |
| Measurement of Productivity | Cycle time and lead time | Velocity |
| Cadence | Continuous development (can be event-driven) | Timebox iterations |
| Release Methodology | As soon as there is something to release | Preferably per each iteration but not compulsory |
| Events (Types of Meetings) | No defined meeting types and rules but the team meets regularly | Planning Daily Stand Up Demo Meeting Retrospective Meeting |
| Change Philosophy | Changes can be made at any time (when capacity allows) | Changes are undesirable during a sprint |
| Key Metrics | Cycle time Lead time Throughput WIP Queues Control Chart, CFD, etc. |
Velocity Burndown charts |
Pros and Cons of Scrum and Kanban Management
For a different kind of work, we use different tools: we can make quick notes either with a pen on paper or by using a smartphone. We can also use the tip of a sword and a stone but that is not convenient and quite old-fashioned.
Agile approaches, such as Kanban and Scrum, can also be viewed as tools. They are designed to help regulate and organize the work on a project. To find out what kinds of projects Scrum and Kanban are good for, we need to analyze their advantages and disadvantages.
Agile Scrum Methodology: Benefits and Pitfalls
One of the biggest benefits of Scrum is that it allows a team to move fast and to have results early on. Constant communication between the Scrum Team members and the Product Owner helps to be in the loop of things and to not miss any important details.
Since each Scrum sprint cycle does not last very long, a team can release a product for users more often and collect their feedback more frequently. It helps to release a more relevant product for customers each time.
When should Scrum be used? It works perfectly for big projects and small startups, those that test their product and that know exactly what they want to create.
Speaking of pitfalls, Scrum process may not seem to be so lean, as there are many things that are prescribed.
Advantages and Disadvantages of Kanban Method
Imagine that you have a continuous stream of work requests with constantly changing priorities. Sounds like a bit of a mess. Kanban is the perfect tool to sort out this mess and make the process as sound and efficient as possible.
This is conceivable because of the nature of Kanban flow. In a nutshell, all the tasks are prioritized according to Kanban classes of service: expedite, fixed delivery date, standard, intangible. Additionally, it is possible to add custom classes based on your needs.
When should Kanban be used? It works perfectly for ongoing projects where new tasks and changes come together in a row or for complex R&D projects with uncertainties and tight schedule. These are the main advantages of Kanban vs. Scrum.
On the other hand, Kanban has some disadvantages that are mostly caused when it is misused by the Kanban team. If they keep their Kanban board outdated or make it too complicated, it may lead to problems in product development.
Using Kanban with Scrum: Is it Possible?
There is an option to combine both methods to leverage their best features. The cocktail of Scrum with Kanban can have dozens of variations. One of the most popular documented options is called Scrumban. This uses Scrum as its base, with a few Kanban distinctions:
- there are no predefined roles, the team keeps the roles it already has or creates the ones it needs
- iterations are usually kept very short
- all the tasks are put on the board
- work in progress limit, like in Kanban, is applied
You can also make your own mix of Scrum and Kanban, which may look Kanban-ish or more Scrum-like. In any case, the aim of any framework is to help you benefit from it, make the most of it, and not be a slave to it.
Top Kanban Boards and Scrum Tools for Agile Project Management
There are a pretty good bunch of tools that can be utilized for project tracking and management. Some are specifically tailored for one framework, whereas others can be easily customized. Let’s name the most popular ones that are used to work with Scrum or Kanban.
Jira Atlassian is definitely the best known and most popular tool for for tracking issues and projects. It is perfectly tailored for an Agile environment. It also has an easy-to-use dashboard, allows integration with many development and tracking tools, has advanced reporting and filtering, and much more. All of the aspects mentioned above make it applicable to different agile methodologies.
Trello looks like a typical Kanban board; projects are represented by boards with status columns that contain lists. Lists contain cards that depict tasks. Each task can be assigned to a specific team member. Trello also allows for commenting, setting deadlines, etc.
Asana helps to easily organize tasks, upload attachments, share notes, and have multiple workspaces. It can work perfectly for any Agile development methodology. However, there is no doubt that it is perfectly taylored for the Kanban framework.
Targetprocess is a software tool that helps to visualize and manage Agile projects according to Kanban, Scrum, or even a custom approach. It has a diverse reporting system in place, different views, and can be easily integrated with other communication, management, and development tools. Furthermore, it allows a team to drill down or scale up the details from any level of the hierarchy.
Kanban vs. Scrum: Which Methodology to Choose
Neither of these frameworks is perfect nor complete. Famous Agile and Lean coach Henrik Kniberg compared Scrum and Kanban to a knife and a fork. Let’s say if your task is to cut bread - you use a knife. To eat meatballs, for example, your choice would certainly be a fork. For some dishes, the combination of both of them together will work better than using just one. However, there may be situations where neither of them serve adequately.
At MLSDev, we follow Agile software development with Scrum and Kanban depending on the stage (mostly Kanban for UX/UI design creation and Scrum for custom software development services. Following Kaizen, or the continuous improvement principle, we can sometimes suggest not sticking to pure Scrum or Kanban and to close the bottlenecks that the chosen framework may bring.
Based on our professional experience in software development, we usually know which approach to apply to each specific project or even to each project stage. This positively contributes to performance and helps to grow a robust project.
Don’t be afraid to experiment, and go Agile!
If Kanban vs. Scrum is the choice you are currently looking to make, we can help you define which framework will work best for your project. Contact us and we will work together to make your application great.