Agile Success Stories: die Wiederauferstehung des abgeschriebenen Teams

Bild: Pexels / Yan Krukau - 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.

Diese hier begann zuerst wenig verheissungsvoll. Eine der ersten Aussagen am ersten Tag in einem Team, das ich als Agile Coach begleiten sollte, kam vom Product Owner und lautete, dass solange er im Amt wäre nichts neu entwickelt werden und schon gar nichts Neues auf Produktion deployed werden würde. Was auch immer die Entwickler machen würden wäre ihm egal, Hauptsache nichts an der von ihm verantworteten Anwendung. Was für ein Einstieg.

Seine Begründung: die Anwendung sollte schon länger abgelöst werden, in der Nachbarstadt wurde bereits seit zwei Jahren an der Nachfolgelösung gebaut. Er selbst und seine Fachabteilungs-Kollegen würden darum auch nur noch in Teilzeit im Team mitarbeiten, und da jedem Go Live ein von ihnen mit grossem Aufwand manuell durchzuführender fachlicher Test vorausgehen musste, wäre für den einfach keine Zeit vorhanden. Maximal ein Bugfix pro Monat wäre noch irgendwie machbar, mehr nicht.

In diesem scheinbaren Dilemma entdeckten die Entwickler aber auch eine Chance: da sie praktisch nichts mehr entwickeln durften, hatten sie freie Kapazitäten und konnten diese für etwas nutzen, was ihnen der alte, gerade zum Nachfolge-Projekt gewechselte, Product Owner immer zugunsten neuer Features wegpriorisiert hatte: Testabdeckung und Testautomatisierung. Beim nächsten Bugfix sparte die den Fachabteilungs-Kollegen bereits die Hälfte des Testaufwandes ein, beim übernächsten noch mehr.

Anfangs erstaunt und zunehmend begeistert liess der Product Owner nach und nach seine Blockade-Haltung fallen. Angesichts der plötzlich mit geringerem Aufwand machbaren Releases liess er sich nicht nur auf eine Weiterentwicklung der Altanwendung ein, er hatte auch eine Idee was noch zu tun wäre. Das System war noch nicht an die Auswirkungen einiger neuer regulatorischer Vorgaben angepasst, wodurch regelmässige Strafzahlungen fällig wurden. Diese Anpassungen wollte er jetzt nachholen.

In wenigen Sprints war auch das geschafft, und das gerade rechtzeitig, da sich plötzlich eine neue Möglichkeit für zusätzlichen Umsatz und Gewinn ergeben hatte. Ein anderes Unternehmen hatte eine Vertriebspartnerschaft angeboten, für die lediglich eine neu zu programmierende Schnittstelle und einige Datenbankanpassungen nötig waren. Erneut waren nur wenige Sprints nötig um diese fertigzustellen. Der Product Owner und seine Fachabteilungs-Kollegen waren euphorisch.

Weniger euphorisch war das Nachfolgeprojekt, das übrigens aus einem SAFe-Release Train bestand. Die Vertriebspartnerschaft sollte natürlich auch mit dem neuen System möglich sein, weshalb plötzlich dessen Umfang erweitert und dessen Zeitplan angepasst werden musste. Leicht säuerlich eskalierte der Projektleiter (der erwähnte ehemalige PO) bei der Geschäftsleitung, um ab jetzt zu verhindern, dass neue Weiterentwicklungen der Altanwendung die Erstellung der Nachfolgelösung aufwändiger machten.

Zum Glück befanden sich im Backlog des Altanwendungsteams noch weitere Aufgaben. Ein vergangener Penetrationstest hatte potentielle Sicherheitslücken identifiziert, die jetzt geschlossen werden konnten. Zum nächsten Sprint Review wurden die Beauftragten für IT-Security und Datenschutz eingeladen, die gleichzeitig begeistert und erbost waren. Begeistert wegen der Verbesserungen, erbost weil sie inzwischen erfahren hatten, dass diese Lücken auch in der Nachfolgelösung vorhanden waren.

Die weitere Geschichte kann man sich denken: das Nachfolgeprojekt musste erneut Scope und Zeitplan anpassen, das Altanwendungs-Team hatte Zeit für weitere Refactorings und Prozessautomatisierungen und konnte dadurch immer schneller andere, schon lange gewünschte Features einbauen, die das Nachfolgeprojekt dann ebenfalls einplanen musste. Es entstand eine bemerkenswerte Dynamik: das mittlerweile agile Altanwendung-Team konnte vom Ablöse-Projekt kaum noch eingeholt werden.

Als es irgendwann doch dazu kam, und die alte Anwendung abgeschaltet werden konnte, hatte sich die Wahrnehmung des Teams durch die Organisation völlig geändert. Um es mit den Worten des Product Owners zu sagen: "Nicht nur das alte System, auch die alten Entwickler waren von allen schon abgeschrieben worden. Nach dieser unglaublichen Wiederauferstehung reissen sich jetzt alle darum, sie zu sich in die neuen Teams zu holen. Was für eine Erfolgsgeschichte."

Das wirklich Bemerkenswerte daran: dieser Erfolg beruhte auf keinem Wunder, sondern auf Ideen, die in jeder agil arbeitenden Firma Common Sense sein sollten: ein kleines, crossfunktionales Team, Automatisierung repetitiver Tätigkeiten, enge Zusammenarbeit mit dem Kunden, möglichst schnelles Reagieren auf geänderte Rahmenbedingungen und kontinuierliche Optimierung. Mit anderen Worten: auch andere Teams könnten sich so entwickeln, wenn man ihnen die richtigen Rahmenbedingungen und Freiheiten gibt. Man müsste es nur tun.