Keynote-Transkription 12

Zero bug tolerance – wenn handwerkliche Fehler tödlich sind

Das war der erste Block und ich sage mal der war noch so ziemlich un-agil. Da haben wir noch gar nichts über Teamdynamiken gelernt, da haben wir eigentlich nur gelernt: Last aus dem System zu nehmen bringt unheimlich schnell einen sehr großen Effekt. Das nächste ist jetzt wirklich in die Teamdynamik reinzukommen, da ist das Konzept des frühen Scheiterns essentiell.

Scheitern soll auf allen Ebenen möglich sein. Das heißt sowohl das Scheitern von Einzelpersonen im Sinne einer zero bug tolerance: Wie kann ich handwerklich gute Arbeit abliefern? Hin zu crossfunctional teams: Wie können Teams sich schnell Feedback geben und auf Teamebene Fehler feststellen und beheben. Bis hin zu continous feedback um über die Unternehmensgrenzen hinaus mit dem Kunden zusammenzuarbeiten und Fehler in den Anforderungen festzustellen.

Zero bug tolerance. Ich war vor ein paar Tagen auf einem Workshop in Heppenheim. Der große Sohn von Heppenheim ist Sebastian Vettel. Sebastian Vettel hat zu mal gesagt: „Ich werde in meiner Karriere viele Fehler machen. Aber keinen davon zwei mal.“ Das hat er nicht erst jetzt vor kurzem gesagt, als er schon sehr erfolgreich war, sondern das hat der Kerl mit 20 Jahren gesagt, das war ein Commitment, das war ein Konzept. Hinzugehen und zu sagen: Ich weiß, dass ich Fehler machen werde aber ich werde aus jedem lernen und ich sorge dafür, dass sie kein zweites mal auftreten, das ist letztendlich die Sicherstellung einer guten handwerklichen Qualität. Das ist äußerst wichtig auf dieser ersten Ebene. Auch wieder eine Grafik dazu: Ich kann entweder hingehen und über das komplette Projekt abwarten was nach einem Fehler passiert. Die typische Entwicklung dabei ist, dass sich die Auswirkungen der Fehler im Laufe des Projektverlaufs exponentiell steigern. Nachher hat man dann eine rießige Menge an Arbeit um den ganzen Fehlerberg wieder auf Null zu bringen. Dass Sie linear schaffen ist auch wieder nur eine Best-Case-Vermutung, in der Regel haben Sie hier eher wieder exponentielles Verhalten und damit eine Fehlerkurve die sich bis in die Unendlichkeit zieht. Dadurch haben Sie dann technical debts im Nachfolgeprojekt und muss immer wieder Balkone anbauen.

Wie kann man das machen? Indem man den Zeitraum bis zur Erkennung eines Fehlers extrem verkürzt und ihn nach der Entdeckung auch direkt behebt. Wenn ein Fehler aufgetreten ist wird er also direkt behoben und es wird auch vorher nicht mit anderer Arbeit weitergemacht.

((Darf ich dazu was fragen? (Ja bitte) Ist dann auch Pareto falsch? Weil Sie gerade sagten wenn ich etwas tue dann bitte richtig, fokussiert und auch fertig? Weil Pareto ja immer sagt 80-20, it’s good enough. Es ist aber nicht immer good enough und also das wird oft verwechselt. Gehört das dazu oder ist das jetzt falsch interpretiert?))

(Und ich glaube da sind wir genau zwischen diesen beiden Ebenen. Pareto sehe ich so: Wenn man in die Praxis geht und man möchte für den Kunden etwas entwickeln, dann ist es häufig richtig mit dem Pareto-Prinzip, also mit good enough ranzugehen, um schnelles Feedback zu bekommen. Weil ich weiß ja an der Stelle noch nicht genau, was ist eigentlich der Kundenwunsch. Aber bei zero bug tolerance da ist die „zero“ sehr wichtig. Da müssen Sie wirklich knallhart danach schauen, dass alle erkannten Fehler sofort behoben werden und keiner übrig bleibt.)

Im Prinzip ist das wieder ganz ähnlich wie wir es eben auch schon gesehen haben beim Portfolio was auf links gedreht wurde. Man holt sich Probleme früh an sich ran, behebt sie und sorgt damit zum einen dafür, dass das Projektrisiko minimiert wird. Man bekommt eine gute Kontrolle, da freut sich auch das Qualitätsmanagement. Und zum anderen spart man auch hier wieder extrem viel Zeit, weil man nachher nicht diese Bugfixing-Phase zum Ende des Projekts hat.

Weiter zu Keynote-Transkription 13