But there’s no need to argue anymore.
Today, you will learn the difference between Kanban and Scrum, their advantages, downsides, and situations in which to use them.
So, let’s get straight to the point!
Scrum: organizing chaos with short-term planning
Scrum is, perhaps, the most famous of the Agile frameworks. It focuses on small, self-organized teams that work in short iterations lasting on average 2 weeks (also called Sprints).
The main difference between Agile and Scrum is that the latter doesn’t divide the team into developers and testers. It also has no dedicated project managers as everyone is expected to code, test, and manage their own work.
Additionally, there are two special roles that are crucial for a Scrum team:
- Product owner – a customer’s representative that aims to maximize the product’s value. They need to have a deep understanding of the business problems and be able to communicate the project objectives to the development team.
- Scrum master – a person who protects the team’s time from outside interruptions and inner distractions. They are responsible for helping the team to perform at their highest level and maintaining Scrum rituals.
Before the start of every Sprint, the team gathers for a Sprint planning session. During this meeting, the Product Owner would write user stories (pieces of functionality from the user’s point of view) and add them to a prioritized list called product backlog.
The stories that have the biggest value will get the highest priority.
Before the start of the Sprint, the team will pull a number of stories from the backlog they believe they can complete within one iteration. Typically, those features will share a common goal.
Each story is assigned a certain number of story points representing the amount of work that needs to be done by the team. For the next 2-4 weeks the team will commit to the items in Sprint backlog and ignore all other stories. Any new requirements that appear during the iteration will have to wait for the new Sprint.
After organizing a demo for stakeholders and releasing the completed stories, the team will typically gather for a retrospective meeting.
Its aim is to review the work done, discuss challenges, and readjust the work process for the next iterations. If done properly, retrospectives help build better relationships with the client and improve processes with each new iteration.
The last ritual I need to highlight are the Daily Scrums.These time-boxed standup meetings allow the team to review the progress towards the sprint goals, synchronize activities, and plan work for the next 24 hours.
During a Daily Scrum, each team member has to answer three simple questions:
- What did I do yesterday?
- What I’m going to do today? and
- Are there any blockers that impede my progress?
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – the Agile manifesto.
Regular meetings ensure that the client gets less surprises, even during uncertain times.
In our experience, Scrum is mostly suited for projects that require a quick launch of a product with basic functionality (the so-called MVP – Minimum Viable Product). If you don’t have a precise understanding of the final product, the approach allows to quickly change the direction of development following the change in requirements.
From the management point of view, Scrum provides a great balance of control and flexibility. Sprint planning takes some time away from the development but ensures the committed features will be 100% accomplished. This allows the team to see the bigger picture while managing day to day processes.
On the other hand, it requires high involvement from the client’s side. If you don’t have enough time to dedicate to the project, it’s better to choose a Waterfall software development model.
What’s more, you need to have at least some of the features prioritized and planned for the first two Sprints.
One of our clients from Norway wanted us to develop a system for selecting interior materials for apartments and other real estate objects.
The project had a ton of stakeholders, both from inside the client company and intended users (admins from the partner companies and real estate buyers).
Each stakeholder had different requirements, which complicated the discovery process.
We chose to build an MVP using the Scrum application development methodology. Upon completing the first version of the project, we organized a demo for various stakeholders. Their feedback allowed us to gather a huge number of additional requirements and suggestions which became the basis for the next iterations.
As the client had a budget for continuous development, the team was able to collect requirements on the go and deliver constant improvements with each new release.
Even lockdowns and working from home proved to be an easily addressable issue for Scrum teams with well-established processes.
The approach assumes constant adaptation to a changing environment. The pandemic turned out to be one of those challenges that the team has to discuss during retrospectives. As a result, each team works out their own rules and processes that help them adapt to the new reality of working from home.
You can, for example, have daily stand-ups using video conferencing tools. All team members know they need to switch on their cameras at the same time each day. They also know what they need to report on and what to discuss during the meeting.
Scrum Masters, of course, might worry that the conversations are more stilted than face-to-face meetings. The answer I got from our Scrum Masters was to work harder to break the ice and engage in small talk. The team members need to understand you care about them and everything in your power to make them feel at ease.
Scrum vs Kanban pros:
+ Fastest time-to-market of all Agile approaches.
+ Allows the team to be flexible and adjust plans as they go.
+ Works best in projects with incomplete requirements and high degree of uncertainty. Ideal for new and dynamic markets.
+ Timeboxed environment helps the team to deliver value at the end of each Sprint.
+ Provides great transparency for the client.
+ Daily Scrums provide an objective way to measure team productivity.
+ Allows to accurately predict release dates.
+ The team knows the exact scope of work they need to do in the next 2-4 weeks
Scrum vs Kanban cons:
– Relies on high involvement from the client. Quickly falls apart without adequate communication.
– Requires highly skilled and motivated team members.
– Tailored towards smaller teams and long-term projects.
– Reliant on a buy-in from all team members.
– Sensible to changes in the team composition due to the need to plan Sprints based on team velocity.
Kanban: extreme flexibility and simple execution
Kanban is another popular Agile framework.
It’s central feature is a Kanban board – a simple to-do list with stickers that represent different tasks or user stories. The board has several columns representing different stages of work.
As the team works on the stories, the stickers move between columns, from left to right.
The board is often wide enough for one card and has a limited depth to reduce the amount of work in progress.
When the team completes a user story, the Product Owner pulls the next most valuable task from the backlog and places it on the board.
There are no Sprints or Sprint planning, the process is continuous and can incorporate changes at any given time. Unlike Scrum, Kanban can be easily applied to existing processes at your team.
Developer productivity is measured using lead time – the amount of time it takes for a card to move across the board.
In our experience, Kanban better fits projects in the maintenance phase. On this stage, the team often has to deal with a constant stream of change requests from the client and fix user-reported bugs.
In one of our projects, we had to develop a SaaS system for reporting environmental pollution and social responsibility efforts. The project was initially delivered using the Scrum methodology. When transitioning to the support phase, the client came with lots of change requests that weren’t connected with each other.
Most of these fixes had to be deployed as soon as developed. As it’s very hard to unite such stories with a single goal and organize them into Sprints, we switched to Kanban, a more flexible framework
Now our Product Owner collects feedback from stakeholders and adds new stories to the product backlog. He then prioritizes features according to their value/risk and adds them to the team’s Trello, one task at a time.
The team can work on new stories as they come and make smaller releases several times a week.
Kanban also works in situations where Scrum is too inflexible, for example, when the initial requirements are constantly changing.
This happened during one of our projects when we were developing a social networking app for a German startup. By the time we had to start the first Sprint, the founders were still unsure about the direction of the app.
That’s why we decided to switch to Kanban for the first month of development. This allowed us to start working on the app while collecting requirements and re-prioritizing features.
We also discovered that Kanban requires careful management of client expectations and following at least a general direction of development.
Work from home affects Kanban more than Scrum. As developers have to constantly work on new features, they will have to deal with many bug reports from the QA engineers. Juggling between bug reports and user stories requires lots of self-discipline from developers and admirable self-management skills.
Kanban vs Scrum pros:
+ Extremely flexible. Focus on individual tasks allows to quickly alter the direction of development.
+ Has fewer processes than Scrum: easy task prioritization eliminates idle time.
+ Works even for larger teams.
+ Better suits service-oriented teams.
+ Ideal for the maintenance phase (or situations where you have a continuous stream of change requests)
+ Allows to work on one task at a time. The team doesn’t have to re-plan activities when the client changes priorities.
Kanban vs Scrum cons:
– No Sprint planning makes it harder to make predictions regarding the release dates.
– Project scope can be difficult to control.
– Engineers might have trouble prioritizing the incoming tasks (self discipline is essential).
– No timeboxing might lead to lower productivity.
– Easy to lose the end-goal of development.
– Increased flexibility sometimes inspires clients to change priorities too frequently leading to disorderly development.
I hope this article helped you to understand the difference between the two software development methods and realize which one is more suitable for your next project (see the table below).
The whole Kanban vs Scrum debate can be summarized in a few sentences.
Scrum is a more structured approach with defined roles and rituals that guide the development process.
Kanban is a more flexible approach that allows the team to continuously work on new features and adapt to the ever-changing requirements.
Both approaches can work for your team. Our developers prefer to deliver projects using the Scrum methodology while Kanban is reserved for the UI/UX design phase with unstable requirements and for active maintenance.
Both Scrum and Kanban are flexible frameworks that can be adapted to your current processes. High-performing teams usually discover what works about each of the approaches and combine them to deliver better results.
So, don’t be afraid to experiment with your next project!
And if you need some help with Agile processes or search for a cross-functional team to build a winning product, you can always write us a message.