He broke the build!

Risiken materialisieren sich, Fehler passieren. Minütlich, stündlich, täglich. Ein großer Fehler kann eine gesamte Firma in ihrer Existenz gefährden (oh, ROT). Genauso wieviele kleine Fehler dies tun können.

Eine Firma, in der Fehlerbearbeitung vorallem als Basis für Schuldzuweisungen dient, hat neben Fehlern auch noch demotivierte und ängstliche Mitarbeiter. Mitarbeiter, die Angst haben, meiden die Bearbeitung von risikobehafteten Komponenten (wo sich der Bauch rührt). Damit werden Fehler größer, weil kritische Themen zu spät angepackt werden.

Angst kostet Geld

Eine gute Fehlerkultur im Unternehmen benennt Fehler transparent und ohne Schuldzuweisungen. Und die gesamte Organisiation lernt aus den benannten Fehlern und vermeidet diese zukünftig. 

 

Viele der Rituale, die um "He broke the build" geschehen, sind Teamregeln. Wenn Teams Rituale entwickeln, um auf Fehler aufmerksam zu machen, ist das erstmal gut. Wenn diese Rituale von einigen gefürchtet werden, ist das schlecht. Sehr schlecht. 

 

Eine Bildersuche in Google nach "He broke the build" führt zu einer Vielzahl von Bildern, die von Perücken, Eimern oder sonstigen Devotionalien strotzen, in den einzelne Entwickler dafür "ausgezeichnet" werden, fehlerhafte Software ausgeliefert zu haben. Man kennt auch Fälle, dass Entwickler unter Tischen entlang krabbeln müssen oder Pokale verliehen bekommen (IRL oder im Ticket). Viele Teams scheinen sich mehrheitlich also für eine starke "Auszeichnung" entschieden zu haben. 

 

Alle diese "Auszeichnungen" beziehen sich auf einzelne Personen. Gleichzeitig proklamieren sie, das es gemeinschaftliche Code Ownership gibt. Einzelne Auszeichungen widersprechen der Teamverantwortung für den Code. Wenn Fehler passieren, ist das gesamte Team beteiligt.

 

Wenn das geschieht, kann eine Teamregel sein, dass dies öffentlch gezeigt wird. Z.B. ein blinkendes Wallboard oder ein Hinweis auf der Wandzeitung. 

Nicht nur der Erfolg gehört dem Team - sondern auch alle Fehler

Der Umgang mit Fehlern erfolgt mit Respekt und dem Wissen, dass Fehler jedem jederzeit passieren können.

1. Jeder im Team bekennt sich zu seinen Fehlern. Alle. Auch Vorgesetzte und Geschäftsführung.
2. Kennzahlen über Fehler (Anzahl offener Tickets, Anzahl Blocker) werden öffentlich gemacht. Der Verlauf dieser Zahlen wird öffentlich gezeigt und diskutiert.
3. Der letzte Verursacher in der Kette wird nicht bloßgestellt. Sondern die Fehler werden gemeinsam analysiert und neue Vorgehensweisen beschlossen.

Dies erfolgt in regelmäßig stattfinden Review-Meetings.  Das Team geht den Ursachen für Fehler auf den Grund.

1. Ist das Ziel klar? 
2. Gibt es Kompetenz-Defizite? 
3. Müssen wir unsere Zusammenarbeit anders gestalten?
4. Brauchen wir neue Team-Regeln?

Review-Meetings finden immer statt. Auch wenn es vermeintlich gut läuft. In "guten Phasen" schleichen sich Themen ein, die in Krisen eskalieren können. Der wache und offene Umgang mit Fehlern spart Aufwände und Nerven.

 

Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.