Organizations that want to become agile or improve their agility often find themselves asking the question of which approach is better for their projects — Kanban or Scrum.
As frameworks, both Kanban and Scrum enable organizations to stick to agile principles and execute their projects effectively. While there are quite a few differences between the two, it’s important to realize that both frameworks serve the same purpose — helping organizations create better products and deliver value faster.
Given that both Kanban and Scrum embody the principles of agile development and can help organizations achieve the same goals, it’s vital to understand that the two frameworks can sometimes work in tandem before we move on to talking about their differences.
Both approaches highlight the importance of the volatile nature of product development and provide the tools, processes, and methodologies that help organizations respond to the ever-changing requirements by offering much-needed flexibility during development.
While the two methodologies share a common end goal, the main differences between Kanban and Scrum stem from the practical steps and processes they propose for reaching said goal.
Before we dissect both methodologies and talk about all the different aspects in which they diverge, let’s take a quick look at what Kanban and Scrum are, at their core.
Kanban? Scrum? Measure!
Learn the 17 metrics that matter for modern dev teams.
Kanban: Kanban vs Scrum board
Above all else, Kanban is a lean visualization method with the accent of continuous improvement of processes and workflows.
Kanban seeks to visualize both the process itself, as well as the actual work that passes through that process and aims to improve the effectiveness of the organization continuously. It does so by helping organizations identify potential bottlenecks in the development process and focusing on optimization efforts that would allow the teams to work as efficiently as possible and at optimal speed.
This means that Kanban is extremely flexible. While processes exist and everyone needs to adhere to them, Kanban doesn’t view said processes as set in stone. Instead, it looks at all processes, even the ones that provide great results, and tries to determine how they can be improved further.
Kanban is akin to continuous learning. It rests on the premise that no matter how good you are at what you do, there’s always room for improvement. Unlike most other project management methodologies and frameworks, Kanban seeks to implement the improvements right away rather than to wait for the end of a sprint or a development cycle.
This is both Kanban’s strongest suit, as well as its biggest drawback. While it provides flexibility and adaptability to change, frequent changes might emphasize the feelings of inconsistency and lack of sound structure in the teams.
It may prove difficult for the developers to constantly shift their focus and/or priorities, and the teams might have trouble keeping up with the ever-changing processes. That’s why the best way to implement Kanban is by making small, gradual, incremental changes.
At the heart of Kanban, we find four foundational principles and six core practices.
Kanban’s foundational principles
The foundational principles of Kanban include:
- Start at what you are currently doing — Despite highlighting changes and improvements, Kanban isn’t radical. Instead, it emphasizes the need to apply it to the existing processes that should be changed gradually, at the speed the organization is comfortable with.
- Embrace incremental changes — Change always calls for an adjustment period, and organizations choosing Kanban will do well to remember this. In Kanban, small changes are preferred over drastic ones that might cause heavy resistance within the organization.
- Respect the roles, responsibilities, and job titles — Kanban doesn’t call for organizational restructuring. Quite the contrary — it encourages maintaining and respecting the existing roles, as long as they are performing well. Any changes to the organization’s hierarchy should be implemented slowly, and generally agreed upon by not just the execs but also the entire team.
- Support and encourage leadership — As a framework that preaches continuous improvement, Kanban puts a strong emphasis on leadership. In doing so, it recognizes that leadership acts don’t have to come from higher-ups, but can be initiatives started by anyone, regardless of their position within an organization.
Kanban’s core practices
Kanban doesn’t just tell us what needs to be done in theory — it also offers the core practices that explain how organizations can apply the framework’s principles.
Kanban practices
Here’s a brief explanation of the six core practices in Kanban:
- Visualizing workflows — Creating a physical or an electronic Kanban board that visually represents your organization’s existing workflow. Depending on the size of the organization and the complexity of the current processes, the Kanban board can be quite simple or extremely complex. Regardless, the idea is to ensure that every member of the organization is ultimately familiar with the entire process that’s used to deliver work or the organization’s services.
- Limiting work-in-progress (WIP) — This doesn’t mean trying to get things done faster than it’s realistically possible. Limiting WIP simply refers to getting one task done before taking on another one. Creating limits to the WIP and focusing on completing the tasks at hand is one of the things Kanban strongly emphasizes.
- Managing flow of work — After implementing the first two practices, organizations should observe their workflow and remove any bottlenecks, as well as identify areas for improvement. The main idea is to streamline the work, to prevent it from piling up, and to make it more predictable.
- Creating clear policies — Apart from visualizing the workflow, it makes sense to create clear policies that would provide the rules and guidelines on how the work should be done. Everyone in the company should know exactly what their responsibilities are and how they should approach and document each task.
- Implementing feedback loops — Feedback is crucial for continuous improvement. An organization that wants to implement Kanban must also create feedback loops. In Kanban, it’s essential to review the current work and, when necessary, offer suggestions on how it can be improved. One potential hurdle here is the fact that not everyone takes feedback well, but that’s an individual issue rather than a flaw in the Kanban framework.
- Improving collaboration — Kanban supports the idea that everyone should pull their weight — the organization should improve as a whole rather than by highlighting the mistakes of an individual. Kanban views improvement as a collaborative effort, which starts with a hypothesis that the organization tests and makes necessary adjustments to, depending on the results of the test.
Scrum: Is Scrum better than Kanban?
Scrum is often viewed as an agile project management framework that provides a set of tools and practices that facilitate collaboration within an organization. Scrum seeks to do this by helping organizations break down long, complex projects into short, clearly defined, timeboxed iterations — sprints.
Sprints are planned in advance, and a clear goal for each sprint is set before the work can begin. Apart from planning what the teams will be working on during a sprint, Scrum also emphasizes defining the tasks that would help the Scrum team reach the sprint goal.
During the sprint, teams attend daily Scrum meetings to discuss the state of the project and talk about any potential blocks that are impeding their progress. It’s essential that everyone included in the project knows exactly what stage it is in, which is why the methodology emphasizes the meetings and the Scrum board as ways to ensure everyone has access to accurate, up-to-date project information.
Similarly to Kanban, Scrum defines the three pillars and five core values the methodology rests on.
The three pillars of Scrum
The three pillars that are fundamental to the implementation of Scrum in an organization are:
- Transparency
- Adaptation
- Inspection
The three pillars Scrum rests on
Transparency is crucial to Scrum, given that processes can only be optimized once everyone has access to all the information, takes individual responsibility, and has trust in their coworkers. In order to identify the areas for improvement, everyone needs to be well acquainted with what’s going on at any given stage of the project.
Every aspect of the process must be visible to everyone involved in the project. That is the only way to ensure collaboration and cultivate the company culture of working together on achieving the same goal, as opposed to the mindset that everyone is working on their own thing.
Gain visibility and transparency for your dev team.
Try LinearB, free for 21 days
Inspection might not be the most accurate way to describe what Scrum is getting at. Rather than having your work inspected by an auditor or a higher-up, this pillar highlights introspection. Everyone should be mindful of the processes they apply in their daily work and help identify processes, aspects, and practices that can be improved upon.
Together with transparency, inspection helps organizations identify the bottlenecks and areas that should be improved, as well as take an objective look at the value that’s created at the end of each sprint and adapt to new requirements.
Adaptation involves leveraging the insights gained through inspection and using them to streamline the processes and drive continuous improvement. The main idea is to make a conscious effort to be better than yesterday and increase the value that the work produces.
Adaptation serves the purpose of achieving the initial goals that prompted the organization to become agile in the first place — reducing the time to market, improving the quality of the product, delivering value continuously, and increasing employee and customer satisfaction. At its core, adaptation should lead to an increase in ROI through incremental process improvements.
The five values of Scrum
The core values of Scrum, as a project management methodology, are set in relation to how each of these values enables Scrum to be agile. In other words, Scrum recognizes the necessary values that must be shared within an organization in order to ensure that this agile approach bears fruit.
Scrum values
Here’s what each of the Scrum values implies:
- Commitment — Scrum teams must work together as a cohesive unit and strive towards the same goals. In the context of the work itself, agile teams should take on tasks that they are confident they can complete. Commitment to work, in that sense, means seeing every accepted task to its completion.
- Courage — While it may sound a bit abstract, the value of courage plays a key functional role within a Scrum team. What Scrum considers to be courage is the ability to share information and take responsibility without fear of reprimand, as well as to say “no” and to experiment with new approaches.
- Focus — Focus, in Scrum, closely aligns with commitment. This value highlights that, once a certain project is undertaken, the Scrum team will focus all of its attention and efforts on it in an attempt to complete it. Similarly to Kanban, Scrum aims to limit the amount of WIP (work in progress) and shift the focus on completing the tasks at hand.
- Openness — Openness in Scrum means being receptive to feedback, open to learning new things and improving the existing skills, as well as being honest and upfront when needing help from another Scrum team member.
- Respect — While we would argue that this is a universal value that can be applied to any organization, agile or not, Scrum puts the emphasis on respecting everyone involved in the project. This includes the Scrum team members, the product owner, the Scrum master, and the stakeholders. In practice, this is done by giving everyone an opportunity to voice their opinion and share their ideas by recognizing individual and group accomplishments and by understanding that anyone might have a bad day at work.
Key differences between Kanban and Scrum
Now that we’ve gone over the essence of both frameworks, we can delve a bit deeper and see how Kanban and Scrum differ on the practical level.
Hopefully, this will help you determine which approach best aligns with your goals and project needs. We also want to highlight the potential drawbacks of both approaches and shed light on the possibility of employing them in tandem.
The key aspects we’ll compare Kanban and Scrum against are:
- Roles
- Planning
- Cadence
- Project boards
- Meetings
Roles in Kanban and Scrum
In Scrum, the roles are often pre-defined and must be filled. The mandatory roles Scrum prescribes are:
- Product owner
- Scrum master
- Scrum team
Although a bit counterintuitive, the product owner in Scrum isn’t the client, the end-user, or the company’s CEO. Instead, the product owner acts more like a COO in that they’re responsible for defining stories and the product backlog and giving general directions to the team. Product owners are internal decision-makers who are in charge of developing the vision of the product and maintaining the technical and conceptual integrity of its features.
A Scrum master acts as a guide for the Scrum team. As an integral member of the team, they take a servant-leader role, helping the team learn and implement the Scrum values while, at the same time, helping them remove any blocks they might run into. The modern role of a Scrum master involves being data and automation-driven and connecting the development team with the execs, the clients, and the business, rather than shielding them.
The Scrum team are professionals within the company who work on the project and develop the product or service by upholding Scrum values and implementing the processes. They are the backbone of every agile organization that employs Scrum.
Kanban takes a fundamentally different approach to roles within an agile organization. Rather than defining strict roles and responsibilities, Kanban enables organizations to maintain their existing organizational structure.
There are two roles that Kanban proposes, which aren’t mandatory:
- Service delivery manager
- Service request manager
In a way, these two roles in Kanban break down the responsibilities of a Scrum master and delegate them to two individuals. The service delivery manager handles processes and the Kanban board, while the request manager takes on a more HR-esque role, handling governance and reducing risks associated with individuals.
| Roles in Kanban and Scrum | |
| Kanban | Scrum |
| The focus is on the existing structural organizationKanban offers suggestions instead of mandating specific rolesIt focuses on responsibilities and collaboration, rather than emphasizing the chain of command | Adopting Scrum means restructuring the organization and committing to specific rolesOrganizations need to appoint a product owner and a Scrum masterCollaboration is encouraged, but decision-making and leadership roles are clearly defined |
Planning vs. Visualization
Scrum is fairly restrictive for an agile framework. It emphasizes proper planning and aims to clearly define the work that needs to be done in each sprint. A Scrum master holds a sprint planning meeting before any work can begin, working with the team to define the scope of work and create specific tasks and sub-tasks.
In Kanban, the focus shifts from planning to visualization. This doesn’t mean that planning is absent from this framework, but rather that it’s approached as a prognostic effort that’s largely based on past workflow data.
The workflow is continuous, and organizations relying on Kanban often visualize the work by setting monthly goals. The idea is to leverage the existing data and plan the work based on the average time necessary to complete each task type.
In other words, there’s still a vague timeline that the team strives to meet, but Kanban leaves much more room for reprioritizing and shifting the focus.
Cadence (Scheduling) in Kanban and Scrum
Both Scrum and Kanban have cadence built into the framework. We can view cadence as scheduling or, better yet, timeboxing certain activities to maximize productivity and keep the project going.
The difference between the two frameworks is what they apply cadence to.
In Scrum, the work is done in timeboxed iterations — sprints. The general consensus, largely influenced by the Scrum Guide, is that sprints shouldn’t be longer than four weeks. In practice, the most common length of a sprint is two weeks. Another thing that Scrum Guide proposes, which most organizations fail to adhere to, is that the daily standups, also known as scrum meetings, shouldn’t last longer than 15 minutes.
Kanban doesn’t impose such strict time limitations but rather supports the continuous flow of work. While there is cadence in Kanban, it’s mostly applied to meetings. Even here, Kanban isn’t as strict as Scrum — it merely suggests that the organization should define the frequency and length of the meetings, which should serve the purpose of improving communication and sharing information with everyone working on the project.
Scrum board vs. Kanban board
Both frameworks utilize boards as a way of visualizing work and creating an information source that lets everyone involved in the project see the stage the project is in. Kanban leans more towards the former, while Scrum emphasizes the latter.
The Scrum board can be viewed as an extension of the product backlog. It holds all the tasks for the current sprint and shows to-dos, work in progress, and completed work. This is under the assumption that the board is regularly updated and displays accurate information.
The Kanban board serves as a sort of a map, visualizing the team’s process and acting as the backbone of a sustainable Kanban system that the organization aims to create. One major difference, when compared to the Scrum board, is that the board in Kanban limits the amount of WIP items.
The idea is to focus and commit to a specific task, which should limit the amount of work in progress that enters the process and help improve the delivery speed gradually.
Meetings
Scrum is adamant about holding meetings, and it views them as a way to improve collaboration and facilitate the flow of information within an organization. That’s why, in Scrum, there are several types of meetings [too many meetings?] that have to be held on a regular basis.
The mandatory Scrum meetings include:
- Sprint planning
- Daily standups
- Sprint reviews
- 1-on-1s
While Kanban recognizes the importance of meetings, it doesn’t enforce them by default. Rather, it gives organizations the opportunity to create their own meeting structure that aligns with their existing workflow the best.
There are seven types of Kanban meetings organizations can choose from, and you can implement any or all of them:
- Daily meetings
- Delivery planning meeting
- Service delivery review
- Replenishment and commitment meetings
- Operations review
- Strategy review
- Risk review
More often than not, Kanban meetings won’t have an exact schedule but will rather be called when necessary. For example, a strategy review meeting might take place when the new requirements are introduced, or processes need to be improved or altered.
| Key differences between Kanban and Scrum | ||
| Kanban | Scrum | |
| Roles | No mandatory roles | Product ownerScrum masterScrum team |
| Planning | Visualization of work; flexible planning; commitment to the task at hand | Thorough planning for each sprint; clearly defining the tasks and sub-tasks |
| Cadence | Flexible timelines; cadence based on data from past workflows | Work is timeboxed in 2-week-long sprints |
| Boards | A map of the team’s process that helps create a sustainable Kanban system; the amount of WIP is limited | Extension of the project backlog; source of information |
| Meetings | Organizations are free to create their own meeting structure and schedule the meetings as necessary | Mandatory meetings:Sprint planningDaily standupsSprint reviews1-on-1s |
The final verdict
As you’ve probably gathered by now, there is no definitive answer to the question of which framework is better. We’d go as far as to argue that the question itself is fundamentally wrong.
Each organization and project is unique, so it’s important to choose the best project management methodology and framework for your situation and projects.
There are a few more areas in which Kanban and Scrum differ, but now that you understand the key differences between the two, you should be able to make an informed decision.
One thing to consider is that Scrum and Kanban can be applied in tandem through a hybrid called Scrumban. You can pick and choose aspects of each framework and work to create a unique mix of the two that aligns with your business flows and integrates with your workflow.
Another crucial thing to keep in mind is that, regardless of which framework you opt for, the key to success will be communication. Establishing a flow of information and ensuring that everyone is on the same page regarding both the project and the processes is vital.
No project management methodology or framework is perfect, least of all Kanban and Scrum. They have inherent drawbacks, and every organization needs to adopt the frameworks to their unique situation in order to get the most out of them.
The most common issues organizations run into are disrupted information flow and the lack of communication or misunderstanding between the developers and the rest of the team/executives.
It’s not uncommon for the team members to find themselves asking the following questions:
- What are we working on?
- When are we delivering?
- What’s blocking us from delivering on time?
- What problems might we run into?
- Who needs help, and who’s the person that can provide the necessary assistance?
All of these questions stem from a lack of a unified source of information — managers use PM software, and the developers rely heavily on Git. The issue is only aggravated through meetings that end up being status reports, rather than constructive dialogue and problem-solving sessions.
Regardless of what you do and which approach you take, everyone needs to have a clear view and a deep understanding of the processes, as well as easy access to all relevant information. In other words, you need to keep track of what you’re doing.
LinearB was designed for this purpose specifically! Our platform connects all of your different information sources to create a unified platform that provides quick and easy access to everything you need to know about the project. This facilitates information sharing greatly and helps improve delivery predictability, speed, and quality.
A unified platform that connects all your information sources
Our robust, fully customizable platform lets you keep all of your business-critical information in one place by integrating the project management software with Git branches. It also provides you with a comprehensive view of all the crucial metrics and enables you to create mile markers with ease.
If you’re interested in seeing what LinearB can do and how it can help you streamline your workflows and improve productivity, click here to schedule a free demo.
