Agile Success Stories: das Warnsignal

Bild: Pexels / Andrea Piacquadio - Lizenz

Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Die heutige kleine Geschichte habe ich in einem grossen Industriekonzern erlebt, der in mehreren Grossprojekten seine Anlagensteuerung und -überwachung digitalisierte und modernisierte. Diese Projekte waren zu Beginn alle nach Wasserfall durchgeführt worden, das in dem ich zeitweise war, war eines der ersten in denen agil gearbeitet wurde - unter misstrauischer Beobachtung übrigens, da es das verbreitete Vorurteil gab, dieser Arbeitsmodus wäre unzuverlässig und unsicher.

Wie man sich denken kann hakte es an einigen Stellen, unter anderem waren viele Stakeholder lange nicht bereit an den Sprint Reviews teilzunehmen, solange noch nicht alle Anforderungen vollständig umgesetzt waren.¹ Erst eine Management-Intervention konnte das ändern, und so liessen sich ein Vierteljahr vor dem Go Live eines neuen Überwachungssystems endlich einige der zukünftigen Anwender vom Entwicklungsteam den bisher fertiggestellen Umfang vorführen.

Einer dieser zukünftigen Anwender war deren Teamleiter, ein Ingenieur namens Xin Mi.² Mit strengem Blick verfolgte er die Vorführung, stellte mehrfach Nachfragen und machte sich jedesmal kopfschüttelnd Notizen, wenn er über ein Feature hörte, dass es erst in einem der kommenden Sprints umgesetzt werden würde. Irgendwann wurde er dann plötzlich hektisch und aufgeregt. Laut auf deutsch, englisch und chinesisch schimpfend stürmte er aus dem Raum, immer wieder "das geht so nicht" rufend.

Sein Problem: die Überwachungs-Ergebnisse des neuen Systems wurden in Echtzeit auf einem Bildschirm angezeigt. Was niemand dem Entwicklungsteam gesagt hatte war aber, dass der nur einer von über 20 auf einer ganzen Bildschirm-Wand sein würde. Was Xin Mi zurecht anmerkte - der davor sitzende so genannte Operator könnte eine auf nur diesem einem Bildschirm angezeigte Störungsmeldung leicht übersehen, und auch der Warnton war so leise, dass er in einem solchen Raum überhört werden könnte.

Etwas irritiert von dem Ausmass des Dramas überlegte das Team sich im folgenden Planning eine Lösung: der Warnton wurde lauter und durchdringender und um den Bildschirm wurde bei Störungen ein rot blinkender Rahmen angezeigt, um den Blick dorthin zu lenken. Die Umsetzung passte auch irgendwie noch in den nächsten Sprint hinein. Der immer noch aufgebrachte Xin Mi war zwar nicht bereit, während des Sprints darüber zu reden, zum nächsten Sprint Review kündigte er sich aber an.

Diesesmal tauchte er in Begleitung mehrerer Manager auf und verhielt sich wieder überraschend. Direkt zu Beginn verlangte er die Agenda umzustellen und mit der Störungsmeldung zu beginnen. Leicht irritiert gab das Entwicklungsteam diesem Wunsch nach und führte die Ergänzungen des letzten Sprints vor. Xin Mi, der gerade angesetzt hatte, den mitgebrachten Managern zu erklären, wie schlimm alles wäre, war völlig perplex. Dass sein Problem plötzlich gelöst war, war für ihn unbegreiflich.

Sein verdattertes Schweigen wurde von den Entwicklern falsch interpretiert und für Unzufriedenheit gehalten, also machten sie ein weiteres Angebot: Wenn Warnton oder Signalfarbe nicht passen würden könnte man auch das im nächsten Sprint noch ändern, jetzt, da die Funktionen da wären, wäre das kein Problem mehr. Für Xin Mi war das zu viel. Mit Tränen in den Augen stand er auf, bedankte sich überschwänglich und entschuldigte sich für sein bisher ablehnendes Verhalten.

Zum Hintergrund: in den bisherigen Wasserfallprojekten waren auch kleinste Änderungen der Anforderungen nur mit erheblichen bürokratischen Aufwänden machbar gewesen. Da neue Funktionen in den alten Anwendungen nur zweimal pro Jahr released wurden, waren diese Releases aufwändig und fehleranfällig, was dazu geführt hatte, dass zusätzliche Änderungen möglichst abzulehnen waren. Für jemanden der aus einer solchen Welt kommt, sind Auslieferungen alle zwei Wochen unvorstellbar.

Obwohl (oder vielleicht gerade weil) die hier beschriebene Anpassung nicht besonders gross war, war ihre schnelle und unkomplizierte Umsetzung für Xin Mi ein Erweckungserlebnis. Er wurde zum begeisterten Teilnehmer der Sprint Reviews und zum grössten Fürsprecher des agilen Arbeitens in seiner Abteilung und zog sogar zeitweise in das Büro des Entwicklungsteams, um so einen noch engeren und intensiveren Austausch haben zu können. Ein Stakeholder wie man ihn sich wünscht.

Geschichten wie seine (von denen ich einige erlebt habe) kann man sich immer wieder vor Augen führen, wenn andere Dinge nicht funktionieren wie gehofft. Sie sind nicht so imposant wie ein grosses Kulturwandel- oder Skalierungsprogramm, in Summe aber für die Akzeptanz und den Erfolg agiler Produktentwicklung viel, viel wichtiger. Und dieser eine Moment, in dem aus Wut Unglaube und aus Unglaube Begeisterung und Dankbarkeit wurde, ist einer, der im Gedächtnis hängen bleibt.

¹Was natürlich den Zweck dieses Termins konterkarierte
²In Wirklichkeit hiess er anders, Xin Mi ist für diese kleine Geschichte sein Pseudonym