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

Ein Beitrag von Cecil Dijoux

(Dieser Artikel wurde zunächst in Englisch auf Info@.com publiziert.)

Man kann Lean auf verschiedene Arten definieren. Aber die motivierendste Definition ist diejenige des Gründers des Lean Enterprise Institutes, John Shooke , in seinem Buch „Managing to Learn“: Lean Management besteht darin, Produkte zu entwickeln, indem man die Mitarbeiter entwickelt.“

Er erklärt, dass Lean bedeutet, seine Mitarbeiter durch die Lösung von Problemen zu entwickeln: Die Arbeit wird so gestaltet (und auch die Chancen auf Erkenntnisgewinn), dass Probleme sichtbar gemacht werden, mit Hilfe einer wissenschaftlichen Herangehensweise, um sie Schritt für Schritt dann zu lösen, wenn sie auftreten.

Als ich mit Agile Teams an Software-Entwicklung gearbeitet habe, verwechselte ich Fehler und Probleme: Ich dachte, der Agile-Prozess sei Lean, weil er die Fehler erkennbar machte. Seitdem, mit einigem Abstand, habe ich verstanden, dass ein Agile Team, das Fehler produziert, nichts mit einem Lean-System zu tun hat, das Möglichkeiten des Lernens produziert: Es war damals nur ein Team mit Qualitätsproblemen, wie ich es schon oft gesehen habe.

Mein Verständnis von Fehlern und Problemen hat sich weiter entwickelt. Das Ziel dieses Artikels ist es, Ihnen Wegweiser zu geben, wie Probleme, die Fehler produzieren, besser verstanden werden können, um die Performance zu verbessern. Und dies mit illustrativen konkreten Beispielen (damit will ich keineswegs sagen, dass alle agilen Teams die gleichen Probleme haben) …

Was ist ein Fehler, ein bug?

Das Wort „bug“ hat in der Softwareentwicklung mehrere Bedeutungen: Es kann sich um einen Systemfehler handeln (NullPointerException, Fehlercode 404 http, blauer Bildschirm, …), ein Funktionsproblem (wenn ich auf B klicke, sollte das System Z machen, macht aber Y), ein Leistungsproblem, ein Konfigurationsproblem, etc.

Ein bug, ein Fehler, ist also kein Problem im Sinne von Lean des Wortes solange er nicht entsprechend verstanden wird (siehe dazu nächster Absatz). Ich habe eine ganze Reihe solcher Fehler gesehen (und auch selbst produziert), und 95% der Fehler waren keine Probleme. Mit Ausnahme vielleicht von Fehlern bezüglich der Performance.

Was ist das, ein „Problem“?

Die Standarddefinition im Toyota Way Field book von Jeffrey Liker beschreibt die 4 Bedingungen für die Definition eines Problems:

1 – die aktuelle Performance

2 – die gewünschte Performance (Standard oder Zielvorgabe)

3- die Bedeutung des Problems, wie definiert durch den Unterschied zwischen aktueller und angestrebter Performance

4 – Die Tragweite und Charakteristika des Problems.

Wie Bené Brown in seiner Darstellung über die Anfälligkeit TED talk about vulnerability es sagt: „Was man nicht messen kann, existiert nicht.“ Oder konkreter, wenn man ein Problem nicht durch Performance-Abweichungen erläutern kann, dann hat man vermutlich nicht genug nachgedacht.

Bevor man beginnt an einem Problem zu arbeiten, muss man es unbedingt klar umschreiben, sich die Zeit nehmen, es zu verstehen (der Lean-Experte Michael Ballé sagt sogar, man muss es „positiv werten“) und der Versuchung widerstehen, eine Lösung vorzuschlagen.

Einstein meinte dazu: „Wenn ich eine Stunde hätte, um ein Problem zu lösen, würde ich die ersten 55 Minuten darauf verwenden, über das Problem nachzudenken, und 5 Minuten über die Lösung.“  Dabei sagt niemand, dass das einfach wäre!

Im Rahmen einer agilen Softwareentwicklung können die Performance-Indikatoren Diagramme sein (Kosten und Verspätungen), Zahl der Anomalien, Antwortzeiten (Qualität), Kundenbewertungen über die gelieferten Lösungen an Nutzer (User Stories) (Note auf einer Skala bis 10 der Kundenzufriedenheit) und die Zahl der gelieferten Lösungen pro Sprint (Produktivität).

Hier einige Beispiele von Problemen, gegründet auf solchen Indikatoren:

Qualität: Zielvorgabe für die Antwort einer vorgegebenen Seite ist 500 ms, aber wir haben 1500 ms gemessen, bei einer gleichzeitigen Nutzung durch 5000 Personen.

Qualität: Die Zahl der Anomalien die nach einem Sprint verbleibt (2 anstatt 0).

Kosten / Verzögerungen: Wir setzten 3 Tage an, um eine User Story zu schaffen. Wir haben aber 8 Tage gebraucht.

Produktivität: Das Team hat am Ende des Sprint 5 User Stories anstatt 7 liefern können.

Kundenzufriedenheit: Wir möchten eine Note von 8/10 pro Story haben, aber wir haben beim letzten Sprint zwei gehabt, die darunter lagen (6,5 bzw. 7).

Wie kann man nun Probleme identifizieren?

Anomalien oder bugs sind eher generelle Symptome von Schwierigkeiten, und es ist zwingend, das Verhältnis zwischen den Symptomen und tatsächlichen Problemen zu verstehen. Man könnte annehmen, die Arbeit von Teams, die sich der täglichen Verbesserung verschrieben haben, sei die Identifizierung und Behebung der Probleme aus dem Stapel der Fehler. Das verlangt eine Analyse und eine Umwandlung der gefundenen Punkte in Lernmöglichkeiten.

Ich habe einen Weg gefunden, indem ich die Anomalien in Kategorien gesammelt  und dann jeder eine Bedeutung zugemessen habe. Meistens ist ein bug die Ursache eines tatsächlichen Systemfehlers oder ist selbst ein Problem. Mit dieser Zuordnung ist man sicher, die Probleme in der richtigen Reihenfolge anzusprechen. Dabei beginnt man mit demjenigen, das den größten Einfluss hat auf die operationelle Performance. Wenn man immer noch nicht weiß, wo man beginnen soll, liefert Lean  uns einen guten Hinweis: Lean sagt uns, mit der Qualität zu beginnen.

Beispiel 1: in der Agilen Welt

Ich war Manager eines agilen Entwicklungsteams. Wie so häufig handelte es sich nicht um ein funktionsübergreifendes Team, sondern um ein Team wie in einem Silo, das iterativ arbeitete und dabei Server-Software für Anwendungsteams entwickelte, die andere Iterationen nutzten.

Mit Hilfe von Pareto-Analysen über Anomalien identifizierten wir eine Gruppe von Anomalien, die 20% repräsentierten: festgestellt von den Anwendern und bezogen auf die Definition von „implizit“ des API auf der Serverseite der Software.  Als die Fachteams diese Services nutzten, stellten sie fest, dass bei der Eingabe Parameter fehlten und bei der Ausgabe Daten, etc. … Außerdem fanden sie bugs, indem sie Daten auf der Ausgabeseite mit den erwarteten Ergebnissen verglichen. Das Entwicklungsteam sagte daraufhin: Aber das ist implizit vorgegeben, dass wir diese Daten nicht wieder ausgeben.

Wir stellten außerdem fest, dass die Lebensdauer dieser bugs, von ihrer Entstehung bis zu ihrer Lösung, ungefähr 4 Wochen war. Der Code wurde erst nach Iterationen von einem Monat abgeliefert, im besten Fall. Sie stießen dabei auf den bug erst 2 – 3 Wochen nach seiner Kodierung ….

Um das zu ändern, entschieden wir, unsere Arbeitsweise zu ändern und die Mitarbeiter interdisziplinär, funktionsübergreifend und in ortsfesten Teams kooperieren zu lassen.

Auf dieser Basis haben wir die „impliziten API“ bugs sehr nachdrücklich (um ca. 50%) reduziert. Noch interessanter aber: Die Lebensdauer der bugs fiel auf 2 Tage. Genauer gesagt, manche bugs wurden repariert ohne ein Ticket zu öffnen, weil die Entwickler sie im gemeinschaftlichen Programmieren gleich korrigierten.

Trotz dieses Fortschrittes war ich nicht zufrieden. Später wurde mir klar, warum: Aus Lean-Sicht gesehen gab es zwei Probleme:

1-Das Weiterbestehen von Anomalien war Ursache für Nacharbeiten und das Entwicklungsverfahren produzierte Waste, also Verschwendungen: mangels Qualität während des Prozesses („built-in quality“) gab es nichts, was ein Weitergeben von Problemen an den nächsten Schritt verhindert hätte. Zudem gab es keinerlei Standard, der das Team dazu verpflichtete, bei jedem Problem zu stoppen und zu versuchen, es zu verstehen.

2-Selbst wenn die Resultate merklich und ermutigend waren, so gab es doch keinerlei Korrelation mit der täglichen Leistung des Teams, was es erlaubt hätte, sofortige Maßnahmen einzuführen und deren Ergebnisse am Tag darauf ablesen zu können. Wir betrachteten nur das Macro-Resultat am Ende eines Updates nach 6 Monaten. Dann aber konnte man nur eine Verbesserung der Qualität aufgrund der funktionsübergreifenden Neuorganisation feststellen, aber es gab kein Mittel, um Verbesserungen tagtäglich zu überwachen und zu entwickeln.

In der Episode 2 sehen wir an einem anderen Beispiel, wie es in einer „Mehr-Lean“ Welt abläuft! Hier in diesem Blog in wenigen Tagen!

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