Kanban for Skeptics

As a change agent, you constantly need to reassure people that the path we follow is worthwhile traveling. This need is often expressed in the form of critique and difficult questions. When I coach Agile teams, this is often the case. The same thing happens when introducing Kanban. However, I noticed that Kanban raises much harder questions on a management and leadership level, once people are introduced to the basics and start to explore the subject on their own. For instance: “How can we plan if we measure instead of estimate?”

The type of questions Kanban raises, seem to be hard to answer without lapsing into an hour-long discussion. I guess this is normal because Kanban is much less prescriptive than Scrum, for instance. In order to provide reassurance, as a coach, you need to trace the questions all the way back to the principles of Kanban, which are grounded in Lean thinking.

That’s why I wrote a free e-book that lists the 5 most common arguments against Kanban and my response to them.

It will take longer

One popular argument against Kanban is that it will take longer to create the product. This reasoning is deeply entrenched in our everyday life. It is related to our education and how businesses have been managed for centuries. We’ve seen that Kanban focuses on using real data to make decisions. By measuring flow we manage our people and product.

This is completely opposite to what we’re used to. Managers have learned to control their workers by assigning work and monitoring their performance. You get a task and get it finished on time or you have to justify why you didn’t make it on time. The same approach is taught in schools. Students get an assignment with a deadline, which needs to be finished on time or they’ll feel the consequences through punishment in the form of lower grades. How many times did you get an assignment without a deadline? “This is what I’d like you to do, don’t worry about the timing, we’ll measure afterwards.”

Let's find out how Kanban uses measurements as a core management tool without losing focus.

Parkinson’s law

“The amount of time which one has to perform a task is the amount of time it will take to complete the task.”

Many people act by this simple definition. If we don’t set any deadlines, a worker will take much more time to complete the task. He will relax and start working whenever he feels like it. Time is money, so we can’t allow this, right?

It has been done like this for decades in the world of project management. A project plan is created by the project manager and senior developer. Based on estimates, a schedule and timing is created which becomes the target for a development team, whether realistic or not. The reasoning is quite simple, the team needs a deadline to keep focused. The project manager will add some buffer in his own plan, just in case the team doesn’t make it. But then at least they will make it for 90 percent. Without this focus they might not even reach 50 percent...

Simply from a cost perspective, this is a good approach. From a value perspective, this is a bad approach. Because what happens when people get stressed? They cut corners, try to do more in less time and introduce malfunctions by sloppy work.

From an HR perspective this is also a bad approach. People get overworked, stressed out and leave the company if the external pressure is too high.

You realize that there needs to be a balance between freedom and control. A first step in project management was to include the team in estimating the project plan. This gave them a first voice in the management side of the project and resulted in an increase in intrinsic motivation. Later with agile development, a next step was taken by measuring what a team could deliver in an iteration and using those numbers to plan instead of pushing for an initial estimate. This led to a significant increase in value creation and quality.

How does Kanban deal with keeping a healthy focus between control and freedom?

A healthy balance in Kanban

In a Kanban flow, team members pull new features from an ordered input queue. In many cases these features are not estimated up front. At most they are sized on a scale. Measuring flow is the main management tool that is used to control efficiency. By continuously monitoring lead and cycle time, we get a good idea about the progress of the team. These numbers become a target for each contributor to the flow. If the average cycle time is 5 days at a certain point in time, the team will indirectly focus on this number when starting on a new feature.

The beauty in this approach is that it’s founded on real data, not wishful thinking. If it takes 5 days to deliver a new feature, chances are high that it will take approximately 5 days for another feature. The focus is not created externally by management, but it has evolved from within the team. Therefore they will be more intrinsically motivated to pursue it. People will have to cut less corners and will deliver more valuable and high quality features.

From a management point of view, the style changes from command and control to helping the team to improve. Accepting that the system can deliver a new feature in 5 days is accepting reality. From that point all involved in the Kanban flow can start the process of continuous improvement. Everybody is responsible to think about how we can improve flow, reduce bottlenecks and variation. Soon your average lead & cycle times will change, along with the focus of the team. Their new focus will be a realistic one since it is based on real measurements on an improved flow.

I found it very useful to keep the theory of constraints in mind when trying to improve your Kanban flow.

Theory of constraints for process improvement

The theory of constraints (TOC) is a management philosophy introduced by Eliyahu Goldratt in his 1984 book titled “The Goal”. It is based on the idea that “A chain is no stronger than its weakest link”. If we project this to Kanban, this means that the weakest stage in the flow will determine the rate of value creation of the entire system.

For instance, if we notice that the user acceptance testing stage can’t keep up with the preceding stages, it will slow down output of the entire Kanban flow to it’s own capability.

(Click on the image to enlarge it)

By visualizing work on a Kanban board, the TOC will become visible in the form of bottlenecks that block the system. During the course of their work the team will also feel the TOC trough the use of Work In Progress (WIP) limits. These are numbers set at each stage of the flow, indicating the maximum amount of work items that can be present.

For instance if we’ve decide to start with a WIP limit of 3 on the UAT column, this means that no more features can be started in the preceding stages if the UAT column if full. You can imagine that this can become quite frustrating. Most of us are eager to start a new task, especially when we’re trying to get a release out of the door! People feel uncomfortable doing nothing, because we think it gives a bad impression. We must be busy all the time! It won’t take long before a situation like this is escalated. But that’s a good thing! We want to find bottlenecks as soon as possible.

This is usually the moment when an improvement session is triggered. How can we prevent this from happening again? Are our WIP limits not set accordingly? What is the root cause of this bottleneck, how can we unclog it? This session resembles a retrospective, but with a wider focus. Most retrospectives are held within the development team, with an occasional participation from a product owner. In Kanban, improvement sessions typically include many more different roles of the organization because of the focus on the entire flow, from idea till installation on production. This causes business analysts, system engineers and sometimes even sales people to be included.

The continuous improvement focus of all the different roles from the organization creates a healthy peer pressure and more opportunities to share knowledge. WIP limits will reveal bottlenecks quickly and create momentum to help others and start the continuous improvement cycle. The power of continuous improvement in Kanban will help you improve flow, which will tilt the perception that it will take longer into a feeling of greater efficiency. And you will have the measurements to prove it!

Flow

Kanban is based on the principles of a pull system, pioneered in Lean manufacturing. The goal is to get as close a possible to a single piece flow, where the organization is only working on products that are ordered by a customer. Why is this, and what does this have to do with software development?

The reason we only want to be working on customer requests is because we want to eliminate waste, which are actions that don’t bring any value to the customer. Forget about innovation for a moment, because there's no customer order is triggering the pull system. Working not only on customer requests means you’re guessing what the customer will order in the future, and therefore you are building up inventory, a stock of products waiting to be purchased. This is waste because of two reasons. It is capital spent on items that are not bringing in revenue and therefore costing us money. Also, these items contain a big risk of not being sold or not complying to customer’s wishes, leading to costing us money. In software development the same issues apply. Features waiting months to be released are costing money and contain a risk.

WIP limits reduce inventory and create a pull system upstream. If you have finished a task, you pull a new one from the preceding stage, freeing up capacity there, giving an opportunity for the preceding stage to pull on its own. This keeps going all the way up to the input queue.

(Click on the image to enlarge it)

The most common critique on WIP limits is that it will cause a drop in efficiency. Off course, people will be idle once in a while because of WIP limits that are reached. What would happen if they would ignore the WIP limits? The organization would gradually start building up inventory, more than the flow can handle. People can't be 100% busy. The perception that they should can be traced all the way back to the start of industrial times when factories started to grow and expensive machines were introduced to increase capacity. Off course these machines were so expensive that they had to run continuously in order to keep the unit cost low. This led to large unevenness in the production line and a growth of inventories. In those times, a product was not customized to the user, so the risk of not complying to it’s wishes was none existing simply because they had no choice. The company just had to make sure they sold the inventory. Today, for many organizations products are customized by the end users, causing inventory to be a major risk. This applies for IT as well, since the majority of systems are customized for a client, a customer segment, …

One continuous sprint

Kanban being a continuous flow leads to the perception that teams get no more chance to pause and reflect. It is a never-ending sprint where team members are pushed to deliver faster and faster. As we all know, a sustainable pace is important for the quality of the end product and the health of the team. Some slack is needed to get your senses together or reflect on the future of the product, which allows the team to take better decisions during the course of delivery.

Measuring flow makes it easy to fall into the trap of micromanagement. Pushing the team to work harder, feature by feature. This is where a coach has an important role to play. He must help all team members to understand that in order to go faster, they must take the time to reflect on the process, not on the speed of development. Kanban focuses on the end-to-end flow. Pushing one step in the flow to go faster will often cause problems for the rest of the flow in the form of defects, bottlenecks and swift decisions. This is again the Theory of Constraints, which tells us that problems will appear downstream if we push one step in the process to go faster.

A new Kanban team starts with their current efficiency and continuously inspects its collaboration in order to perform. Not by working faster, but by optimizing the flow. This makes it easier to guarantee a continuous flow, since we all agree that the system is more important than the individual, and we can achieve more by improving together.

Summary

It is a strange idea that by measuring flow instead of setting deadlines, work will be done efficiently. Kanban creates awareness on the importance of every phase in the process. Instead of pushing each individual phase to go faster, we optimize the whole. Again, because this is what matters to the end users. They don’t care how well our developers are meeting their deadlines, they need the order to be delivered. As soon as the process is under control, the team can start trying to improve their efficiency. Not locally, but end to end. Not by pushing individuals to work harder, but by reducing bottlenecks and optimizing the flow. The circumstances in which people work are tuned to better suit everyone's needs. A sustainable pace for the employees, a reliable relationship for the client and a profitable business for the owners.

Free e-book

You can read about the other 4 arguments against Kanban by downloading the e-book for free at leanpub.com/kanbanforskeptics and automatically get next versions in the future.

About the Author

Nick Oostvogels is an independent Belgian consultant who has worked at different companies in various industries. He helps organizations to deliver successful projects in whatever role necessary, often as a project manager or coach. He is a proud father of a daughter and twin boys, and enjoys outdoor sports such as mountain bike, running, soccer and drinking a Duvel afterwards. Nick is a regular blogger at skycoach.be and enjoys speaking and learning at conferences.