Chapter 2. Kanban principles

This chapter covers

  • Introducing kanban principles
  • Getting you started using kanban
  • Defining what kanban is

In chapter 1, we introduced you to kanban through a short story. The purpose of this story was to show you, in a practical way, how kanban can be used to help you improve. We hope you already feel that you could use kanban now; but you probably have a few questions, too, such as

  • How did Marcus and Joakim come up with all those ideas? Did they pull them out of thin air, or was there some method to the madness?
  • That all sounded good, but my team and its situation don’t look much like the Kanbaneros; how can I use kanban in my team? What do I need to change?
  • Was that all? It seemed a little simplistic, didn’t it? How can we expand on this?

All of these questions and many more will be addressed throughout the rest of this book. In this chapter, we want to show you the principles that kanban is based on, by looking back on what we did with the Kanbaneros.

But fear not, this is not a lengthy theoretical write-up on everything kanban. If you really want to, you can always go directly to section 2.2 and skip the theory. We’ll still keep the theory part short and practical; this is a practical book focusing on practical needs. That’s why we’ll keep the theory to a minimum and serve it to you in bite-sized chunks as you need it. We’ll also give you a quick recipe in this chapter for how you can get up and running with kanban quickly.

You remember the Kanbaneros, don’t you? They will pop back into the text throughout the book to ask questions, challenge us, and present practical problems on your behalf. Here they are again:

Had we introduced another process, such as Scrum, XP, or even Rational Unified Process, the first chapter would have looked different. We would have focused on how the process should work, what to do and not to do, how long iterations or sprints are, what the tasks are for the Product Owner role, and so on.

Kanban isn’t like that. It doesn’t prescribe many things at all; it’s more like a meta-process that can be applied to whatever process you’re working with today. This is great news, because it means you can start where you are today, without changing anything, and improve from there. No new processes, no new roles, and no troublesome reorganizations needed.

Kanban, kanban, or kanban systems?

If you read the text closely, you might spot that we’re spelling kanban with a lowercase k in this book. The kanban community is continuously improving and evolving, so things change a lot. We have interpreted the current knowledge as follows:

  • The Kanban method (capital K)—A method to create evolutionary change in your organization, first formulated by David J. Anderson and documented in his book Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010, http://amzn.com/B008H1APT0).
  • Kanban (sometimes lowercase k, sometimes capital K)—Sometimes refers to a “visual process management system that tells what to produce, when to produce it, and how much to produce” (last time we checked Wikipedia anyway), sometimes to the actual visual signal.
  • Kanban system— The system that is set up to track the work in process. An example of this might be a kanban board, the cards, and the policies around your work. All of that is your kanban system.

In theory, these things have quite different meanings; but in practice, people in the community often don’t distinguish between them. What people typically refer to as “using kanban” is to use some sort of kanban system to manage and optimize kanbans (the visual signals) in order to evolutionarily improve. That is what we mean when we use the word kanban.

If that was confusing to you, don’t worry—you can read the book and make up your own mind about what kanban is, and we promise there won’t be a test at the end.

The Japanese connection

You should probably know something about the word kanban itself, if for no other reason than so that you can impress your friends with your knowledge of Japanese. Kanban is two Japanese words put together: kan, meaning visual, and ban, meaning card. Put together, it becomes something like “visual card” or “signaling card.”

Kanban as a concept comes from Toyota, where it was invented as a scheduling system for just-in-time manufacturing in the Toyota Production System (TPS). When researchers in the West studied TPS, they called it Lean Production System, later Lean Manufacturing and Lean Thinking.[a] Kanban has its origins in the principles of TPS and Lean, which is why you’ll find a lot of references to these concepts throughout this book and in most other texts about kanban for software development.

a John F. Krafcik, “Triumph of the lean production system,” Sloan Management Review 30, no. 1 (1988): 41–52. James P. Womack, Daniel T. Jones, and Daniel Roos, The Machine That Changed the World (Scribner, 1990, http://amzn.com/B001D1SRRS).

Although kanban doesn’t prescribe many concrete rules or practices, you still can improve greatly by using it. How can that be? At the heart of kanban are a few principles that can guide you on how to use kanban to improve. Let’s take a closer look at those principles.

2.1. The principles of kanban

Kanban is based on three simple principles:

When we got down to business with Team Kanbaneros, we started by visualizing their work. To start, this can be as simple as creating sticky notes that represent each work item and a visualized workflow in the shape of a board to track each item’s current status. This is a great way to get to know your work, learn how your “work works,”[1] and start seeing improvement opportunities in your workflow.

1 See John Seddon, Freedom from Command and Control: A Better Way to Make the Work Work (Vanguard Consulting Ltd, 2003, http://amzn.com/0954618300).

For many teams that we coach, this creates a big impact right away. Just making information visible that previously was not can help you solve a lot of problems by itself.

There are other underlying aspects of visualization as well, because you’re also starting to make implicit policies around the work explicit. That is, everybody might think they know how you work with a feature request; but by showing the workflow on the board in columns, the real process becomes apparent to everyone on the team. By doing this, you make any differences you might have on policies about work more evident. This can lead to a discussion that clarifies the policies you work from, and you can easily capture them on the visual board so that all team members approach the work in the same way.

With Team Kanbaneros, we went through some common ways of visualizing work: the board, the work items, and the expedite lane, for example. There is much more to know about this, and chapters 3 and 4 will take you through it in greater detail.

We continued with the Kanbaneros by playing a game called Pass the Pennies (see chapter 13 for more details on this and other games). This showed the principle of limiting work in process. Simply put, the principle states that you deliberately establish a limit for how many items you’ll work on at the same time. The first apparent gain from doing this is that with fewer items being worked on at the same time, each item will be done more quickly. Chapter 5 will explain the effects of work in process in depth.

But limiting work in process (WIP) is also important for other, subtler reasons. By establishing a WIP limit, you’ll create a little tension in your workflow; this is a Good Thing™, because it will expose problems in your system, or, as we put it to the Kanbaneros, “unrealized improvement opportunities.” You can read more about limiting WIP, the reasons for doing so, and how you can visualize these limits in chapter 6.

Limiting WIP will start surfacing improvement opportunities. Flow through the workflow will stall (stickies moving slowly over the board), start to back up (a lot of stickies in certain columns), or stop completely (items waiting). These are all indicators that you can improve your system. What you do to fix these problems will determine whether you improve.

But if you want to improve, you should know what the goal is, and this is where the last principle of kanban comes into play: manage flow quickly and without interruptions through the workflow.

This is the start of your journey to continuously improve the workflow. The bad news is that you’ll never be done with this task. Your workflow can always be improved; there’s always a bottleneck that slows you down.[2] The good news is that the problems will reveal themselves to you, visually, on the board. Not only that, but often the biggest problem will be revealed first—solve that, and you have made a big improvement to the flow through your workflow.

2 Well, when software—or rather, solutions—materialize instantly when you imagine them, we guess there are no more bottlenecks. It probably won’t happen any time soon, though.

Team Kanbaneros discovered several improvement opportunities, as you might remember from chapter 1:

  • They realized that the way deployment was done was hindering the flow severely. For the Kanbaneros, we could see this on the board with all those stickies in the Waiting for Ops column. You could say they already knew this, but now they have data constantly in their face, demanding action.
  • They talked briefly about bugs, which were handled differently than normal items. You could say that bugs are in a different class of work than the other items and maybe should be given precedence over other items in prioritization.
  • The Kanbaneros put WIP limits in place to help their work flow smoothly; for example, they queued up four items for acceptance so that Cesar and Beth didn’t have to run to the team several times every day. Instead they now have a reasonable amount of work to do, waiting for them when they come by the team.

Help the work to flow faster through the workflow. That doesn’t sound so hard, right? You can always find help in chapter 7, so by all means—make it happen!

There are a lot of things you can do to accomplish this. When working with this principle, you can find inspiration in Lean Thinking to help your work flow more smoothly by removing waste in your process. You can also take a look at the Theory of Constraints[3] and identify, exploit, and alleviate the bottlenecks in your system. Practices from the agile software development community movement might help you to improve collaboration and quality and thereby improve the flow of your system. It’s up to you which route you take to improve your system. The important thing is that you react to the signals that your work is sending you and improve on it.

3 Visit http://en.wikipedia.org/wiki/Theory_of_constraints to read about the Theory of Constraints (TOC).

In reality, you’ll see the principles combined with each other a lot. For example, in order to get a quicker flow, you limit WIP, which is also shown visually on the board.

With a visualized workflow, a limit for the WIP, and a focus on moving work through your workflow, you have set yourself up to easily spot improvement opportunities. How you go about doing that is pretty much up to you, but we won’t leave you high and dry. We have packed chapters 3–7 full of tips, practices, patterns, and common solutions to improve the flow in your workflow.

The search for improvements will soon take you outside the boundaries of your own team. In order for you to get a faster flow, you might have to interact with other teams or functions around you in a different manner. A first step toward this is to include teams or functions before and after yours on your board. Or maybe you could even have a board for all the teams in your department, aggregating the status of the teams there.

It could be the start of a transformation that can ultimately reach the entire company, in an evolutionary way. Soon you’ll find yourself teaching kanban to others and being involved in change management on an organization-wide scale. You can read about this in chapter 13.

Three principles? I thought it was five properties. Or was it six practices?

Kanban is fairly young as a methodology used in the software business. There’s a vibrant community, and new things are discovered and put into practice continuously. This is something good, and it’s very much in line with the principles of Lean and continuous-improvement thinking.

The three basic principles we describe in this section make up the foundation that kanban is based on. Recently, David J. Anderson and others have extended the three basic principles to five properties and later six practices; these are now referred to as the core practices.[a] They are as follows:

a See http://mng.bz/EkgB.

  1. Visualize— Described earlier.
  2. Limit work in process— Described earlier.
  3. Manage flow— Described earlier.
  4. Make process policies explicit— With explicit policies, you can start to have discussions around your process that are based on objective data instead of on what you think, feel, and have anecdotal evidence for.
  5. Implement feedback loops— This practice puts a focus on getting feedback from your process: for example, in what is called an operations review, which is a kind of retrospective for the process itself.
  6. Improve collaboratively, evolve experimentally (using models and the scientific method)—This practice encourages you to use models such as the Theory of Constraints or Lean to push your team toward further improvements.

That’s three more practices added to the principles we’ve talked about so far. Note that this holds true for the Kanban Method of “incremental, evolutionary change for technology development/operations organizations,” and in that context the last three practices are important.

As you probably have noticed already, we take a practical and pragmatic approach, and for us the last three practices fit nicely within the basic principles:

  • Make process policies explicit— Making policies explicit is what much of the visualization of work is about. As often as not, the important step might not be to write it on the board (although that’s important too), but rather to hold discussions that allow you to form consensus about the policy you intend to put in place. Although it’s great to make this ... umm ... explicit, we feel that it’s part of the principle of visualization.
  • Implement feedback loops—This is part of the “manage flow” step for us. In order to help the work to flow, feedback loops are essential and should be sought and implemented where needed.
  • Improve collaboratively, evolve experimentally (using models and the scientific method)— We wholeheartedly agree on the importance of this. But this mindset is so deeply rooted in the Lean principles that underlie kanban that we don’t think it’s a principle of kanban per se, but rather the environment and ecosystem that kanban springs from.

To further complicate things, David J. Anderson and others are now using “principles” to describe some other principles:

  • Start where you are.
  • Agree to pursue incremental, evolutionary change.
  • Initially, respect current roles, responsibilities, and job titles.

And recently a fourth principle was added:

  • Leadership at all levels in the organization.

During our time as kanban practitioners, the principles we talk about have become practices, the practices have gone from three to five to six, the term principles has been redefined, and a new principle has been added. We expect and hope that the discussion around these practices isn’t over. But from this sidebar, you now understand why we’re talking about three principles (visualize, limit work in process, and manage flow) when others are talking about five practices. Or was it six?

2.2. Get started right away

Just like the Kanbaneros, you can easily get started right away, due to the lightweight nature of kanban. In fact—why not start now?

It doesn’t take much, and you can start easily right where you are today. Just begin focusing on getting stuff done, really done, before picking up new work. Make that the motto for you and your team: stop starting; start finishing! This is a simple way to limit the work in process, but it can be effective.

If you want to be a little more concrete and practical, you can also do an exercise similar to the workshop we ran with the Kanbaneros in chapter 1. Here’s a short description of how that can be played out:

  1. Start by visualizing your work. We asked the team to create a sticky for each work item they worked on and place it anywhere on a whiteboard.
  2. Map your workflow to the board. A simple way to do this is to create a column for each stage in your workflow. Move the tickets that are in the different stages into the correct columns. At this stage, the Kanbaneros talked quite a lot about how the work worked, and that’s something good that increases your knowledge of the process. But resist the urge to optimize your workflow before you can see what’s going on. After this exercise, you might end up with a board like this:

    A Word from the Coach

    Make sure you draw the board together as a team. Don’t let one person do this by herself—especially not you, if you’re an external coach. The buy-in from the team will suffer greatly. Trust us; we’ve made that mistake far too many times already.

    A simple way to make this exercise a team effort is to pass the pen around as you draw the board.
  3. Make a couple of dry runs with some work that has passed through your workflow to see that the workflow actually matches the way you work. Change as needed. We didn’t have time to do this with the Kanbaneros, but we think it’s good practice, and it quickly shows you whether you got the workflow right. Remember, at this stage you’re aiming to track down how you actually work.
  4. Decide on a work-in-process limit—how many work items you, as a team, should be working on at the same time. We spent quite a lot of time here as we helped the Kanbaneros, but please don’t overthink it. It’s better to get something up there and improve as needed. For now, go with two work items per person in the team (six in our example), for example, and spread them evenly across all columns. Or get some good ideas in chapter 6, which is all about WIP limits.
  5. For extra measure, create some avatars—small pictures of yourselves—and attach them to the things you’re working on now. This will help you more easily see what’s going on and who to turn to if you have questions regarding one of the work items.

There—you now have a simple kanban board to improve on. But even this simple tool will help you to spot problems and continuously improve, in small steps. The rest of the book will help you learn how to do that.

2.3. Summary

Kanban is an approach to software development based on simple but powerful ideas. It aims to make the work flow fast through the whole value chain, from idea or concept to software in production, delighting your customers. The tools that make this happen are a few simple yet powerful principles: visualizing your work and policies, limiting the amount of work in progress, and helping the work to flow better through the process.

These tools can guide you to continuously improve your process to gain an even faster, smoother flow of work through that process. This is a never-ending quest that will help you and your team to improve, little by little, every day.

There—now you’re up and running. As your work progresses, move the items accordingly on the board. Take care of problems that are hindering your flow. When a problem occurs, stop and talk about it; these are your improvement opportunities! Don’t waste them; handle with care!

The rest of this book is packed with practical advice about visualizations, how to limit WIP, and different ways of helping your work to flow smoothly and quickly through your workflow. We have put a strong focus on practical matters to make sure you can use the practices, patterns, and tools we describe right away with your team.

Let’s jump right in and start looking at visualization—a subject that will get your creative juices going.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset