Agree, everyone, who knows the word agile has somehow come across such concepts as Kanban or Scrum. And a lot of people have always wondered what is better to use in their work: Scrum or Kanban. In this article, I will try to explain in as much detail as possible, but at the same time briefly explain and show the main differences between these two agile streams.
Before we talk about the differences, let's briefly (just very briefly) brush up on what Scrum is and what Kanban is.
According to the Scrum Guide (the holy book for all Scrum fans), Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. In other words, Scrum requires detailed and restrictive planning and has predefined processes and accountabilities. In Scrum, the work is divided into smaller tasks that must be completed in a predefined period (Sprint). Also, adding new work items during a Sprint is highly discouraged, making new work waiting for a new Sprint and reducing the team's ability to react to change. The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and minimize the need for meetings not defined in Scrum.
Kanban is a method (if you want) or a visual system for optimizing and managing workflows, which lets you visualize processes on a Kanban board and continuously process work items. Kanban's goal is that workflow should proceed smoothly at an optimal speed. The work in progress limits at each workflow stage allows your team to use its capacity optimally. In other words, Kanban helps you optimize your existing process with a set of principles. The main objective of implementing Kanban is to identify potential bottlenecks in the process and fix them.
Now let’s compare Scrum and Kanban and understand the main difference between these 2 techniques. There are many similarities and many differences between Kanban and Scrum. I am not sure it is correct to publish all of them. At least it will not be informative. So, I’ve decided to add the six most important differences between Kanban and Scrum to help you understand the real difference.
| Kanban | Scrum | |
Roles or accountabilities |
There are no pre-defined roles for a team. Although there may still be a Project Manager or even the Product Owner, the team is encouraged to collaborate and chip in when anyone becomes overwhelmed. | Scrum Master, Product Owner, and Developers. Each Scrum Team member has a predefined accountability |
Delivery cycle |
Products and processes are delivered continuously on an as-needed basis (with due dates determined by the business as needed). | Regular, fixed-length Sprints. The Sprint cycle lasts one to four weeks (or a maximum month) |
Change policy |
It can be incorporated at any time. Allows for changes to be made to a project mid-stream, allowing for iterations and continuous improvement before completing a project. | It is generally not made during the Sprint, but it is ok to add new items into the Sprint Backlog (without contradiction to the Sprint Goal). If required, A Sprint could even be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint. |
Delegation & Prioritization |
Uses a “pull system,” or a systematic workflow that allows team members to only “pull” new tasks once the previous task is complete. | It also uses a “pull system”; however, an entire batch is pulled for each iteration. |
Artifacts |
There is one well one known artefact - the Kanban board | Product Backlog, Sprint Backlog, Increment |
Measurement of Productivity |
Measures production using “cycle time,” or the time it takes to complete one entire piece of a project from beginning to end. | Measures production using velocity through sprints. Each sprint is laid out back-to-back and/or concurrently so that each additional sprint relies on the success of the one before it. |
Also, it is a significant step to understand when to use Kanban or Scrum. Honestly, there is no single rule and single answer. It depends on many factors, but in general:
- Kanban has been shown to improve visibility, foster a culture of continuous improvement, and increase productivity. Kanban can fit in with processes that already exist—including Scrum. If you don’t want to overhaul your entire work process but are hoping to gain the benefits that an Agile process can bring, Kanban can be an excellent way to start.
- Scrum has been linked to higher productivity, faster delivery, lower costs, and higher quality. Many project managers also see Scrum as an effective method to tackle complex projects or projects that might see frequent change.
Scrum can make sense to use if you’re in an industry that sees frequent change or if your project might need space to adapt to feedback. This might include industries with frequent technology updates or projects creating new products.
So, we briefly figured out what Scrum is and what Kanban is. We discussed the main differences between these two agile streams. Now, let's understand whether it is possible to work with these two techniques at the same time.
Scrum and Kanban are “agile by the books.” They work in a tried and true fashion that is quite frankly hard to argue against. Borrowing from another famed catch-phrase, you might say, “No one gets fired for choosing scrum.”
But your decision doesn't need to be so black and white. Many and many teams are using hybrid models influenced by both Scrum and Kanban.
I must say that yes, it is possible, but with some reservations. Those who combine Scrum and Kanban often refer to this activity as Scrumban.
Moreover, the scrum.org team even wrote a unique guide on using kanban in scrum teams. Below, in the description of this video, is a link to the guide. I will also say that I know several Scrum teams that use the kanban technique inside the Sprint.
Regardless of what you choose, stick with it for a little while. Take some work from the backlog to do, and then ask your team what went well and what went poorly. By trying Scrum and Kanban and asking these questions, you're well to agile bliss.
