Fehler korrigieren oder Probleme lösen: von Agile zu Lean (2/2)

 

 

 

 

 

 

Ein Beitrag von Cecil Dijoux (Fortsetzung)

Zur Erinnerung an die Episode 1 über das, was ein Agile Team von einem Lean Team unterscheidet: Aufgrund der fehlenden Qualitätskontrolle während des Prozesses („built-in-quality“) wird nicht sichergestellt, dass ein Entwicklungsteam nicht Fehler von einem Schritt zum nächsten weitergeben wird. Keinerlei Standard verpflichtet das Team, bei jedem Problem innezuhalten und zu versuchen, das Problem zu verstehen. Zudem kann das Team nur aufgrund einer Makro-Analyse nach einem neuen up-date nach 6 Monaten nicht erfahren, welche direkte Korrelation es zwischen seinen Verbesserungsschritten und der täglichen Performance gibt.

In dieser zweiten Episode werden wir nun sehen, wie es in einem Lean Team abläuft und wie man ein Agile Team zu einem Lean Team umformen kann.

Was in einer mehr „Leanen“ Umgebung passiert

Zwei Jahre später bin ich in der gleichen Organisation Leader und Coach geworden mit der Aufgabe, Agile im Rahmen eines großen Multi-Team und Multi-Technologie Projektes einzuführen. Eines der Teams entwickelte eine komplexe Technologie-Integration mit einer Technologie, für die wir nicht wirklich Experten waren. Dieses Team war nicht in der Lage, eine einzige „User Story“ im Laufe der letzten beiden Sprints abzuliefern und hatte Qualitätsprobleme mit vielen Bugs. Im Rückblick auf die letzten beiden Sprints entschied das Team, wöchentlich die Fehler zu analysieren (auf der Basis von der „roten Körbe“ in der Lean-Sprache). Es begann also, ein Pareto über die Probleme aufzuzeichnen.

Von nun an setzte es sich als Ziel, die Ursache jeder Gruppe von Bugs zu eliminieren, eine nach der anderen, und dabei mit der Gruppe des häufigsten Auftretens zu beginnen. Um die Zusammenarbeit bei dieser Aufgabe zu verbessern, entschied der Scrum Master, das Pareto mit der Anzahl der Bugs neben dem Scrum Board anzubringen und es täglich upzudaten. Jeder neue Fehler wurde unverzüglich in der Morgenbesprechung berichtet, wenn das Team seine „Fehler des Tages“ berichtete. Das machte die tägliche Qualität explizit und konkret für das ganze Team. Das half auch, den Schritt „C“ des PDCA zu gehen: den Check. Wenn das Problem behoben ist, darf es auf der entsprechenden Zeile keinen derartigen Fehler während einer Woche mehr geben. Wenn er doch passiert, ist das eine neue Möglichkeit zu lernen!

Ein Beispiel: Das Team erkennt als Gruppe von Fehlern eine ungewollte Rückkoppelung: Eine Änderung des Software unterdrückte eine existierende Funktionalität. Das zeigte sich generell an der Nutzerschnittstelle, was sehr schwierig ist, automatisch zu testen. Eine der Ursachen (root causes) war die Unerfahrenheit der jüngsten Entwickler, die sich nicht immer im Klaren über die Auswirkungen ihrer Modifikationen waren. Als Gegenmaßnahme wurde ein neuer Schritt in den Prozess integriert, ein Review des Codes mit einem älteren Entwickler vor seiner Implementierung. Dieser 15-minütige Schritt reduzierte nicht nur drastisch die ungewollte Rückkoppelung, was täglich anhand der Zahl der Bugs pro Release (2 pro Tag) sichtbar wurde, sondern erlaubte auch, die Kompetenzen der jüngeren Entwickler zu verbessern.

Schließlich waren alle Probleme behoben und die Resultate waren bemerkenswert: Die Fehler wurden durch diesen Standard einer nach dem anderen eliminiert (Code Review vor Implementierung). Die Zahl der täglichen Fehler fiel und die Zahl der ausgelieferten User Stories – Funktion ohne Fehler – stieg mit jedem Schritt. Nach 3 Monaten wurde das Team, das den traurigen Rekord bei der Fehlerlieferung im Projekt hatte, ein Musterteam bezüglich schneller und qualitativ hervorragender Lieferung.

Dieser Ansatz, „leaner“ als der vorherige, hat eine direkte Rückwirkung auf die tägliche Performance (Qualität) und die Produktivität (Zahl der User Stories), und das Team legte die Latte hoch für die operationellen Standards.

Beispiel von Performance-Indikatoren für ein Agile Team

Ein Agile Team in ein Lean Team umformen

Anhand dieser Beispiele und dessen, was ich gelernt habe, schlage ich hier einen Ablauf vor, um ein Agile Team in ein Lean Team umzuwandeln:

Die Performance messen, sie sichtbar machen und jeden Tag besprechen

Was jetzt folgt ist vielleicht etwas schwierig zu lesen für Agile Coaches, aber die Wahrheit ist: Wenn man etwas verbessern möchte, muss man es messen. Genauso, wie man nicht lernt, außer man stellt sich der Realität. Genau so machen es die Giganten des Web (Google, Amazon, Twitter, Facebook) und andere führende Organisationen, wie Etsy: Sie messen fast alles. Nicht einfach, indem die Stories gezählt werden, wodurch sie wurden, was sie sind!

Ein konkretes Beispiel für ein Agile Team: Neben dem „Burndown Chart“ des Sprint eben auch die Qualitätsperformance zeigen (Zahl der noch offenen Bugs, Bugs pro Release, pro Gruppe, etc.), die Kundenzufriedenheit (Note von 1 – 10 je User Story z.B.) und sich jeden Tag fragen, warum man das Ziel auf dem Burndown Chart nicht erreicht hat.

Sich vergewissern, dass die Probleme im „Lean“-Sinne des Wortes dargestellt sind

Ein Problem muss dargestellt werden als Differenz zwischen dem Ziel und der gemessenen Performance. Das Pareto ist ein Werkzeug, um die nackten Daten in Gruppen zu ordnen. Aber es benötigt eine zusätzliche Analyse um zu verstehen, wie jede Gruppe die Performance beeinträchtigt.

Auf diese Weise ist man sicher, das Problem sauber formuliert zu haben und es aus dem Blickwinkel der ökonomischen Performance richtig anzugehen.

Probleme eins nach dem anderen behandeln, dann wenn sie auftreten

Einer der Schlüssel von Lean bei der Problemlösung: Man behandelt nicht mehrere Probleme gleichzeitig. Man geht nur eines an, um seinen Einfluss auf die Leistungs-Indikatoren zu verstehen und um sich zu vergewissern, dass man den Zusammenhang von Ursache und Wirkung versteht.

Nachprüfen!

Erfahrungsgemäß ist das der Schritt, den man am Leichtesten vergisst. Seine Erwartungen mit der Realität konfrontieren. Hat es nicht geklappt wie erhofft? Super! Was kann man daraus lernen? In diesem Raum zwischen dem Erwarteten und dem Eingetretenen vollzieht sich der Lernprozess. Genau das passierte dem 2. Team. Wie es J. Spear in Chasing the Rabbit erklärt, klopft hier Ihre innere Organisation an Ihr Ohr : «  Es gibt etwas, das du noch nicht weißt. Aber wenn du aufmerksam hinhörst, werde ich es dir sagen.“ Genau an dieser Stelle entwickelt ein Team seine Erfahrungen über seine eigene Arbeit und seine Prozesse, und wird ganz plötzlich ein „Dream Team“.

Von Agile zu Lean

Ich war ein „Agiliste“ seit 2004, habe mich aber zu Lean hin entwickelt im Laufe der letzten Jahre. Das erlaubte mir, Hindernisse zu überwinden, die ich mit Agile allein nicht hätte meistern können.

Lean erlaubte mir, über Agile hinauszugehen, Methoden der kontinuierlichen Verbesserung aufzunehmen, die einen direkten Effekt auf die Performance des Teams und seines Engagements haben. Eine klare Unterscheidung zwischen Fehlern und Problemen vorzunehmen war entscheidend für diesen Fortschritt.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s