+43-676-330-4803ContactImprint en de

Blog

Limited offer: “Practical Kanban” for $9 on InfoQ

Since a few weeks now, the English edition of my second book „Practical Kanban“ is all completed and available on Leanpub. Ben Linders has asked me about the key insights of the book in this interview on InfoQ and together we had the idea of making a special offer to InfoQ-readers.

Until 26th November, the download version of “Practical Kanban” will be available for only $9 instead of $24! All you have to do is follow the link in the InfoQ-article.

Lean Business Agility E020: The Spotify Model

In this episode of Lean Business Agility, I talk to Cliff Hazell about the Spotify Model. What is known today as “The Spotify Model” goes back to an article from 2012 that explains how Spotify worked at the time. Since then, countless organizations have adopted this practice and “implemented” the Spotify model in the hope that the organization’s performance will improve. This is also where the problem lies and why it did not work for most of them: The practices do not make Spotify a great company but it is the constant search for a better way of working according to the motto “be the best at getting better”.

Cliff Hazell is Coach Chapter Lead at Spotify.

Subscribe to the YouTube Channel of Lean Business Agility or the Podcast at iTunes or Overcast oder check the RSS Feed.

Agile Greece Summit and Lean Agile Scotland

It was really nice at the Agile Greece Summit, and I mean not only the bright sunshine on the conference day. Two years ago, the first conference for the southern European Agile Community took place with around 200 participants. On 22nd September 2017, more than 600 people strolled around the old Papastratos Tabakfabrik, a truly exceptional location in the middle of Athens (even with an open-air stage). The topic “Lean Business Agility” was very well received and as it looks, I will also be visiting Athens again in the coming year.

A real community meeting with many friends was the Lean Agile Scotland from 4 to 6 October 2017 in Edinburgh. In five parallel tracks, all the hot and important topics in the Agile world were covered. In addition to my talk on Lean Business Agility, I used the time to work with Troy Magennis on the trainings “Improving Kanban – Metrics Special” in Vienna and Düsseldorf. Many thanks to Julia Wester for the cool sketchnotes!

There is also a summary of some tweets to my sessions



WIP Limits Must Die!

A drastic title, but I really mean it. Some people have a fit when I say that you should limit the work in a Kanban system. The notion of limiting them, and the work, leaves an unpleasant aftertaste. At the implementation level, it sounds like, “You think I’m not capable of doing two things at once?” At higher levels, for instance in portfolio management, it sounds like, “We are rejecting customer orders.”

In the world of working effectively, WIP limits are a core element. Their purpose is to simply prevent you from getting bogged down. This bogging down is most apparent when the only thing being discussed is starting initiatives, proposals and projects. Meanwhile, we know multitasking is a myth and companies are not successful because they start as many projects as possible, but rather when they finish as many projects as possible.

Nothing can fly where everything lands

Here’s the thing: We do not want to restrict or constrain work with WIP limits. Rather, we want to get to the point where arrival and departure rates in the system are nearly equal. I like to compare this to an airport: When there are more airplanes landing than taking off, the entire area will be piled up with airplanes in very short order. It is absolutely logical that an airport has a certain capacity (WIP limit) and that arrivals and departures are planned based on this capacity (starting and completing work). If the airport is at capacity, airplanes must depart (work must be completed) before the next airplanes can land (new work can be started).

Most importantly, limiting the amount of work in a work system is a means to an end. There should not be more work started than can be finished. To prevent the system from becoming clogged, there can only be a certain amount of active work, and this amount is represented by the WIP limit. Even though my inherent enthusiasm for WIP limits will probably never waver, and from every possible practical and theoretical point of view they simply make sense, I find myself more and more often trying to avoid the term “limit”. It prompts many people to make an incorrect association. But I am baffled at the moment how to phrase WIP limits differently.

Does anyone have an idea? I would be thankful for any suggestions.