The agile manifesto consists of guiding principles that help software development teams incorporate feedback and make changes faster.
In today’s environment, modern agile software development teams can no longer afford to take months (or years!) to deliver solutions to customers. Which is why teams are striving to become agile in order to build better products and get them to market quickly.
Scrum and Kanban are two of the most commonly frameworks used by teams use today. They incorporate agile practices and offer very distinct sets of recommendations for teams.
But which one should you choose for your team? Let's jump in and find out.
What is Scrum?
Scrum is an agile framework that involves breaking down large blocks of work into smaller, executable chunks. These chunks of work are taken up by cross functional development teams and delivered in time-boxed sprints that may vary in duration from a single week to being close to a month-long.
What is Kanban?
Kanban is a process improvement framework that has found its way into software development circles. It involves visualising existing workflows onto a board and identifying roadblocks in the workflow.
The most common Kanban implementations used by software teams are on physical Kanban boards (whiteboards with sticky notes) or digital project management tools that support Kanban boards.
Key differences between Kanban vs Scrum
| Scrum | Kanban | |
|---|---|---|
| Schedule | Scrum teams follow a | |
| 2 - 4 weeks Sprint. | Kanban teams don't have a strict |
schedule. They follow a
continuous delivery process using
kanban boards. |
| Prioritization | Work items are not reprioritized
after it is added to a sprint. | There is no strict rules around
reprioritization. |
| Roles | Roles in a Scrum team
are defined as:
- Product Owner
- Scrum Master
Development Team | There are no defined roles in a
team that follows Kanban.
However, they may employ a
project manager to have a
smooth process. |
| Meetings | Teams run scrum ceremonies.
There are 4 main ceremonies:Sprint retrospective | No mandatory meetings are held. |
| Measurement | Teams often use reports like
burndown charts & burnup
charts to track the Sprint's
progress. | Teams use cumulative flow diagram
to keep track of the progress. |
| Popular Tools | Scrum teams use Scrum Board
tools.
You can read more about Scrum
Board over here. | Kanban board software is used. |
5 Questions you need to answer before choosing between Scrum and Kanban
1. What are you looking to improve?
Scrum and Kanban fundamentally focus on two different things.
Scrum teams are committed to planning and estimating better. Once work is broken down into sprints, the focus is on achieving and maintaining velocity in order to successfully complete these sprints.
The Kanban framework focuses on improving flow (or efficiency) of existing processes without fundamentally changing the current workflow. Kanban teams focus on identifying trends and incrementally improving the process.
Are you looking to fundamentally change your underlying process or are you just looking to improve visibility of what is happening and clear roadblocks?
Scrum could be the right option if you believe that you need to spend more time planning your products and moving your development efforts to a more iterative style of delivery.
Kanban may be a better fit if improving visibility of work progress is the most important outcome. Kanban focuses on making existing processes more visible and surfacing bottlenecks - leading to steady process improvement.
2. How are your teams structured?
Scrum works best in a cross functional team environment. As you are required to arrive at a shippable/demo-ready feature at the end of every sprint, specialised teams struggle to fully adopt scrum. For example - a typical scrum squad could consist of designers, developers, QA and a scrum master. This cross functional team is constructed to be able to take care of end to end product delivery.
In addition to this, scrum requires teams to have members that have scrum-specific roles. The most important of these are the product owner and the scrum master. Team members have to be specially trained in these roles and responsibilities.
Kanban is suitable for both cross-functional collaboration and specialised teams. It also does not require any specialised roles in the team.
3. How clearly structured and repeatable are your processes?
Kanban is better suited for processes that can be laid laid out on a sheet of paper(clearly visualised). It also helps when these processes are mostly repeatable.
Scrum does not focus as much on the underlying workflow but requires your product development process to be broken down into sprints. If your team or product does not suit a development lifecycle that consists of a series of sprints, you are likely to find it difficult to implement scrum.
Similarly, if your team is taking up a lot of ad-hoc tasks that require different workflows, you might struggle to implement Kanban effectively.
4. How frequently do you ship features?
Scrum teams work in batches or sprints. Continuous deployment of features can be difficult to achieve in a Scrum environment. This is mainly because products are usually scoped down to arrive at demo ready sprint targets. This often leads to teams building versions of features that are batched together in releases.
Kanban is designed to support continuous delivery. The focus of the framework is to continuously deliver features while constantly striving to reduce the time it takes to deliver.
5. How quickly do you need to see results?
Scrum is inherently more complicated to implement than kanban. The amount of training and planning that is needed to implement scrum in an organisation is quite large.
Scrum also involves several specialised roles like the product owner and the scrum master who need to be hired or trained separately. To add to this, the culture of meetings before and after sprints will have to be slowly integrated into the company. This could take significant time and investment to get right. Also, failed scrum implementations are a lot more common simply because of a complete overhaul of existing processes.
Kanban on the other hand focuses on incremental change in your organization. It can be implemented fairly quickly and requires fairly minimal management buy-in. If you are looking to get started with agile and make gradual progress towards becoming more efficient, Kanban might be your best bet.
Summary
Choose Scrum if
- You are looking to drastically change the way your teams approach software development and delivery.
- You feel that your teams need to do a better job of breaking down work, estimating timelines, and releasing software.
- Your teams are cross functional and you have the bandwidth to train them in the concepts of scrum.
- You can break down large bodies of work into smaller blocks and execute them as sprints.
- You feel your teams can dedicate more time for meetings. Scrum takes quite a few iterations to get right. Planning meetings and retrospectives may add overheads and drag timelines - but they are essential to making scrum work.
- You have enough time to get it right. Teams typically start seeing performance improvements after 3-4 sprints. It is not uncommon for teams to miss targets by miles in the first few sprints. Understanding processes, getting good at estimation and figuring out roles - all take time. Scrum may disappoint you if the goal is to see improvements from day one.
Choose Kanban if
- Your team has a workflow that can be visualised.
- Your tasks usually follow the same repeatable workflow rather than being more ad hoc in nature.
- You feel that the current levels of planning are sufficient.
- You are looking for incremental performance improvement.
- You are looking for a process that is light on meetings.
- You want to implement and get started quickly.
Oldest comments (0)