Kanban in 30 Days: Modern and efficient organization that delivers results

The Kanban method is described by the following foundational principles:

The four principles make it clear that the Kanban method is not a process in itself to just put in practice, it's a method to drive improvement and it starts with the process you already have. Bullet 1 and 3 say clearly to not make any changes neither in the process nor in the roles, initially. Bullet 2 and 4 set your mind to involve everyone to take small steps of improvement that will be permanent. Kanban is not a destination, it's a direction and wherever you are, you can always apply these principles.

Beside the four principles there are six core practices to follow when using Kanban; stick to these six and you will be on your way to get a streamlined Lean system that works effectively. Kanban works on a personal as well as on an organizational level and both on big and small companies.

Practice 1 – visualizing your work

The first practice is to visualize what you are doing. This includes both the steps in the process and what work you currently have in each step.

You can use an electronic board or a physical whiteboard. It's great to have an electronic tool but so far I haven't seen anything that beats a big whiteboard. A whiteboard, because of its size, will easily give you an overview of the status and it´s flexible; you just draw new lines and add text wherever it's needed. The whole team can stand around it, get a good understanding about a project or process, and they can update the status simultaneously. If you can get a whiteboard on wheels, you can take it with you when you are in meeting rooms. The following image shows you how your whiteboard may look, with each column signifying a step in the process and the cards indicating the work you have to do in each.

Process steps and work shown on a Kanban Board. In this example it starts with an unsorted queue for future tasks followed by the sorted queue for the tasks to undertake next. The following process steps are one each for analyzing the requirements, designing the software architecture (design), development, testing, and deployment. At the end is a column for tasks that are done.

Practice 2 – limiting work in progress

The second practice is about limiting work in progress, also called WiP. By setting limits, you are not allowed to bring more work in than you are able to handle. If the persons working in the earlier process step work faster than the ones in the next step, then the work stays in the column until there is available capacity in the next step and they are ready to bring it in. Because of rule 2, the earlier steps are not allowed to bring more things in than what its limit allows. This is to prevent you from building queues of half-done work inside the system. Piles of unfinished work are one of the biggest wastes according to the Lean philosophy. What are people that are working in the early steps to do if they have reached the limit and are not allowed to bring more work in? Either they do nothing or even better, they check what they can do to help the bottleneck.

The following image shows the same Kanban Board when you have added limits:

Process steps, work, and limits shown on a Kanban Board. If requirement analysts, who have a limit of 1, are done then they can't bring more work in since the next step, the design step, has reached its limit of 2. The only way for requirement analysts to get an empty slot is when designers have available slots.

In the example, you can see that the process steps Next, Requirement analysis, and Design have reached their limit. It might be that the Design step is the bottleneck and that the people working with requirement analysis are doing nothing. We don't know that by just looking at the Kanban board but we do know that they are not allowed to start working on something new.

Practice 3 – managing flow

The third practice is about improving the flow of a process so the time-to-market, also called lead-time, is decreased.

This image describes the lead-time for an item.

Lead-time is the time from when we start working on an item until we are done with it

The lead-time could be measured in many different ways. In the previous example, the lead-time is from when we start working on the item until we have deployed it. It would also make sense to measure the time from when the item was requested until it was deployed. In the diagram this would be when the item gets into the list named FUTURE.

Since the third practice tells us to optimize the lead-time, here is where we start changing organizations and the way they work. This is not simply because a selected process tells us to, but because we believe the change will decrease the lead-time. Our belief is that the organization is more willing to change when they know why.

The value of the requested product is likely to decrease over time and that's the reason for the third practice. We don´t want it to take too long a time from the request until we deploy the product.

Lean is a management philosophy developed at Toyota. The Kanban process with signal cards described at the beginning of the chapter is a part of Lean, but there are many other components to it as well. It is described in 14 principles, which tell us to think long-term and focus on quality and the smoothness of a process's flow. It is centered upon the understanding that cost originates from more things than machines and people. There are invisible costs that exist between people and machines. For Toyota, it is car parts that were waiting to be used. These parts not only required storage and transportation but also risked being damaged during transportation. There was also the chance that they would grow old in storage and at the end be thrown away because they were not needed anymore.

For software development, these in between costs can be found in pre-studies, design documents, and code that have not yet been released to the market. You have the cost but no value. Some of this will become valuable but some of it will be outdated before it generates any value. The Lean idea is to reduce the risk for outdated products by shortening the time to market or at least the time before you get feedback. You want to know if you are doing the right things or not and you want to take as little risk as possible.

Besides the 14 principles, Lean is a way of thinking and an attitude. It is about challenging problems, continuously improving and continuously striving for perfection. With a Lean attitude, we know that our competitors have the same problems that we have, and if we are a little better than the competitors dealing with the problems, then we are ahead of them in our competition.

When I (Tomas) was in Japan 2009 visiting Lean companies, something I repeatedly heard was "if we are not a little better next week than we are this week, we will sooner or later be out of business". When visiting European and American companies I do more often hear "we are the best". Lean companies are looking for perfection; they do not settle with just being the best for now.

In the Lean attitude, there is also a way of handling visions that are overwhelming. It is a simple way and can be described with these steps:

Steps 2 to 4 should be repeated forever, as long as the vision is still valid. If it is not, you will need to go back and find a way of redefining it.

This image shows the Lean attitude:

A Lean attitude is a way of taking small steps in the direction toward the vision

There is another way of looking at the way of taking small steps towards the vision. When you have employers who are very fond of Kanban, they might complain that you're not taking the big steps to the vision immediately. This thinking helps people understand that it's hard to take those big steps and that the vision might be easier to reach by taking small steps. The organization is then able to slowly, at its own pace, make changes. Those who are eager for big steps can feel calm knowing that the company is moving in the right direction.

Lean is also about ensuring that workers are encouraged and expected to continuously suggest and implement improvements in their way of working. To be able to contribute, everyone needs to get the full picture. That's why visualization is so important in Lean.

Agile, like Lean, is more of a culture than a process. Agile is defined by 4 values and 12 principles, telling what the 17 authors of the manifesto have discovered to be important when it comes to effective software development. In short, you could say it's about getting fast feedback and being technically and mentally prepared for changing direction. Some describe this in a negative tone as "you never know what you will get". We would say that it's more correct to say that we never know from the beginning what the user or customer needs so we have to use a process that makes it possible to learn and adjust along the way. Agile is a way of minimizing risk, the risk that the customers do no longer want what we originally thought they wanted.

When talking about risk handling, the risk of delivering the wrong product or feature is one of the more important. When starting a project, we can guess what the customers need, but it's only when the customer starts using the output of the project that we know for sure if we delivered a high value product or not. To make it even more complicated, the right product could quickly become the wrong one when time passes since customers' needs and expectations change quickly. To minimize the risk of building the wrong things, Lean and Agile values quick feedback by getting features in a testable or sellable state as quick as possible. Lean and Agile values small releases often instead of big bang releases. They do also suggest that you optimize on flow instead of resources.

There is one more important thing about Lean and Agile: the view on decision-making. Many organizations are based on the assumption that employees should be divided into thinkers (managers) and doers (workers). This comes from Frederick Winslow Taylor who was one of the first management consultants. We think Taylor was right when he divided people between thinkers and doers just because at the time, around 1900, when he was active, there was a huge difference in education between managers and workers. His idea was that the educated should tell the uneducated what kind of products they should build and how to build them. This was a great way to get uneducated people productive in advanced industries. Today we usually don't have this difference in education. Instead, we have a lot of well-educated people in our organizations. In today's world, Taylor's ideas are wrong. To not use all the intelligence of our employees is waste.

We need all the intelligence at our disposal to collect and analyze the feedback we get by quickly getting to market and to find out how we can best improve the product. Unfortunately, a lot of managers are trained in the Taylor way of thinking. They serve the developers their working tasks in a requirement document and a design document and then they just want them to deliver the required things according to a plan. That way of working is likely to foster developers to value compliance over engagement and innovation.

If you tell people exactly what to do and how to do it, you don't give them much room to think themselves. If you instead give them goals and ask them to find the way and solve their problems themselves, you will see more energy and get far more engagement from them.

This following diagram is about fast feedback and reacting to it:

Agile and Lean is about getting fast feedback, being able to react to known knowledge and to wake up the employee's engagement.

To cultivate a culture of self-organization, managers need to build an environment where people:

Scrum is, like Kanban, a process framework, which applies the values and principles of Agile and Lean. In order to compare them, here is a one-minute description of Scrum.

In Scrum it is prescribed that you should have a cross-functional team, that is, a team with all competences needed to develop a whole feature. There should be a Scrum Master who is the master of the Scrum framework with the mission to make sure the team's process works well, is effective and is according to Scrum. There is also a Product Owner who knows the vision of the product, communicates with the stakeholders, and makes sure the team knows what is the right thing to be working on and in which priority.

The following diagram shows people involved in a scrum:

Scrum prescribes that you have a Product Owner who collects and prioritizes work to be done from the stakeholders.

In Scrum you work in iteration or Sprints of usually 1-4 weeks. Each Sprint starts with the planning of work for the Sprint and ends with a releasable increment of features. Hopefully the plan remains unchanged all through the Sprint.

Kanban has fewer rules. For instance, there is nothing about roles or about working in iterations. Kanban is more focused on continuous flow, visualizing the work and optimizing the time between ideas and runnable features.

This image shows the difference between Scrum and Kanban flow. You can easily see whether a Scrum team is at the beginning or at the end of a sprint.

In Scrum you work in iterations called Sprints. In Kanban there is more of a constant flow

So which one, Scrum or Kanban, is the best?

That depends on the circumstances; let us tell you a story from our past to explain what we mean by that.

Some years ago, I (Tomas) was working in a team that was doing Scrum. It worked well until we got to a point where we were about to develop support for new equipment. We had a deadline coming up but the purchasing department had not been able to choose the supplier of the new equipment. I remember a print planning meeting where item after item was refused, as we didn't know how to develop drivers without knowing the supplier (items can also be called user stories). In Scrum we are supposed to give a forecast of what we would release at the end of the sprint after the sprint planning, and without knowing the supplier we couldn't give a forecast.

I suggested that we should try Kanban because it can handle just-in-time planning. We changed method and managed to get to know the supplier in the last seconds and luckily we were done in time. Kanban rocked.

The project we started after this was one of those where you think "it should work just like it did before but with the new hardware". The problem was that no one knew how it used to work. We solved it by testing the system with the new hardware one step at the time and fixed problems whenever they occurred. Again, we had a tight deadline but we made it. This made me think that Kanban really rocked.

After the second project we didn't have so much to do but fixing allot of less important small issues. Then I observed that the energy within the team was going down drastically and that even small things took time. I realized that without a goal, Kanban doesn't work very well. Scrum, on the other hand, has a built-in goal every sprint thanks to the forecast made as the output of the sprint planning. Even though the result of the planning should be considered as a forecast and not a commitment, most teams try a little bit harder just to make the forecast come true. By changing back to Scrum, we got the energy back to a high level again.

To summarize, Kanban works great with uncertainties but needs a goal while Scrum needs to have enough certainty to be able to plan a few weeks ahead.

Kanban does also have an advantage against Scrum when it comes to surviving organizational reluctance to changes. Kanban does not oblige you to change so much in the early stages of its implementation. It doesn't force you to change your organization nor your way of working, but instead provides a framework to make your organization work more effectively and efficiently. Indeed, you may well implement larger changes later, but if you do that it is because the flaws in your current organization or process have been made obvious by using Kanban.

Our advice is to not get too religious about the difference between Scrum and Kanban. Most Kanban teams we have seen have a Scrum Master, but they call it something else. It also common to have a Product Owner, meetings like Daily Standup, demo and Retrospective, and terms like "backlog" and "impediments". All this is borrowed from Scrum. Actually, there is no rule or practice in Kanban stopping you from working in iterations just like in Scrum. At least as long as working in iterations improves your flow.

In this chapter we discovered that Kanban prescribes an evolutional process change originating from your current context. We went through the six practices of Kanban in detail:

We also covered Lean, which is described in 14 principles, which tell us to think long-term and focus on quality and have a continuous process flow.

We also described that Agile is about getting short feedback, and being able to technically and mentally change and mobilize brainpower. The latter does also show that Agile is a culture where respecting people, trust, and self-organization are important parts. That is an important step away from the traditional ideas about dividing people into thinkers (managers) and doers (developers).

Finally, we showed you the difference between Kanban and Scrum and discovered that the main difference was that Scrum prescribes roles, meetings, and artifacts, while Kanban is only focused on improving flow. They can also be combined. Whichever one is best depends on the situation.

In the next chapter, we will see how to get to know your process as the first step to set up your Kanban system, and how to make a value stream mapping. The chapter will give you a good foundation when you later on take steps to improve your effectiveness.