Um mich zu entspannen stelle ich Domino Steine in eine Reihe und erfreue mich daran, wenn zum Abschluss ein Stein die ganze Reihe zum Fallen bringt.
Danach denke ich an etliche Teamsitzungen vor großen Releases. In einem Fall hatte das PMO (Project-Management-Office) alle Formen von Metriken angewandt und zwei Wochen vor dem Release-Termin alle Ampeln auf Grün gestellt. Sämtliche Product-Owner standen mit stolz geschwellter Brust im Termin, und auch Teile der Führungsmannschaft kamen zur Projektsitzung, denn der CIO (Chief Information Officer) hatte seine Teilnahme angekündigt. Schließlich und endlich sollte nach 9 Monaten ein neuer Mandant aufgeschaltet werden, und nicht weniger als 53 Applikationen (Produkte) waren betroffen. Die IT-Führung (CIO) hatte diesmal – es war schon der dritte Anlauf – der Unternehmensleitung vorzeitig mitgeteilt, dass alle Entwicklungen erfolgreich abgeschlossen seien.
Zwei Stunden vor der Sitzung hatte ich ein Gespräch mit dem Qualitäts- und Testmanager. Große Teile des fertig gemeldeten Codes waren noch immer nicht eingecheckt, und es bangten alle Beteiligten ob das Lade-Script für die Debitoren-Stammdaten laufen würde. Das heißt, eigentlich glaubte auf Mitarbeiterebene niemand daran, dass das Script erfolgreich durchlaufen würde. Dennoch hatten die zuständigen Abteilungsleiter am Vortag alle Arbeiten als abgeschlossen und getestet gemeldet.
Wie an jedem Morgen hatte ich die Raucherecke aufgesucht und mich mit den Kollegen unterhalten. Einige Kollegen waren schon seit 5 Uhr im Büro und noch immer dabei, Code zu schreiben. Sie waren im intensiven Austausch über verschiedene Lösungsvarianten und trotz des möglichen Code-Freeze am heutigen Tag sehr entspannt. Sie scherzten darüber, dass ihre Entwicklung ja nur an verfügbaren Debitoren-Stammdaten getestet werden könne. Die Abteilungsleitung der Debitoren-Abteilung (in der IT) hatte eine Sonderstellung im Hause und ließ keine direkte Ansprache ihrer Mitarbeiter zu, was allgemein durch die Führung geduldet wurde.
Ich machte mich erst auf den Weg zur Abteilungsleiterin der Debitoren-Abteilung die versicherte, dass alles OK sei. Trotzdem ging ich dann zum zuständigen Mitarbeiter ihres Teams. Er war nicht gesprächsbereit, da er nicht durfte, aber die Anspannung war ihm anzusehen. Er hatte auch das Wochenende durchgearbeitet und versuchte noch immer, zwei Fehler im Lade-Script für die Debitoren-Stammdaten zu lösen.
Zurück in der Sitzung meldeten alle Applikationsverantwortlichen wie erwartet Grün und der CIO war zufrieden. Ich äußerte starke Bedenken und erklärte an einem Beispiel welche Abhängigkeiten vorhanden waren und argumentierte, dass wir uns nicht an verbalen “Fertigmeldungen” einzelner Komponenten sondern an erfolgreichen Tests des Gesamtsystems messen müssten.
Wir spielten eine Auftragsabwicklung verbal durch, also einen Vorgang, der mehrere Teile des Gesamtsystems durchläuft. Die Nachfragen gingen von einer zur nächsten Person, wurden spezifischer, und mehr und mehr Unsicherheit machte sich breit.
Am Ende blickten alle zur Abteilungsleiterin der Debitoren, die mit einem Lächeln versicherte, dass ihre Entwicklung ohne jegliche Einschränkung fertiggestellt worden wäre, hätten ihre Kollegen nicht permanent verspätet zugeliefert. Damit war der erste Dominostein gefallen: Sie hatte zugegeben, dass ihr Teil nicht wirklich fertig war. Nun fielen auch die anderen Dominosteine – eine Entwicklungsabteilung nach der nächsten meldete gravierende Fehler und Probleme. Das Release musste also ein weiteres Mal in letzter Minute abgesagt werden.
Im Nachgang übernahmen wir die Gesamtsteuerung ausnahmslos aller Entwicklungsabteilungen und der gesamten technischen Testtruppen. Das nachfolgende Release brachte dann die gewünschte Qualität.
Es gibt einige Lehren, die man aus dieser Geschichte ziehen kann:
Christoph Lefkes