Kanban translates from Japanese as sign board or signal card. It was this signal card that was originally used as a mechanism by car manufacturer Toyota to help them ensure that they received the required car parts just in time. A physical card was sent to the supplier as a signal that the plant needed more of a certain part. The same card was stuck to the part when it was delivered and when the part was consumed, the card, still the same, was detached and sent to the manufacturer again as a signal for the need for more parts. Essential to this process is a rule that the number of cards stays the same. The number of cards cannot be reduced or increased without a formal decision. This mechanism ensures that the number of unused parts are kept at a level that will maximize flow and at the same time minimize manufactured but unused car parts. Car parts that have still not been attached to a car body are considered as waste.
The mechanism is also used in the Imperial Garden in Tokyo. That's where a certain David J Anderson saw the possibility to convert the ideas to software development. This is the story I heard from him: He came to the garden and a guard asked if he had a ticket. Since he didn't have a ticket he got one for free. He was a little confused about it and got even more confused when he, at the exit, was asked to give the ticket back. He later understood that the ticket was a controlling system, making sure the number of people inside the park was under a certain limit. I guess they had found out that if the number of people exceeded this number then the crowd would make people walk on the grass to pass each other and the park would be destroyed. David, who was working at Microsoft at the time, saw similar problems with software development. When people took on too much work in parallel it caused problems like bad quality and late deliveries. Together with the Kanban community, he created the Kanban method that is described in this book.
In this book we will use the definition of Kanban that is described at the Lean Kanban University (http://edu.leankanban.com/).
In this chapter, we will cover the first two days of learning Kanban, and we will learn about Kanban, Agile, Lean, and also the difference between Kanban and Scrum.
Let's begin by looking at the four foundational principles and six core practices of Kanban.
The Kanban method is described by the following foundational principles:
Start with what you do now
Agree to pursue evolutionary change
Initially, respect current roles, responsibilities, and job titles
Encourage acts of leadership at all levels
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.
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.
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.
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.
The fourth practice is about being clear about the process and the policies and principles behind it. This is to make sure everybody involved knows and follows the process and can suggest improvements of it. The reason is simply that it's very hard to discuss and improve a process unless you know what the current process is.
According to practice 3, you should measure and optimize the lead time and this will help you become successful. But wait a minute, just delivering fast is not everything; delivering the right things is also important. To know this you need to know what the customers, the end users think, and how well the product contributes to your company's revenue and wellbeing. Here is where practice number 5 comes into the picture, the need for getting feedback from people outside of your system. There is also a need for feedback loops within a system to make sure you deliver the expected functionality with the right quality. Here is where different kinds of tests come into the picture. Automated tests that run continuously are preferred since they make feedback loops shorter.
The sixth practice is the one that makes Kanban more interesting, as well as more complicated. This practice tells us to use all theories about flow you can find and apply it to your process in order to fulfil practice number three (optimizing lead-time). These theories can be Lean, queuing theory, chaos theory, gaming theory, theory of constraints, and probably many more. This will take a while to learn, but it will be worth it in the long run. The practice also tells us to take decision of changes in consensus to make sure everyone is aligned with the decision.
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:
Define your vision even if it feels impossible to reach.
Define where you are now.
Define what next reachable goal in the right direction.
Iteratively make improvements until the goal is reached.
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.
Long-term philosophy:
Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals
The right process will produce the right results:
Create continuous process flow to bring problems to the surface
Use the "pull" system to avoid overproduction
Level out the workload (heijunka) – work like the tortoise, not the hare
Build a culture of stopping to fix problems to ensure quality right from the start
Standardized tasks are the foundation for continuous improvement and employee empowerment
Use visual control so no problems are hidden
Use only reliable, thoroughly tested technology that serves your people and processes
Add value to the organization by developing your people and partners:
Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others
Develop exceptional people and teams who follow your company's philosophy
Respect your extended network of partners and suppliers by challenging them and helping them improve
Continuously solving root problems drives organizational learning:
Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu)
Make decisions slowly by consensus, thoroughly considering all options (Nemawashi); implement decisions rapidly
Become a learning organization through relentless reflection (Hansei) and continuous improvement (Kaizen)
Source: "The Toyota Way" by Jeffrey K Liker.
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.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Source: http://agilemanifesto.org/
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Source: http://agilemanifesto.org/
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:
Are very aware of goals.
Are exposed to well-visualized information of how well they are doing.
Know they are allowed to experiment with their process. They own the process within some well-defined limits.
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:
Visualize your process and your current status.
Limit how much work you have started so that you don´t build queues within your system.
Improve your flow to decrease the time it takes from when work is started until it's finished.
Make process policies explicit so everybody can participate in improving them.
Implement feedback loops to make sure we continuously learn and implement improvements on both a local and organizational level.
Use known theories such as Lean, Agile, queuing theory, gaming theory, chaos theory, and theory of constraints to collaboratively and experimentally improve your flow.
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.
