Coffee, Beer and Taxi Rides. Or: Visiting Stockholm with Jimdo

I had the pleasure to give a presentation at the first StopStarting, Start Finishing Conference in Stockholm last Monday. I thought this might be a great opportunity to visit some interesting companies. So I planned an extended stay and asked Fridel from Jimdo if he wanted to join me. He wanted....as well as Naddel (the Flow Manager)...and Matze (the second founder)...and Sönke (employee number 5 at Jimdo)...and Spring (the third  founder). 

So it hapened that the six of us entered the train in Hamburg Altona on Sunday morning 08:46. Only 13.5 hours later we arrived in Stockholm (I skip some interesting things about the train ride here). 

A train ride to Stockholm is not a petting zoo!

After a short taxi ride we arrived at our accomodation af Chapman – an old sailing ship which serves as a hostel now. This was a really good decision! If you ever have the opportunity to do so, book a couple of nights there!

The af Chapman

Blue sky and sunny weather as we entered a taxi the next morning. First thing on our agenda: visit Ericsson in Kista. Our expectations hadn’t been too high. It’s a really huge enterprise, the sort of big oil tanker that needs ages to change direction, so what should we expect? But wow! It’s really impressive how far Erik’s team already has come – with the help of Håkan, their Flow Senssei, of course (he prefers to be referred to as a „plumber“:-) What we could observe was: cross-functional and co-located teams, high visibility of work, flow and problems as well as a leadership team that has accepted the challenge to change their way of working and act more and more as teachers and mentors. After a Gemba Walk we discussed end-to-end-flow at Ericsson and Jimdo. Of course the companies are different as can be. But some things are surprisingly similar: What exactly is the role of Managers in a truly Lean organization? Where are the boundaries of self-organization? And what can we do to keep alignment (in a growing company like Jimdo) or to re-create alignment (in a huge enterprise like Ericsson). And, once again, it became clear to me that the company culture plays a crital role in all change processes (imagine the impact of a value like "perseverance" if it it rooted deeply in your company DNA).

Checking Wifi at Ericsson

Some taxi rides later (from that morning on we had our own taxi driver) we arrived at the Spotify headquarter where we could talk to a couple of Lean/Agile coaches as well as a systems engineering guy. The first thing that you experience at Spotify is – of course – loud music. The second thing are some of the coolest offices I have ever seen! Spotify’s organizational structure is really interesting and described in this paper. We digged into some details. Spotify seems to have managed to cope with an extremely fast growth: If I remember it correctly, the grew from 30 to 300 engineers in less than 3 years with a total of roughly 800 employees (nobody seems to know the exact number, because it changes every day). How do you „manage“ a company of this size without implementing a classical hierarchical matrix structure? Spotify has some interesting answers to this question. From this discussion emerged an idea that could help with one big challenge that Jimdo is facing: Until now they have 3 founders, 140 employees and 6 dogs, that’s it, (almost) no formal leadership. As Jimdo is growing, this is not a sustainable structure, because the workload is way too high for the founders. Jimdo wants to scale leadership without setting classical managers or team leads in place. We’ve discussed this topic quite often during the past couple of months and the visit at Spotify might have brought the answer or at least a starting point for trying things. Other topics that day were self-selected teams with interesting boundary conditions (have at least one sceptic in every team), finding more female engineers and a lot of technical stuff I didn’t understand a word of. 

We were lucky that Spotify organized a community event later that evening. It was called „Scaling Agile“ and consisted of 5 Lightning Talks, good food and a lot of beer. This was a really nice occasion for reflecting our learnings.

Make sure you never run out of beer!

After another taxi ride and emptying some „Hülsenfrüchte“ as well as our bottle of Whisky we had a good but short sleep. The Jimdo guys flew out that morning and I had to prepare my talk about Alignment.

After the great conference (which is worth another blog post) I walked through the old town to my last visit: Crisp. Mattias Skarin showed me the office and told me about Crisp’s way of collaboration, culture and their business model. And he invited me to a great dinner! Crisp is a fascinating company and in many respects they are comparable to what we do at it-agile: Similar size, similar business, similar problems challenges, similar intent to be a "democratic" company and similar experiences with clients. The conversation with Mattias was insighful for me, because he has some great ideas about coaching, which made me think. I really think Crisp is doing a great job and if I lived in Stockholm, I would invite Mattias to dinner every evening to become a Crispare:-) And great news: Mattias is very close to join Twitter. He already opened the registration page but was distracted for some reason!

Crazy Matze

These are my main takeways from our visit in Stockholm:

• Visiting companies is a great way of learning – even if the company seems to be very different from your own.
• There are many ways to build cool companies beyond the classical structures. Unfortunately this comes with a price and takes a lot of effort and failures learning experiences. Lucky enough, there are so many smart people around the world we can learn from. We all should do this more often!
• The Kanban community is absolutely amazing! All three visits were really easy to organize, because the locals very extraordinary helpful. And they all were very open to share their learnings. Tack så mycket Håkan, Erik, Joakim, Anders, Mattias and all the other people we talked to!!!
  
• I have never drunken so much coffee and never had so many taxi rides (thanks, Fridel, for breaking your leg!) And I think we owe Spotify some beers...

P.S. Our next destination is San Francisco. Fridel, Naddel and I will be there in April. And I heard there might be a couple of interesting companies as well...

Empowerment done right

On Saturday I read this tweet by David Anderson:

One great thing about #lkna13 is the empowerment of track chairs. As conference chairman I like to get surprised by speaker selection
— David J Anderson (@agilemanager) 26. Januar 2013

I am one of the track chairs, and this tweet made me think about empowerment (again).

Empowerment is not that easy

No matter which concepts and models you dig into - nowadays almost all of them recommend empowerment. And who would ever argue against empowerment? So just empower everyone, and you‘ll be golden, right? The problem is: It is really hard to "do" empowerment right. In order to make empowerment successful, you need boundaries, trust, an appropriate environment, and leadership. As soon as you lack one of these ingredients, empowerment might not work as you want it to. I will walk through these points and use the conference Lean Kanban North America (LKNA) as an example.
The LKNA conference is split into 6 different tracks plus the main stage. Every single track has a track chair who is responsible for setting up the program for his track. Hillel Glazer is the program chair, so he‘s responsible for the overall program (watch this video with Hillel), of course he works closely together with David Anderson, who is the conference chairman (he pays the bill;-).

Boundaries

The first thing that Hillel did after he had found his track chairs was to organize a conference call where  we discussed some basic stuff about the conference. But what he basically did was setting the boundaries. Three of them (and the most obvious ones) are: Every track chair has a budget to compensate for travel expenses and a certain amount of nights in the speaker hotel. There are also deadlines for having the program ready. And the sessions should somehow be related to the topic of the track.

This sounds trivial, but I think it‘s not! The art is to set the right boundaries! They have to be in balance between being too tight and too loose. If they are too loose, people might not know what to do - they tend to get lost in their empowerment (and in this case, the costs for the conference might explode). If the boundaries are too tight, people might become frustrated, because they don‘t have room to manoeuver. Also, too tight boundaries kill innovation (you will get what you always got). 

Classical management tends to set too tight boundaries. As a counter measure, in the agile community, we often make the mistake to go into the other extreme: way to loose boundaries (or none at all)!

Trust

The LKNA conference is not a pet project. It‘s the flagship of the worldwide Lean-Kanban movement, and the costs will be in the range of a medium 6-digit number. For this reason it‘s important that Hillel trusts his track chairs (and that the track chairs trust each other). One way to reach this level of trust is to build a long term relationship (play an infinite game instead of a finite one). Most of the track chairs know each other by person, and Hillel knows all of them. And there is another important thing about trust, we learned from our experience with Kanban implementations: Frequent delivery builds trust. Hillel gave me trust on advance by empowering me. And I want to keep and increase that trust, so I give my very best to deliver in small batches (talk by talk), and if I fail to do, I will talk to him as soon as I know (admitting failure also increases trust).

In my experience, a lack of trust is one of the biggest problems in many organizations. As long as we don‘t get a leaver on increasing trust, we will not benefit from empowerment!

Environment

In order to be successful in putting together a great program, the track chairs need the right kind of environment. An effective communication structure is part of this environment. Transparency about what the other track chairs do is also crucial. We don‘t want to contact the same speakers twice, we want to gain some economy of scale, and perhaps we need a common pool of backup speakers. Who‘s responsible for this environment? In my opinion, Hillel is. That does not mean that he has to implement all of this by himself. Perhaps it evolves from the track chairs themselves. But Hillel should have an eye on it and make sure that this environment will be in place when needed!

With all the bashing on management, people tend to forget the importance of a good environment. In my view, taking care of this environment is a core duty of management - and good mangers do this well!  If we don‘t have management any more, we need to have other mechanisms in place!

Leadership

So far, Hillel has shown great leadership in organizing the conference program. He set up the environment, he has an eye on the big picture, he points us to pitfalls and great opportunities (but never forces us to take one of them), he gives us examples of how things worked well and how things might not work, he asks if people need help when there seems to be no progress, etc. This does not mean that Hillel is the only one that takes leadership - we all do every know and then. 

It‘s impossible to talk about empowerment without talking about leadership - it‘s the flipside of the same coin. Empowerment can never work without leadership! We don‘t necessarily need to tie leadership to a single role or person. But we need to make sure that leadership takes place! Someone needs to ask all the unpleasant questions at the right time, be the messenger of bad news, step outside the comfort zone etc. 

Here again: We tend to throw the baby out with the bathwater! When we change organizations towards more empowerment and abandon existing structures, we need to make sure that leadership still happens. Otherwise we might end up in chaos!

Hillel the Leadersheep :-)

P.S. The program for LKNA will be online soon. I already know large parts of the program, and I can guarantee it will be a blast! So stay tuned and save the date: April 28 - May 2, 2013 in Chicago. You can also follow LKNA on Twitter

Kanban durch seine Werte einführen (Übersetzung)

Mike Burrows, einer der weltweit führenden Kanban-Experten, hat vor einer Woche einen tollen Blog Post zu den Werten hinter Kanban geschrieben (hier findet man den Original-Post, und hier ein Follow-Up von Mike). Der Post macht sehr schön deutlich, dass Kanban viel mehr ist, als nur bunte Zettel auf einem Whiteboard hin- und her zu schieben! Der Post hat ein großes Echo in der Kanban-Community hervorgerufen (unter anderem hat David Anderson gesagt, er wünschte, er hätte diesen Post selbst geschrieben:-)

Weil ich glaube, dieser Post könnte ein wichtiger Schritt in der Weiterentwicklung von Kanban sein, halte ich es für wichtig, dass er auch auf Deutsch verfügbar ist. Deshalb habe ich Mike gefragt, ob ich ihn übersetzen darf, und er hat eingewilligt. Hier kommt also die Übersetzung:

Die meisten Kanban-Einführungen beginnen mit dem Kanban-Board (ein Tool) und gehen dann über zur Beschreibung der Kernpraktiken. Wenn man Glück hat, erfährt man dann auch noch ein bisschen über die Grundprinzipien.

An dieser Stelle möchte ich einen anderen Ansatz vorstellen. Dieser Ansatz legt gleich viel Gewicht auf die Kanban-Prinzipien, die meiner Meinung nach an erster Stelle kommen sollten (nicht umsonst heißen sie Grund-Prinzipien (foundational practices)) und die Kernpraktiken. Sowohl den Prinzipien als auch den Praktiken liegen Werte zugrunde. Wenn wir diese Werte identifizieren, behandeln wir automatisch alle Hauptelemente der Kanban-Methode. Vielleicht eignet sich dieses Vorgehen ja auch als Framework, um Kanban zu schulen?
Auf jeden Fall ist das Ergebnis holistisch (die Werte lassen sich auf ganz unterschiedlichen Ebenen anwenden), es entspricht dem grundlegenden Zweck von Kanban (Veränderung von Organisationen), und es hilft, mit den drei falschen Vorstellungen aufzuräumen, dass Kanban
i.         eine Methode für Softwareentwicklung sei;
ii.        keine Werte mitbringe, die Organisationen und Change-Agents vor Herausforderungen stellen;  
iii.        nur etwas für Tool-fixierte Zahlenfreaks sei, die in Kontroll-versessenen Organisationen arbeiten (diesen Punkt übertreibe ich nur ein wenig).
Darüber hinaus möchte ich zeigen, dass eine  Wert-basierte Beschreibung von Kanban auch aus anderen, konstruktiveren Gründen nützlich ist.

Mein Ausgangspunkt

Aus den Grund-Prinzipien von Kanban in ihrer gängigen Reihenfolge leite ich vier Werte ab: Verstehen, Einverständnis, Respekt, Leadership. Der erste Wert erfordert eine Erklärung, aber die anderen drei lassen sich direkt aus den Prinzipien ableiten, so wie sie üblicherweise formuliert werden.
Die Werte, die hinter den sechs Kernpraktiken stehen, sind hingegen etwas schwieriger. Nicht, weil sie nicht da wären, sondern weil es hier keine unmittebare 1:1-Beziehung gibt. Ich habe weitere vier Werte aus den Praktiken abgeleitet: Transparenz, Balance, Flow, Zusammenarbeit. Ich finde es allerdings sinnvoll, hier von der offensichtlichen Reihenfolge abzuweichen und außerdem einen weiteren Wert hinzuzufügen, so dass wir bei insgesamt neun Werten landen.
Wir werden uns diese Werte gleich einen nach dem anderen ansehen und dabei auf weitere mögliche Kandidaten stoßen. Ich werde durch Fett-Druck alles hervorheben, was für mich nach einem Wert aussieht (in erster Linie abtrakte Substantive). Mit einer Ausnahe (Fokus auf den Kunden), auf die ich bereits angespielt habe, sind sie jedoch nicht so wichtig, weniger grundsätzlich und weniger im Kern von Kanban als die dargestellten Grund-Werte.

Die neun Grund-Werte von Kanban

1. Verstehen

Verstehen ist ein Kanban-Wert, der nicht ganz offensichtlich ist. Für mich steckt dieser Wert im ersten Grund-Prinzip: „Beginne dort, wo du dich aktuell befindest“.

Verstehen bezieht sich auf die Sache, die wir gerade verändern – egal ob es sich um ein wichtiges Detail des Prozesses handelt, um die Art, wie unser Prozess unter Stress-Bedingungen funktioniert oder so etwas abstraktes wie der generelle Ansatz, nach dem Veränderung in unserer Organisation vorgenommen wird.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
Zitat aus: The Process Myth, Rands in Repose

In unseren Kanban-Schulungen unterrichten wir einen Systems-Thinking-Ansatz, bei dem Verstehen sehr hohe Priorität genießt. Verstehen spielt also schon ganz am Anfang, bei den Kanban-Grundlagen, eine wichtige Rolle – von der ersten Übung an. Woher kommen unsere Aufgaben? Wodurch sind verschiedenen Arten von Aufgaben charakterisiert? Welche Ansätze, um Veränderungen herbeizuführen, haben eine große Wahrscheinlichkeit, erfolgreich zu sein oder zu scheitern – generell und in unserer eigenen Organisation? Woran könnte das liegen?
Wenn es kein Verstehen gibt, dann haben wir es per Definition mit Cargo-Kult-Implementierungen [http://de.wikipedia.org/wiki/Cargo-Kult] zu tun. Selbst wenn es aus dem besten Absichten geschieht: Wahrscheinlich wird es kein Verstehen geben, wenn Veränderungen top-down durchgeführt werden, wenn sie nicht ausreichend motiviert werden (zum Beispiel, indem immer wieder auf Best Practices [http://en.wikipedia.org/wiki/Best_practice#Critique] verwiesen wird) oder wenn Veränderungen ohne weitere Reflexion auf unterschiedliche Bereiche der Organisation angewendet werden. Es kann uns daher nicht wirklich überraschen, dass Veränderungsprojekte häufig zu Enttäuschungen führen. Zum Leidwesen von fauilen oder unfähigen Managern erfordert Verstehen (ebenso wie die verwandten Werte Lernen und Alignment) einige Anstrengung.


2.    Einverständnis
Einverständnis findet sich direkt im zweiten Grundprinzip: „Einige dich mit Anderen darauf, inkrementelle, evolutionäre Veränderungen durchzuführen“. Ich würde hier gern einmal die Perspektive umdrehen: Können wir wirklich davon ausgehen, dass Veränderungen ohne Einverständnis funktionieren kann? Könnte es sein, dass ein Mangel an Einverständnis unserem Erfolg im Wege steht? Oder vielleicht gibt es zwar Einverständnis, aber dieses ist nicht tief greifend genug – wir sind uns darüber einig, dass ein bestimmtes Problem vorliegt, aber wir sind uns uneinig, was die Ursachen sind und welche Auswirkungen es gibt (hier landen wir direkt bei Verstehen).

Dieses Prinzip könnte einen weiteren Wert beinhalten: Inkrementalismus. Ich sehe dies jedoch nicht als einen Kern-Wert an. Denn wir treten ja für inkrementelle, evolutionäre Veränderung ein, weil sich dadurch die Erfolgswahrscheinlichkeit erhöht – und nicht weil die Alternativen des Radikalismus bzw. Konservativismus grundsätzlich schlechter wären. Wir könnten natürlich auch Pragmatismus als weiteren Wert einbringen, aber dieser wäre schwer greifbar.

3. Respekt
„Respekt für die Menschen“ bildet eine der Säulen von Lean. Auf Veränderungen bezogen findet sich dieser Respekt im dritten Kanban-Prinzip wieder: „Respektiere zu Beginn die bestehenden Rollen, Verantwortlichkeiten und Berufsbezeichnungen.“

Genau so wie im übrigen Leben, ist Respekt auch dann eine gute Idee, wenn es um Veränderungen geht. Erhöhen wir unsere Erfolgschancen, wenn wir andeuten, dass Menschen schlechte Arbeit leisten oder dass ihre Rollen nutzlos sind? Wahrscheinlich nicht! Ist es nützlich, Anderen schlechte Absichten zu unterstellen? Vermutlich auch nicht.!Aber bedeutet Respekt, dass wir immer nett sein müssen? Auch das nicht!

Respekt für Menschen zu zeigen, bedeutet nicht, dass wir jeden mögen müssen, mit allen Meinungen übereinstimmen müssen oder jedem halbgaren Argument zustimmen. 
Stephen Parry 

Wenn wir Respekt in dieser Weise verstehen, dann gehört auf jeden Fall auch Mut dazu. Und dies führt uns direkt zu unserem nächsten Wert.

4. Leadership
Leadership taucht in so gut wie jeder Erfolgsgeschichte auf, wurde aber erst 2012 als weiteres Kanban-Prinzip mit aufgenommen: „Sorge dafür, dass Leadership auf allen Ebenen der Organisation stattfindet – von einzelnen Mitarbeitern bis zum oberen Management.“

Über Leadership wurde bereits viel geschrieben, und ich möchte an dieser Stelle nur einige kurze Beobachtungen hinzufügen:
i.         Vielleicht wünschen wir uns manchmal einen Autokraten á la Steve Jobs (oder Steve Ballmer) – aber mit Leadership „auf allen Ebenen“ ist etwas anderes gemeint.
ii.         Leadership ist zu begrüßen, aber das bedeutet nicht, dass Management automatisch schlecht wäre (wir erinnern uns an Respekt?)
iii.         Weiterhin schließt weder Leadership noch Management Selbstorganisation aus – in dem Sinne, dass Einzelpersonen, Teams und Systeme sich weiterentwickeln dürfen, ohne dass ihnen dafür zentral eine Richtung vorgegeben wird. Ganz im Gegenteil: Gute Leadership und gutes Management sorgen für die Bedingungen, unter denen Selbstorganisation gedeihen kann.
iv.         Gute Leadership bedeutet immer auch Herausforderung (wir haben darüber schon kurz gesprochen). Wer Veränderungen vorantreibt, muss darauf gefasst sein, andere herauszufordern und selbst herausgefordert zu werden.

5. Flow
Wir wenden uns jetzt den Praktiken zu und beginnen mit Nummer drei: „Den Flow managen“. Der Management-Anteil dieser Praktik meint die taktische Organisation sowie Entscheidungen, die darauf abzielen, Aufgaben so gut wie möglich zu bearbeiten (Effektivität). Dies hat auf einem gewissen Abstraktionsniveau universelle Gültigkeit – allerdings mit sehr unterschiedlichem Erfolg.

Flow fügt dem noch etwas hinzu, das weit weniger offensichtlich ist: Gleichmäßigkeit und Vorhersagbarkeit. Sich systematisch um alles zu kümmern, was den Flow behindert, stellt ein mächtiges Werkzeug für Verbesserungen dar – so wie es in Lean angelegt ist.
Darüber hinaus schätzen wir Flow auch im Sinne von Csikszentmihalyi, also dieser positive Zustand, in dem wir komplett in unsere Aufgabe versinken. Dieses Art von Flow ist schwer zu erreichen, wenn wir ständig abgelenkt und unterbrochen werden und wenn häufig wechselnde Prioritäten unsere Arbeitsumgebung dominieren.

6. Fokus auf den Kunden
Wir sind noch nicht ganz fertig mit „den Flow managen“! Eine ausführlichere Version dieser Praktik könnte lauten:

Sorge dafür, dass es einen gleichmäßigen Flow gibt, in dem früh und regelmäßig Wert für den Kunden ausgeliefert wird.

Wert ist hier in dem Sinne von Zweck (also das Verstehen des „Warum“ des Kunden) gemeint, aber sehr wohl auch monetär (wobei wir Nützlichkeit nicht mit Kosten verwechseln sollten). Wenn wir uns wirklich darauf konzentrieren, Dinge für den Kunden fertig zu stellen (Completion), so geht dies sowohl über die reine Erledigung von Aufgaben als auch über die Produkt-zentrierte Sichtweise (potenziell auslieferbares Produktinkrement) hinaus. Meiner Erfahrung nach ist dieses Konzept überraschend herausfordern und hat oft dramatische Auswirkungen.
Wenn wir nur Aufgaben erledigen, von denen der Kunde nicht profitiert, so haben wir nichts weiter produziert als Kosten (sunk cost). Wir werden auf diesen Punkt später noch einmal zurückkehren und über den Aspekt „regelmäßig“ sprechen, wenn wir den Wert Balance behandeln.

7. Transparenz
Transparenz untermauert drei Kanban-Praktiken:  Die erste “Visualisierung [der Arbeit]”, die vierte “Regeln explizit machen” und die fünfte “Feedback-Schleifen einrichten”.

In Kanban wird Transparenz auf unterschiedlichen Ebenen hergestellt:
i.         Die Arbeit wird sichtbar gemacht
ii.         Der Workflow wird sichtbar gemacht: Welche Stationen durchlaufen Aufgaben? In welchen Prozessschritten befinden sich unsere Aufgaben gerade?
iii.         Die Einflussgrößen, Regeln und Grenzen, die unsere Entscheidungen beeinflussen und letztlich auch die Leistung unseres Systems bestimmen, werden sichbar gemacht.
iv.         Die Auswirkungen von i. – iii. werden durch Kunden-zentrierte Metriken sichtbar gemacht.

Die ersten beiden Arten der Transparenz ergeben sich automatisch aus kanban-Systemen (mit kleinem k), nach denen die Kanban-Methode ja benannt ist. Die ersten drei Punkte zusammen erzeugen wichtige Hebel – Stellen in unserem System, an denen bedeutende Veränderungen zu relativ geringen Kosten vorgenommen werden können. Die vierte Praktik (Feedback-Schleifen) stellt sicher, dass unsere Veränderungen in die gewünschte Richtung gehen.
Kanban stellt deshalb einen Weg dar, um Systeme entstehen zu lassen, die ständig lernen und sich anpassen – eine Strategie für Organisationen, bessere Fitness in einem von Konkurrenz geprägten Ökosystem zu erlangen.

8. Balance
Die zweite Praktik lautet: „Den Work-in-Progress (WIP) limitieren“. WIP-Limitierung eines Prozesses bietet verschiedene Vorteile:

• Wie durch Little’s Law dargestellt wird, verkürzen sich Durchlaufzeiten (und damit auch Feedback-Zyklen) tendenziell. Der Kunde wird früher zufrieden gestellt, und wir können schneller lernen. 
• Neue Arbeit wird nur dann begonnen, wenn es auch freie Kapazitäten dafür gibt. Dadurch entsteht Flow aus der Perspektive der Aufgaben. Und es entsteht Balance zwischen Bedarf und Versorgung aus Sicht der Teams und Einzelpersonen (Respekt).
• Wenn wir uns ein bisschen näher damit beschäftigen, dann wird klar, dass es auch zur Balance zwischen verschiedenen operativen Aufgaben sowie zwischen operativen Aufgaben und Verbesserungen kommt.

Der letzte Punkt legt ein weiteres Prinzip nahe: „Heiße Vielfalt willkommen“. Systeme, die gut mt Vielfat umgehen können, lassen sich als robust (resilient) beschreiben. Dies ist gut für die Kunden ebenso wie für die Angestellten und Organisationen – auch hier finden wir wieder Balance.

Und das ist ein wirkliches Killer-Feature von Kanban: Die Entwicklung von robusten Systemen, die für eine Bandbreite unterschiedlicher Aufgaben Vorhersagen bezüglich der Leistung erlauben (wobei die Zeiten von Stunden oder Tagen bis zu Monaten oder noch längeren Zeiträumen reichen können).

Für weitere Informationen zum Thema Balance empfehle ich den Vortrag von David Anderson When is Kanban not appropriate [video,  slides] Sowie meinen eigenen Vortrag Kanban the hard way [video, slides], in dem ich auch auf die Themen Vielfalt und Robustheit eingehe.

9.  Zusammenarbeit

Zusammenarbeit findet sich in der sechsten (und letzten) Kernpraktik: “Sich gemeinsam verbessern und durch Experimente weiterentwickeln [indem man Modelle [und wissenschaftliche Methoden] verwendet]”.
Aufbauend auf den Werten Verständnis, Respekt und Fokus auf den Kunden formuliert Zusammenarbeit die Erwartung, dass wir über die Grenzen unseres eigenen Teams hinausgehen, um Hindernisse aus dem Weg zu räumen, die dem Flow im Wege stehen.
Wenn wir nun auch noch die zwei Teile dieser Praktik betrachten, die in Klammern stehen, so finden wir darin die Aufforderung, systematisch daran zu arbeiten, unser Verstehen zu verbessern, indem wir Beobachtungen anstellen und Modelle, Experimente sowie Messungen verwenden (Empirie).
Der Zusatz „Modelle verwenden“ hat außerdem noch eine weitere Bedeutung – nämlich dass wir die Werte Neugier und sogar Großzügigkeit ernst nehmen sollten. Kanban ermutigt alle Anwender ausdrücklich, sich außerhalb der eigentlichen Methode umzusehen, welches Wissen dort noch zu finden ist. Kanban erkennt an, dass viele seiner Wurzeln in anderen Bereichen liegen: Lean, Engpasstheorie, Agilität, Grundlagen der Warteschlangentheorie und der Komplexitätstheorie, Einflüsse aus Lean Startup und der Familientheraphie. Viele Kanban-Anwender verwenden die Modelle, die sie persönlich bevorzugen – ich zum Beispiel beziehe mich viel auf die Modelle A3, GROW und Influencer.

Warum nur neun?

Ich fand es schade, dass der Lean-Wert Fokus auf den Kunden sich nicht ohne weiteres aus den Standard-Formulierungen der Kanban-Prinzipien und –Praktiken ableiten ließ. Man könnte also sagen, dass ich an dieser Stelle geschummelt habe! Ich bin aber nach wie vor der Meinung, dass dieser Wert seinen Platz völlig zu Recht in Kanban findet.
Bei den anderen Werten, die ich herausgearbeitet habe, sieht es nicht ganz so klar aus:

• Lernen und Alignment sind stark mit Verstehen verbunden. Mir ist bewusst, dass es gute Argumente für jeden dieser drei Werte gibt. Ich habe mich für denjenigen entschieden, der meiner Meinung nach am besten die Wurzeln widerspiegelt, die Kanban im Systems Thinking hat. Derjenige meiner Artikel, der am häufigsten referenziert wird (http://positiveincline.com/index.php/2010/06/learning-together-kanban-and-the-twelve-principles-of-agile-software/), legt einen Schwerpunkt auf Lernen. Es war also eine harte Entscheidung, mich hier gegen Lernen zu entscheiden.
• Herausforderung (ebenso Vision) und Mut überschneiden sich klar mit Leadership, aber ich betrachte sie nicht als fundamental. Vergleiche hierzu meinen Post Dole out the 3C’s.
• Selbstorganisation steht ziemlich weit oben, wenn es um Werte bezüglich der Gestaltung von Organisationen geht, aber Respekt scheint mir für Change Agents eine ebenso gute Anleitung zu bieten. Wenn alles Andere gleich bleibt, würde man durch Respekt immer eine Lösung vorziehen, die Selbstorganisation zulässt oder aktiv aufbaut.
• Robustheit spielt eine große Rolle in meinem eigenen Denken, aber hiermit wird eher ein Resultat als ein Ansatz beschrieben. Dasselbe gilt für Gleichmäßigkeit und Vorhersagbarkeit.

Die Werte im Einsatz

Sehen wir uns unsere neun Werte noch einmal an:

Verstehen, Einverständnis, Respekt,
Leadership, Flow, Fokus auf den Kunden,
Transparenz, Balance, Zusammenarbeit

Ich muss zugeben, dass dies eine recht lange Liste ist – länger als die drei oder vier Werte, von denen ich lange Zeit bei verschiedenen Gelegenheiten gesprochen habe. Auf der anderen Seite sind es auch nicht so viele, dass man nicht mehr vernünftig darüber reden könnte. Sie lassen sich auch noch gut merken, so dass man auch leicht auf sie verweisen kann.
Ergeben einige dieser Werte mehr Sinn für Sie als andere? Was folgt daraus? Ich überlege, hierüber auf einem Leadership Retreat mit anderen Praktikern zu diskutieren – die unterschiedlichen Meinungen könnten extrem erhellend sein!
Gibt es Werte aus dieser Reihe, die in Ihrer Umgebung fehlen? Was folgt daraus? Können Sie daraus folgern, dass etwas geändert werden sollte?
Wenn ich beispielsweise zurückblicke, dann kann ich mich an viele Situationen erinnern, in denen es nicht genug Einverständnis gab. Dadurch wurden Veränderungen entweder langsam, oder es ergaben sich Veränderungen, die sehr schnell wieder zurückgedreht wurden. Und wenn ich mir Erfahrungsberichte von Anderen ansehe, dann bekomme ich den Eindruck, dass nicht nur ich diese Erfahrung gemacht habe.

Reflexion

Ich habe Werte explizit gemacht – dies ist angewandte Transparenz. Hierdurch wird Herausforderung geschaffen (in erster Linie, weil ich den Fokus auf den Kunden noch deutlicher im den Kern von Kanban sehen möchte). Außerdem habe ich durch diese Transparenz mein Verstehen von mindestens einer Quelle von Unzufriedenheit besser verstanden. Im Sinn von „Eat your own dogfood“ funktioniert das System! Das gefällt mir!
Ob Sie und die Kanban-Community dieselben Werte wählen würden, ist eine interessante Frage, die ich gern diskutieren würde. Wie könnte man sonst noch vorgehen? Ich würde wirklich gern alternative Ansätze sehen. Ist es vielleicht nützich, die Werte, die ich ausgewählt habe, anders zu strukturieren oder anzuordnen? Oder sind Werte so zerbrechlich, dass man am Besten gar nicht über sie spricht?
Aufbauend auf einem Gedanken, der auf meinen Post How Deep is Your Kanban? vor einigen Monaten zurückgeht, stellt sich mir die Frage: Könnten Werte eine bessere Basis darstellen, um ein Assessment-Tool der zweiten Generation für Kanban zu etablieren? Im Moment fokussiert das Assessment-Tool auf die Praktiken. Wird dadurch vielleicht der wahre Zweck von Kanban verschleiert? Ich glaube, das ist gut möglich.
Ob die Werte einen guten Weg darstellen, um Kanban zu erklären und einzuführen, lässt sich nur herausfinden, indem man es ausprobiert. Das werde ich tun.

5 Ideas what to to with your done tickets

When I talk about Kanban, I sometimes get asked: „What shall we do with all the tickets after they are done?“ Two years ago my answer was: „If the task is really done, just throw the ticket away.“ But during the past couple of months I’ve learned that there are many useful things you can do with the done tickets. Here are my top 5.

Note: I’ve faked all the pictures shown in this article, but I’ve seen all of the described scenarios in real life.

1: The leaf approach

Leave all tickets in the done column until they fall off the wall – like leaves fall off the trees in fall (this, of course, only works if you use sticky notes, otherwise you might be waiting for a long time:-) The adventage is that it has a motivating effect, because it shows to the team and everyone passing by how much the team gets done.

2: Separate by weekdays

How much do you get done on which weekday? Are there paterns? If these questions are interesting for you, you can simply divide the done column into five swim lanes – one for every day of the week. At the end of the week (or the beginning of the new week) you hold a quick retrospective: How are the done tickets distributed amongst the weekdays? Why is that? Meetings? Incidents? And do we see patterns regarding which type of work is usually finished on what day of the week? After you have talked about this, take a picture and then throw the tickets away (or use them in any other way you find useful).

Note: I think I‘ve read about this technique in a blog post before I suggested it to one of my clients who now applies it. If you know the original reference, please let me know.

Update: Now I found out that it was this post by Jesco von Voss I saw this technique before.

3: Use them for generating your charts

If you’ve ever played GetKanban, you know that updating charts is not as much effort as we might think. Often it only means plotting one data point for every ticket you get done. So what if we wouldn‘t plot points but use our done tickets as dots instead? This ist not only more fun, but it also provides us with additional information, because we still have all the information written on the ticket available. Use this charts for your daily work, for feedback meetings, for forecasting and for discussing with your stakeholders.

Here’s an example of a Time Distribution Chart (aka Spectral Analysis Chart). 

Of course a Run Chart (mostly named „Cotrol Chart“ although we don’t use control limits) is also possible and not much effort, either.

And here’s a suggestion for a Burn Up Chart built with sticky notes. I’m also thinking about using Cumulative Flow Diagrams this way. I think it would look really cool. The only disadvantage would be that you have to clone tickets avery day (because you don’t take tickets from „testing“, „developing“ etc. off the wall before they are done).

4: Make improvement opportunities visible

Imagine you are working in a big company. Your team is supposed to build features, but in fact you are doing bug fixes and enhancements for other teams most of the time. You feel that this is a problem, but it’s mostly a gut feel. So why not collect the done tickets for a longer period of time, so that you will see how the mix of Features, Bug Fixes and Enhancements is? This picture might be an eye opener for your team and your stakeholders:

After you have visualized that, you can go even one step further. Another problem is that your team has interdependencies with other teams. This leads to the situation where you get your tickets done, but after that they will not be deployed for weeks or even months because of these dependencies and the complicated deployment process. You have talked about with other teams and your boss but they seem not really to understand how bad this situation really is. So you change your done column into a time line with the next planned release as the end date. Now you get a really good picture how much costs (cost of delay) your company generates, bacause valuable features have to wait for weeks before the will be deployed. And this picture shows another truth: Of course you could work on becoming more efficient in your team. But this is probably only a tempest in the teapot. The real big leaver here is to reduce the wait time before deployment! And why does the mix of features change over time? Why do we have so many pink tickets just before the release?

Click to enlarge

5: Box them

When I visited one if my clients for the first time, I saw they had a box next to their board in which they collected all the done tickets. I asked: „What do you do with all the tickets?“ The answer was one of the coolest things I‘ve ever heard. „We ship them to our competitor.“ Until today I’m not sure if they were kidding or not.

Summary

• There are many ways to use your done tickets. Which technique is appropriate for you? There is only one way to find out: Try. If it does not provide you with any value, try something different! What I‘ve learned is that done tickets can be used for better understanding your team‘s/organization‘s demand as well as its capability. You can use them as a learning tool, and it can be a great tool for showing improvement opportunities. And last but not least: It should be motivating. 

One disadvantage of some of the techniques I‘ve described in this post is that they require a lot of space. So it might not be possible to simply copy them. But I‘m sure you will find a way to emerge new techniques that fit your context.

Do you find this useful? Do you have any other examples what to do with done tickets? Please share them!

P.S. Mike Cohn has just tweeted another possibility for using your done tickets: decorate your Christmas tree ;-) 

Ist Little’s Law keine lineare Beziehung?

Wer sich intensiver mit Kanban beschäftigt, kommt um Little’s Law nicht herum. Diese Formel sieht einfach aus, hat es aber in sich. Immer wenn ich glaube, ich hätte verstanden, woraum genau es geht und wie man Little’s Law sinnvoll einsetzt, kommen bei mir neue Fragen auf. Deshalb ist ein ein riesiger Glücksfall, dass ich dieses Jahr in Boston Frank Vega kennen gelernt habe. Frank ist nicht nur ein unglaublich netter Mensch, sondern er ist ursprünglich auch Mathematiker. Und in unserer Community ist er sicherlich einer der größten Experten zu Little’s Law und dem ganzen Bereich der Warteschlangen-Theorie. Aus einer Frage, die ich Frank per Mail gestellt hatte, ist ein Blog Post entstenden, der für mich definitiv zu den besten Post gehört, die 2012 geschrieben wurden. Deshalb habe ich Frank gefragt, ob ich seinen Post (eigentlich ist es mehr ein Fachartikel als ein Blog Post) ins Deutsche übersetzen darf. Und er hat es erlaubt :-)

Hier findet man den ursprünglichen, englischen Post von Frank

Hier also der übersetzte Text von Frank:

“Unter dem Strich lässt sich festhalten: Der größte Hebel, um Produkte schneller auszuliefern, besteht darin, sich auf die wichtigen Produkte zu fokussieren und die unwichtigen aufzugeben.“
Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.”
“Jetzt denken Sie vielleicht: ´Das mag ja alles stimmen, aber können wir nicht auch diue durchschnittliche Fertigstellungsfrequenz (completion rate) erhöhen?´  Im Prinzip haben Sie Recht, aber der Effekt davon ist viel geringer, als wenn wir den TIP (things-in-process), also die Menge an parallelen Dingen, reduzieren. Das liegt daran, dass es sehr schwieirg ist, die durchschnittliche Fertigstellungsfrequenz zu erhöhen, denn diese ist häufig eine Funktion aus verfügbaren Ressourcen, sich ständig vermehrenden Anforderungen, Anforderungen und Veränderungen des Marktes usw.“
 You might be thinking: ‘True, but couldn’t we also increase the average completion rate’? You’re right, but the impact of doing that is much lower than reducing the TIP (things-in-process) — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc.”
- Pete Abilla, Nov 2006, Little’s Law for Product Development

Vor ein paar Wochen hat Arne Roock, ein Mitstreiter im Bereich Kanban/Lean-Agile, mir diese Frage zum Zusammenhang zwischen Little’s Law und Auslastung gestellt: „Die Warteschlangentheorie sagt uns, dass die Geschwindigkeit von Netzwerken drastisch (nicht-linear) abnimmt, sobald die Auslastung über 80% ansteigt. Gleichzeitig folgt aus Little’s Law (ein stabiles System vorausgesetzt), dass sich die Durchlaufzeit linear verlängert, in dem Maße wie wir den WIP (work-in-progress) erhöhen (was eine Erhöhung der Auslastung bedeutet). Aber müsste uns Little’s Law nicht eigentlich voraussagen, dass die Durchlaufzeit ab einem bestimmten Zeitpunkt (in etwas ab 80% Auslastung) exponenziell ansteigt?“ Aus dieser Frage entwickelte sich ein E-Mail-Austausch über Little’s Law und warum in der Softwareentwicklung ein erhöhter WIP zu einem exponenziellen Wachstum der Durchlaufzeit führen kann. In diesem Artikel gebe ich einige Gedanken aus unserer E-Mail-Diskussion wieder und spinne diese weiter. Ich könnte mir vorstellen, dass auch Andere sich über diese Fragen Gedanken gemacht haben. Falls ja, wird dieser Artikel hoffentlich nützlich sein.

Little‘s Law: In aller Kürze

Zuerst sollten wir alle auf demselben Stand sein und uns die Grundlagen zu Little’s Law ansehen. 

Hinweis: Ich habe beobachtet, dass Little’s Law je nach Kontext und Szenario ganz unterschiedlich formuliert und bezeichnet wird. Die nachfolgenden Varianten beziehen sich in erster Linie auf meine eigenen Anwendungen im Bereich der Softwareentwicklung

In der Regel wird Little’s Law wie folgt dargestellt:

L = λ W

Dabei gilt:

L = die durchschnittliche Anzahl an Aufgaben in einem Warteschlangen-System (Queuing System) innerhalb eines bestimmten Zeitabschnitts

λ = die durchschnittliche Anzahl an Aufgaben, die innerhalb eines definierten Zeitintervalls neu in das System gelangen (Ankunftsrate)

W = die durchschnittliche Zeit, die eine Aufgabe insgesamt im System verbringt

Durch simple Algebra lässt sich Little’s Law umformulieren. Wenn wir die Größen dann noch umbenennen, bekommen wir die Form,  die im Kontext der Softwareentwicklung häufig verwendet wird:

LT = WIP / Durchsatz

Dabei gilt:

LT = die durchschnittliche Lead Time, also die Durchlaufzeit, die eine Aufgabe benötigt, um durch den gesamten Workflow von Beginn bis zur Auslieferung zu gelangen

WIP = die durchschnittliche Anzahl an Aufgaben (Work in Progress), die gleichzeitig begonnen wurden und sich innerhalb eines definierten Zeitraums innerhalb des Workflows befinden

Durchsatz  = die durchschnittliche Anzahl an Aufgaben, die das System innerhalb eines definierten Zeitintervalls verlassen

Beachtenswert ist dabei, dass sich bei dieser Umstellung der Formel die ursprüngliche Ankunftsrate in den Durchsatz verwandelt – also die Frequenz, in der Aufgaben das System verlassen.

In der Softwareentwicklung nehmen Aufgaben typischerweise die Form von User Storys, Change Requests, Bug Fixes usw. an

Hinweis: Hier gibt es einen älteren Blog Post von mir, in dem ich den Unterschied zwischen Lead Time und Cycle Time diskutiere und auch darauf eingehe, welche Auswirkungen sich daraus für das Tracking von Zeiten vs. Tracking von Aufwänden ergeben.

Little‘s Law: Eine kurze Probefahrt

Nun wollen wir die zweite Darstellung von Little’s Law einmal hernehmen und eine kurze Probefahrt „im Klassenzimmer“ unternehmen. Im Grunde ist es ja ein einfaches Verhältnis: Wenn wir den Durchsatz (also den Nenner) konstant lassen, dann können wir leicht sehen, dass sich die Durchlaufzeit (Quotient) proportional verlängert in dem Maße, indem wir den WIP (Zähler) erhöhen. In diesem Schul-Beispiel gibt es keine Schwieirgkeiten, oder?
Aber wie tragfähig ist die Annahme wirklich, dass wir den Durchsatz konstant halten können, wenn wir den WIP erhöhen? Wir werden in Kürze auf diese Frage zurückkommen. Aber zuerst müssen wir alle Annahmen verstehen, auf denen Little’s Law fußt.

Little‘s Law: Annahmen

Es gibt nur wenige solcher Annahmen, und hier ist meine Zusammenfassung: Alle drei Parameter in Little’s Law müssen in derselben Einheit dargestellt sein; bei jedem Parameter handelt es sich um einen langfristigen Durchschnitt; und wir haben es mit einem stabilen System zu tun. Die erste dieser Annahmen ist trivial. Wenn wir den Durchsatz als Anzahl an erledigten Aufgaben pro Tag definieren, dann muss sich der WIP auf dieselben Aufgaben beziehen. Im Kontext der Softwareentwicklung beispielsweise kann der Durchsatz sich auf fertig gestellte Tasks pro Tag beziehen. Dann darf sich der WIP aber nicht auf User Storys beziehen.
Die letzten beiden Annahmen sind hingegen etwas kniffliger, denn sie nehmen je nach Kontext und Szenario etwas andere Formen an. Es ist wichtig, sich über diese unterschiedlichen Gestalten klar zu sein und sie zu verstehen. Aber eine ausführliche Diskussion kann in diesem Artikel nicht geleistet werden. Als weiterführende Literatur verweise ich hier auf Kapitel 5 des (englischen) Aufsatzes „ Little’s Law“ von Dr. Stephen C. Graves, Professor für Mechanical Engineering and Engineering Systems am M.I.T.
An dieser Stelle werde ich nur insoweit auf Details eingehen, wie sie in unserem Zusammenhang wichtig sind.

Little’s Law: Langfristige Durchschnitttswerte und ein stabiles System

Jetzt wird es Zeit, dass wir uns die Hände schmutzig machen und Little’s Law mitsamt seinen Annahmen einmal an einem einfachen Praxisbeispiel ausprobieren. Mein Beispiel mit den zwei Wassertanks wurde wiederum von einem anderen Beispiel inspiriert, das ich hier gefunden habe.
In den linken Tank fließt Wasser in der Menge von 8 Liter pro Stunde herein und heraus. Der Durchsatz, also die Menge an Wasser, die den Tank verlässt, bleibt konstant. Ebenso bleibt der WIP, also der Wasserstand im Tank, bleibt konstant bei 20 Litern. Weil kein Wasser am Rand des Tanks hängenbleibt, bleibt die Lead Time, die ein Wassermolekül (oder ein Liter Wasser) benötigt, um einmal durch den Tank zu fließen, ebenfalls konstant. Noch einmal zur Wiederholung: So lange wir konsistent beim Durchsatz und beim WIP  bleiben, spielt es keine Rolle, ob wir Moleküle oder Liter als Einheit nehmen – oder irgendetwas ganz Anderes, was uns gerade besser passt.

Wenn wir nun Litle’s Law anwenden, erhalten wir eine Lead Time von 2,5 Stunden (20 / 8). Wir gehen das einmal kurz durch: Wenn kein weiteres Wasser in den Tank fließen würde, dann wäre der Tank (bei gegebenem Durchsatz von 8 Litern pro Stunde) in genau 2,5 Stunden leer. Wenn wir nun genau so viel Wasser neu in den Tank füllen, wie hinausfließt, bleibt der Wasserstand konstant und es ergibt sich eine durchschnittliche Durchlaufzeit von 2,5 Stunden.
Nun erhöhen wir die Auslastung des Wassertanks. Wir lassen also so lange mehr Wasser hinein- als herausfließen, bis der neue  Wasserstand von 80 Litern erreicht ist. Danach gehen wir wieder zurück auf den vorherigen Zustand und lassen genau so viel in den Tank, wie auch hinausströmt (8 Liter / Stunde). Dabei halten wir die ganze Zeit über den Durchsatz, also die Menge an Wasser, das den Tank verlässt, konstant. Egal wie viel Wasser in den Tank fleißt, es fließt immer genau gleich viel heraus.

Hinweis: Ich konzentriere mich auf die Frage, was geschieht, wenn wir den Wip erhöhen, weil dies der Kern der Ausgangsfrage nach Little’s Law und der Auslastung eines Systems ist. Mir ist bewusst, dass es noch die verwandte Frage gibt, was geschieht, wenn wir den WIP unter eine bestimmte Menge reduzieren. Dieser Frage gehe ich jedoch in diesem Post nicht weiter nach.

In der Phase, in der mehr Wasser in den Tank gelangt als herausläuft, ist der WIP kein langfristiger Durchschnitt mehr, sondern er erhöht sich mit der Zeit. Wenn wir den WIP (=Wasserstand im Tank) erhöhen, so sagt uns Little’s Law eigentlich, dass die durchschnittliche Lead Time für die einzelnen Wassermoleküle sich verlängert. Aber ist es überhaupt zulässig, Little’s Law in der Phase anzuwenden, in der mehr Wasser in den Tank hinein- als herausfließt?
Der Durchsatz bleib zwar die ganze Zeit über konstant, in der sich der WIP erhöhte. Aber in unserem einfachen Wassertank-Beispiel haben wir erst dann wieder ein stabiles System, wenn wieder so viel Wasser in den Tank gelangt wie ihn auch wieder verlässt. Sobald das System dann wieder stabil ist, berechnet uns Little’s Law eine neue langfristige durchschnittliche Lead Time. Der neue WIP beträgt 80 Liter, der Durchsatz bleibt bei 8 Litern, also ergibt sich eine neue Lead Time von 10 Stunden. Und dieser Anstieg der Lead Time ist wiederum proportional zum Anstieg des WIP, der jetzt ja 4 mal zu groß ist wie zuvor. Man beachte, dass in den Annahmen, auf denen Little’s Law gründet, nichts über die Auslastung des Systems ausgesagt ist.

Little’s Law: Der Effekt von Auslastung

Stellt nun also Lillte’s Law eine „lineare“ Beziehung dar in dem Sinne, dass ein Anstieg im WIP immer zu einem proportionalen Anstieg der Lead Time führt? Um diese Anfangsfrage zu beantworten, müssen wir überlegen, inwieweit die Annahme zutrifft, dass wir den Durchsatz wirklich konstant halten können, wenn wir den WIP erhöhen.
Das Beispiel des Wassertanks ist ein sehr einfaches Szenario für den Einsatz von Little’s Law, weil darin ein schön gleichmäßiger und kontinuierlicher Workflow modelliert wird. Der Wert dieses Beispiels besteht für mich darin, sich klar zu machen, wie wichtig diese Annahme ist. Zu verstehen, warum wir in allen drei Parametern dieselben Einheiten brauchen, ist einfach. Jetzt ist hoffentlich auch klar geworden, warum wir langfristige Durchschnittswerte und ein stabiles System benötigen, wenn wir Little’s Law anwenden möchten.

Hinweis: Für mich ergibt sich aus dem bisher Gesagten, wie wichtig WIP-Limits sind. Selbst wenn wir zu Beginn nur ein einziges Limit für das gesamte System etablieren und dieses Limit zuerst absurd hoch zu sein scheint, so trägt dieses Limit dazu bei, ein System stabil zu machen und zu erhalten. Dadurch wird es möglich, dieses hilfreiche Werkzeug (Little’s Law) effektiv einzusetzen, um besser zu verstehen und zu lernen, wie wir unseren Workflow verbessern können. Und hierdurch können wir auch besser beurteilen, welche Maßnahmen wirklich zu Verbesserungen führen.
Ich bekomme häufiger gesagt, dass Leute keine „expliziten“ WIP-Limits haben, sie aber trotzdem in den meisten Fällen „erfolgreich“ ausliefern. Gleichzeitig haben sie eine beträchtliche Mange an Aufgaben gleichzeitig in Arbeit. Wenn ich dann ein bisschen tiefer grabe, stoße ich meistens auf einen (oder beide) der folgenden  Punkte.
Der erste Fall besteht darin, dass es eine Person gibt (meistens ein erfahrener und begabter Projektmanager), der mit „impliziten“ WIP-Limits arbeitet. Das bedeutet, er sorgt dafür, dass einige Aufgaben zurückgehalten werden, indem er den Umfang oder den Komfort von Features reduziert und sich darum kümmert, Erwartungen und sichtbare Risiken zu managen. Dies würde ich als „gutes“ Projektmanagement ansehen, aber ich stoße nicht häufig darauf. Im zweiten Fall von „impliziten“ Limits ist die Qualität verbesserungswürdig und das System erfordert erhebliches „Heldentum“ bei den Beteiligten, um zu funktionieren.
Ich beobachte eine ganze Reihe von Nachteilen, die sich aus dieser impliziten Art der Limitierung ergeben: Durch die schlechte (oder gar nicht vorhandene) Sichtbarkeit wird der Prozess noch subjektiver, häufig auch „politischer“; Umwege werden wahrscheinlicher; es gibt mehr Kontextwechsel; häufig werden mehr „ungeplante“ Überstunden fällig; es entstehen mehr Bugs und Hacks usw. Und ja: Auch explizite WIP-Limits werden manchmal ignoriert – mit ähnlichen Ergebnissen. Aber nachdem ich mit beiden Arten (explizite und implizite Limits) gearbeitet habe, lehrt mich meine Erfahrung, dass es besser ist, WIP-Limits (passend zur Leistungsfähigkeit des Systems) explizit festzulegen und zu visualisieren und dann durch Policies zu Verhaltensweisen zu ermutigen, durch die der Workflow im Hinblick auf diese Limits gemanaged wird. Dadurch wird sich eine effektivere (d.h. weniger subjektive) Umwelt ergeben, in der es einfacher ist, die wirklichen Ursachen für Verzögerungen und schlechte Qualität aufzudecken und dann sinnvolle Änderungen durchzuführen und hinterher zu bewerten.

Aber es bleibt die Frage, ob wir es im Bereich der Computer-Netzwerke und in der Softwareentwicklung mit ebenso gleichförmigen und gleichmäßigen Szenarios zu tun haben wie in unserem Wasser-Beispiel? Und falls nein: Wie würden sich die Unterschiede auf Little’s Law auswirken? Bezogen auf die Softwareentwicklung kam mir sofort ein Gedanke: Wenn wir den WIP erhöhen, führt dies wahrscheinlich zu mehr Kontextwechseln (falls wir dem nicht durch explizite Regeln entgegenwirken). Und diese Kontextwechsel können bewirken, dass wir den Durchsatz nicht konstant halten können.
Dazu sehen wir uns noch einmal diese Darstellung von Little’s Law an:
LT = WIP / Durchsatz
Wenn es stimmt, dass ein erhöhter WIP zu mehr Kontextwechseln und somit zu einem niedrigeneren Durchsatz führt, dann haben wir es mit einem höheren Zähler und gleichzeitig einem niedrigeren Nenner zu tun. Wenn wir nun diese neuen Zahlen (als neue langfristige Durchschnittswerte) in Little’s Law einfügen, dann wird die Lead Time nicht mehr linear im Verhältnis zum WIP ansteigen. Noch einmal in Kurzform: Wenn wir bei einem erhöhten WIP den Durchsatz nicht konstant halten können, sondern dieser sinkt, dann werden wir beobachten, dass die Lead Time nicht-linear zum WIP ansteigt.

Zusammenfasung

Die Kernpunkte meiner E-Mail-Diskussion mit Arne lassen sich wie folgt zusammenfassen: 1) Es ist wichtig, sich darüber klar zu werden, auf welchen Annahmen Little’s Law basiert und was diese Annahmen für den jeweils betrachteten Kontext bedeuten. 2) Je nach Kontext kann sich aus Litte’s Law ergeben, dass die Lead Time linear oder eben auch nicht-linear ansteigt wenn wir den WIP erhöhen.
Wenn wir die zweite Darstellung von Little’s Law verwenden, dann müssen wir sicher gehen, dass wir es mit einem stabilen System mit langfristigen Durchschnittswerten für WIP und Durchsatz zu tun haben, bevor wir einen langfristigen Durchschnittswert für die Lead Time berechnen können. Wenn der Durchsatz konstant bleibt, während wir den WIP auf ein neues Niveau erhöhen, so wird die neue Lead Time sich proportional zum WIP erhöhen. Wenn allerdings der Anstieg des WIP mit einer Verringerung des Durchsatzes einhergeht (z.B weil es im Kontext der Softwareentwicklung zu mehr Kontextwechseln kommt), so wird die neue Lead Time im Verhältnis zum WIP nicht-proportional ansteigen.
In den nachfolgenden Tagen, nachdem ich dies hier aufgeschrieben hatte, wurde mir allerdings klar, dass es noch viel mehr zu Arnes ursprünglicher Frage zu sagen gibt. Ich hatte das Gefühl, dass wir auf den ersten Teil der Frage noch gar nicht tief genug eingegangen sind. Die dargestellten Punkte zu Little’s Law waren zwar sehr hilfreich für die Diskussion, aber sie beantworten immer noch nicht die Frage, warum in Computer-Netzwerken die Geschwindigkeit nicht-linear absinkt, sobald die Auslastung über 80% steigt. Im Nachhinein muss man wohl sagen, dass dieser Beitrag Arnes Frage gar nicht wirklich beantwortet hat. Also habe ich danach mehr und mehr darüber nachgedacht, wie und warum die drastische Absinken der Geschwindigkeiten von Computer-Netzwerken bei starker Auslastung zu erklären ist. Und noch wichtiger: Können wir daraus etwas über die Art lernen, wie wir unsere Policies erstellen und anpassen sollten, um unser System bei hohem WIP zu managen? Man kann sich denken, dass ich tiefer in dieser Frage eingestiegen bin und bereits einige interessante Dinge gelernt habe. Diese Dinge würde ich gerne aufschreiben und mit Anderen teilen. Aber dies gehört definitiv in einen zukünftigen Post

Alle Gute,
Frank

Anmerkung von mir (Arne Roock): Ja, es beantwortet meine Frage nur zum Teil. Aber das macht nichts, denn dieser Post beantwortet dafür eine ganze Reihe von Fragen von denen ich noch nicht einmal wusste, dass man sie stellen sollte! Danke, Frank! Und ich warte gespannt auf den angekündigten nächsten Post!