+43-676-330-4803ContactImprint en de

Blog

Practical Kanban – Chapter 5: From Prioritization to Risk Assessment

Chapter 5 of my book, Practical Kanban, has now been published. Only one chapter left to publish and the book will be complete. Hooray!

What is Chapter 5 going about? Generally speaking, you could probably say it discusses prioritization. To be more precise however, it deals with how you fill your system with new work. You know the routine: The Option Pool is filled with great ideas and finally a piece of work is finished, making space available for a new piece work. Fantastic! But which piece of work should you start on? The reality is that there are often heated discussions amongst the stakeholders about which piece of work is most important. In Chapter 5, I’ll show you how to have these discussions on an objective and economical basis. I discuss how you can determine a sequence of execution for your work using quantification and Cost of Delay. I’ll also show you other risk-based tools that are available in order to determine what should be worked on next.

Practical Kanban – From Team Focus to Creating Value is available on Leanpub.

Get the book

Kanban at Porsche Informatik

I am always pleased to get feedback on the work I have done with clients. After we sent out our July Newsletter, Anton Spitzer from Porsche Informatik in Salzburg contacted us. His colleague, Oliver Bonrad, wrote an article about how Porsche Informatik uses Kanban. I supported their Kanban implementation with several workshops, so I would like to thank Oliver for mentioning this!

In the first part, Oliver discusses how the board at Porsche Informatik is structured. He also discusses how working with Kanban affected communication and, as a consequence, how quickly problems were resolved. Because the Kanban board has been in use since 2015, there will be a continuation of this article. Has it changed? How has it changed?  And is anybody even still working with it? Oliver will be answering these questions in the next part.

Little’s Law and System Stability – An Interview with Daniel Vacanti

Daniel S. Vacanti is a software veteran. He started as a Java Developer/Architect and has worked with Lean and Agile methods for more than 15 years. Dan was involved to the development of Kanban, and he was part of the  first Kanban project in 2007. With his company “Actionable Agile”, he has specialized in forecasting tools, and is the undisputed master of flow-based metrics.

Klaus: You are one of the experts for flow-based metrics and you have worked intensively with Little’s Law. Why is Little’s Law so important?

Dan: The short answer is, it isn’t important. Or better said, it is not important in the way most people think it is. Just forget the math. Most of the time, Little’s Law is used deterministically. The numbers are assigned and Little’s Law spits out the answer. There are two problems with this approach:

  1. Little’s Law looks at the past, not the future—more on that later.
  2. Little’s Law is helpful in situations where you can only measure two metrics, because the third metric is too difficult, too expensive or too difficult and too expensive to measure. In our world, it is very easy to measure all three metrics, so Little’s Law should never be used for calculations. Accurately measuring the missing flow metric is, in this case, the correct approach.

Regardless, it is important to understand the assumptions that must interact for Little’s Law to function. It is not just an equation, it is an equation and a set of assumptions. My recommendation is to forget the equation and focus on the assumptions. These are a guideline for the policies that must first be established for a process to become predictable. Assuming, naturally, that you place a value on predictability.

Klaus: When it’s going about metrics, most people want to jump immediately into sexy topics like probabilistic forecasting. In your opinion, is that a good place to start?

Dan: Most often the problem is that, for things like a Monte Carlo simulation, knowledge about the system stability is required. This is where Little’s Law shines. If the process follows the assumptions of Little’s Law, then the process exhibits a certain stability and you can slowly begin to bring sophisticated techniques, like a Monte Carlo simulation, into play. If the process continuously breaks the assumptions of Little’s Law, then the process is, by definition, unstable and every type of forecast—probabilistic or otherwise—is highly questionable. That’s why I really like your approach in this book. You first establish a very simple metric to get feedback about the stability of the system.

Klaus: The actual formula for Little’s Law is L = λ × W, but we use CT = WIP/TH (CT: cycle time, TH: throughput). Wherein lies the difference, and what are the consequences of this?

Dan: Actually, both formulas are legitimate definitions of Little’s Law, if you assume that the relationship of average values are observed. The difference lies in the perspective: L = λ × W sees the process from the perspective of arrivals in the system. In contrast, CT = WIP/TH examines the process from the departure perspective. Although both formulas represent Little’s Law, the change of perspective makes a huge difference. As I already said, there are two sides: the equation and the assumptions behind the equation. The assumptions behind CT = WIP/TH are different than those behind L = λ × W. It is important to realize this, because like I said, you only understand Little’s Law when you understand the assumptions behind it. First you must be clear about whether you want to concern yourself more about the arrivals or about the departures, because this perspective influences all the policies used for predictability.

Klaus: How can the readers of this book utilize Little’s Law in their daily work with Kanban systems?

Dan: By understanding the assumptions behind it, and establishing policies in their processes through which these assumptions will only minimally be damaged. Like I said, only if predictability should play an important roll.

Klaus: What do these assumptions look like?

Dan: If you use the throughput version of Little’s Law, you have the following five assumptions:

  1. The average input or arrival rate should be equal to the average output or departure rate.
  2. Each piece of work started will be completed at some point and will also leave the system.
  3. The Work in Progress should be the same at the beginning and at the end for the calculation of the chosen time interval.
  4. The average age of Work in Progress neither increases nor decreases.
  5. Cycle time, Work in Progress and throughput must be measured with consistent units. For example, you should not use a day as the unit of measure for the cycle time and a week for the throughput.

It’s best if you take a moment and think about your own process. Do you have an eye on the arrival and departure rate of work, or does work enter the system faster than it can be completed? To determine this, you can use the stability metric presented in this book, for instance. Do you pay attention to how old the work items are that are currently being worked on, or does the work remain untouched for an arbitrary amount of time? If you do not pay attention to these things, you are breaking the principles of Little’s Law. Every time you act contrary to the fundamental assumptions, the process will be more unstable. The more unstable a process will be, the more difficult it will be to create a precise forecast. In my book “Actionable Agile Metrics for Predictability”, it’s primarily going about creating stable processes based on Little’s Law, in order to be able to make precise forecasts.

Klaus: Why can you not simply use the formula of Little’s Law to create forecasts?

Dan: There are two reasons. First, you cannot make forecasts with Little’s Law because Dr. Little himself said so: “However, let it be noted that the determinism and exactness are after the fact, i.e., the sample path is known. This is not all bad. It just says that we are in the measurement business, not the forecasting business.” Anyone who wants to use Little’s Law for forecasting is barking up the wrong tree, because it was specifically developed to use data already gathered as a basis for looking back—not for a forecast where there can be many different results.

Even if you could use Little’s Law for forecasting, you wouldn’t want to. It is based on the relationship of averages. There is an excellent book that discusses this point in detail: “The Flaw of Averages” (Savage, 2012). The treacherous thing about averages is primarily that plans based on averages will, on average, fail. Even if you could simply put two numbers in the formula so a third number is spit out as a forecast, you should keep in mind that the third value only gives an average—and averages have no value for a forecast.

Klaus: In your book, you write about “flow debt”. Can you explain what you mean by this?

Dan: Flow debt simply means that you borrow cycle time from one work item in the work process in order to give it to a different work item in the same work process. In the short term, you can make the process look better because certain work can be pushed quickly through the system. In the long term, this strategy only contributes to making the process less predictable. Express-Tickets are the best example: As soon as teams receive an express request, they typically stop what they are currently working on. Naturally this policy has the advantage that Express-Tickets proceed quicker in the process and the cycle time for these work items looks good. The nice cycle time has a price however: All other work that was stopped for the Express-Ticket has a higher cycle time. At some point this debt must be settled and this occurs in the form of worse cycle times for the delayed work, when it is finally finished. Better cycle times paid for with worse cycle times is what I call “flow debt”. Every time you favor certain work items in an already running work process, flow debt occurs. The price that you pay for this is increasing unpredictability of the system.


This interview is part of my book Practical Kanban. Get it on Leanpub now!

Lean Business Agility E016: Too Much Work in the System

In this episode I am discussing with Joanne Perold one particular question: “What shall we do when there is too much work in the system?” You probably know the situation when you start to visualize your work, the whole system is overloaded with work. We discuss strategies of how you could deal with this situation like e.g. to park work items within the system, cut the inflow of work, understand the value and bring the value in, etc. Nice one!! 🙂

Joanne Perold is Certified Scrum Master with agile42 in South Africa.

Subscribe to the YouTube Channel of Lean Business Agility or to the Podcast in iTunes or Overcast, or get the RSS Feed.