Seite 3: Zusammenhänge verstehen

Inhaltsverzeichnis

Vierter Schritt: Serviceklassen

Manche Arbeiten sind wichtiger als andere. Die Einteilung in Serviceklassen bedeutet, Aufgaben differenziert zu behandeln und ihnen entsprechend Kapazitäten zuzuteilen. Serviceklassen betrachten die "Costs of delay", die reale ökonomische Auswirkung nicht oder zu spät getaner Arbeit auf den Geschäftserfolg. Und das nicht nur in Form von Geld, sondern auch von Reputation, Kundenzufriedenheit et cetera. Die Costs of delay sind eine Funktion der Auswirkungen des Zeitverlaufs. Wie die Serviceklassen zu benennen und zu definieren sind, sollte unternehmensspezifisch gelöst werden. Gängige Klassen wären etwa "beschleunigt", "fester Liefertermin", "Standard" und "unbestimmbare Kosten". Einfach vordefinierte Serviceklassen aus Büchern zu übernehmen, ist jedoch wenig sinnvoll, da Zeit-Impact-Zusammenhänge in jedem Business anders aussehen.

Das Spannende bei der Einführung von Serviceklassen ist, dass sich alle der Auswirkungen bewusst werden müssen und dadurch in Entwicklungsteams ein größeres "Geschäftsbewusstsein" entsteht. Stakeholder und Management sind im Idealfall Diskussionspartner bei der Definition der Serviceklassen. Sie sind näher am Markt und wissen genau, was sich nach außen auf welche Art und Weise auswirkt.

Fünfter Schritt: Regeln

Jede Serviceklasse ist mit Regeln und Kapazitäten zu hinterlegen. Dazu definiert man, wie viele Tickets aus welcher Serviceklasse maximal im Arbeitsfluss sein dürfen und was das Team tun muss, wenn sich ein Ticket einer bestimmten Serviceklasse in den Arbeitsfluss einklinkt. Viele Teams betrachten Regeln als Beiwerk, sie sind aber essenziell. Nur wenn Team, Management und Stakeholder Regeln penibel einhalten, können sie Fehler in der Regel erkennen. Eine der ersten Regeln ist: Sobald ein Problem auftritt, muss es gelöst werden. Die Regeln selbst sind davon nicht ausgenommen: Ist eine Richtlinie nicht mehr sinnvoll, wird sie geändert – alles andere stoppt den Verbesserungsprozess.

Sechster Schritt: Messungen

Hat man etwas verändert, will man später auch wissen, ob sich die Änderungen bewährt haben. Dazu misst man, ob man sich den definierten Zielen genähert hat. Dabei werden nie einzelne Mitarbeiter bewertet, sondern immer das System. Denn wie schnell oder langsam jemand arbeiten kann, unterliegt zu einem Großteil dem Einfluss des Systems, in dem er sich bewegt.

Es gibt unendlich viele mögliche Messungen. Welche man wählt, hängt von den Zielen ab. Wichtig ist dabei nicht die Genauigkeit auf die zigste Nachkommastelle. Frei nach Russell Ackoff ist es besser, diejenigen Dinge unscharf zu messen, die wirklich zu messen sind, als Dinge hochgenau zu analysieren, die einen nicht wirklich weiterbringen.

Siebenter Schritt: Betrieb installieren

Mit allen Kanban-Werkzeugen in der Hand sind zu guter Letzt noch "Zu- und Abfluss" der Arbeit zu definieren, um den Kanban-Prozess in Gang zu setzen.

Bei der Input-Koordination legt man fest, wie Arbeiten am Board landen. Die Klärungsplattform dafür sind "Queue Replenishment Meetings". Hier besprechen Stakeholder und Team, welche Aufgaben als nächstes zu erledigen sind. In der Praxis stehen bei diesen Meetings mit der Zeit nicht mehr Einzelwünsche im Vordergrund, vielmehr rückt das Sinnvollste für das Gesamtunternehmen in den Mittelpunkt. Das Entwicklungsteam kann dabei technische Entscheidungshilfe leisten, das Management bringt den unternehmerischen Kontext ein.

Auch das Liefern verursacht Kosten. In der Output-Koordination ermittelt man daher – wieder ausgehend von ökonomischen Betrachtungen – den idealen Releaserhythmus mit dem Ziel regelmäßiger Lieferungen. Das ökonomische Modell zeigt auf, an welchen Stellen systemische Änderungen passieren müssen, um diese Vorgabe zu erreichen.

Im Daily Standup – dem wichtigsten aller Meetings – beschäftigt sich das Team täglich mit den Fragen seiner Arbeit. Wo sind die Engpässe und Probleme? Darauf aufbauend entschiedet man, wie weiter vorzugehen ist. Gerade am Anfang sind wöchentliche Team-Retrospektiven sinnvoll. Das Team lässt alle Ereignisse der Woche Revue passieren, um zu erkennen, wo Veränderungsbedarf besteht. Im Laufe der Zeit werden Retrospektiven obsolet, weil die Teammitglieder lernen, Probleme dann zu lösen, wenn sie entstehen.

Arbeiten mehrere Teams zusammen, sollte es ein Operations Review geben. Darin klärt die Gruppe übergreifende Probleme und Zusammenhänge. Management und Stakeholder sind ausdrücklich willkommen, tragen sie doch dazu bei, einen Überblick über die Fortschritte zu bekommen und zu erkennen, wo sie mit ihren Mitteln helfen können.

Alle an den Start

Natürlich kann ein Team mit dem Buch in der Hand alle Instrumente und Mechaniken von Kanban selbst definieren und installieren. Idealerweise passiert das aber mit einem erfahrenen externen Kanban-Experten, der gemeinsam mit dem Team das System aufbaut. Wichtiger als die Anwendung aller Instrumente ist nämlich das Verständnis der Zusammenhänge, und dabei verstricken sich Teams ohne Führung von außen gerne in Details. Symptomatisch sind zum Beispiel Diskussionen zur Höhe der WiP-Limits. Wichtig ist es zu verstehen, wie sich deren Änderung im System auswirkt, dann findet sich die richtige Balance von selbst. Ein guter Kanban-Coach liefert also keine Vorschriften, sondern verdeutlicht die Auswirkungen unterschiedlicher Handlungsweisen. Er macht mit seiner Haltung klar, dass Fehler keine Schwächen, sondern Lern- und Veränderungspotenziale sind. Und er zeigt dem Management, dass Stehzeiten genau das Gegenteil von Stillstand sind. Stehzeiten, freie Kapazitäten, sind Zeit und Raum für weitere Verbesserungen. Nur wenn mit dem Kanban-System auch diese Gedanken implementiert werden, kann es das liefern, was alle erwarten: Erfolg.

Klaus Leopold
ist selbstständiger Trainer und Consultant für die agile Entwicklungsmethode Kanban. Er leitet seit 2003 Software-Teams und IT-Projekte im wirtschaftlichen und universitären Umfeld. ()