Chapter 12. Kanban pitfalls

This chapter covers

• How to avoid common kanban pitfalls and criticism
• The number-one mistake when starting to use kanban
• The fact that kanban isn’t a process at all, at least not as you might think

By now you should have plenty of reasons to use kanban in your process. You can show interested people that kanban has improved and continues to improve your process. Because of the approach that kanban takes to change management (“Start where you are and improve from there”), most teams and organizations don’t object too loudly to kanban and the principles it’s built on.

That said, some criticism comes up from time to time. It wouldn’t be fair if we didn’t at least touch on the most common issues and how to deal with them. For the most part, the criticism focuses on pitfalls that are easy to fall into if you don’t look out. We wrote this chapter so you know what to avoid.

The aim of this chapter is twofold: to introduce you to some commonly raised objections and then to help you avoid the pitfalls identified by this criticism. Learning about the ways people criticize is a great way to improve—it helps make sure you steer clear of bad things.

Let’s take the bull by the horns and start with criticism that came up in the early years of kanban, leveled by one of the founders of Scrum.

12.1. All work and no play makes Jack a dull boy

(Everyone who checked the door to see if Jack Nicholson was ready to break in with an axe, raise your hand.) The heading of this section is a quote from the famous horror movie The Shining, in which an overworked author^[1] just keeps typing the phrase “All work and no play makes Jack a dull boy” on his typewriter. It’s also what we thought we heard^[2] Ken Schwaber say when he criticized the early kanban community. The real quote is this:

¹ Neither Marcus nor Joakim had reached that point at the time of writing. Our families are safe. But Marcus has not dared to give tricycles to his twins.

² It’s a bit of a stretch but it made a great heading, don’t you agree?

God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause.

Ken Schwaber^[3]

³ “Waterfall, Lean/Kanban, and Scrum,” http://mng.bz/OrXd.

Ken Schwaber is, together with Jeff Sutherland, the father of Scrum. He was commenting on the lack of iterations in kanban. To him, kanban was just a long list of work lined up, with no end in sight: just work, work, work.

That doesn’t sound too nice, does it? Sadly, he had a point, especially considering many of the kanban implementations we’ve seen at our different clients and workplaces.

Kanban is very lightweight and is easy to get up and running. As we’ve mentioned a lot already, it’s just a few simple principles. If you’re already doing Scrum or some other iteration-based method, you can even remove stuff like iterations, if you want. Before long, you end up with just a continuous flow of work and “no slack ... to rest and be creative.”

But that’s not how it needs to be, and it’s not how kanban was intended to be. Quite the opposite! Kanban never said to remove iterations. But it does give you the freedom to detach the ceremonies of other methods—such as planning, reviews, and retrospectives—from each other.

Kanban doesn’t say anything about having the same cadence for different ceremonies or not. If you find that useful, by all means go ahead and do that, but don’t be unnecessarily constrained by it. Take the opportunity to defer decisions until the “last responsible moment,”^[4] when you have the most information in your hands. Using kanban, you can also greatly benefit from showing your stakeholders what you’ve done and how you’re progressing, with demonstrations and reviews.

⁴ Mary and Tom Poppendieck, Lean Software Development, Addison-Wesley Professional, 2003, http://amzn.com/0321150783.

Back to the criticism of Ken Schwaber that we started this section with. He could be right, but it doesn’t have to be that way. Make sure you take time for reviews, retrospectives, and other good practices. But do them when it’s the right moment, not because a certain amount of time has passed or when the iteration is over. Do it when needed—just in time rather than just in case. We talk about this in the chapter on planning (chapter 9), where we describe cadences.

Finally, using WIP limits will drive you to collaboration, and you might also end up with “slack ... to rest and be creative” from time to time.

12.1.1. Creating cadences for celebration

To fight the risk that your process is just “work, work, work,” you could and should have a cadence for celebration. It’s as important as other events that we’ve talked about, and it’s a great way to boost morale and team enjoyment. Cadences for celebration can take many forms, and there’s often no shortage of creativity when it comes to inventing new ways to celebrate. In this section, we’ll introduce you to two ways of having celebration cadences as part of your process.

Frequent flyer miles

With frequent flyer miles, the team can collect points for the work they’re doing. They can then use points to do something fun together. The points work much like an airline’s frequent flyer miles—after you travel a certain number of miles, the airline gives you some points to spend on free trips, upgraded hotel rooms, or other perks.

The team and the stakeholder come up with some way to track the points earned by the team and decide what to do when the team reaches a certain point threshold. For example, when you’ve completed 50 story points or 20 work items, you have a pizza and gaming evening at the office.

We’ve also seen teams working this in layers, which allows the team to save points for even greater rewards. For example, you can have the pizza and gaming night at the office at 50 points, or you can save up points for the next level, 100 points. That’s when the stakeholder takes the team out on the town for laser tag, dinner at a nice restaurant, and so on.

Warning

We should probably mention here that it’s possible to go overboard with the rewards. Dan Pink talks about this in his book Drive: The Surprising Truth about What Motivates Us (Riverhead Books, 2011, www.danpink.com/books/drive). Pink cites several studies indicating that for knowledge work, the result has a tendency to get worse if you pay more, give higher bonuses, and so on.

Use the perks and celebrations we suggest here as a way to have a good time with your team. Don’t let them be the only reason that people are doing work for you. Read more about that in Drive.^[5]

⁵ Spoiler alert: autonomy, mastery, and purpose drive us—not more money, nor pizza and beers for that matter.

Working to the cake limit

Another way to create a cadence for celebration is to have a WIP limit on the final column of the board. It confused us at first when we saw that on a board at Spotify, but as the team^[6] explained the concept, it made great sense. It’s also a nice way to extend the use of the mechanisms in kanban to this area.

⁶ The team at Spotify quickly understood the mechanics of kanban and used it to introduce a pull mechanism for celebration. Creative and fun!

The WIP limit on Done limits the number of items you can put in that column. Let’s say you set the limit at 15 items. That means after you’ve filled the Done column with 15 items, you can’t finish any more items. You’re up to your WIP limit for Done. Not only that, but work also starts to back up in the workflow (because nothing can move forward), creating an increasing urgency to clear the Done column.

The only way to clear the Done column is for the stakeholder to bring cake^[7] and thank the team for work well done. It’s both brilliant and fun, and it shows the principles of queues and bottlenecks in a nice way.

⁷ Or something else that the team enjoys and is allowed to eat and drink during working hours.

Let’s continue on to another criticism about the flow that’s the heart of kanban. In short: there are no timeboxes in kanban, but you can add them if you see the need.

12.2. Timeboxing is good for you

Timeboxing is a powerful technique that helps you maintain focus and make the necessary decisions to deliver the right things on time. The following triangle is one way to show what timeboxing is all about. It illustrates the trade-offs you have to make in any project, but in particular for software projects (sometimes called the iron triangle or triple constraints).

This triangle balances scope, time, and cost against each other. Scope refers to the scope of the features someone wants. Cost is how much money it will cost—for example, how many people are on the team and which hardware/software is needed to build it, and other costs. Time represents how long the endeavor will take, or the due date when the project needs to be done.

In the middle of the triangle is a fourth^[8] aspect: quality. You can take quality into consideration and make trade-offs with it. More often than not, that creates problems afterward in the form of technical debt that needs to be paid off. We don’t often recommend trading with quality but rather suggest trying to make the quality as good as possible, considering the other aspects.

⁸ Yes, fourth. In a triangle. Stay with us.

Back to the triangle. The crux of it is, you can’t fix all three of these aspects. Actually, you could, but you’ll see later why that would be considered bad. For the sake of argument, let’s say that you agree that you can’t fix time, scope, and cost.

What are your options, then?

• You can fix time and scope and let the cost vary. “We’ll be done with this exact feature at 0900 on 14 May, but it’s going to cost us.” Most companies and stakeholders don’t like that setup. And for the most part, it’s very hard to make software development projects go faster by throwing more people^[9] on the team. Typing code isn’t the biggest constraint in software development; learning and understanding are.^[10]

  ⁹ “Nine women don’t give birth to a child in a month” is something that a witty colleague has often said to Marcus to get the message across.

  ¹⁰ If you need more evidence for that, just ask anyone involved in a project if it would proceed more quickly if they got the opportunity to do it all over again. They will most likely say, “Yes, of course.” Then ask them why. What made you go slower the first time around?

• Let’s fix scope and cost instead and let time vary. “We’ll have this exact list of features ready, and it will cost $47,343, but we don’t know when we’ll be done.” This is also something that most companies shy away from—it’s often worse than letting the cost vary. Companies want some sort of predictability, and saying, “We don’t know when we’ll be done” is more uncertainty than most organizations can cope with. Another (possibly bigger) problem with this approach is that it assumes that you can know the scope before starting something and that there will be no new discoveries. For these reasons, “fixed scope” is rarely really fixed anyway.
• That leaves fixing cost and time and letting scope vary. “We’ll be done at 0900 on May 12, and that will cost you the salary for these six guys during that time. But we don’t know what will be done by then.” Although that sounds scary at first, this is actually a business opportunity. It gives you the chance to order the list of items you want the team to do in business-value order, doing the most valuable ones first. Or if the business values are hard to see or know, you can sort the list of items to do in order of how much you can learn or how much risk you can reduce. With a quick estimate, the team could probably guess how far they would get.

The last approach is known as timeboxing—fixing the time (and cost) for when things are to be done and adjusting the scope accordingly.

Let’s get back to the critique about kanban and timeboxes. By now you can see the good things that timeboxes bring with them. The main thing is that they provide a constraint that you take on that makes sure you prioritize and do the most important stuff first.

In iteration-based processes like Scrum and XP, natural timeboxes are built into the process. In Scrum, they’re called sprints: timeboxed iterations for which the team takes on the top features in the product backlog. The time and cost are set beforehand, and the scope the team takes on is ordered in business value. If the team fails, the least valuable features are the ones that don’t get done during the sprint.

A flow-based process like kanban doesn’t have timeboxes built into it. It’s just a flow, right? It’s a long, never-ending river of work coming toward you. Well, it doesn’t have to be like that. You can create timeboxes of your own, for single work items, sets of work items, or columns in your process, for example.

Using deadline dates on your work-item cards, SLAs, and different classes of service (see chapter 8) is a way of making sure you get some constraints into your system. That, in turn, helps you focus on getting the right things done first.

Iterations and timeboxes encourage you to trim the tail of how much work you can squeeze into the iteration. This can be helpful and beneficial because it may nudge you into splitting big work items in two and pushing the second part to the next iteration. When you’re done with the first part of the work item, you may find that the second part wasn’t really needed.

When you, in a flow-based process, focus on individual items, you’re instead trimming off the tail of each story in the same way. You might move an advanced feature (like a nice drop-down box for selection, for example) into a work item of its own and use a text box with the numerical value instead. And lo and behold—perhaps your users are advanced enough that they like entering the numerical value better, and it turns out to be even quicker for them.

We’ve now tackled two criticisms that often come up around the way flow-based processes behave. Another one relates to the subtle and non-intrusive way that kanban can be introduced. Can that really be criticized? Yes, as you’ll find out in the next section.

12.3. The necessary revolution

Kanban is great because it starts where you are. You can begin using kanban without changing a thing. Merely visualize the way you work and limit the number of items going on at the same time. From that, you can improve and evolve your process as you learn more.

This is good news because it means you easily can introduce kanban into almost any environment, regardless of the process you’re working with today. There’s no big bang, no changing of titles and roles—you can keep working as you used to. The visualization part is something that even the most avid opponents of new ways of working can often live with, as long as you keep it aligned with the ways you work now.

In short, kanban can be introduced as an evolution, avoiding painful revolutionary changes. By now, you may wonder how on Earth this can be a criticism of kanban. It’s easy to see, in fact: it turns out that sometimes you need a revolution. Sometimes you need to shake things up and get your organization to wake up. In order to survive or take advantage of new business opportunities, you might have to change a lot, and change fast. If that’s the case, then you should probably go with a tried-and-tested method (like Scrum or XP) and then add the kanban principles on top of that to drive improvement. You can think of it in terms of risk assessment: a small, malleable team, with a willingness to try something new and a great coach nearby, can probably take a lot of change without risking too much. On the other hand, if you’re a Cobol team in a big, conservative bank organization, the risk of changing is greater.

The great news here is that you’re in control of the tempo at which you improve with kanban. With more aggressive, lower WIP limits, for example, more improvement opportunities will present themselves. Putting stuff out in production earlier and more often will provide feedback faster and thereby give you even more reasons to change and improve. If you end up with too many problems to improve on at the same time, you can always push back from your WIP limits again and handle the biggest issue first, as normal. (Read more about how to control the WIP limits in chapter 6.)

You can add practices from other methods for your needs, as you see fit. For example, pick up some practices from XP, like pair programming or test-driven development, to get a handle on your code quality. Or you might start looking into impact mapping and specification by example to get a grip on the early stages of your feature’s life and a make sure you’re building the right thing. In recent years, continuous delivery and the ideas behind Lean startup have become popular. These methods focus on shortening the feedback loops in your process so you can get feedback on your new features more quickly. The principles of kanban can be of great use here to help you visualize and track the quick flow of your features.

In short, you’re in control of your process improvement’s speed and reach. Make sure you improve at the speed that you and your organization can handle. But don’t go too slowly: sometimes you need a revolution.

Speaking of too slowly: for some teams, kanban can become an excuse to stop doing the good practices that were already in place. That’s the topic of the next section.

12.4. Don’t allow kanban to become an excuse to be lazy

Some teams that start “doing” kanban stop doing the good practices that some other method has given them, such as standups, retrospectives, and reviews. We often hear stuff like “We used to plan our work, but now, with kanban, we’ve stopped that.” Other teams are the opposite and don’t begin with agile practices in the first place. “Scrum doesn’t work for us! We tried a planning meeting yesterday, and it was boring. Instead we’ll do the new thing called kanban. It’s simply a standup (we might remove it later) and some stickies on a wall. That’s enough for us.”

These teams miss out on one important aspect. We’ll let you in on a secret, this late in the book.^[11] Lean in real close to the page. There. Here we go: you can’t do kanban. Once again, a bit louder: you can’t do kanban.

¹¹ Well, we already said this, actually. In chapter 2, we said that kanban isn’t a process like others, but rather a meta-process that you can apply to other processes you’re already running.

Yes, you read that right. You can’t “run kanban” at your company. You can’t even “switch from Scrum to kanban.” What you can do, and get a lot out of, is apply the kanban principles to your process. Kanban can be said to be a meta-process—an improvement process for processes.

If your head spins because of that sentence, don’t feel bad. It’s like that for all of us,^[12] at least in the beginning. But this is actually great news, because it means you can apply kanban to whatever method you’re working with today and improve from there.

¹² Except for Torbjörn Gyllebring (@drunkcod), who has made a name for himself by going around explaining that “kanban isn’t your process” to the kanban community.

Back to the teams that stop doing other stuff because they have “started doing kanban instead”: kanban says nothing about stopping practices that help move work through your workflow or that improve the quality of the process you’re working on. After doing kanban for a while, you may end up questioning your current practices and begin wondering whether they really provide value. But until then, keep doing them as if nothing has changed. Because it hasn’t. You’ve just started your improvement journey with kanban.

Until you find good reason to stop, keep doing the following: retrospectives, reviews, and sprints (with a planning session at the beginning and a review at the end). Keep writing lengthy specifications documents and handing them over in the next phase in your process.

Kanban will soon show you what’s slowing down your flow. On your visualized workflow (on the board, for example), you can see when work items are stacking up. Your metrics and diagrams may help you see where the process is slowed down. These things may eventually lead you to start questioning the way you write specifications, handoffs, sprints, and so on.

One of the things that we’ve seen many kanban teams run into is not using WIP limits. You’d think that most teams would think about that (because it’s one of only three principles), but it happens a lot. Here’s a very common scenario that many teams end up with when introducing kanban into their process:

A lot of teams start using kanban principles without any WIP limits. This is a mistake, in our opinion. With no WIP limits, there’s no tension to drive you to improve your process. You can just keep adding work in process when problems arise. Often this manifests as a lot of blocked or waiting work items on the board.

You can liken this to an iteration that can be extended indefinitely. There’s no incentive to complete the scope for the iteration on time—you can always extend the scope.

Remember the true nature of a WIP limit: it’s not a rule, but a guideline and a discussion trigger. Without it, there’s no reason to have the discussion. You just keep adding work to your process, and there’s no mechanism to ask whether you should do this or not.

One common reason that WIP limits are never introduced is that it may seem daunting to come up with the “correct” number for the WIP limit. Chapter 6 contains a number of suggestions for this. One that’s really easy to get started with is called “Drop down and give me 20” (see section 6.3.3). You basically pick a large number and then drop the WIP limit (allowed number of work items) gradually until you start running into problems. Then ease back a bit on the WIP limit and start doing something about your problems.

Finally, remember that there isn’t a correct WIP limit. The WIP limit is just a tool you control that helps you drive improvements. Without it—no reason to improve.

Don’t let kanban become an excuse to stop your good practices. Kanban should help you improve your process, not make it worse.

12.5. Summary

In this chapter, we took a look at some pitfalls and at the criticism that’s been raised about kanban. We also showed how you can avoid falling into those traps:

• Kanban can end up just being a long flow of work that seems never-ending—it’s just work, work, work. Make sure that doesn’t happen to you by adding cadences for reviews, retrospectives, and planning as needed.
• No timeboxing is suggested when using kanban, which can remove the constraint you need to finish stuff and make trade-offs to do so. To tackle this, add timeboxes to individual items; use deadlines/due dates or SLAs.
• Kanban is great because it starts where you are: you don’t have to change a thing about how you work to get started with kanban. But sometimes you need a revolution:
  • Nothing is hindering you from taking on new roles or ways of working.
  • You can also control the tempo at which you improve by limiting WIP, more or less. Less WIP means more opportunities to improve.
• Kanban is a meta-process—an improvement process for an already-existing process. Don’t remove things that work today merely because kanban doesn’t say anything about them.
• The number-one mistake when starting with kanban is to begin without any WIP limits. This means there’s no constraint pushing you to improve.