Lean & Kanban 2011 Benelux in Antwerpen

Am Fluss und im Fluss

Gerade bin ich zurückgekehrt von der Lean & Kanban 2011 Benelux in Antwerpen – eine rundum gelungene Konferenz, wie ich finde. Sie fand im Hangar 26 im Hafen von Antwerpen statt – ein loftiger Ort für Veranstaltungen, direkt an der Schelde gelegen, nur ein paar Schritte entfernt vom neuen MAS-Museum (MAS = Museum aan de Stroom). Während man in den Konferenzpausen in der Lounge mit interessanten Leuten spricht, lässt man den Blick über den breiten Schelde-Fluss schweifen, gleichzeitig eine wunderbare Übereinstimmung mit dem Konferenzthema Kanban, in dem das Fluss-Prinzip ja auch eine große Rolle spielt. Hier ein Bericht von einem Ausschnitt der Dinge, die man dort lernen konnte.

Muss Deming neu gedacht werden?

Die Konferenzen in der Lean/Kanban-Community haben den Ruf, mit heiligen Kühen nicht zimperlich zu sein. Das belegte Don Reinertsen gleich am Anfang in seiner ersten Keynote sehr eindrücklich: „Is it time to rethink Deming?“, fragte er.

Es ging um die zentralen Aussagen von W. Edwards Deming, dem Qualitätsmanagement-Pionier des vorigen Jahrhunderts, der mit seinen 14 Prinzipien des Managements schon sehr früh zum Ausdruck brachte, was Manager tun können, um Arbeitern in der Produktion zu erlauben, erfolgreich zu sein. Demings Ideen sind in das Toyota-Produktionssystem eingeflossen, von dort aus weiter in Lean Production und Lean Product Development, schließlich auch in die Kanban-Community.

Über Deming wurde in der Community immer wieder gesprochen und seine Lehre wurde so weit vereinfacht, dass sie in die Gefahr geriet, zur heiligen Kuh zu werden. Don Reinertsen hinterfragte, ob wir Demings Aussagen nicht zu unkritisch in ein Umfeld übernehmen, in dem sie nicht mehr gelten. Beispiel: Deming machte als Statistiker Empfehlungen zur Produktion, nicht zur Entwicklung. Wenn man Prozesse mit statistischen Methoden untersucht, muss man sich immer darüber im Klaren sein, ob man unabhängige Ereignisse beobachtet oder solche, deren Varianz akkumuliert, weil sie voneinander abhängig sind. In der Produktion hat man ersteres (die Fertigung eines Teils nach dem anderen sind statistisch voneinander unabhängige Ereignisse), in der Entwicklung letzteres (die Entwicklung einer Idee beeinflusst die bereits entwickelten und noch zu entwickelnden Ideen).

Don hat versprochen, die wichtigen Aussagen seiner Keynote aufzuschreiben und zur Verfügung zu stellen. Als zentrales Argument habe ich ihn folgendes sagen hören:

• Deming versucht mit seiner statistischen Prozess-Steuerung (SPC), den Status Quo zu halten, indem er in den Rückspiegel blickt.
• SPC versucht zu vermeiden, dass sich das System von der Vergangenheit entfernt.
• Das ist gut für die Produktion, jedoch nicht gut für die Entwicklung.
• Als Mittel zur Untersuchung setzt Deming Stichproben ein (sampling). Sampling ist teuer, wenn die Stichprobe groß werden muss.
• In der Entwicklung ist es besser, wenn man statt Sampling einzelne Experimente macht, die schnell Erfolg haben oder schnell fehlschlagen, also die Information früh herausfinden. Don verweist auf die Arbeit von Eric Ries zu Lean Startups.

Doppelte Lernschleife

Benjamin Mitchell berichtete in seiner Session über das Mutual Learning Model von Chris Argyris und Donald Schön. Die Frage dabei ist: Was ist Lernen? Argyris definierte Lernen als das Herausfinden und Korrigieren von Fehlern. Wenn Menschen aus Fehlern lernen, was korrigieren sie dann? In der Regel ihre Aktionen. Aktionen gehen aber immer aus einer gewissen mentalen Einstellung (mindset) hervor. Was wäre also, wenn man beim Lernen nicht nur eine Schleife einbaute, sondern zwei? Also nicht nur die Aktionen korrigieren, sondern gleich die mentale Einstellung? Das ist Argyris‘ double loop learning, das Benjamin eindrücklich anhand von Beispielen darstellte.

Mit Benjamin habe ich später noch lange in der Lounge diskutiert. Ich finde, Argyris hat sehr viel dazu beigetragen, dass Menschen sich in schwierigen Gesprächen besser verständigen können und trotz unterschiedlicher Meinung offen reden können. Benjamin konnte das eindrucksvoll zeigen, indem er die Technik der Gesprächsführung auch selbst einsetzt. Danke, Benjamin, so konnte ich alles sofort am lebenden Objekt erfahren.

Reale Optionen

Olav Maassen und Chris Matts führten in das Gebiet realer Optionen (real options) ein, eine Session diesmal wirklich für Anfänger, so dass man alles auf Anhieb verstehen konnte. Eine Option (option) ist eine Möglichkeit zu handeln. Eine Verpflichtung (commitment) ist hingegen ein fester Entschluss, ein Versprechen. Eine Entscheidung (decision) ist das Ausüben einer von in der Regel mehreren vorhandenen Optionen. Olav und Chris gaben für jeden Zuhörer drei farbige Karten aus: blau für Option, rot für Verpflichtung, grün für Entscheidung. Sie gaben dann verschiedene Begriffe des alltäglichen Lebens vor (Flugticket, Konzertkarte, Hotelreservierung, Hochzeit, Kinder bekommen und anderes mehr) und baten das Publikum, mit Hilfe der Karten abzustimmen, ob es sich jeweils um eine Option, eine Verpflichtung oder eine Entscheidung handelt.

Ist ein Flugticket eine Option, eine Verpflichtung oder eine Entscheidung? Die Leute hielten Karten unterschiedlicher Farbe hoch, die meisten davon jedoch blau für „Option“. Die Antwort ist allerdings: Es hängt vom Blickwinkel ab. Aus Sicht des Kunden ist es eine Option: Wenn er ein Flugticket kauft, muss er ja nicht fliegen! Aus Sicht der Fluggesellschaft ist es jedoch eine Verpflichtung: Wenn sie ein Flugticket verkauft, muss sie bereit sein, den Fluggast zu befördern. Aus Sicht des Reisenden, der sich kurz vor Antritt seiner Reise befindet, ist das Einlösen des Flugtickets eine Entscheidung: für den Flug und gegen die Bahn oder das Auto.

Reale Optionen haben mit Optionen aus der Finanzwelt manches gemeinsam:

• Optionen haben einen Wert.
• Sie laufen zu einem bestimmten Datum ab.

In der Produkt-Entwicklung kann es helfen, die Liste der noch nicht realisierten Anforderungen als Liste von Optionen zu betrachten (anstatt als backlog von dem, was das Team alles noch zu tun hat). Jede Option hat einen bestimmten Wert. Man geht eine Verpflichtung immer möglichst spät ein, um sich andere Optionen offen zu halten. Erst im letzten verantwortbaren Moment fällt man die Entscheidung und „zieht“ eine der Optionen. Dadurch kann man als Produktmanager den Wert, der für den Kunden und für die eigene Entwicklungsorganisation geschaffen wird, maximieren.

Ich finde, das ist eine neue Art, ein Backlog zu sehen: als Menge von Möglichkeiten, nicht als Menge von bereits eingegangenen Verpflichtungen. Auch aus Kundensicht hat das Vorteile: Der Kunde bekommt, was er jetzt braucht – nicht das, was er vor sechs Monaten noch brauchte.

Chris und Olav stellten noch weitere interessante Analogien zur Finanzwelt her: Liquidität zum Beispiel. Es gibt Liquidität an Geld, an Zeit, an Räumen und an guten Leuten. Beispiel: Was machen Sie mit dem Mitarbeiter, der am meisten von Ihrem System versteht, das Sie gerade entwickeln? Die erstaunliche Antwort: Sie halten ihn von Arbeit frei und lassen ihn Kaffee trinken! Warum? Dann ist er jederzeit verfügbar, um den anderen zu helfen, ihre Arbeit besser zu machen. Er sollte also der letzte sein, der eine Aufgabe bekommt, nicht der erste. Das erzeugt „Liquidität an guten Leuten“.

Zeitplan an der Tafel

Sami Honkonen von Reaktor in Helsinki schilderte eine Situation mit seinem Kunden. Der Kunde stellt die beliebte Frage: „Wann arbeitet Ihr endlich an meinen Features?“. Sami erklärte, er habe dem Kunden zunächst die übliche Kanban-Antwort geben wollen: „Hier sind Ihre Features in der Warteschlange. Sie rücken soundso schnell auf nach oben (Durchsatz). Wenn die Features dann in den Prozess kommen, dauern sie durchschnittlich soundso lange (Zykluszeit) bis sie wieder herauskommen. Dann bekommen Sie Ihre Features.“

Die Antwort des Kunden: „Alles sehr schön. Aber wann arbeitet Ihr endlich an meinen Features?“

Sami erkannte den Bedarf für eine neue Darstellung. Der Zeitaspekt musste einfach besser herauskommen. Trotzdem sollte die Planung im Fluss bleiben. Der Kunde konnte mit einem Plan leben, der sich ständig verändert – nur nicht mit gar keinem Plan.

Sami fand folgende Möglichkeit: Sie hängten eine weitere Tafel (Zeittafel) neben die Kanban-Tafel. Diese Zeittafel sah wie folgt aus:

Die Spaltenüberschriften sind einfach Nummern von Kalenderwochen. Die Zeilen entsprechen den Themen oder den Schritten des Workflows – auf jeden Fall dem, was auch auf dem Kanban-Brett als Überschriften steht. Man hängt Kopien der Kanbans in die Zellen dieser Planungstafel, so dass der Kunde genau sehen kann, welches Kanban voraussichtlich in welcher Woche entwickelt werden wird. Die Kanbans sind mit T-Shirt-Größen hinterlegt: S=small, M=medium, L=large, XL=extra large, um bei Planänderungen den Zeitbegriff beizubehalten.

Sami berichtete, dies habe den Kunden zufrieden gestellt und es habe noch einen weiteren guten Effekt gehabt: Die Teams selbst fühlten sich mit Kanban vorher etwas „verzettelt“. Die Sicht war auf einzelne Kanbans beschränkt, es wurde ein Zettel nach dem anderen abgearbeitet, und der Zusammenhang der Zettel war unsichtbar. Die Zeittafel lieferte nun diese fehlende Sicht. Das Team konnte erkennen, wie die Strategie sein würde, die in der Reihenfolge der Tickets lag.

Als ich dies sah, hatte ich zuerst das Gefühl: „hmmm… jetzt bilden wir also Gantt-Charts mit Zetteln ab?“. Doch im Nachhinein merkte ich, dass diese Lösung trotzdem sehr flexibel ist. Sie zeigt, was in etwa passieren wird, ohne alles festgeschrieben zu haben wie in einem Gantt-Chart-Tool.

Komplexitätstheorie à la Cynefin

Dave Snowden erschien und mischte als erstes einmal das inzwischen etwas schläfrige Publikum auf, indem er ein paar wilde Thesen in den Raum warf:

• Systems Thinking ist oft nichts anderes als Taylorismus.
• Die Theorie der komplexen adaptiven Systeme löst Systems Thinking nach und nach ab.
• Alles, was explizit gemacht wird, kann auch gefälscht werden.
• Systemdenker beschreiben die gewünschte Zukunft und schließen dann die Lücke von der Gegenwart zu dieser Zukunft.
• Junge Leute unter 25 Jahren bringen Innovation durch Inspiration. Leute über 45 bringen Innovation durch Synthese. Dazwischen: naja!

Das Ganze wurde so eloquent und provozierend vorgetragen, dass die Zuhörer sich gut unterhalten fühlten. Alle wachten auf und amüsierten sich. (Am nächsten Tag würde John Seddon als Vertreter der Systems Thinker wie folgt kontern: „Dave versteht kein verdammtes Bisschen von meiner Arbeit!“, doch das wussten wir zu dem Zeitpunkt noch nicht).

Nun ja, Provokation ist ganz nett, doch was steckte wirklich hinter dem, was David Snowden da vortrug? Er wollte meines Erachtens darauf hinaus, dass die Theorie komplexer adaptiver Systeme die Realität besser handhabbar macht als das, was er unter Systems Thinking versteht. Ein System in David Snowdens Sinne ist demnach ein Netzwerk, das Kohärenz zeigt. Innerhalb des Systems bewegen sich Agenten. Ein geordnetes System ist eines, das seine Agenten einschränkt, so dass sie nicht mehr beliebig handeln können. Ein komplexes System schränkt die Agenten nur leicht ein, doch modifizieren die Agenten das System dadurch, dass sie sowohl mit dem System selbst als auch miteinander interagieren. Das System und die Agenten „ko-evolvieren“.

Je nachdem, welche Art von System wir vor uns haben, reagieren wir als Manager unterschiedlich. David Snowden ist der Erfinder des Cynefin-Frameworks, einer Management-Theorie, die Systeme in fünf Klassen unterteilt. Die ersten vier davon sind:

• Simple, in der die Beziehung zwischen Ursache und Wirkung für alle offensichtlich ist. Die Heransgehensweise ist hier Sense – Categorise – Respond, und wir können bewährte Praktiken (best practice) anwenden.
• Complicated, in der die Beziehung zwischen Ursache und Wirkung Analyse oder eine andere Form der Prüfung erfordert und/oder die Anwendung von Fachwissen. Hier geht man mittels Sense – Analyze – Respond heran, und man kann gute Praktiken (good practice) anwenden.
• Complex, in der die Beziehung zwischen Ursache und Wirkung nur im Nachhinein wahrgenommen werden kann, aber nicht im Voraus. Hier ist der Ansatz Probe – Sense – Respond, und wir können emergente Praktiken (emergent practice) feststellen.
• Chaotic, in der es keine Beziehung zwischen Ursache und Wirkung auf Systemebene gibt. Hier ist der Ansatz Act – Sense – Respond, und wir können innovative Praktiken entdecken.

David Anderson erklärte einen Tag später in seinem Vortrag zu Kanban, dass ein System sich gleichzeitig mehreren dieser Zustände befinden kann, je nachdem, wo man hinschaut. In jedem Bereich des Systems reagiert man damit unterschiedlich. Auch im Bereich der komplexen Systeme kann Kanban helfen, sinnvolle Experimente zu finden, die man auf das System anwendet, weil Kanban die Auswirkungen dieser Experimente sehr schnell sichtbar macht.

Kanban und die Menschen

Alan Shalloway stellte seinen Vortrag unter das Thema „Lean-Kanban is about people“. Er griff die Aussagen des Agilen Manifestes auf und kritisierte: „Sobald man sagt, Menschen seien wichtiger als Prozesse oder Prozesse sind wichtiger als Menschen, erzeugt man ein neues Problem: Das Problem der Trennung zwischen Menschen und ihren Prozessen. Prozesse geben Struktur. Struktur hilft den Menschen, sich zu orientieren.“

Hier einige weitere Aussagen aus seinem Vortrag, die ich interessant fand:

• Wir haben inzwischen genug Wissen, genug Prozesse, genug Technologie – wir müssen all dies im Alltag in Aktion bringen. Wir haben ein Transitionsproblem in den Alltag.
• Gute Leute benehmen sich nett in guten Situationen. Sie werden diese Situationen nicht absichtlich sabotieren. Gute Leute können sich in schlechten Situationen jedoch wie Trottel benehmen.
• Lean Management bedeutet, über Situationen Kontrolle zu haben, ohne in Kontrolle zu sein.
• Nicht die Veränderung ist schlecht, sondern zu viel Veränderung ohne wirkliches Verständnis ist schlecht. Gemeinsames Verständnis hilft, Zusammenarbeit zu erzeugen.

Nach dem Vortrag hörte ich, wie jemand fragte: „Alan, wie erzeugt man im Lean-Umfeld ein Gefühl von Dringlichkeit?“. Alans Antwort fand ich sehr gut: „Ich ziehe ein Gefühl von Aufregung und Begeisterung vor. Dringlichkeit ist nicht auf Dauer aufrechtzuerhalten, Begeisterung schon.“

Teams und Verträge

Zu dieser Konferenz hatte ich auch einen eigenen Vortrag mitgebracht: „Teams und ihre Verträge mit den Partner im Wertstrom.“ Die Grundidee: Teams sind im Wertstrom nicht allein, sondern arbeiten mit anderen Partnern zusammen. Diese Partner können z.B. Stakeholder, Manager oder andere Teams sein. Wie kann ein Team nun den Partnern helfen, dem Team zu vertrauen und es richtig zu nutzen?

Zunächst stellt sich heraus, dass das Wort Vertrag ungeeignet ist. Schaut man z.B. in Wikipedia nach, zeigt sich, dass 90% des Vertragsrechtes darum kreist, was an einem Vertrag nicht funktioniert. Wir wollen aber, dass er funktioniert.

Vertrauen basiert auf Verständnis des Verhaltens anderer. Um Vertrauen aufzubauen, könnte das Team sein Verhalten in Form von Szenarios beschreiben, in der Sprache des Behavior Driven Development. Diese Sprache hat eine interessante dreigliedrige Struktur:

GEGEBEN <eine Sitution, ein Kontext oder ein Ergebnis der Vergangenheit>
WENN <ein interessantes Ereignis in der Gegenwart>
DANN <ein Verhalten, das in die Zukunft führt>

Ein Entwicklungs-Team könnte also z.B. das folgende Szenario erfinden, um seine Reaktion auf Push-Anforderungen zu schildern:

GEGEBEN Sales arbeitet an einem neuen Kunden
WENN Sales fragt Dev: „Arbeitet etwas mehr, dann kriegen wir diesen Kunden!“
DANN Dev schaut sich die gewünschten Features an, betrachtet Zykluszeiten und WIP
UND Dev antwortet an Sales: „Dieses neue WIP wird alle Projekte um 20% verzögern. Wollt Ihr, dass das passiert?“

Ich habe in dem Vortrag noch mehr solche Szenario-Beispiele gezeigt und dargestellt, dass es pro Team (z.B. biz, dev, ops) jeweils eine charakteristische Menge von Szenarios gibt, mit denen es seiner Umwelt zeigen kann, wie es arbeitet. Die Umwelt kann daraufhin anfangen, zu verstehen und zu vertrauen.

Im Publikum saß Liz Keogh, die in der letzten Zeit zur Spezialistin für BDD geworden ist und für ihre Arbeit an BDD, Feature Injection und Real Options in 2010 den Gordon Pask Award bekommen hat. Ihr Feedback würde mir später sehr wichtig sein. Sie hatte während des Vortrags ihren Twitter-Client aktiv und zwitscherte, sie vermisse einen wichtigen Punkt in meinem Vortrag: Szenarios entstehen nicht im stillen Kämmerlein, sondern aus Konversation. Ohne diesen Tweet zu kennen, kam ich nun genau zu diesem Punkt:

Szenarios gut und schön – es ist jedoch ganz entscheidend, aus welchem Geist, aus welcher inneren Einstellung diese Szenarios entstehen, wenn Menschen über ihr Verhalten sprechen und schreiben (ich greife hier auf Erkenntnisse von Otto Scharmer, dem MIT-Forscher, zurück):

• Sind die Menschen nur bei sich? Wollen sie nur ihre festgefügte Meinung in einem solchen Szenario kundtun?
• Führen die Menschen wenigstens eine Debatte über ihr Verhalten, so dass man Unterschiede zwischen dem entdecken kann, was passiert und dem was man innerlich glaubt?
• Noch besser: Sprechen die Menschen in einem empathischen Dialog miteinander und versetzen sich in die Schuhe des anderen, so dass sie nach dem Gespräch nicht mehr dieselben sind wie vorher?
• Oder am besten: Kommen die Menschen gemeinsam zur Ruhe, richten ihre Aufmerksamkeit neu aus? Auf die Gegenwart bzw. die allernächste Zukunft, die gerade dabei ist, zu entstehen? Auf den wirklichen Zweck der Firma oder den Zweck des Teams, um das es geht? Schreiben die Menschen in diesem Geist ein Szenario auf, wird es eine ganz neue Qualität haben und Vertrauen schaffen können.

Nach dem Vortrag kamen viele Fragen. Eine der Antworten, die im Gespräch entstanden: Kanban ist eine Möglichkeit, zu dieser Ruhe zu kommen und den Platz zu schaffen, in dem die Aufmerksamkeit neu ausgerichtet werden kann. Platz im Raum ist essenziell für Veränderung – immer ausgelastete Menschen haben diese Ruhe nicht und können die Neuausrichtung nicht so einfach vollziehen.

Liz Keogh, Eric Willeke und ich fanden uns nachher in der Lounge zusammen. Liz gab mir in ihrer eigenen, kristallklaren Art viel Feedback zu dem Vortrag (danke, Liz!) und sagte, sie fände meine Idee revolutionär: einmal den Geist zu betrachten, in dem die Szenarios gefunden und geschrieben werden. Wir tauschten uns dann noch über so interessante Dinge wie NLP aus, die die Kommunikation weiter verbessern könnten.

Mit Eric möchte ich noch Verbindung aufnehmen, denn er arbeitet an ganz ähnlichen Themen. Leider lag sein Vortrag zeitgleich zu meinem, sonst hätte ich ihn besuchen können.

Kanban – wann nicht?

David Anderson kam mit konzentriertem Stoff, der uns allen wirklich zu kauen gab: „Kanban – when is it not appropriate?“

David muss sich diesen Sommer intensiv damit beschäftigt haben, was andere über Kanban sagen und was der Markt glaubt, welches die Idealbedingungen für den Einsatz von Kanban seien. Dabei sind viele Missverständnisse entstanden, die dazu tendieren, sich im Markt festzusetzen, indem sie immer wiedererzählt werden. David hatte sich zum Ziel gesetzt, damit explizit aufzuräumen – er schrieb am Tag vorher auf Twitter etwas drastisch: „Für morgen plane ich, Nägel in die Särge mancher Mythen und Fehl- und Falschinformation über die Anwendung von Kanban zu schlagen“.

Im Vortrag wählte er dazu folgendes Beispiel: In den letzten Monaten wird immer wieder gesagt, Kanban sei ein Prozess, der sich besonders für die IT-Operations und Helpdesk-Domäne eignet, weil anscheinend Kanbans entkoppelte Rhythmen (Planung, entkoppelt vom eigentlichen Tun, entkoppelt von der Freigabe der Ergebnisse) und der Single Piece Flow auf natürliche Weise zu dieser Domäne passen. Auch heißt es immer, dass dieselben Stärken im Bereich der größeren Projekte weniger zum Tragen kommen, so dass man glaubt, Kanban sei im Bereich größerer Projekte wohl weniger nützlich.

David machte klar, dass dies eine zu sehr vereinfachte Sicht der Dinge ist. Zu sagen, Kanban sei eine Prozessimplementierung für Arbeit, die aus einzelnen (voneinander isolierten) Stücken besteht, ist simplifizierend und reduziert Kanban auf eine Lösung für ein ganz bestimmtes Problem. (Ich würde aus meiner Erfahrung ergänzen: Ein Arbeiten an einzelnen voneinander isolierten Stücken ohne den nötigen Zusammenhang stellt in der Software-Entwicklung sogar eine Dysfunktion dar!)

Er zeigt dann auf, dass es ein Spektrum gibt:

• von Einzelstück-Arbeit wie IT Operations und Helpdesk
• über Software-Wartung mit ihrem typischen Mix aus Änderungsanforderungen und Produktions-Bugfixes
• bis hin zu größeren Projekten mit Fokus auf größeren Entwicklungszielen

Auf der Seite IT Operations und Helpdesk ist die Business-Agilität besser und Lead Time die nützlichste Metrik. Auf der entgegengesetzten Seite des Spektrums (bei den größeren Projekten) ist die Business-Agilität schlechter und der Durchsatz die nützlichste Metrik. Idealerweise, sagte David, sollten wir versuchen, möglichst viel Arbeit vom „schweren“ Ende des Spektrums zum „leichteren“ Ende zu bewegen, indem wir die Batchgrößen verringern.

David erklärte dann, dass die voll ausgebaute Kanban-Methode (also kanban-System plus Messen, Risikomanagement, Marketingstrategie, strategische Planung, etc.) interessanterweise gerade an dem Ende ihre größte Kraft entfalten kann, an dem die Nachfrage werthaltig ist (value demand) und noch gestaltet werden kann. Das ist bei der Entwicklung größerer Projekte der Fall. Im Helpdesk-Bereich beschäftigen wir uns dagegen meist mit Bruchlast (failure demand), über die nicht großartig verhandelt werden kann. Fehler und Probleme müssen schlicht und einfach beseitigt werden – da können sogar Zweifel an der Nützlichkeit von WIP-Limits und Pull-Systemen entstehen. (Anm.: Eine Feuerwehr kann es sich nicht aussuchen, sie muss immer reagieren, ob ihr WIP-Limit gerade erreicht ist oder nicht!)

Gerade im Bereich größerer Entwicklungen kann man die Nachfrage (Anforderungen) als Pool von Optionen verstehen, die zur richtigen Zeit ausgeübt werden können und sollten. Auf dieser Seite des Spektrums kann man wesentlich besser proaktiv und mit Pull-Charakter arbeiten als auf der Helpdesk-Seite des Spektrums. Mit Kanban seine Fähigkeiten zu verbessern, um die „Konversionsrate“ der Optionen zu steigern, ist hier besonders interessant. Auf der Helpdesk-Seite ist ebenfalls Fähigkeiten verbessern angesagt, doch hier mit dem Ziel, den Anteil an Bruchlast zu verringern – durch Analyse der Wurzel des Übels und durch Verbesserungen, die systemisch (anstatt nur lokal) wirken. Im Bereich der Software-Wartung (mit ihrem ausbalancierten Mix aus werthaltigen Änderungsanforderungen und Bugfixes) konnte Kanban entstehen; dort wurde von der Community am meisten über das Design von kanban-Systemen gelernt.

Wow – mir scheint, manche Neuronen im Netz des bisherigen Verständnisses von Kanban müssen sich neu anordnen! Es ist ein bisschen wie in der Physik: Man entdeckt irgendwann, dass die Newtonsche Mechanik nur bei kleineren Geschwindigkeiten gilt und muss sein Weltbild in Richtung Einstein korrigieren. Danach entdeckt man, dass im subatomaren Bereich wieder andere Gesetze gelten und muss sein Weltbild in Richtung Quantenmechanik korrigieren. Das alte Weltbild wird dadurch noch nicht einmal wirklich ungültig, sondern ordnet sich vernünftig in einen Kontext ein. Danke, David – ich dachte schon fast, die Wissenschaft von Kanban sei abgeschlossen! Wie schön, dass das nicht der Fall ist!

Es ist das System, du Dummkopf!

John Seddon machte den Abschluss der Konferenz mit seiner Keynote: „It’s the system stupid!“.

John erzählt immer gern von Systemen. Vor allem von solchen, die sich im Sinne des Kunden idiotisch verhalten. Es macht Spaß, ihm zuzuhören, wenngleich man vieles davon schon in anderen seiner Vorträge gehört hat und sich wünscht, er würde mehr variieren und mehr neue Erkenntnisse einfließen lassen. Hier einige seiner zentralen Thesen, so wie ich sie herausgehört habe:

• Die Kosten liegen nicht in den Tätigkeiten selbst, sondern im Flow der Tätigkeiten. Die Zahl der Transaktionen und Übergaben dominiert die Kosten. Daher ist eine Trennung in Front-Office und Back-Office schlecht. Wenn man dann eins davon nach Indien auslagert, steigen die Kosten noch weiter an.
• Versuchen Sie nicht, die Kosten direkt zu managen. Sie werden damit die Kosten nur erhöhen.
• Wenn Sie auf hohe Auslastung der Kapazität, auf Kostenreduzierung und auf das Management von Deadlines setzen, doktern Sie damit nur am System herum. Sie erhöhen damit die common cause variation, die Sie eigentlich verringern wollten! (Anm.: common cause variation sind systemimmanente oder prozessimmanente Schwankungen im Sinne von W.E. Deming. Man kann sie nur durch Arbeit am System, nicht an Einzel-Ursachen, verringern.)
• Studieren Sie zuerst den Zweck eines Systems. Dann die Maßnahmen, die das Management getroffen hat. Erst dann die Prozesse und Methoden, die zum Einsatz kommen. Denn: Aus dem Zweck entstehen die Maßnahmen, aus den Maßnahmen folgen die Methoden.
• Lassen Sie die Leute selbst entscheiden und einen Experten zu ihrer Arbeit hinzuziehen, wenn er gebraucht wird. Trainieren Sie die Leute darin, zu erkennen, wann sie ein Problem selbst lösen können und wann sie unbedingt einen Experten hinzuziehen müssen.

Am Schluss machte John Seddon noch eine interessante Aussage: „Schwimmbahnen in Kanban schaden der Kapazität des Systems.“

David Anderson gab darauf eine Antwort, die ich nicht so schnell verstand und deshalb nur bruchstückhaft wiedergeben kann. Sie muss wohl so etwas bedeutet haben wie „Das Auffüllen der Eingabe-Warteschlange hat sowohl Transaktions- als auch Kommunikationskosten. Wenn diese unter Berücksichtigung der Batchgröße kleiner sind als der Schaden, den man der Kapazität zufügt, dann führen wir Schwimmbahnen ein, sonst nicht.“

Darauf John Seddon: „Ich verstehe kein Wort von dem, was Du da sagst.“

Mir ging es genauso: Ich konnte so schnell nicht erkennen, wie sich Schwimmbahnen auf die Kosten auswirken sollen. Die Zeit war jedoch um, alle wollten lieber in die Lounge. David hat später auf Twitter versprochen: „Ich beabsichtige, dazu eine ausführliche Antwort mit Erklärung in einem Blog-Beitrag zu schreiben.“ Darauf bin ich sehr gespannt.

Kuchen und Pralinen vor der Rückreise

Antwerpen hat exzellente Chocolaterien. Eine davon hat mich (und meine Frau) besonders begeistert: Del Rey. In der Nähe des Bahnhofs gelegen, bietet dieses Geschäft traumhafte Torten, Kuchen und Pralinen an. Diese Qualität von Macarons, zum Beispiel, habe ich so noch nirgends gefunden (und ich bin Spezialist für Macarons, kann ich sagen).

Auf der Rückfahrt besuchten wir dann noch Vlissingen. Die Mündung der Schelde mit der Brandung, die direkt aus der Nordsee kommt, der starke Wind, der einem ins Gesicht bläst – ein schöner Abschluss dieser Konferenzreise!

Nachtrag vom 12.1.2012

Inzwischen ist viel über diese Konferenz veröffentlicht worden. Das Material finden Sie hier:

• Auf Vimeo gibt es die Videos der Vorträge.
• Auf Slideshare gibt es die Slides zu den Vorträgen.