Today I attended a presentation for the German edition of the Kanban book by David Andersen at the Lehmann’s book store in Hamburg. My colleagues from it-agile, Henning Wolf and Arne Roock translated the English book to German. They gave an introduction to Kanban, and answered some questions from the roughly 100 attendees.

Henning Wolf and Arne Roock started the introduction with a play between an IT consultant and a CxO in IT. The two meet again after years, and exchange some thoughts. The CxO asks the consultant how they could get faster from the idea for something new to earning money from it. The consultant starts to explain Kanban and how he uses it for software development.

The consultant Arne explains to Henning that there are four main principles. First of all the workflow in the company is visualized. Arne introduces Henning to the Kanban board with several columns. Arne asks Henning about their different step sin the way they work. He starts to fill a Kanban board with several columns with the name of the process step as the header. In Henning’s company there are the steps ToDo, Analysis, Development, Test, and Live. The next step in the visualization of the workflow is to fill the board and columns with items on which the team is currently working. There are quite various items. From features, to stories, and even there are quite some bugs floating around.

When asked Henning explains that they currently use JIRA to track these items or tasks. Arne suggests to use a physical board in parallel to an online tool if he needs a computer tool at all. In order to track the items, index cards or sticky notes are usually fine. Arne explains that they fill up the Kanban board from the right to the left. They start with the tasks for the two testers in the team on the right. The testers are currently working on six tasks in parallel. On the column left the ten developers are currently busy with three tasks. Oh, and of course there are also some bugs, six in number. Finally, the two analysts are currently working on a single task. And of course there are lots of ideas floating in the ToDo column as well. Arne notices that Henning has a ratio of 50:50 for tasks in relation to bugs.

As a side note Arne explains that Kanban is Japanese for signal card. In the medieval these cards were used to indicate that someone has something to sell. They were placed outside the ironsmith house, and everyone knew that this shop was open. Toyota took the concept to indicate that a worker while manufacturing a car needs maybe 5000 screws. The card denotes what is needed, and is then passed to the workstation before the worker in question.

Continuing to get the initial Kanban board set up, Arne explains Little’s Law to Henning. Little’s Law says that the lead time for a system is the number of currently on-going work – that is work-in-progress – divided by the throughput to that system. Since Henning wants to reduce the lead time in order to get from concept to cash in less time, there are two factors which he can take influence on. On way is to maximize the throughput. Henning can achieve this by putting more people to the problem, or maybe by reading more management books. Henning claims that he already did that, and he has a gut feeling that the situation improved.

As a second option to reduce the lead time in the system, Arne explains that Henning may reduce the amount of currently on-going work. As Henning objects to this idea, Arne explains that this might sound counter-intuitive, but when he finishes one task first, and then starts to work on another one, he can make money with the first item sooner as if he works on both in parallel. Henning can take competitive advantage from the first finished item, and maybe for the second he has to wait for some new hardware, which is not yet available. Arne therefore suggests to put limits on each of the columns in their development cycle. Arne and Henning come up with the initial limits of three for analysis, fourteen for development and three for the test activities. Arne explains that this limits the system to overall 20 tasks in progress at one time. Arne also hints to the broken limit in the test column, where currently six items are in progress, but a limit of three is suggested. Over time the testers will finish some of the tasks, and re-ensure the work-in-progress there.

After a while Henning and Arne meet again. Henning explains to Arne that they put the board in place, but now have a problem. The testers finished some of their cards, and hit the work-in-progress limit, but the developers also finished some of their activities on bugs. They moved the tasks from the development column to the test column, and broke the limit again. Arne notices that he might have forgotten a point to explain to Henning. While the second point in the Kanban system is to limit the work-in-progress (which they seem to have forgotten), the third major principle in Kanban is the pull principle.

While Henning may be used to push the work into the development system, in Kanban the pull principle brings benefits. In the Toyota environment on each card the worker denotes what he needs, how much of it, and when he needs it. For example, the worker in need for new screws will send out a card just-in-time before running out of screws. He will tell upstream processes that he needs maybe 5000 screws within the next hour, and then continue working. Likewise in software Kanban tasks are asked for when workers are ready to take on another task. This is called the pull principle.

But there is a problem. Where do you place the cards that are finished when they are finished, Henning asks. Arne explains that there are several ways to distinguish in-progress work from partially finished work in one column. Since he also wants to make this visual, dividing up each column into a sub-column doing, and another sub-column done is one way to do this. Another option is to indicate finished tasks per column with a colored-dot, or to simply turn the card by 90 degrees.

Arne warns Henning that pull principle does not start with demanding it. For example, “just be spontaneous” doesn’t work that way either. The pull principle needs trust in order to work. Arne explains that team members are happy to do something, and they want to have a feeling of achievement. When doubted by Henning, Arne explains that this does not equal a request programme. Self-organisation means that the team works on the tasks at hand. And in case there are work-avoiders in his workplace, they will also find their way to avoid work in any other system. The next task is usually taken based upon a team rule.

Usually Kanban teams use a FIFO rule. The task that first got into the system is taken first from the upstream process. This implicates that when starting a task for the first time a starting date is denoted on it. Another option for a team rule could include to handle bugs before any new developed feature, or to handle the cards based on their overall business value. This raises the question how to measure the success of the pull principle. Arne does not have numbers, but based on his feeling pull systems are successful more often than other systems.

Henning notices that a pull principle may lead to the problem that developers may not take on new work, as their column hit the limit. Arne explains that Kanban makes this problem transparent. When developers can not take on new work, they are stuck by a possible bottleneck in the system. What each company does with this transparency is different. The team’s primary priority then should become to re-establish the workflow again. One way to do this could be to have developers help testers out with some of their tickets. Maybe developers can help the testers by automating some of their manual work, or the idle developers could seek opportunities to improve the process overall. The Theory Of Constraints teaches that a system is constrained by its lowest bottleneck or constraint. Up to this point throughput can be achieved, but no more – unless the system can be changed, i.e. having developers help testers out.

After two weeks Arne and Henning meet for the third time. Henning claims that they are finished with Kanban. He is happy to state that they put everything in place that Arne and he discussed. By shifting two developers from development to test, they changed the system, and re-adjusted the limits. Now they got a limit 10 for their eight developers, and a limit of five for their four testers. Arne is suspicious about Henning’s claim to have finished Kanban. He asks what their current throughput through the system is. Henning explains that they got from initially 60 days – numbers taken out of JIRA from the previous work – down to 10 days per ticket which is quite impressive. Arne challenges the 10 days, and asks what Henning needs to get down to 8 days, or even lower.

Arne thereby introduces the fourth principle of Kanban, which is called Kaizen. Kaizen means to take tiny steps in order to move forward. This implicates that there is no “finished” for Kanban. A working Kanban system is context-dependent. A system that is working for one team may even fail for another team (or even another time). Henning find this trying.

Arne explains the two principles of Kaizen. First the team applies a measure to the work. For example for each ticket a starting and ending date is denoted. If the measures their throughput with 15 days, then he would raise the question how to reduce it even further down to 12 days maybe. Of course, principles like garbage-in, garbage-out also hold for Kanban. But the team is asked what it needs to do in order to reduce the time a ticket takes to get through the system.

The second principle of Kaizen is to reflect. This is done in two ways. First, there is a daily stand-up meeting. Similar to the stand-ups in Scrum, this may be organized by going through each person, answering the three questions. Alternatively the team can go over each ticket and raise the question what does it take to get this to the next column. Arne also likes to indicate blocking point on each card using red sticky notes. On the red stickies he denotes the reason for that card being blocked, and how they overcame this. The second way to reflect in Kaizen is the retrospective. On a regular basis the team gets together to think about ways to improve their process.

At this point Henning and Arne conclude there play for the introduction to Kanban, and introduce the German translation of David Anderson’s Kanban book. The German translation has one additional chapter with a field report from mobile.international and their use of Kanban. Markus Andrezak wrote this additional chapter. Also the German book is more up-to-date as the English version, since they incorporated some lessons in the translation which will be up in the 2012 edition of the English version. Arne and Henning explained that it was an honor to translate the book.

They said that roughly two years ago a colleague introduced them to Kanban, and they saw the potential. Since then it-agile has worked closely together with David Anderson, and even offer courses taught by him in Germany. Henning explains that Kanban answered many of the problems they faced with XP or Scrum introductions to companies. Kanban thereby became another tool in the methodology toolbox.

For the additional field report from mobile.international in the book, Arne and Henning explain that they track whole projects on a separate Kanban board. They have a portfolio Kanban board. Upper management meets in front of that board to make strategic decisions for the whole company. Each project is later tracked on a separate board in isolation.

On the usage of Kanban in software development, Henning explained that he would use it anywhere where iterations do not make sense. This includes too small tickets for bugs for examples, but also for too large tickets that do not fit into an iteration at all.

Arne and Henning finished their presentation stating that Kanban is evolutionary compared to the revolutionary approach of methods like Scrum where a whole company is working differently after the introduction. With Kanban changes happen slowly in smaller steps. Self-organization, and the Scrum roles are challenging for many companies. For Kanban this change happens more slowly and based upon insights from the teams doing the work in front of the board. Thereby Kanban can be a tool in the toolbox of a consultant.

Henning and Arne answered some questions from the audience. One question was about how to organize releases using Kanban. Instead of waiting for a release, Arne explained, that each ticket should be as independent as that it can be released in separation the others. This implicates that the tickets need to be a so called minimal marketable feature, a minimal feature, which can be released. Another way is to organize tickets in swim lanes. Each lane marks a release, gets an additional ticket for building the release in the end, and once all tickets from one lane are finished, the release can go out.

Another question was raised regarding how to deal with Kaizen improvements for individual software projects. Arne and Henning explained that the goal of Kaizen is a process improvement. This will probably hold over multiple different projects as well as the current team. They also raised the point that as part of this process improvement the team may conclude to use better development techniques, grow reusable components, etc., which then in turn may become a competitive advantage for the company.

The third question asked about possibilities for visualization through a bug tracker. JIRA with GreenHopper are one way to do this, and there are surely some web-based tools around. Arne explained that he prefers to use a tangible Kanban Board over a computer tool. The haptic, tangible feeling provides an advantage as well as the feeling of success when a team member moves a card one column to the right. Also a physical board with cards has the advantage of physical dimension. While it’s easy to add another card in a tool, there are some limits to do this on a real board. Also the flexibility of a real board is impressive. Teams come up with ideas like ringing a bell when a card is finished, sweats on the board, and the like. Finally, computer tools are more inhibitive to innovation, since people prefer to work around tool problems, rather than to solve them.

On the pro side for computer Kanban boards, these provide ways for statistical evaluation, and for highly dispersed teams there is no way to have every participate on a physical board.

The fourth question handled about an effect often seen in Scrum. One team member gets stuck, and at the end of the sprint everyone is helping out to get the remaining work for the review done. How does this work in Kanban? The goal of Kanban is not to build a team, though this might be an implicated goal in order to improve further in the long-run.

Regarding skills needed for Kanban, Henning and Arne explained that Kanban defines no roles at all. Kanban is a method for change management. Kanban makes the problems surface, but I still need to handle them.

Regarding the size and effort of each ticket, Henning and Arne said that for Toyota there is a pace. Each 57 seconds a new car leaves the plant. Referring to Scrum, this can be thought of as the velocity. Something similar does not exist for development work. Variability is a Must for development, otherwise innovation may be harmed. Regarding ticket sizes they suggested not to use too small tickets, reflect over the course regularly. For some teams T-Shirt sizes (S, M, L, XL) work fine.

Regarding the initial limits of the Kanban board, Arne proposed to try out any limit that make sense, and adapt when it stops working. One participant asked whether Scrum should be used for large projects, while Kanban works best for maintenance. Henning explained that David Anderson introduced Kanban to a 80 person project with a single board. So, Kanban also works very well for larger teams. Of course, a Scrum-like Daily stand-up does not make sense for a 80 person team in front of one board. Instead they then talked about each card, rather than each person. Regarding Scrumban – starting with Scrum, and improving further using Kanban’s WIP limits – Arne hinted at Corey Ladas book called Scrumban.

Regarding estimations of tickets, Henning and Arne explained that detailed hourly estimations are not needed, since this rather might try to solve the problem when a release is finished. Instead, T-shirt sized for tickets work quite fine. Henning cited from Anderson’s first Kanban project. They measured the time they spent on estimation on that project, which was 30% of their overall time. In the Lean sense this is wasted work time, so they disestablished estimations very early on in the project. Kanban as a method does not teach to use estimations, but it also doesn’t say you should avoid it. There is no must for estimation, but you may if you like.

Regarding the practicability of Kanban, Henning explained that he hasn’t seen a project where Kanban couldn’t be used. But he could think of two circumstances where Kanban would not be his first bet. If one goal is to build teams, then he would rather prefer Scrum over Kanban. Another goal of the project could be to increase the truck number – the number people that could get hit by a truck before the project suffers from it. If you want to spread your insulated knowledge within the team, then Kanban can achieve this, but way slower compared to revolutionary methods as Scrum. Henning also explained that there are a lot of projects doing Kanban, and there he has seen nearly everything done with it. Last, a third situation came to mind, where Henning would avoid Kanban. On a project, which has just three months left before a critical release, he would rather go for Scrum, since changes in the organization happen too slowly for Kanban to help the organization.

The last question was about a company which moved from Kanban to Scrum. In this case Henning and Arne explained that probably Kanban was used in order to make transparent where the organization currently was, and then started the overall transformation progress towards Scrum, when the Kanban system indicated to do so.

Before ending the event, Henning and Arne pointed to the free magazines of the Agile Review and a Kanban card, which explains the method in brief as takeaways for the attendees. Since the presentation happened in a book store, participants also were asked to stay and browse for some books, and maybe buy them.