Visualisierung, Teil 2: Die Tickets

In einem früheren Post zu den Prinzipien von Kanban habe ich geschrieben, dass ein sehr großer Teil der positiven Wirkung von Kanban durch die Visualisierung zustande kommt. Neben dem Kanban-Board sind die Tickets wichtige Artefakte, die zur Visualisierung dienen. Tickets sind in der Regel Karteikarten, Haftnotizen, ausgedruckte Zettel, oder auch virtuelle Tickets in einem elektronischen Tool, auf denen die wichtigsten Informationen zur jeweiligen Aufgabe vermerkt sind. Die Tickets sollten groß genug sein, damit man die wichtigsten Informationen auch aus einigen Metern Entfernung lesen kann. Im Einzelnen sollten diese Informationen auf jeden Fall auf einem Ticket vermerkt sein:

• Möglichst sprechende Bezeichnung der Aufgabe, z.B. "Validiere Teilnehmer-Mailadresse".
• Der Name des augenblicklichen Bearbeiters/Pairs/Teams. Bei Fragen weiß so jedes Teammitglied, an wen es sich wenden kann. Und darüber hinaus wird deutlich, welche Teammitglieder an wie vielen Tickets gleichzeitig arbeiten (und wo sich evtt. zu viel Expertentum/Wissensmonopole befindet). Einige Teams verwenden Sticker oder Magnete mit Portraits oder Avataren, die auf die jeweiligen Tickets geklebt werden. So lässt sich schnell herausfinden, welche Kollegen an zu vielen Aufgaben gleichzeitig arbeiten. Wenn man die Anzahl der Sticker/Magnete beschränkt, kann man über diese Visualisierung also auch eine einfache WIP-Limitierung pro Person vornehmen.
• Das Eingangsdatum (also das Datum, an dem mit der aktiven Arbeit am Ticket begonnen wurde), und nach Erledigung das fertigstellungsdatum (also das Datum, an dem Das Ticket den Bereich der Wertschöpfungskette, den wir kontrollieren, verlassen hat). Das Eingangsdatum ist eine wichtige Information bei den Standup Meetings, weil ein lange zurückliegendes Eingangsdatum auf Probleme hinweisen kann und man dieses Ticket eventuell als blockiert behandeln sollte. Aus der Differenz zwischen Eingangs- und Ausgangsdatum lässt sich dann die Durchlaufzeit errechnen. Je nach Kontext kann es sinnvoll sein, zusätzlich die Daten auf dem Ticket zu vermerken, an denen das Ticket jeweils in einen neuen Prozessschritt gezogen bzw. in eine Queue geschoben wurde. Allerdings kann es verwirrend sein, alle diese Daten auf dem Ticket selbst zu vermerken, so dass es häufiger sinnvoll ist, sie nur in dem Tool festzuhalten, mit dem man auch die Tracking-Diagramme erstellt (Excel, Googel-Spreadsheets usw.)
• Wenn ein Ticket blockiert ist, sollte dies auf den ersten Blick zu erkennen sein. Die meisten Teams kleben dafür eine rote Haftnotiz auf das entsprechende Ticket.

Zu diesen Basisinformationen können je nach Kontext weitere Elemente hinzukommen, die man auf den Tickets festhalten sollte:

• Wenn man mit verteilten Teams arbeitet und/oder zusätzlich ein elektronisches Kanban-Tool/Bugtracker verwendet: Eine Ticket-ID, mit der man die Verbindung zum elektronischen Ticket herstellt und auf die man sich bei Telefonkonferenzen, in E-Mails usw. beziehen kann. 
• Die Serviceklasse der einzelnen Tickets - sofern man mit unterschiedlichen Serviceklassen arbeitet. Dann ist besonders wichtig:
• Mit welcher Priorität die Tickets behandelt werden sollen. Häufig wird dieser Kennzeichnung über die Farbe der Tickets vorgenommen (z.B. Weiß für besonders eilige Aufgaben (Expedite-Tickets)). Es gibt hierfür allerdings auch andere Möglichkeiten. Henrik Kniberg schlägt beispielsweise vor, einen roten Stern auf ein Ticket zu malen, um hohe Priorität anzuzeigen. Sollte es dann zu einem Notfall werden, wird ein zweiter Stern hinzugefügt (Panik). Dies hat den Vorteil, dass  sich die Serviceklasse leichter ändern lässt.
• Bei Tickets, die einen fixen Liefertermin haben (d.h., dass extrem hohe Verzugskosten entstehen, wenn das Ticket bis zu diesem Termin nicht erledigt wurde), sollte dieses Datum ebenfalls direkt auf dem Ticket vermerkt werden.

Links und Literatur

• Kapitel 6 im Buch "Kanban" von David Anderson. Buch bei Amazon
• Kanban kick-start example von Henrik Kniberg (englisch) -> Zeigt auf einen Blick wichtige Elemente eines guten Kanban-Boards und der Tickets.

Visualisierung, Teil 1: Das Board

In einem früheren Blogpost habe ich geschrieben, dass Visualisierung eines der Grundprinzipien von Kanban darstellt und dass häufig schon eine recht simple Visualisierung einen riesigen Erkenntnisgewinn bringt und Veränderungen anstoßen kann. Grund genug, etwas mehr zu Visualisierung zu schreiben. In diesem Post geht es um das Kanban-Board, später wird es noch je einen Post zu Tickets und weiteren Elementen geben, die es zu visualisieren lohnt.
Das Kanban-Board ist das zentrale Planungs- und Steuerungstool jedes Kanban-Teams. Die Standup Meetings sollten vor dem Board abgehalten werden, ebenso wie die Retrospektiven/Operations Reviews. Darüber hinaus lässt sich anhand des Boards besser über Probleme bei der täglichen Arbeit diskutieren. Und nicht zuletzt erlaubt das Board nicht nur dem Team Einsichten über den Prozess und den Zustand einzelner Aufgaben, sondern auch Stakeholdern und Mitgliedern aus anderen Teams. All diese Punkte machen zwei Dinge deutlich: 1) Das Board sollte so groß wie möglich sein, damit möglichst viele Details vom Arbeitsplatz aus erkennbar sind. 2) Das Board sollte so platziert werden, dass es von möglichst vielen Teammitgliedern mit dem kleinst möglichen Aufwand eingesehen und aktualisiert werden kann. Selbst wenn man nur kurz von seinem Arbeitsplatz aufstehen und einmal um die Ecke gehen muss, stellt dies oft schon eine Hemmschwelle dar, das Board so oft zu verwenden, wie es hilfreich wäre. Elektronische Tools haben übrigens immer so eine "Ecke" eingebaut: Selbst wenn es nur zwei Klicks dauert, das elektronische Board zu öffnen, stellt dies eine kleine Hemmschwelle dar. Auch wenn es logisch kaum zu erklären ist, führt dies oft dazu, dann nicht im Tool nachzusehen oder eine kleine Ergänzung vorzunehmen. Wenn man allerdings nur kurz den Kopf heben und etwas drehen muss, um die nötigen Informationen zu erlangen, so führt dies zu einer regeren Nutzung. Aus diesem Grund empfiehlt es sich, auch dann ein physikalischen board zu verwenden, wenn man parallel dazu auch ein elektronisches Tool einsetzt.

Welche Informationen sollten auf dem Board erkennbar sein? Obwohl die Details ja nach Kontext abweichen können, gibt es einige Punkte, die wohl generell für jedes Board gelten:

• Der Workflow, also die Reihenfolge der Prozessschritte, die eine Aufgabe (normalerweise) durchläuft.
• Die Anzahl der Aufgaben, die sich gerade im System befinden. Allein die tatsächliche Menge an Aufgaben am Board zu sehen, hat häufig einen enormen Effekt. Auch wenn man schon vorher irgendwie wusste, dass man an zu vielen Dingen gleichzeitig arbeitet.
• Der jeweilige Prozessschritt, in dem sich eine Aufgabe befindet (in Entwicklung, beim Test usw.)
• Der jeweilige Zustand jedes einzelnen Tickets: | In Arbeit | wartet darauf, in den nächsten Schritt gezogen zu werden | blockiert | fertig |. Der Zustand bietet einen wichtigen Anhaltspunkt, um über Verbesserungsmaßnahmen zu diskutieren, beispielsweise wenn über die Ursachen von Blockaden gesprochen wird.
• Die Work-in-Progress-Limits für die einzelnen Prozessschritte
• Die Reihenfolge, in der neue Tickets gezogen werden. Dieser Punkt wird in der Regel nicht allein durch das Board visualisiert, sondern durch eine Kombination aus der Anordnung der Tickets am Board, der Art der Tickets (Serviceklasse) und vereinbarten Teamregeln.
• Der Mitarbeiter (bzw. das Pair oder das Team), der gerade an der Aufgabe arbeitet. Dies ist zum einen deshalb wichtig, damit jeder weiß, an wen er sich wenden kann, wenn er eine Frage zu einem Ticket hat. Zum anderem macht diese Kennzeichnung deutlich, wenn einzelne Teammitglieder an sehr vielen Tickets gleichzeitig arbeiten, was häufig auf Wissensmonopole hindeutet.

Das Board soll auf einen Blick die Verteilung der Aufgaben zeigen und Probleme sichtbar machen.

Zum Weiterlesen:

• Kapitel 6 im Buch "Kanban" von David Anderson. Buch bei Amazon
• 10 verschiedene Kanban-Boards auf dem Blog von Mattias Skarin
• Der Visual Management Blog zeigt sehr schöne (reale) Kanban-Boards

Lean bedeutet einen Perspektivenwechsel

Anfang November besuchte ich in Hamburg einen Vortrag von Kent Beck (der "Erfinder" von eXtreme Programming und testgetriebener Entwicklung). Das Thema lautete: Software G Forces and the Effects of Acceleration. Neben vielen anderen interessanten Punkten hat dabei vor allem ein Aspekt ein Aha-Erlebnis bei mir ausgelöst: Agiel/Lean (die für mich zwei Seiten derselben Medaille darstellen) bedeutet häufig, traditionelle Sichtweisen aufzugeben und eine zuerst ungewohnte, neue Perspektive einzunehmen.
Becks Vortrag handelte davon, was geschieht, wenn ein Team/eine Organisation dazu übergeht, ihren Release-Zyklus immer weiter zu verkürzen: von jährlich auf quartalsweise auf monatlich auf wöchentlich auf täglich auf stündlich (ja, so etwas funktioniert tatsächlich, wie beispielsweise flickr eindrucksvoll beweist). Für jeden dieser Rhythmen hat Beck auf einer Folie dargestellt, was jeweils dafür nötig ist, um auf diese Stufe zu gelangen und welche Dinge man sich auf der anderen seite nicht mehr erlauben kann. 

Was ist nötig für monatliche Releases (links), und was kann man sich nicht mehr erlauben (rechts)?

Beispielsweise ist es ab einem monatlichen Rhythmus nicht mehr möglich, eine eigene Q/A-Abteilung zu haben, weil die Arbeitsübergaben und die Kommunikationsaufwände dann zu hoch wären, um so ein schnelles Tempo zu erlauben. (Intessanterweise kann man ab einem bestimmten Tempo auch keinen Bugtracker mehr haben. Stattdessen muss man es hinbekommen, dass nur noch extrem wenige Bugs entstehen, und diese wenigen Bugs müssen sofort gefixt werden - oder man muss sie ignorieren und bis in alle Ewigkeit mit ihnen leben.) 

Auf der Seite der Dinge, die nötig sind, um schneller zu werden, waren alte Bekannte zu lesen wie automatisierte Akzeptanztests, Continuous Integration und Refactorings (und zwar schon bei quartalsweisen Releases). 

Das hat mich zuerst erstaunt, aber dann ist der Groschen gefallen: Bei all diesen Praktiken geht es gar nicht in erster Linie darum, sie einzusetzen, um ein bestimmtes Ziel zu erreichen. Ich hatte vorher immer viel zu sehr von den Praktiken her gedacht. 

"Warum macht Ihr TDD?" - "Weil sich dadurch ein schlankeres Design ergibt." 

"Warum arbeitet Ihr im Pair?" - "Weil wir dann weniger Fehler machen." 

Das sind natürlich nach wie vor sehr gute Gründe. Wenn man aber die Reihenfolge umdreht, wird aus der möglichen Argumentation eine zwingende. Und sie ist besonders zwingend, wenn es um kurze Durchlaufzeiten und häufige Releases geht (was ja tatsächlich für viele Organisationen die größten Herausforderungen darstellt). Die Unterhaltung könnte dann ungefähr so aussehen: 

"Wir möchten gern wöchentlich Releasen. Geht das?" "Ja, aber nur, wenn wir Pair Programming einsetzen und TDD praktizieren." "Dann sollten wir sofort damit anfangen." "Gern, aber vorher brauchen wir etwas Zeit und Geld für Weiterbildung, andere Schreibtische und und größere Monitore." 

Pair Programming und Co. sind also keine Hindernisse für hohes Tempo, sondern eine Voraussetzung!

Dasselbe gilt übrigens für den Zusammenhang zwischen Geschwindigkeit und Qualität (ein Umstand, auf den die Poppendiecks immer wieder hinweisen): Die Alternative lautet nicht Geschwindigkeit oder Qualität. Sondern sie lautet: Schnell werden durch hohe Qualität oder langsam bleiben, weil die schlechte Qualität kein höheres Tempo zulässt. Wie im TDD-Beispiel ist es natürlich auch hier einfacher gesagt als getan, denn die Qualität zu erhöhen, ist ja alles andere als trivial. Aber wenn man schneller werden will (oder muss) führt kein Weg daran vorbei. XP-Praktiken sind nichts, was man macht, weil es irgendwie cool wäre, sondern sie stellen Bedingungen dar, an denen man nicht vorbeikommt, wenn man bestimmte Ziele erreichen möchte.

Zum Weiterlesen

• Markus Gärtner hat mit seiner unvergleichbaren Live-Blogging-Technik den Vortrag von Kent Beck sehr schön zusammengefasst. Zur Zusammenfassung
  
• Mary und Tom Poppendieck (2006): "Implementing Lean Software Development." Buch bei Amazon
  

Kanban und Scrum - Teil 1

Wenn man etwas zu Kanban erzählt, kommen immer Fragen wie: "Ist das besser als Scrum?", "Wann verwendet man Kanban, und wann Scrum?" usw. Diese Fragen ergeben genau genommen keinen Sinn, denn Scrum und Kanban sind keine Gegensätze. Henrik Kniberg hat es einmal sehr nett ausgedrückt [1]: Genau so gut könnte man fragen, was besser ist, Messer oder Gabel? Manchnmal braucht man ein Messer, manchmal eine Gabel, manchmal beides, und manchmal etwas ganz Anderes, z.B. einen Löffel.

Scrum ist ein Management-Framework (zumindest lautete so die offizielle Sprachregelung der ScrumAlliance bis zur Einführung des Certified Scrum Developers). D.h. Scrum sagt etwas dazu, welche Rollen man besetzen sollte, welche Artefakte man benötigt, und welche Meetings zu welchen Zeitpunkten durchgeführt werden sollten, um erfolgreich Produkte zu entwickeln. Kanban ist kein Management-Framework, sondern eine Change-Management-Methode. In Kanban geht es darum, den bestehenden Prozess (wie auch immer der aussehen mag) durch Visualisierung, Limitierung und Messungen immer weiter zu verbessern. Es kann durchaus sein, das man Kanban verwendet, um Seine Scrum-Implementierung noch weiter zu verbessern (das nennt sich dann Scrumban [2]). Es kann aber auch sein, dass man Kanban auf einen Wasserfall-ähnlichen Prozess aufsetzt, um ihn in kleinen Schritten immer agiler zu machen

Wenn man genau hinhört, dann wird zwar gefragt, ob Scrum oder Kanban besser sei, aber dahinter steht meistens eine ganz andere Frage: Nämlich die Frage nach dem Sinn und Unsinn von Iterationen. Hierzu macht Scrum ja die klare Aussage, dass es Iterationen (Sprints) fester Länge geben muss - zwei Wochen scheint inzwischen die häufigste Sprintlänge zu sein. Es gibt also alle zwei Wochen ein Priorisierungsmeeting, ein Sprint Review und eine Retrospektive. Kanban sieht keine Iterationen vor - es verbietet sie jedoch auch nicht. David Anderson ampfiehlt immer wieder, auch in Kanban regelmäßige Rhythmen (cadences) zu etablieren. Wie lang diese Rhythmen sind und ob sie miteinander gekoppelt sind, hängt vom jeweiligen Kontext ab, in dem das Team und die Organisation sich befindet. Wenn der Aufwand für ein Release sehr hoch ist, dann ist es vielleicht (zunächt einmal) sinnvoll, nur alle zwei Monate zu releasen und sich immer wieder Gedanken zu machen, wie man die Kosten für das Release (Koordinierungs- und Transaktionskosten) kontinuierlich senken kann, um einmal pro Monat, alle zwei Wochen oder wöchentlich releasen zu können. Wenn aber auf der anderen Seite die Kosten für die Priorisierung neuer Anforderungen sehr gering sind (z.B. weil es bereits regelmäßige Abstimmungsmeetings gibt, in denen die richtigen Leute für die Priorisierung zusammensitzen), dann kann es sehr sinnvoll sein, die Priorisierungen in einem viel kürzeren Takt vorzunehmen. Dann gibt es zwar immer noch nur alle zwei Monate ein neues Release, aber die meisten Anforderungen, die in diesem Release umgesetzt werden, sind wesentlich jünger als zwei Monate. Auch hier gilt wieder: Nur weil etwas im Moment so ist, bedeutet das noch lange nicht, dass es so bleiben muss. Aber der Startpunkt sieht erst einmal genau so aus.

Kanban schreibt also keine Iterationen vor, verbietet diese jedoch auch nicht. Deshalb lässt sich Scrum auch als eine spezifische Ausprägung eines Kanban-Systems ansehen (bei dem nämlich die drei genannten Rhythmen in Form von Iterationen gekoppelt sind). Und tatsächlich könnte ich mir vorstellen, dass man mit einem Wasserfall-ähnlichen Entwicklungsprozess startet und ihn mit Kanban kontinuierlich immer weiter anpasst, bis eines Tages Scrum dabei herauskommt (oder etwas sehr Scrum-Ähnliches).
Scrum als Management-Framework steht also nicht im Widerspruch zu Kanban als Change-Management-Methode. In dieser Hinsicht ist die Frage "Scrum oder Kanban" tatsächlich unsinnig. Allerdings führen die meisten Organisationen agile Methoden ja nicht auf der grünen Wiese ein, sondern sie haben bereits einen etablierten Entwicklungsprozess, mit dem sie aber unzufrieden sind. Und sie versprechen sich von Scrum massive Verbesserungen (oft auch den einzigen Ausweg). In diesem Szenario geht es also um Veränderungen, und Scrum ist der Trigger, um diese Veränderungen anzustoßen, bzw. erst einmal das volle Ausmaß der Probleme transparent zu machen. Wenn wir aber von Veränderungen sprechen, dann ist es sinnvoll, sich zu überlegen, ob man diese disruptiv (also revolutionär) oder evolutionär einführen möchte. Scrum steht für den ersten Ansatz, Kanban für den zweiten. Keiner der beiden Ansätze ist per se besser oder schlechter, sondern der Kontext entscheidet. Wenn ein Unternehmen mit dem Rücken zur Wand steht, ist Scrum vielleicht der einizig mögliche Ausweg. Und in dieser Situation sind die Beteiligten häufig auch bereit, schmerzhafte Veränderungen durchzuführen. In anderen Situationen hingegen werden revolutionäre Veränderungen nicht akzeptiert - oder nach ersten Erfolgen bei einzelnen Teams wird die Skalierung durch Vertragsgestaltungen, Prämienmodelle o.ä. ausgebremst. Dann könnte Kanban der bessere Ansatz zur Veränderung sein. Eine Erfolgsgarantie gibt es weder hier noch dort.


P.S. Eigentlich sollten in diesem Post zwei Graphiken zum Zusammenhang zwischen Kanban und Scrum abgebildet sein. Nach einer Dsikussion mit Bernd Schiffer und Stefan Roock (vielen Dank dafür!) bin ich jedoch zu dem Schluss gekommen, dass ich darüber erst noch weiter nachdenken muss und daraus wohl ein eigener Post wird.

Referenzen
[1] Henrik Kniberg und Mattias Skarin (2010): "Kanban and Scrum - Making the Most of Both." Buch bei Amazon oder kostenloser Download
[2] Corey Ladas (2009): "Scrumban - Essays on Kanban Systems for Lean Software Development." Buch bei Amazon

Lean und Kanban auf den XP Days Germany 2010

Vom 25.-27.11. fanden wieder die XP Days Germany statt - zum dritten Mal in Hamburg.
Holger Koschek hat schon einen sehr schönen Post mit seinen Eindrücken geschrieben. Deshalb beschränke ich mich hier auf meine Lieblingsthemen: Lean und Kanban.
Im "regulären" Programm Donnerstag und Freitag gab es insgesamt fünf Session zu Lean und Kanban. Den Anfang machte Traian Kaiser, der über Paradigmenwechsel im Projektmanagement auf dem Wege zur Lean Enterprise bei der XING AG sprach. An dieser Session konnte ich leider nicht teilnehmen, weil ich zeitgleich im Nebenraum eine Karata-Kata gelaufen bin (Foto).
Direkt danach führten Markus Andrezak und Stefan Roock ein kleines (sehr amüsantes) Rollenspiel auf, in dem sie gewissermaßen im Zeitraffer darstellten, wie das Portfolio-Management mit Kanban bei mobile.international funktioniert und welche Entwicklungsschritte bis heute durchlaufen wurden. Passende Folien hierzu gibt es auf Slideshare.
Nach dem Mittagessen haben dann Olaf Lewitz, Bernd Schiffer und ich eine Kanban-Einführung gehalten. Olaf hat zu Beginn die Prinzipien von Kanban dargestellt, und danach haben wir mit sechs parallelen Gruppen das Name Game gespielt, in dem man sehr schön die Auswirkungen von Multitasking in einem praktischen Beispiel selbst erleben kann. Die Teilnehmer produzieren Namensschilder - einmal acht Stück parallel, und einmal eins nach dem anderen. Andreas Schliep hat dazu eine sehr interessante Zahl genannt: Nach dem Putnam Model waren die Gruppen im zweiten Durchlauf bis zu 2.000% (!) produktiver als im ersten! Mir hat die Session riesigen Spaß gemacht. Vielen Dank an alle Teilnehmer insbesondere Olaf und Bernd!
Am Nachmittag gab es dann noch zwei Kurzvorträge zum Thema: Markus Andrezak berichtete von seinem Italien-Urlaub und wie eine Pasta-Fabrik ihn dazu brachte zu erkennen, dass die Lead Time nicht immer entscheidend ist. Hier die Folien bei Slideshare. Und hier der passende Blog-Eintrag von Markus dazu. Dann durfte ich in einem Pecha Kucha Justins Reise vom Wasserfall über Scrum zu Kanban nacherzählen.

Pecha kucha kanban_slideshare

View more presentations from arneroock.

Fast noch interessanter wurde es dann Samstag beim OpenSpace. Dort wurden gleich drei Sessions zu Kanban angeboten: Eine Einführung von Bernd und mir, eine Diskussion zu Scrum&Kanban und schließlich ein sehr interessanter Perspektivenwechsel darauf, unter welchen Bedingungen Kanban schlecht geeignet sein kann und welche Anzeichen darauf hindeuten, dass man es allenfalls mit einer leeren Kanban-Hülle zu tun hat. Vielen Dank an Jiri Lundak, der diese Session angeboten und moderiert hat. Die Ergebnisse wollen wir als Grundlage verwenden, um einige Antipatterns zu Kanban festzuhalten. Mehr dazu hoffentlich bald.

Die XP Days haben wie immer riesigen Spaß gemacht, ich habe eine Menge gelernt und viele interessante Menschen kennen gelernt! Und es bleibt die schöne Erkenntnis, dass Lean und Kanban ihren Platz in der Agilen Community finden und dazu beitragen, die Agile Gedankenwelt weiterzuentwickeln.

Hier finden sich die Fotos zu den XP Days

Die Prinzipien von Kanban

Rund um (Software-)Kanban haben sich inzwischen so viele nützliche Best Practices herausgebildet, dass es gar nicht mehr so einfach ist, einen Schritt zurückzutreten und die grundlegenden Prinzipien zu erkennen.
Wenn ich Kanban erklären, dann beschränke ich mich inzwischen auf drei fundamentale Eigenschaften, die jede Kanban-Implementierung aufweisen muss:

1. Visualisierung
2. Limitierung
3. Kontinuierliche Verbesserung

Dies ist zweifellos stark abstrahiert, aber wenn man diese Punkte ernst nimmt, kommt man sehr, sehr weit.

Visualisierung
Der aktuelle Prozess muss auf einem "Board" visualisiert werden - egal ob Whiteboard, Pinnwand, Fensterscheibe, an der Wand (oder zur Not auch in einem elektronischen Tool). Diese Visualsisierung sollte möglichst einfach, leicht verständlich und vor allem für das gesamte Team (am Besten die gesamte Organisation) gut sichtbar sein. Wenn man 2 Stunden benötigt, um einem neuen Kollegen das Board zu erklären, dann ist es ganz sicher zu kompliziert.
Die zweite wesentliche Form von Visualisierung besteht darin, implizite Regeln explizit zu machen - und auch diese gut sichtbar aufzuhängen (z.B. auf einem Flipchart). Solche Regeln beziehen sich z.B. darauf, wann welche Meetings stattfinden, in welcher Reihenfolge die Aufgaben abgearbeitet werden, wie mit Notfall-Tickets umgegangen wird, welche Termine und Lieferzeiten dem Kunden versprochen wurden usw.
Erfahrungsgemäß bringt die Visualisierung, obwohl sie recht simpel ist, einen riesigen Erkenntnisgewinn und führt für sich schon zu Verbesserungen führen.


Limitierung
In einem Kanban-System ist die Menge an begonnener Arbeit stets begrenzt. In der Regel bezieht sich diese Limitierung nicht nur auf das Gesamtsystem, sonder auch auf die einzelnen Prozessschritte (Entwicklung, Test usw.)
Untrennbar verbunden mit der Limitierung ist das Pull-Prinzip: Nur, wer eine alte Aufgabe erledigt hat, zieht sich eine neue Aufgabe aus der Spalte links von ihm und beginnt mit dieser. Aufgaben werden stets selbstständig gezogen, nicht von Vorgesetzten zugewiesen. Damit wird deutlich, warum es nicht ganz einfach ist, ein echtes Pull-System zu etablieren, denn es gehört viel Vertrauen dazu! Denn die Vorgesetzen müssen darauf vertrauen, dass neue Aufgaben auch tatsächlich regelmäßig gezogen werden und die Mitarbeiter nicht stattdessen lieber den ganzen Tag lang Kaffee trinken oder im Internet surfen.


Kontinuierliche Verbesserung (Kaizen)
Egal wie gut unser initiales Kanban-System auch sein mag, es muss immer weiter verbessert werden. Sobald wir aufhären, uns zu verbessern, machen wir auch kein Kanban mehr! Diese Verbesserug kann in sehr kleinen Schritten vorgehen, aber sie muss vorhanden sein. Und die Verbesserungs-Maßnahmen sollten vom Team ausgehen. Wenn aus dem Team keine Verbesserungsvorschläge mehr kommen, ist dies ein sicheres Zeichen dafür, dass etwas mit dem Prozess im Argen liegt. Für kontinuierliche Verbesserung ist es unabdingbar, dass sich das Team regelmäßig ausreichend Zeit nimmt, um über den Prozess und die Zusammenarbeit zu reflektieren (z.B. in Retrospektiven). Und es ist sehr nützlich, ständig einfache Messungen durchzuführen (z.B. Durchlaufzeiten, Termintreue, Fehlerrate usw.), anhand derer man Verbesserungsmaßnahmen besprechen kann.
Die kontinuierliche Verbesserung ist zweifellos der wichtigste Punkt unter den dreien - und leider derjenige, der oft nicht richtig Ernst genommen wird. Hierin sehe ich tatsächlich eine Gefahr: Wenn der Prozess visualisiert und die Arbeit limitiert wird, dann sieht es von außen nach einem Kanban-System aus. Und dann ist es sehr einfach, es beim Status Quo zu belassen. Aber dann fehlt ein wichtiger Feiler von Kanban!


Literatur und Links

• Einführungs-Artikel aus dem BT Magazin
• Interview mit David Anderson aus dem OBJEKTspektrum (Deutsch)
• Einführungs-Webseite (Englisch)
• Online-Heimat der Kanban-Community (Englisch)
• Deutscher Wikipedia-Artikel zu Kanban
• Infos und Schulungen zu Kanban in Deutschland
• Kanban-Buch von David Anderson bei Amazon (Englisch)
• Deutsche Übersetzung des Kanban-Buches bei Amazon, erscheint Ende Januar 2011

Was ist noch mal dieses Lean?

Lean hat jeder schon mal gehört. Und alle finden es irgendwie cool. Aber was genau Lean eigentlich ist, kann kaum jemand sagen. Das liegt allerdings nicht daran, dass die Leute zu blöd wären, um Lean zu verstehen. Vielmehr bin ich inzwischen überzeugt davon, dass es das eine Lean gar nicht gibt. Denn es werden unterschiedliche Vorstellungen und Konzepte unter der Bezeichung Lean zusammengefasst. Das reicht dann von der Kostenreduktion um jeden Preis über Einfachheit bis hin zur recht jungen Community der Lean Startups. Ich kann mich noch dunkel daran erinnern, dass wir das Thema Lean Production in der Oberstufe behandelt haben. Das Einzige, was daraus bei mir hängen geblieben ist: Durch die Just-in-Time-Produktion haben die Automobilhersteller ihre Lager auf die Straße verlegt. Also kann Lean offenbar auch bedeuten, die Kosten, die bei der eigenen Verbesserung entstehen, auf die Allgemeinheit abzuwälzen;-) 

Was ist Lean also: Eine Produktionsmethode? Eine Managementphilosophie? Oder doch nur ein (nicht mehr ganz so) neues Schlagwort, unter dem uns alte Kamellen als tolle Neuerungen verkauft werden sollen? Sicherlich ist überall etwas Wahres dran. Für mich liegt der Kern jedoch in etwas Anderem: Lean ist eine Blickweise, bei der konsequent die Perspektive des Kunden eingenommen wird! In Lean geht es darum, möglichst häufig möglichst viel Wert für den Kunden auszuliefern. Alles, was diesem Wert abträglich ist, sollte reduziert oder abgeschafft werden. Und wir wollen uns immer weiter verbessern. Punkt. So einfach ist die Sache. Dies ist der Kern von Lean. 

Worin dieser Wert besteht (und wer der Kunde ist), wird je nach Kontext variieren: Es kann sich ebenso um Geld handeln wie um Wissen, Zeit, Sicherheit oder vielleicht auch Spaß. Dieser Wert lässt sich oft nicht eindeutig quantifizieren, aber es muss ihn geben. Andenfalls sollte man sich ernsthaft fragen, womit man eigentlich seine Zeit verbringt, wenn dabei nichts herauskommt, was für irgend jemanden von Wert ist.

Nimmt man diese Sichtweise ein, dann ist Lean keineswegs auf die Geschäftswelt beschränkt, sondern lässt sich auch auf die Freizeit anwenden. Dann kann ich auch mein eigener "Kunde" sein, und der "Wert" z.B. eines Spaziergangs besteht in meiner Erholung. Aus einer Lean-Perspektive heraus könnte ich mich dann fragen, wie ich mich möglichst oft möglichst vollständig erholen kann. Vielleicht ist die lange Fahrt ans  Meer ein Hindernis für mich, und ich sollte mal nach einer netten Strecke in meiner Umgebung suchen? Oder ich brauche eine winddichte Jacke, damit ich mich auch im Herbst aus dem Haus traue? 

Wenn Lean aber tatsächlich so einfach ist, was hat es dann mit den vielen Schlagworten auf sich, die überall herumgeistern: Defer Commitments, Pull, Optimize the Whole, Build Quality in, Limit Work to Capacity und viele weitere? Hierbei handelt sich sich um Prinzipien, die sich als nützlich herausgestellt haben, um Strukturen und Prozesse in Richtung Lean zu verändern. Sie alle haben ihren festen Platz im Lean-Universum - aber keines dieser Prinzipien an sich macht Lean aus. Sie alle spielen eine "dienende Rolle" bei der Fokussierung auf den Wert für den Kunden. Und wenn wir uns in einer komplexen Domäne wie der Softwareentwicklung bewegen, ist es ja tatsächlich gar nicht so einfach zu entscheiden, wie genau so eine Fokussierung denn nun aussehen soll. Da sind solche Prinzipien dann sehr nützlich.
Unterhalb dieser Prinzipien wird es dann noch einmal konkreter, wenn wir uns die Praktiken ansehen, die allgemein hin als Lean angesehn werden: Stop the Line und Root Cause Analysis wären solche Praktiken. Und viele der agilen Managementtechniken und der Entwicklungspraktiken, die aus XP bekannt sind, ebenfalls. Doch dazu mehr in einem späteren Post.

Kontakt und Impressum

Arne Roock
arne (dot) roock (at) emailica (dot) de
Profil bei Xing 
Twitter: @arneroock

Inhaltlich Verantwortlicher

Inhaltlich Verantwortlicher gemäß § 6 MDStV: Arne Roock

Haftungshinweis

Trotz sorgfältiger inhaltlicher Kontrolle übernehme ich keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Hallo Welt!