What process do I choose – Kanban or Scrum?

Reading Time: 6 minutes

What happens when you put a group of project managers and agile practitioners in the same room? You get war – that’s right. It usually starts with the discussion on different forms of process and project management. By the end of the day, the discussion would have escalated to a war with fanatical fundamentalists on either side. The most popular of these topics of discussion are Kanban vs Scrum.

 Let’s try an understand what we are exactly talking about here. Let’s start with some basic definitions.Scrum

Scrum is an Agile methodology by Ken Schwaber and Jeff Sutherland who are also originators of several Agile Manifesto and Agile Principles. Scrum has specific expectations regarding roles and ceremonies unlike Kanban which is strictly focused on managing the flow of work, and agnostic about how you actually deliver that work.

 Let’s focus on some of the main principles of Scrum which are as follows.

1. The team is self-organized and self-organizing.
2. Scrum focuses on delivering maximum business value, from beginning early in the project and continuing throughout.
3. The crux of scrum is iterative development. This emphasizes how to better manage changes and build products that satisfy customer needs. This is short and time-boxed and focused on deliverables.
4. Teams make commitments based on what they think they can do with help of sprint planning, daily standups, reviews and retrospective meetings.

 A typical scrum board will look something like this.

 Example of project execution using Scrum

Google is working on the project to come up with a competing product for MS Word, that provides all the features provided by MS Word and any other features requested by the marketing team. The final product needs to be ready in 10 months of time.

Let’s see below on how this can be handled using Scrum

1. In the Scrum, each project is broken up into several ‘Iterations’.
2. All Iterations will be of the same time duration (between 2 to 8 weeks).
3. At the end of each iteration, a working product will be delivered.
4. In simple terms, in the Agile approach the above task will be broken up into 10 releases (assuming each iteration is set to last 4 weeks).
5. In Scrum, the team will decide the basic core features that are required in the product and decide which of these features can be developed in the first iteration. This doesn’t leave much scope for spending one to one and half month for complete requirement gathering.
6. Any remaining features that cannot be delivered in the first iteration will be taken up in the next iteration or subsequent iterations, based on priority.
7. The team will deliver a working software with the features that were finalized for that iteration at the end of the iteration.
8. There will be 10 iterations and at the end of each iteration, the customer is delivered a working software that is incrementally enhanced and updated with the features that were shortlisted for that iteration.
9. The evolution of the software through iterations is shown in the example below.

Agile methodology gives more importance to collaboration within the team, collaboration with the customer, responding to change and delivering working software.

 Kanban

Kanban is a Japanese term for “signboard” or “Billboard”. It is a concept related to lean and just-in-time production, where it is used as a scheduling system that tells you what to produce when to produce it, and how much to produce.

In the software industry, we use Kanban to focus on on “work in progress” and “lanes” of work that are required to deliver software. A typical Kanban board will look something like this

Now while Scrum is better suited for Software Development, Kanban is about change management. In the above example, you will note that the “To Do” bucket has a work item limit of ten, but only four items in it.  This is good — it means that there’s room for more work in the To-Do line; on the other side of the coin, there is a work item limit of five in the Done bucket, but eight items assigned there — this shows that there’s a backup in the process that needs to be addressed.   And there’s no work item limit on the Deployed column because these are closed items and there is no work required on them.

In Kanban, we follow something called the “pull” process for the team. The team takes the top item in their vertical lane, works on it until it’s done, and moves it to the next lane.  Once that’s done, they take the next item in the lane and work it until it’s done, then move that to the next lane.  It’s a very production-line mentality, and while you can do estimates using story points or hours, the primary measure of progress and productivity is the number of work items in each lane, not the time it’s going to take to get any one thing done. The idea is to move into a “just in time” mindset, where you’re finishing the top item at the same time that another work item is coming in to take its place.

 So which is better?

 The following three questions should help in deciding which process would suit the organizational needs.

1. Does the team or organization have an existing culture of continuous improvement?

Holding Scrum, Sprint Planning, and Sprint Retrospective meetings for teams that are new to Agile can help them get into the habit of thinking about the work they will be doing in upcoming sprints and how they can improve from sprint to sprint.

2. What sort of change the does team expect during the project?

Sometimes, the volume of high priority issues is high sometimes there is none. With this changing level of demand, it is very difficult to conduct any sort of sprint planning. It’s no surprise that we can use Kanban for this. Kanban has become very popular with maintenance and support teams do the unpredictable amount of work that comes to them at any given time. However, if expected change in requirements during the sprints is low, Scrum may be a better fit for the team.

3. Is your team or organization ready to make big changes to the way they work?

Moving to Scrum requires assigning people to Scrum Master and Product Owner roles. Training sessions need to be conducted to go through the different ceremonies and roles. These are big changes and not every team is ready to make this commitment. If the team is unable or unwilling to make the changes to adopt Scrum, Kanban can offer some help as it requires less change to the way a team is currently working. To start with Kanban, teams can immediately start visually managing their work and see areas where they are getting blocked or areas where there may be the waste. Teams need to start implementing WIP limits and these should get stricter over time as the team matures. Although beginner teams may not be able to take full advantage of the flow, continuous delivery, and continuous improvement elements enabled by Kanban, the barriers to starting are lower since there are no prescribed roles or ceremonies.

Well simply put, the answer depends on when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves.  We cannot term either one better or worse. It depends on the circumstances.

So what’s the verdict?

Well, there is no one-size-fits-all answer to this question, in fact, there are many successful teams who use some combination of both approaches, popularly known as “ScrumBan”.  As with any Agile tool, process, or approach, you need to try something to determine whether it fits your needs and your culture, and then adopt and adapt as necessary.