Scrum and Kanban can be combined together to get more benefits than the one you would have if you were to apply them separately. Hence, in this guide we will see how useful it can be to apply both Scrum and Kanban project management at the same time.

If you are there, you probably know that both Scrum and Kanban are different flavours of agile project management – an approach to manage projects that aims to reduce wasted effort and resourced, and tries to cope with an extremely volatile environment. We will also take care of explain the basics of both Scrum and Kanban in this article.

Scrum and Kanban, Individually

Scrum in Brief

Scrum is born for software development and lives on the concept that the team that does the work is in chief. The project manager should do whatever he can to empower the team, because only the team gets the work done. As a consequence, the PM should try to remove any roadblock to the team.

Scrum is based on the concept of servant leadership, and places great emphasis on organic collaboration. It privileges face-to-face discussions to other communications means.

With scrum, the team meet daily in the morning in what is called a “scrum meeting”. All team members talk in turn, each saying what he accomplished the day before, what he plans to accomplish the current day, and raise any issue that may be blocking him. Those meetings are not meant to be long detailed discussion, but help everyone understand the general situation. In fact, they should last about 15 minutes, and are often called “stand up meetings” because they are done while stating, based on the idea that they standing is less comfortable for people and they will try to keep the meeting short.

Any issue that requires further discussion is then addressed after the meeting only by the people involved. Asides from that, everyone goes and work on his own until the coming day, where the next daily meeting is set.

Kanban in Brief

Kanban is another discipline in agile. It focuses on making the work visible and identify (and remove) any bottleneck. This, like many other agile concepts, was born out of Japanese manufacturing companies, and it stems out of inventory management practices.

Inventory is the amount of products you, as a manufacturer or retailer, have at hands to do your work. For example, a retailer needs to have some clothes ready on the racks so that when customers arrive in the store and are ready to buy, they find (and buy) what they were looking for. The more inventory you have, the less likely is your consumer to become unsatisfied. However, having inventory is costly, because you have to spend cash to acquire inventory (buy clothing), and you don’t see that cash back until you make a sale.

So, with lean manufacturing, we try to keep inventory as low as possible, and have it just enough to satisfy demand.

In manufacturing, the concept is extended because, to produce a product, raw materials flow from one step (or station) to the next. Each station consumes materials produced from a previous station, and it is therefore its customer. Rather than having the previous line just produce a bunch of stuff, waiting for the next line to take them and do something with them, with lean manufacturing we adopt a pull approach. With this mechanism, the previous station produces materials only when the next station requests them. In other words, it is the far end of the process (the customer, the demand) driving all production.

To increase visibility of this, Japanese manufacturer started to have racks and shelves where they put intermediary inventory that was waiting to be consumed by the next line. This made work visible, making it clear where most inventory was accumulated.

With Kanban, you can do the same with any type of work, and not necessarily physical inventory. To do this, you have to divide work into pieces that have a clear scope and definition, we call them cards. Then, you have to envision your production process as a series of linear step a card can be in. For example, it may be ready to be created, in progress (someone is working on it), or complete, to give you an extremely basic framework.

In this way, you can clearly see what is the status of each work item by looking in which column its card is.

Scrum and Kanban, Together

Both Scrum and Kanban have clear benefits. By adopting both practices together, they can build onto one another. You obtain more by combining them together than the mere sum of the two.

Daily Scrum with Kanban Boards

When you do a daily scrum, don’t just talk about what is going on. Instead, use a Kanban board to visualize the status of the work. Every time someone discusses what he is doing, he should relate with a specific card on the Kanban board.

Doing so means you force people to ensure they are actively working on what is agreed and that we do not lose time executing tasks that are not really important or that are outside of what was planned (the cards). Plus, the benefit of visualization also makes you see which card remain blocked longer in certain stages of their lifecycle, which helps identify implicit roadblocks.

Furthermore, implementing a Kanban board during daily scrums is easy. You can do that with a normal whiteboard, or alternatively use online tools like Trello or Azure DevOps Boards.

Sprint Planning

Sprint planning is another important concept in Scrum and Kanban. A sprint is a predetermined amount of time during which you commit to complete some work, shown as cards on a Kanban board. You can extend this concept to be both Scrum and Kanban.

Before each sprint starts, you perform sprint planning: decide which features you should implement first. This is done according to both scrum and Kanban methods. It is based on Scrum because we empower the team by having them join and decide together what should be addressed next, what are the features to implement in the sprint, and what are the features that can be put on hold for now.

It is Kanban because we lay down work in cards on a board so that it is visible. This is done by having the first column named backlog, where you put all the features that you are interested in pursuing. Then, you decide which ones should go in the coming sprint.

Sprint Retrospective

Our final tool to apply both scrum and Kanban together is sprint retrospective. This goes hand in hand not only with Scrum and Kanban, but also with the sprint planning process we just mentioned. In this case, we still use the Kanban board as a reference, but the sprint retrospective has a different goal from the planning.

The Sprint Retrospective, or Sprint Review, means stopping close to the end of a sprint and reflect on what was accomplished, what not, and why not. It is a moment of self-reflection, and the entire team is brought to speak up. Of course, the ultimate purpose is to get better, and by having this discussion with the team we can get better and better over time. It is Scrum because it empowers the team to understand what is not going well and take proactive action to fix it. It is Kanban because we based the discussion on a Kanban board.

Scrum and Kanban in Summary

Long story short, Scrum and Kanban are two flavours of agile project management that can be combined together to get much better results. To do that, you should learn more about each, and I suggest you start reading this guide on Kanban.