The book Kanban in Action by Marcus Hammarberg and Joakim Sundén is a practical introduction for using kanban to manage work. It provides ideas for applying kanban to visualize work and track progress, to limit work in process, and on how to use metrics for improvement. It also provides games and exercises to learn the kanban principles.
You can download a sample of Kanban in Action to get a first impression of this book.
Manning Publications has a special offer for InfoQ readers "Save 40% on all items in your cart when you purchase Kanban in Action. Just enter kanban40infoq in the Promotional Code box when you check out. Only at manning.com".
InfoQ interviewed Marcus and Joakim about storytelling as a way to learn kanban, the relationship between kanban and lean, using kanban boards, and estimation and planning with kanban.
InfoQ: Why did you write this book? What makes it different from other kanban books?
Marcus: Funny story in fact. Manning asked me to call them and I was under the impression that they were writing a book on Kanban. So I was very relaxed, since I was only part of a survey. Their first question was: "What do you think should go into a book on kanban?" and I said something like this:
The bible of kanban books is already written in the "KANBAN - Successful Evolutionary Change For Your Technology Business" book by the man that took kanban into the software development world - David J Andersson. There's no way a new book can compete with that, unless you would take a completely different approach. The book I would love to see is a book that starts with and focus on the practical, common, everyday questions and just gives you enough theory. A "kanban for the rest of us" kind of book, if you will.
After 45 minutes conversation about such kind of book Manning just said: So - you want to write that for us, then?
I was dumbstruck and think that I said Yes, but I'm not sure.
(I still don't know why they called me. I think they have the wrong number, but I'm not telling :) )
My next thought was that I wanted to write this together with Joakim since we had been working so close around kanban the last couple of years before we wrote the book.
Joakim: Marcus is too humble. We had created an extensive tutorial on kanban that we had presented at several conferences, in formats ranging from short lectures to a full day's workshop. We had developed the material for years and tested it on hundreds of people. Marcus had also written a lot about kanban on his quite popular blog so it's no great wonder Manning contacted him. And given the hours we spent developing and delivering the content together I guess it was natural for Marcus to involve me early in the process. I'm very glad he did, a book felt like a very good way to summarize all we had learned together. We thought it would be enough material for 200-250 pages. We ended up with 360 pages…
InfoQ: Your book starts with a story of a teams in distress. What made you take this approach?
Marcus: Both me and Joakim are fans of the storytelling approach in some of the great books we've read, such as The Goal by Eliyahu Goldratt, and we wanted to try that kind of writing. Also, it was a great vehicle for us to keep true to our ideas with the book; staying practical and just add "enough" theory. That's why there's a ticking clock for the coaching session we follow in the beginning. They don't have time to go into every detail, but just enough to get you started and know what to look for. The real learning starts after that as the team will solve the "unrealized improvement opportunities" (aka problems) to improve their flow.
Joakim: We had a lot of fun writing the chapter and it's filled with small jokes including some that probably no one besides us two understand. From time to time we worried that while the approach was great fun for us, our humor and novelist skills maybe wouldn't be as appreciated by our readers. To get some feedback we included a question in the review rounds and also asked some of our friends and colleagues to read it. A couple of the reviewers didn't like it but several of them really loved the approach. In the end it was an easy decision to keep it but just in case we made sure you don't have to read the chapter to understand the following ones and included a disclaimer before the chapter. :)
InfoQ: At several points in the book there are references to lean. How do kanban and lean relate to each other?
Joakim: Kanban is a scheduling system used in lean production. It was developed at Toyota as a way to improve production by challenging people to continuously improve the Just-in-Time flow of goods and services while avoiding overburdening of the system and the workers. This was achieved mainly through limiting WIP, visualization and managing flow. Very much like kanban in software development. Kanban is only a part of Lean but it embodies some of the most important principles of Lean just like Scrum is only a part of Agile.
I like to think of Lean and Agile as born of the same spirit but first implemented in different contexts (car manufacturing vs. software development).
Marcus: Hmmm ... I think this one is hard to answer, I think. Because they go together I think. Kanban is a tool used by many lean practitioners and team. Lean is business strategy that focuses on flowing work through your process as smooth and fast as possible. You could do lean without kanban and use kanban without lean... but most don't. They go together.
For me personally kanban was the thing that made me start to read and learn about lean.
InfoQ: Can you describe to the InfoQ readers how a kanban board can look?
Marcus: It's very much up to you, and so it should be since a board is just a visualization of your current, actual process or workflow. Typically it's a sequence of columns showing where value is added to a work item as it flows from the left to the right. Although we've seen other variants too, like work flowing top to bottom, "swimlanes", spiral (!) boards, switches in boards to several lanes/or even boards, and so on, most boards use the columns approach.
You want to show the actual process and not the one that you're dreaming of or have in your official document. You want to stay as close to reality as possible.
It’s generally a good idea to try to take as much as possible, of your entire process into consideration, even if some of the steps are performed by third party teams or stakeholders. In our story the Kanbaneros team works at a place where the deployment of the code is done by a separate team. The Kanbaneros still decides to show this as a column on their board, to show the work they have waiting there. Maybe that can trigger a discussion that will help improve the overall process.
Oh, and finally, draw it with a marker on a whiteboard so that you can change it easily. And often. Because the board is also just "best so far". We're aiming to improve our process and our visualizations of it.
InfoQ: Where does a kanban board differ from a scrum board. Why do they differ?
Marcus: The main difference is that typically a scrum board is reset before each sprint. At the start of the sprint you add all the work, that you aim to complete during the sprint, into the first column (Todo). During the sprint the work flows over the board and ends up in the final column (Completed, Done or what have you). Then you start over for the next sprint.
Kanban doesn't dictate sprints so typically it's more like a continuous flow of work where we just add new work in the first column as there is room on the board (according to our work in process or WIP limits) on it.
Other things that might differ (but doesn't have to) are:
Kanban boards tends to have more columns, detailing the process. Many Scrum team runs with Todo, Doing, Done with the names and detail their process in the tasks for each work item.
Kanban boards typically have some kind of Work in Process limit. It could be numbers limiting the number of items in a column or for the entire board etc. This is present in Scrum teams as well, if in no other way so by the fact that the team only pulls in as much work as they seem appropriate for the next sprint.
In my experience kanban boards tend to change more frequently, where Scrum boards tend to stay the same. Its just my experience and is certainly nothing that Scrum says that you cannot do. But maybe how we teach Scrum. I have had clients saying, after attending a Scrum master course: "Scrum doesn't work for us. We cannot use Todo, Doing, Done. And my teacher said that it's how Scrum boards look". No! You decide how it looks.
Joakim: I want to emphasize that these are the differences we commonly see between teams that say “we’re doing Scrum” and teams that say “we’re doing kanban” We view kanban as a kind of meta-process that you can apply to whatever you’re doing, so the “correct” way of describing it would probably be “we do Scrum with kanban” or “we started out doing Scrum, started using kanban too and now we’ve substituted continuous Just-in-Time planning for sprint planning so I guess we can’t really say we’re doing Scrum anymore”. It’s no problem combining them but in my experience it’s highly unlikely that a Scrum team that has embraced kanban keeps doing Scrum “by the book”; the continuous improvement and pragmatism inherent in kanban will lead them to customize their process.
InfoQ: What are the main differences between physical and electronic kanban boards. Are there ways to combine them?
Marcus: This is a trick question, right? One is physical and the other ...
In fact this is one of the most common questions we get when talking about kanban. To me there are two important differences:
with a physical board you can touch the work and it's more present in the room than a tab in a browser. Even the times we have gone through the trouble of putting up a big screen I still "felt" the physical, full wall board in another way.
Every tool have it's limitations. A physical board has fewer limitations on what and how you can visualize your work. Even though I have to say that some of the more modern tools (LeanKit Kanban for example http://leankit.com/, no association) is allowing for a lot of customizations they will always have limits.
That said; with an electronical board a lot of data and statistics is created without any effort and the policies you implement are easier to make sure that everyone follow (you simply cannot drag a card into a column where you violate a principle for example).
Our suggestion is often that you start on a physical board and when you feel comfortable with that move over to an electronic board. Use the tool and don't let the tool use you.
Joakim: I like to use both. Physical ones because they are easier to continuously improve, they radiate information and they encourage collaboration; digital ones because they can accommodate distributed teams and stakeholders and they make it easy to collect metrics. Some people think it’s too tedious to maintain both a physical and a digital board. I like to think it’s because developers are too hung up on the DRY principle (Don’t Repeat Yourself) and go to great lengths to only have a single source of information. (And maybe, just maybe, because they usually shy away from “administrative” tasks…) But if you consider what they really are and which problem you want to solve you may often realize that they serve different purposes. To me a physical board can be used to foster collaboration encourage face-to-face communication and breed accountability in a team. Spending a few minutes a day on duplicating a few sentences is a pretty small price to pay for that. There is really no reason for exact duplication by the way; only use the information needed to support the purpose for each tool - maybe you only need high-level work items for one and low-level tasks for the other?
InfoQ: Can you name some things that teams can do to limit their work in progress and increase their throughput? How can they use WIP to support this?
Marcus: This is a very common question and we have, therefore, devoted an entire chapter on this in the book (chapter 6). The most important thing to remember about WIP limits, I think, is that there is no right answer. The WIP limits are just a tool that you can use to help you improve your flow. The lower the WIP limit the faster the flow so a lower WIP limit is generally better. But, with a lower WIP limits any problems in your process will also surface faster. This is a message of hope: you will get problems! Or "unrealized improvement opportunities" as we call them. Rightly so, because if you do something about them your process will run faster and smoother.
Now, what can you do then?
Some team have a WIP limit for the entire board, but the cards can be anywhere on the board. The lower your WIP limit the more collaboration and faster flow you end up with. With WIP limit of 4 for a 5 person team collaboration is the only way, if not one person is to be idle (not that there’s anything wrong with being idle… slack is needed to give room for improvements...)
Most common maybe is to have a WIP limit for one or more columns / steps in our process so that we make sure not to overload a certain step. Maybe we only have one tester. In order to make sure that the work flows steadily for him we set a suitable WIP limit for him. 3 items maybe, or 2. When his column is full work will back up and others get a clear signal that there’s a bottleneck situation they should help with instead of keep overburdening the poor tester.
Other things that are common is to only allow a certain number of avatars for each person and no cards without any avatar attached. This makes sure that no one person is taking on too much work.
Joakim: Above all you have to learn to stop starting and start finishing. This is simple but also complicated because it means you have to say no, not only to others but also to yourself. It’s so easy to just pick something new up as soon as you run into a blocker or have to wait for someone. Try to instead spend some time on understanding how to avoid being blocked in the future or even how to unblock yourself now.
InfoQ: Swarming is a technique that can be used to deal with blockers. Can you elaborate on that?
Marcus: Swarming is modeled from the (in)famous Andon cord found in many Lean factories around the world. Basically it means that if you run into a problem that is blocking your progress, you pull the cord and people will come running to help you to clear the blockage.
In most (read: all) software development teams I've seen there's no cord, but rather if you're blocked you just call everyone in the team to help. There's no cord, but the idea is basically the same.
In essence we take problems that hinders our flow so serious that we leave everything else and help to alleviate the blockage. This is a great advice since not only will the item continued to be blocked, but also a bottleneck will be created and work will start to back up through the process, if we don't do anything about our blockages. By waiting, more WIP is created.
Finally, if you're really serious about improving, all these events should be analyzed and retrospected so that you can learn from it. Why did this happen? How can we stop this from happening again? A 5 Whys exercise is a very good tool for these kind of retrospectives.
InfoQ: Your book describes several estimation techniques that you can use with kanban. Can you describe some of them?
Marcus: The techniques we describe in chapter 9 is all about relative estimating where you just contrast the effort of completing one item against the rest of the items you have done all ready. Quite often these sizes are given a name or number (S, M, L or 1,2,3,5,8,13).
Planning poker is probably the most well known of them. This is a wisdom-of-the-crowd-technique were you basically talk about an item and then each person makes up their mind of an estimate and then show their choice at the count of three. If we're in agreement we proceed to the next item. If the estimates differ we talk some more until we are in agreement.
The fastest technique I've used we called "A line of card". Basically you just put one of the work items you're estimating on the table. Then take the next one and ask the team: Is this bigger or smaller? If it's bigger you place it above, smaller below the item on the table. You continue through the items you need to estimate asking the question for each one. After a while you have created a line of cards in estimated size order. Now you could assign sizes to different groups and get a nice overview of the estimated size for all work estimated.
Goldilocks is an interesting technique because it's basically doing the opposite of estimating. We shape the work into the sizes we want. Create 3 piles "Too big", "Just right" and "Too small". Have the team vote for all the items where it should belong. For all the items that ends up in "Too big" split them into "Just right"-sized ones. For the items in "Too small" - group together into "Just right".
InfoQ: You stated that "in time the need for planning becomes less when using kanban". Can you explain why?
Marcus: We're proud to be the first book that have any written content around #noEstimates. In the estimation-chapter. Nothing strange. The idea behind #noEstimates is to try to find ways to do software development so that estimates are not needed. For example, if you have really short lead times (max a couple of days in some teams I've coached), business people tend to think that estimates are not needed that much. A mere "it's about the size of the reporting work we did last week" often suffice.
And if you think back; how often have an end customer (not the business requirement guy, or the project manager) but the end customer called into the office and thank you all for the accurate estimates? Or great specification? Or all the meetings you attended?
All of these are just how our process works now. From the customers point-of view they are waste (btw, if they are not waste they are value. So do more of it then!) and we should instead try to maximize our output. Maybe we could do with less estimation work? Let's try for awhile and see?
Joakim: Kanban tends to drive teams to make items smaller and more evenly sized as this allow them to flow more evenly through a workflow. Combined with the popularity (in the kanban community) of tracking lead times for work items and built-in support in some tools for forecasting and simulations (e.g. LeanKit Kanban) this makes it easier to get good forecasting based on historic data.
Breaking up big planning meetings where items are worked through in batches and replacing them with continuous Just-in-Time planning of individual items can shorten the planning. Doing this can also make it easier to customize planning for different contexts and groups and make the planning feel less disruptive.
InfoQ: Every method has some pitfalls or issues. What about Kanban? How can you deal with them?
Marcus: Kanban is flawless! :)
Seriously - as we said in the beginning; kanban is a process improvement tool. It's just a couple of very simple principles. The "pitfall" is that you will have to act on the problems that are hindering you to improve. Committing to improving from our current state is hard work and takes courage and diligence. Not all organizations are willing to do that. Not when kanban starts to question our firmest hold beliefs or "how we always have done business here".
I cannot count the number of times I have been in or coached teams that stops doing retrospectives, stops following WIP limits or even stop using the visualizations tool we created. This is because it's hard work to improve all the time. You need a good reason to do so.
Joakim: Yeah, sometimes kanban seems to be used as a way out for teams that don’t want to put in the time and effort needed to get methods such as Scrum or XP to work for you. “Let’s keep the stickies on the wall call it kanban and be done with it.” Without other good practices kanban can leave you a bit clueless about how you should improve so make sure to not stop with visualization and WIP limits, check out other methods and practices too. This is basically the reason why we added the whole part of “advanced kanban” in the book.
About the Book Authors
Marcus Hammarberg Get agile to work in practice - is his motto. This had led him to take interest in all kind of things: Lean, TDD, Kanban, Specification by example, Node, Continuous Deliver, NancyFx and Koa. Right now he’s off the Software Development track a few years and works for the Salvation Army in Indonesia trying to help their hospitals to become more effective.
Joakim Sundén is an Agile Coach at Spotify, making music available and accessible to the world. He helps people improve through mentoring and coaching at individual, team and organizational levels, often using Agile and Lean thinking and methods such as Kanban, Scrum and XP. He is an organizer of, and active participant in, conferences, networks and user groups in the Agile and Lean communities. Joakim is also the author of “Kanban in Action” (Manning, 2014).
