Stolpersteine bei der Kanban-Einführung

„Scrum ist sehr anstrengend, lass uns Kanban machen, das ist leichter. Und ist ohne Meetings.“

Als Kanban-Trainer der Kanban University höre ich das seit mehr als 5 Jahren. Ich habe zahlreiche Teams bei ihrem Umstieg begleitet, daher kann ich sicher sagen: Kanban ist auch anstrengend, nur auf eine andere Art.

Hier sind die wichtigsten Stolpersteine, über die alle meine Teams und Organisationen in den letzten Jahren gefallen sind – damit Sie nicht auch darüber stolpern, zeige ich Ihnen die Warnsignale, auf die Sie achten sollten.

Stolperstein 1: Beteiligte sind verwirrt, weil wichtige Begriffe nicht von Beginn an etabliert werden

In den meisten Organisationen sind Begriffe wie Arbeitsfluss (Flow) oder WIP-Limits böhmische Dörfer – kein Wunder, gilt doch das ungeschriebene Gesetz, dass jede einzelne Person im System (aus Kostengründen) maximal ausgelastet sein sollte. Das Ziel von Kanban ist jedoch die Verbesserung der systemischen Gesamtleistung. Wir betrachten das System stets als Ganzes und konzentrieren uns auf die Interaktionen.

Ich starte in meinen Workshops gerne mit einer Form von Simulation (je nach Zeitbedarf mehr oder weniger komplex), um die Zusammenhänge zwischen Work in Progress, Liefer- und Wartezeiten und ja, auch Stress, zu verdeutlichen. Am Ende steht immer die Einsicht, dass die Menge gleichzeitig begonnener Vorhaben maximalen Einfluss auf Lieferzeiten und Vorhersagbarkeit in unserem System hat.

Zudem etabliere ich auf diesem Weg „Flow“ als wünschenswerten Zustand und definiere passende Metriken.

Stolperstein 2: Boards geben keine Anhaltspunkte für Verbesserungen, weil die wertschöpfenden Aktivitäten nicht visualisiert sind

To Do / In Progress / Done mag für den Beginn auf einem Board in Ordnung sein, diese Darstellung stößt aber sehr schnell an ihre Grenzen. Wie viel an Informationen können Sie bspw. aus diesem Bild ableiten?

Sie wissen lediglich, dass gerade eine Menge verschiedener Dinge getan werden, aber was bedeutet das genau? Es bietet sich daher an, die einzelnen Phasen, die Ihr Arbeitsgegenstand durchlaufen muss, bevor er als fertig gelten kann, als separate Spalten abzubilden.

Schon erkennen Sie, an welcher Stelle im Prozess sich die Arbeit staut, welche Arbeit geblockt ist und was (Stand heute) als nächstes kommen wird. Sie können bei Problemen Ursachenforschung betreiben und erste Hypothesen zur Behebung entwickeln und dann verproben.

Wichtig dabei nur: Modellieren Sie das Kanban-Board wie die Arbeit real getan wird – nicht nach definierten Soll-Prozessen in irgendwelchen Handbüchern (ja, das ist durchaus ein Unterschied!). Ein erster Wurf ist dabei für den Start gut genug – kein Board ist in Stein gemeißelt, Sie können (und sollen!) anpassen.

Stolperstein 3: Beteiligte sind überlastet, weil es keine Regulierung der nachfließenden Arbeit gibt

Auf der Suche nach besseren Ergebnissen ist das Sichtbarmachen der Arbeit über Karten am Board ein guter und wichtiger erster Schritt, reicht jedoch immer noch nicht aus. Um Ihr System dauerhaft zu entlasten und wieder Arbeit fließen lassen zu können, müssen Sie sich selbst begrenzen.

Viele Beteiligte stellen sich die Frage „Welches Limit ist für mein Team richtig?”

Zu Beginn kommt es nicht auf die Zahl selbst an, sondern darauf, DASS Sie sich sich darauf verständigen, Arbeit eben nicht mehr unlimitiert ins System eintreten zu lassen. Als Faustregel für den Start im Team hat sich bei mir bewährt: immer eine Karte weniger zu haben, als Menschen im Team. So erreichen Sie , dass (statt dem Aufbau von Warteschlangen) immer eine Person verfügbar ist, um sich um Probleme oder z. B. ohne Zeitverzögerung um Code Reviews zu kümmern.

Stolperstein 4: Beteiligte sind verwirrt, weil Sachverhalte unterschiedlich interpretiert werden

Sicher haben Sie auch schon Sätze wie „Ich verstehe nicht, wo hier ein Problem ist. Ich dachte, die Dinge sind klar!“ gehört.

Wir Menschen haben ein großes Problem. Wir können Informationen nicht von einem Gehirn ins andere kopieren. Jeder Mensch bringt seinen eigenen Kontext und seine eigenen Erfahrungen mit, daher schwingt in der Kommunikation stets das Sender-Empfänger-Problem mit: Was für Sie klar sein mag, muss noch lange nicht für Ihren Gesprächspartner genauso klar sein. Nur im gemeinsamen Dialog (und der Dokumentation) finden Sie heraus, ob und wie klar die Dinge wirklich sind. Daher: Machen Sie Dinge explizit!

• „Eine Arbeit ist bei uns dann fertig, wenn xyz getan ist.“
• „Für ein Code Review werden immer zwei andere Peers benötigt.“
• „Bevor wir wirklich fertig sind, muss Person Z darüber schauen und abnehmen.“
• …

Ihre Policies sind so individuell wie Sie selbst – daher empfehle ich, diese aufschreiben. So werden Missverständnisse und Fehlinterpretationen minimiert.

Übrigens: Auch Ihre Stakeholder werden Ihnen danken, wenn sie erfahren und verstehen können, was Sie auf welche Weise tun müssen. Und wer weiß, vielleicht ergibt sich dadurch sogar eine Diskussion darüber, ob man bei Ihnen alles wirklich genau so tun muss.

Stolperstein 5: Teams stochern im Nebel, weil keine Metriken verwendet werden

Sie müssen regelmäßig evaluieren können, wo Sie aktuell stehen. Dazu brauchen Sie objektive und widerspruchsfreie Kriterien. Niemandem ist gedient, wenn Sie nur anhand von Meinungen oder Gefühlen agieren – die Gefahr ist zu groß, dass dann die hierarchisch höher gestellte Meinung zählt.

Ich vereinbare mit Teams immer, dass wir zwei Metriken zur Systembeschreibung verwenden:

• Lead Time und
• Durchsatz.

Die Lead Time gibt Ihnen eine Antwort darauf, wann ein beliebiges Arbeits-Item bei uns fertig wird. Und der Durchsatz gibt Auskunft darüber, wie viel Sie in einem definierten Zeitraum fertig stellen können.

Übrigens: „Wenn Messwerte ein Ziel werden, hören sie auf, gute Messwerte zu sein.“ – Charles Goodhart

Stolperstein 6: Kein Blick auf Flow

Sie versuchen mit Kanban, den Fluss der Arbeit zu verbessern. Eine gute Time to Market oder schnelle Feedback-Zyklen lassen sich nur erreichen, wenn Arbeit zügig und ohne Friktionen durch Ihr System fließen kann. Das ist der Gegenentwurf zu maximaler, individueller Auslastung.

Sie richten Ihren Blick daher nicht mehr darauf, was jeder einzelne über den Tag getan hat, sondern wie gut die aktuelle Arbeit auf ihrem Weg vorangekommen ist. Wenn sich Blocker auftun, ist das gesamte Team gefordert, SOFORT an der Beseitigung zu arbeiten. Vielleicht ist diese die größte Hürde von allen: die Vermeidung von Beschäftigung um der Beschäftigung-Willen.

Fazit

Kanban ist – wie Scrum – nicht einfach und kann sehr anstrengend sein. Wenn Sie die beschriebenen Stolperfallen vermeiden, senken Sie die Hürden für eine erfolgreiche Einführung deutlich. Im laufenden Betrieb müssen Sie sich dann um regelmäßige Kommunikation und Darstellung der aktuellsten Messwerte kümmern. Dann sind Ihrem Erfolg keine Grenzen mehr gesetzt.

Hinweise: 

Wenn sie Fragen haben oder mehr erfahren möchten, können Sie gerne einen Termin mit Daniel Westermayr vereinbaren. Weitere Artikel von Daniel Westermayr finden Sie im Blog von Colenet.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads und Empfehlungen.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.