On Lean and Agility

Bild: Unsplash / Charanjeet Dhiman - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine die ich vor einigen Jahren erleben durfte, trug sich in "der goldenen Zeit der agilen Transitionsprogramme" zu, als das agile Arbeiten noch neuer und aufregender war als heute und in der Unternehmen zeitweise praktisch alles nach Scrum organisieren wollten. Vieles davon war eher wenig sinnvoll, mitunter waren die Ergebnisse aber auch überraschend gut. In einem derartigen Fall wurde Scrum in einer Einheit eingeführt, auf die man nicht sofort kommen würde: im Kundenservice.

In besagtem Kundeservice hatte die Firma ein nicht unwesentliches Problem - er wurde in fast allen Kundenbefragungen als unterdurchschnittlich schlecht bewertet, allerdings ohne dass dafür ein klarer und sich wiederholender Grund angegeben wurde. Stattdessen waren die Begründungen stark uneinheitlich oder so abstrakt, dass sich aus ihnen nicht eine einzige grosse Massnahme ableiten liess. Es brauchte also ein anderes Vorgehen. Und zufällig war gerade erst eines vorgestellt worden.

Wie alle anderen Mittelmanager in diesem Unternehmen hatte auch die Kundenservice-Abteilungsleitung kurz vorher an einer Scrum-Schulung teilgenommen, mit deren Durchführung ich beauftragt war. Und die Idee von kurzen Sprints, in denen alle Beteiligten gemeinsam auf ein kurzfristig erreichbares Ziel hinarbeiteten, war hängengeblieben. Nach diesem Muster den Service schrittweise zu verbessern schien allen eine gute Idee zu sein, also wurde die Abteilung als Scrum Team neu organisiert.

Ab diesem Punkt wurde alle drei Wochen ein neues Sprintziel gesetzt. Das konnte eine einfachere Formulierung der versandten Briefe sein, die erstmalige Verwendung von Grafiken und Icons in ihnen, ein veränderter Aufbau von Selfservice-Seiten, angepasste Uhrzeiten zu denen das Callcenter erreichbar war, die schriftliche Anrede der Kunden mit Du statt mit Sie, oder vieles mehr. Jede dieser Massnahmen sollte innerhalb eines Sprints umgesetzt werden.¹

Die für diese Einheit umfasste Definition of Done umfasste allerdings nicht nur die Umsetzung, sondern auch die Erfolgsmessung. Alle Kunden, die mit angepassten Service-Vorgängen Kontakt hatten, wurden im Anschluss nach ihrer Bewertung gefragt, so dass in den Sprint Reviews nicht nur die Umsetzung der für das Sprintziel notwendigen Massnahmen vorgestellt wurde, sondern auch das dazugehörende Kundenfeedback. Damit wurde die Diskussion bewusst versachlicht und von Annahmen befreit.

Wie sinnvoll das war, konnte man an einem Sprintziel sehen, das auf den ersten Blick eines der am einfachsten umzusetzenden gewesen war: das Duzen der Kunden. Fast zwei Wochen vergingen mit Diskussionen, Eskalationen, rechtlichen Bewertungen, Focusgruppen-Befragungen und ähnlichen vorbereitenden und absichernden Tätigkeiten. Auch im Sprint Review erschienen einige Stakeholder mit sehr gefestigten Meinungen - die erst von dem durchweg positiven Kundenfeedback widerlegt wurden.

Am Ende des Projekts hatte es sowohl erfolgreiche als auch weniger erfolgreiche Sprints gegeben (und sogar einige, die die Kundenzufriedenheit eher verschlechtert hatten), insgesamt waren die Bewertungen des Kundenservice allerdings deutlich besser geworden als zuvor. Das Vorgehen wurde danach wieder in einen eher kontinuierlichen Arbeitsmodus überführt, in den bei Bedarf allerdings weitere Sprints eingeschoben werden konnten.

Was bei mir hängengeblieben ist, war neben diesem Erfolg der geradezu vorbildliche Umgang mit den Sprintzielen, die immer zu Beginn formuliert wurden, und die durchgängig als Alignment- und Erfolgsmessungs-Werkzeug genutzt worden waren. Hätte mir jemand vorher gesagt, dass ich ausgerechnet ausserhalb der IT im Kundenservice erleben würde, hätte ich es bezweifelt. So habe am Ende auch ich dazugelernt. Ein weiterer Grund warum ich gerne an dieses Projekt zurückdenke.

Bild: Unsplash / Chase Chappell - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.

In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.

Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.

Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.

Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.

Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.

Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.

Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.

Bild: Unsplash / Vitaly Gariev - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Ich durfte vor einiger Zeit als externer Berater eine agile Transformation eines grossen Konzerns begleiten, zu welcher eine ganze Reihe von Massnahmen gehörte: Reorganisation von Spezialisten-Gruppen zu crossfunktionalen Teams, Delegation von Verantwortung nach unten, Abbau von Vorschriften, Einführung von Retrospektiven und vieles mehr - was aber nach Aussage fast aller Beteiligten die wichtigste Änderung war, war die der Budgetierung.

Bis zu diesem Zeitpunkt waren die Budgetierungsprozesse so verlaufen wie in den meisten Unternehmen. Ein Budget "gehörte" einer Fachabteilung oder Initiative, die mit den umsetzenden Einheiten aushandelte, was sie dafür erhalten würde. Ab da wurden die Arbeitsstunden den jeweiligen Budgetposten zugeordnet - und nur an Arbeitspaketen für die noch Budget vorhanden war, durfte auch gearbeitet werden. Arbeit an nicht budgetierten Aufgaben war nicht erlaubt.

Dieses Vorgehen hatte ursprünglich einen sinnvollen Kern gehabt, so sollte sichergestellt werden, dass nur an den aus Unternehmenssicht wirklich wichtigen Aufgaben gearbeitet wurde, denn nur die hatten ein Budget erhalten. Für eine Welt sich schnell ändernder Märkte und Technologien war es aber zu langsam und zu bürokratisch - wer den Umsetzungsplan ändern wollte, musste bis zur nächsten (jährlichen) Budgetierung warten oder ausufernde Change Request-Dokumente ausfüllen.

Da das dazu geführt hatte, dass selbst offensichtlich notwendige Planungs-Änderungen nicht stattgefunden hatten, war die Trennung von Arbeitsplanung und Budgetierung eines der Hauptziele der agilen Transformation gewesen. Und glücklicherweise liess sich das Management auch von einem alternativen Ansatz überzeugen: von Beyond Budgeting, das bereits in den 70er und 80er Jahren in Skandinavien entwickelt worden war.

Im Rahmen seiner Umsetzung wurde die harte Verdrahtung von Budgets und Fachbereichs-Anforderungen aufgehoben, stattdessen wurden den Entwicklungsteams jeweils Budgets für ganze Jahre zugewiesen, die lediglich mit groben Themengebieten wie z.B. Zahlungsabwicklung oder Kundenkommunikation verbunden waren. Dass an den wichtigsten Dingen gearbeitet wurde, wurde nicht mehr über die Budgets, sondern durch eine übergreifende Priorisierung sichergestellt.

Wenn sich jetzt während der budgetierten Zeiträume Notwendigkeiten oder Prioritäten änderten, war es nicht mehr nötig, die ganze Finanzplanung anzupassen, es musste nur die übergreifende Priorisierung geändert werden. Natürlich war auch das mit Arbeit verbunden, im Vergleich zum alten Vorgehen war der Aufwand aber deutlich geringer. Dass notwendige Planungs-Änderungen aus Abneigung gegen den damit verbundenen Arbeitsaufwand verschoben wurden, kam ab da kaum noch vor.

Auch die budgetierten Zeiträume selbst wurden flexibler gestaltet. Es gab zwar weiterhin Jahrespläne, diese fanden aber auf einem eher hohen Abstraktionsgrad statt. Das Herunterbrechen erfolgte jeweils zum Beginn der Quartale, wodurch ein längeres Auseinanderlaufen aus (Budget-)Planung und Arbeits-Fortschritt vermieden werden konnte. In einer späteren Phase der agilen Transition wurde diese Quartalsplanung als Ressort-übergreifendes Big Room Planning durchgeführt.

Zur ganzen Geschichte gehört auch, dass diese Umstellungen nicht ohne Konflikt abgelaufen sind. Den Verlust der Kontrolle über die Detail-Budgetierung empfanden manche Fachbereichs-Manager auch als Verlust von Status und von Druckmitteln, die bisher zur Durchsetzung eigener Ziele gegen andere Interessen genutzt werden konnten. Am Ende konnte Beyond Budgeting deshalb auch nicht überall umgesetzt werden. Dort wo es gelungen war, führte es allerdings zu deutlich effektiverem Arbeiten.

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Die heutige trug sich in einem Robotik-Startup zu. Wie in derartigen Firmen üblich war am Anfang alles klein und überschaubar gewesen, was sich mit zunehmendem Wachstum aber nach und nach änderte. Besonders häuften sich die Probleme, nachdem die MVP-Phase überwunden war. Um die funktionale Sicherheit der Embedded Software (des Betriebssystems) zu gewährleisten waren jetzt umfangreiche Tests nötig, die schon bald so lange dauerten, dass kaum noch Zeit für die Entwicklung blieb.

Um das nachvollziehbar zu machen: anders als im Fall reiner Softwareprodukte ist das Testen von Robotern nur schwer zu beschleunigen und zu parallelisieren. Dass z.B. ein Sensor nach zu langem Dauerbetrieb des Roboters der Software ein Signal übermittelt, das dort eine Warnung vor drohender Materialermüdung auslöst, kann nur in einem sehr langwierigen Testdurchlauf validiert werden, der nur in Gänze und ohne Unterbrechung ausführbar ist.

Aufgrunddessen besteht ein Grossteil der Robotik-Entwicklung aus Testläufen in einem Testlabor, was in grossen Organisationen das Risiko einer der folgenden beiden Auswirkungen hat: entweder das Entwicklungsteam betreibt auch das Labor, was aufwändig ist und ständige Kontextwechsel zur Folge hat, oder die Tests werden von einem separaten Test-Team durchgeführt, was zu einer Wasserfall-artigen Silo-Bildung führt, die in der modernen Produktentwicklung eigentlich nicht mehr gewollt ist.

Um es nicht dazu kommen zu lassen, wählten wir in dem erwähnten Robotik-Startup einen anderen, eher ungewöhnlichen Weg. Es gab zwar ein separates Team, das für das Testlabor zuständig war, es führte die Tests aber nicht selbst aus, sondern war nur dafür zuständig das Labor zu betreiben und zu erweitern. Seine Nutzung wurde den anderen Teams überlassen, die es quasi als Plattform-Dienstleistung nutzen konnten. "Test Lab as a Service" wurde es auch scherzhaft genannt.

Konkret sah das so aus, dass am Rand der Testfläche eine ausreichende Zahl der neuesten Generation von Hardware-Prototypen stand. Auf einer grafischen Weboberfläche wurde angezeigt welcher von ihnen gerade verfügbar war und welche Software-Version auf ihm lief. Sobald es eine neue Version dieser Betriebssoftware gab, konnte das jeweilige Entwicklungsteam sie auf einen der Roboter-Prototypen laden, eine Testfahrt starten und sich dann erstmal mit anderen Dingen beschäftigen.

Die im Folgenden stattfindende Testfahrt wurde von verschiedenen Kameras aufgezeichnet. Am Ende der Fahrt wurden das so entstandene Video, die Telemetriedaten der Sensoren des Roboters und die Monitoring-Daten der Software in einem gemeinsamen Ordner abgelegt und das Entwicklungsteam wurde benachrichtigt. Die Hard- und Software, die diese Daten automatisiert sammelte und zur Verfügung stellte, war Teil der Dienstleistung des Plattform-Teams für die Entwicklungsteams.

Die positiven Folge dieser Aufteilung waren spiegelbildlich zu den oben genannten Risiken. Die Entwicklungsteams konnten sich auf die Entwicklung und das Testen ihrer Features konzentrieren und mussten sich nicht mit dem aufwändigen Betreiben des Testlabors befassen. Das Plattformteam dagegen hatte einen klaren Focus auf dem zu Verfügung stellen dieses Labors, ohne selbst mit dem Durchführen der Testfahrten beschäftigt zu sein (von gelegentlichem Troubleshooting abgesehen).

Durch dieses Vorgehen entstand ein hochgradig effektiver und effizienter Entwicklungsprozess, der von allen Beteiligten als einer der besten gelobt wurde, den sie in der Embedded Software bis dahin erlebt hatten. Und als Nebeneffekt führte die automatisierte statt manuelle Überwachung der Testläufe dazu, dass ein immer grösser werdender Schatz an Daten entstand, der für wiederholte Auswertungen zur Verfügung stand. Heute, mit KI, wären damit nochmal ganz andere Dinge machbar.

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist bedauerlich, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine an der ich vor längerer Zeit beteiligt war betraf die Qualitätssicherung in einem grossen IT-Projekt. Die hier tätigen Tester galten in der allgemeinen Wahrnehmung als doppelt problematische Schwachstelle: am Ende fast jedes Sprints wurden in den Entwicklungsteams die Tests der dort programmierten Features nicht mehr rechtzeitig fertig, und nach dem Sprintende waren die Regressionstests häufig zuerst grün, enthielten aber Wochen später plötzlich doch Fehlermeldungen.

Eine Analyse der Entwicklungsabläufe zeigte schnell zwei Hauptprobleme auf: zum Einen gab es in den Teams wasserfallartige Abläufe, in deren Rahmen die Entwickler lange unter sich arbeiteten, und die Tester erst kurz vor Sprintende erfuhren, was sie zu testen hatten (und das dann unter Zeitdruck tun mussten) zum Anderen hatte sich die übergreifende Regressionstest-Suite mit der Zeit selbst zu einem schwerfälligen Legacy-System entwickelt, dass nur noch aufwändig anzupassen war.

Dementsprechend wurden drei Verbesserungsmassnahmen durchgeführt. Zuerst wurden die Tester früher in die Abläufe ihrer Teams integriert. In den Backlog Refinements wurden sie daran beteiligt, die Akzeptanzkriterien testbar zu verfassen statt abstrakt, ihre Testaufwände wurden stärker in den Aufwandsschätzungen berücksichtigt und beim Planen der Sprints wurden Grösse, Auswahl und Anzahl der Entwicklungs-Aufgaben so vorgenommen, dass am Ende genug Zeit zum Testen blieb.

Als zweite Massnahme erfolgte eine stärkere Einbeziehung der Software-Entwickler in die QA-Abläufe. Wie oben geschrieben hatten die bis dahin das Testen als ein nachgelagertes Thema gesehen, das sie selber nicht mehr betraf. In dem verbesserten Vorgehen wurde dagegen eine Testpyramide angestrebt (siehe hier), in der bestimmte Mengen an (von den Entwicklern erstellten) Unit-, Integrations- und Lasttests zu einem Abnahmekriterium wurden, was das Testen am Sprintende deutlich beschleunigte.

Als Drittes wurde eine Überarbeitung der Regressionstest-Suite vorgenommen, die ja zu einem eigenen Problem geworden war. Bis dahin war sie einfach nach jedem Sprint um weitere Tests erweitert worden, während die bestehenden nur angepasst wurden, wenn (und nur dort wo) es Änderungen an den getesteten Funktionen gegeben hatte. Aufgrunddessen waren viele Tests redundant, kompliziert und unübersichtlich, was Anpassungen extrem aufwändig machte.

Um das zu verbessern wurde die Testsuite modularisiert und parametrisiert. Das Eine bedeutete, dass bestimmte Validierungen (z.B. des Login) nicht mehr in verschiedenen Tests enthalten waren, sondern nur noch in einem einzigen Modul, das dafür in beliebig viele Tests eingebunden werden konnte. Das Andere bedeutete, dass bestimmte variable Informationen (Browser, Ordnerpfade, etc.) nicht mehr hart im Test standen, sondern an einer zentralen Stelle systemweit geändert werden konnten.

In Summe führten diese verschiedenen Massnahmen dazu, dass die zu Beginn genannten Probleme fast völlig verschwanden. Die Tests (und mit ihnen die neuen Features) wurden in den Sprints fertig, in denen sie auch programmiert wurden, und die Aktualisierung der Regressionstests benötigte nur noch die Arbeit an einzelnen Modulen oder Parametern, statt an zig Stellen, wodurch versehentliche Seitenauswirkungen der neuen Features sofort gefunden werden konnten, statt Wochen später.

Am Ende ist es eine Binsenweisheit: eine Kette ist nur so stark wie ihr schwächstes Glied, und in vielen Softwareentwicklungs-Organisationen ist dieses schwächste Glied die Qualitätssicherung. Auch hier die agilen Praktiken einzuführen, und zwar sowohl technisch als auch prozessual, ist etwas, wovon alle Beteiligten massiv profitieren können.

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Bild: Pexels / Moe Magners - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht in Frustration und Fatalismus 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 habe ich mehrfach in ähnlicher Form erlebt, aber die an die ich gerade denke, begann damit, dass ich als externer Scrum Master oder Agile Coach in eine Firma gekommen bin und dort Teams vorgefunden habe, die mir gleich zu Beginn Eines unmissverständlich klar machen wollten: dass es agiles Arbeiten bei ihnen nicht geben würde. Sie hätten das bereits versucht gehabt, es sei furchtbar gewesen und sie wären heilfroh, es zugunsten eines besseren Vorgehens  hinter sich gelassen zu haben.

Bedingt dadurch, dass ich diese Erfahrung wie gesagt bereits mehrfach gemacht habe, lasse ich mich in derartigen Situationen zunächst noch auf keine Diskussion über das zukünftige Vorgehen ein, sondern lasse mir zuerst erklären, warum der agile Arbeitsmodus als so furchtbar empfunden wurde und was den stattdessen gewählten so viel besser macht. Und es stellte sich dabei heraus, dass hier zwei aufeinander aufbauende Missverständnisse vorlagen.¹

Das erste dieser Missverständnisse betraf das, was dort irgendwann mal unter dem Namen "Agile" eingeführt worden war. Mit der zugrundeliegenden Idee hatte das eher wenig zu tun, stattdessen wurden lediglich zusätzlich zu den bereits bestehenden (und z.T. unverändert gültigen) Prozessen einzelne aus Scrum oder SAFe entlehnte Meetings, Titel und Begriffe eingeführt, die aber ohne geänderte Rahmenbedingungen nichts verbessert sondern nur alles verkompliziert hatten. Cargo Cult also.

Aufbauend darauf war das zweite Missverständnis entstanden. Da "Agile" als komplizierter, unverständlicher und bürokratischer Prozess wahrgenommen wurde, hatten die Teams stattdessen ein Alternativvorgehen entwickelt, dass auf direkter Kommunikation, crossfunktionaler Zusammenarbeit, wenigen Regeln, kurzen Lieferzyklen und regelmässigen Prozessverbesserungen beruhte.² Folgerichtig hielten sie dieses Vorgehen für nicht-agil und dem agilen Arbeiten überlegen.

Als ich auf diese beiden Missverständnisse hinwies, und darauf, dass der "nicht-agile Arbeitsmodus" in Wirklichkeit sehr agil war, waren zunächst Überraschung und Unglaube gross. Erst nachdem sich einige Teammitglieder bereiterklärten, einige der Originalquellen (Scrum Guide und Agiles Manifest) zu lesen, setzte sich langsam die Erkenntnis durch, dass sie die Idee falsch verstanden hatten, und durch die Abwehr der Cargo Cult-Methode "versehentlich" agil geworden waren.

Wirklich warm geworden sind sie mit dem Begriff zwar nicht mehr, dafür hatten sie sich bereits zu sehr auf ihn eingeschossen. Aber ganz ehrlich - sie waren nah am Kunden, lieferten regelmässig Mehrwert aus, passten das eigene Vorgehen regelmässig an und arbeiteten gut zusammen. Angesichts dessen war die Ablehnung des Wortes "Agil" ein Thema, das man mit gutem Gewissen vernachlässigen konnte. Wenn das Ergebnis stimmt, ist der Name des Prozesses nicht so wichtig.

Bild: Pexels / Vlada Karpovich - 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 hat sich in einem grossen Unternehmen in einer gesetzlich regulierten Branche zugetragen. Die Einhaltung dieser Regulierungen wurde von einer eigenen Abteilung überprüft, der Revision, die von Zeit zu Zeit anderen Abteilungen einen Besuch abstattete, sich deren Abläufe und Ablaufdokumentationen zeigen liess, diese überprüfte und für regulierungskonform oder nicht regulierungskonform erklärte. Wenn das zweite der Fall war, mussten diese angepasst werden, danach wurden sie nochmals überprüft.

Bewusst oder unbewusst hatte sich in dieser Firma mit der Zeit ein eher dysfunktionaler Umgang mit der Revision etabliert: im Vorfeld wurde die Herausgabe von Informationen möglichst stark verzögert, während der eigentlichen Prüfung wurde die Revision dann dafür mit möglichst viel Material überflutet. In dem waren einige offensichtliche aber sehr geringfügige Fehler prominent plaziert, um schnell gefunden zu werden und die Revisoren von einer genaueren Überprüfung der anderen Bereiche abzulenken.

Als externem Berater/Agile Coach war ich in diese Feinheiten nicht eingeweiht worden, weshalb ich mir keine grossen Gedanken machte, als ich kontaktiert und nach einer Prozessdokumentation der agilen Software-Entwicklung gefragt wurde. Bereitwillig verwies ich auf den Scrum Guide und einige Intranet-Seiten, auf denen erklärt wurde, wie Scrum in der Entwicklungsabteilung umgesetzt wurde, die ich zu dieser Zeit begleitete. Noch am selben Tag brach dort Unruhe aus.

Schlafende Hunde hätte ich geweckt und die Revisoren "angefüttert", hiess es, jetzt hätten die mehr Zeit als sonst um sich zu informieren, sich vorzubereiten und noch genauer als sonst zu prüfen, und dadurch würden sie auch mehr finden können und für alle mehr Arbeit verursachen. Ein grosses Drama. Um alle zu beruhigen bot ich schliesslich an, die Vorbereitungs-Arbeiten der Revisions-Prüfung selbst zu übernehmen. Es waren noch etwa fünf Wochen bis zum Revisionstermin.

Eine wirkliche Idee was ich alles abzuliefern hätte hatte ich am Anfang noch nicht, dafür aber eine Idee wen ich fragen könnte - den Revisor, der mich nach Prozessdokumentation gefragt hatte. Und tatsächlich, von ihm bekam ich die "Richtlinien zur Inbetriebnahme, Modifizierung und Ausserbetriebnahme von Netzwerk- und Informationssystemen". Ein riesiges, unübersichtliches Dokument, voller Fachbegriffe und juristischer Formulierungen. Ich verstand bestenfalls die Hälfte.

Immerhin, er war bereit, es mir zu erklären, also stellte ich einen längeren Termin mit ihm ein, der erstaunlich konstruktiv und produktiv war. Hinter den meisten Formulierungen verbargen sich sehr einfache und nachvollziehbare Vorgaben, z.B. dass es ein Vorgehen zur Priorisierung von Anforderungen geben müsste, dass ein Vier-Augen-Prinzip gewährleistet sein müsste und dass neu entwickelte Funktionen eine Qualitätssicherung dürchlaufen müssten.

Umgekehrt konnte ich erklären, was es mit den verschiedenen Fachbegriffen aus Scrum auf sich hatte. Welche Meetings es gab, wer an ihnen teilnahm und dort welchen Beitrag leistete und welche zusätzlichen Praktiken in den Teams verwendet wurden, z.B. User Stories, Pair Programming und Code Reviews. Wir gingen auseinender mit einer Idee: bis zur nächsten Woche sollte ich eine Übersicht erstellen, welche Richtlinien durch welche Scrum-Regeln und Praktiken abgedeckt wurden.

Im nächsten Termin konnte ich bereits für die meisten Richtlinien etwas vorweisen: das Refinement für die Anforderungs-Priorisierungen, die Code Reviews für das Vier-Augen-Prinzip, die Akzeptanz- und Regressionstests für die Qualitätssicherung, etc. Natürlich war noch nicht alles abgedeckt, aber wir konnten jetzt sortieren - Themen bei denen es nichts mehr zu tun gab, Themen bei denen nur noch die Dokumentation genauer werden musste und offene Themen.

In den verbleibenden drei Wochen arbeiteten wir diese Liste durch: zwischen den jeweils wöchentlichen Terminen konnte ich die Prozessdokumentation vervollständigen und Vorschläge erarbeiten, welche noch offenen Richtlinien wie in Scrum umgesetzt werden könnten (z.B. wurden Security-Vorgaben in die Definition of Done aufgenommen), umgekehrt konnte der Revisor sich mit seinen Kollegen abstimmen, ob das auch nach deren Meinung ausreichend war.

Letzteres führte dann auch zu einem unerwarteten Effekt: einige der anderen Revisoren hatten vorher in anderen Firmen bereits agile Prozesse überprüft, und konnten berichten, wie Regularien dort erfüllt worden waren. Sobald uns das bewusst war, fragten wir auch  bei weiteren noch unklaren Fällen nach Erfahrungswerten, und bekamen auch einige (z.B. dass die Nennung einer einzuhaltenden Richtlinie in den Akzeptanzkriterien einer User Story eine ausreichende Dokumentation war).

Der Revisionstermin war dann trotz allem lang und umständlich, schliesslich war es vorgegeben, dass mehrere Revisoren zusammen mit mehreren Mitgliedern der Entwicklungsabteilung den gesamten Prozess und seine Dokumentation im Detail durchgehen mussten. Anders als bei den letzten Terminen war das Meiste den Revisoren aber bereits bekannt - und als ein weiteres Ergebnis der Vorbereitung war die zu sichtende Dokumentation auf das Wesentliche reduziert, hatte also deutlich weniger Umfang.

Am Ende stand die geringste Menge an notwendigen Nacharbeiten, an die sich alle Beteiligten erinnern konnten, und gleichzeitig waren die Vertreter der Revisionsabteilung der Meinung, dass sie noch nie die Prozesse einer geprüften Abteilung so gut verstanden hätten. Auch in der Entwicklungsabteilung wurde anerkannt, dass die frühe und transparente Zusammenarbeit mit den Revisoren nicht die befürchteten negativen Folgen gehabt hatte, sondern sinnvoll gewesen war.

Leider ist es unverkennbar, dass viele Mitglieder der agilen Bewegung mit der Zeit eine eher negative Grundeinstellung 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, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten". So wie diese hier.

Es war in einem meiner letzten Einsätze als klassischer Projektleiter. Ein grosser Mittelständler hatte vor, seine Website einem Relaunch zu unterziehen, inclusive des dort eingebundenen Shops. Insgesamt fünf Teams arbeiteten daran, aus der IT, aus dem Marketing und aus der Unternehmenskommunikation, und wie mir im Vorfeld gesagt wurde, war das Meiste schon fertig. Als externe Krankheitsvertretung des Projektleiters sollte ich nur noch die letzten Arbeiten koordinieren.

Die Realität, die ich vorfand, war dann allerdings eine andere. Zwar war die Arbeit tatsächlich schon weit fortgeschritten, die einzelnen Teile (Shop, CMS, Redaktionssystem, Single Sign on, etc.) passten aber an keiner Stelle zusammen. Jeder Versuch, irgendetwas fertigzustellen oder mit irgendeinem anderen Teil zu verbinden, führte zu einer Kaskade an Fehlermeldungen. Und mit gleicher Zuverlässigkeit ergoss sich regelmässig eine Kaskade aufgebrachter Stakeholder in das Projektleitungs-Büro.

Genau das erwies sich auch als die Ursache des Problems. In früheren Projektphasen hatte jeder Stakeholder ständig seine Wünsche in das Projekt einbringen dürfen. Und aus dem Wunsch heraus, alle gleich gut zu behandeln, hatte die alte Projektleitung die Teams angewiesen, an allem gleichzeitig zu arbeiten. So war es dazu gekommen, dass zwar Alles angefangen war, aber Nichts fertig, Nichts integriert, Nichts getestet und Nichts funktionierend.

Der einzige Vortrteil an dieser Situation war, dass das Projekt intern bereits als gescheitert galt, und alle Manager sich fern von ihm hielten, um zu verhindern, dass sie mit ihm in Verbindung gebracht wurden (das war auch der wahre Grund, warum ich als Externer der Projektleiter geworden war). Dadurch hatte ich relativ grosse Freiheiten, um neue Wege auszuprobieren. Nur welche das sein sollten, war mir noch nicht kar - also fragte ich die Entwicklungsteams. Und die hatten tatsächlich eine Idee.

Statt gleichzeitig an allem zu arbeiten und nirgendwo weiterzukommen wollten sie sich immer nur auf ein Feature konzentrieren, das fertigstellen, testen und integrieren, dann das Gleiche mit einem zweiten machen, dann mit einem dritten, und so weiter. Um zu zeigen, dass sie dabei wirklich vorankommen würden, boten sie mir einen täglichen kurzen Statusbericht an, vor einem Board auf dem der Fortschritt jedes Arbeitspaketes visualisiert wurde. Kanban nannten sie das (der Begriff war mir damals noch neu).

Der Beitrag, den ich dazu leisten musste, war, ihnen alle Stakeholder vom Hals zu halten, an deren Feature gerade nicht gebaut wurde. Mit Erbitterung und erstaunlicher Ausdauer drangen diese darauf, dass jetzt doch auch endlich sie wieder an der Reihe sein müssten, verlangten Fortschrittberichte, brachten neue Ideen auf, die sie noch spät in die Umsetzung einbringen wollten und eskalierten ständig beim Top-Management (das sich aus den oben genannten Gründen aber heraushielt). Ein Vollzeit-Job.

Während ich mir also irgendwo Powerpoint-Saalschlachten mit uneinsichtigen Leuten lieferte, wurden so fast unbemerkt die ersten Funktionen fertig. Zu Beginn noch mit Ablehnung aufgenommen ("Was? Nur so wenig? Da fehlt doch noch alles andere!") wurden sie nach und nach mehr und mehr. Und mit diesen frühen Funktionsumfängen gelang das erste kleine Wunder: als die ersten Stakeholder sahen, dass ihre Kernfunktionen fertig waren, waren sie fürs Erste zufrieden und zogen ihre Zusatzwünsche zuück.

Die verbliebenen kämpften zwar um so verbissener für ihre Interessen, da jeder befürchtete, dass am Ende für die Letzten keine Zeit und kein Budget mehr übrig sein würde, aber die Runden wurden nach und nach kleiner und beherrschbarer. Und irgendwann gelang das zweite kleine Wunder. Nachdem die konzentrierte Arbeit dazu geführt hatte, dass die Teams endlich liefern konnten, wurde ihren Zeitplänen auf einmal Glauben geschenkt und die Eskalationen wurden seltener.

Das aus der Sicht des Unternehmens grösste Wunder fand aber ganz zum Schluss statt: nach der Fertigstellung eines zufriedenstellenden Funktionsumfangs hatten sich alle auf das eingerichtet, was sie in vergangenen Projekten als unvermeidbaren Teil der Softwareentwicklung kennengelernt hatten - eine lange und für alle Beteiligten quälende Phase des Software-Testens und Reparierens, bei der nie so ganz abbsehbar war, wie lange sie dauern würde. Diesesmal aber was diese Phase kurz und schnell vorbei.

Der Grund dafür war, dass jede fertiggestellte Funktion sofort mit den anderen integriert und zusammen mit ihnen getestet worden war. Und da immer nur an einer gearbeitet wurde, waren die jeweils neuen Umfänge und Fehlerquellen immer überschaubar gewesen, wodurch sich die Test- und Reparatur-Aufwände in Grenzen gehalten hatten. Statt erst ganz am Ende mit der Qualitätssicherung beginnen zu müssen, war das meiste davon zu diesem Zeitpunkt schon abgeschlossen.

Am Schluss war auf diese Weise einiges von der zwischenzeitlichen Verspätung aufgeholt worden, und das Projekt endete mit jeweils zehn Prozent Zeit- und Budget-Überschreitung. In der gesamten jüngeren Unternehmensgeschichte (in der nie ein IT-Projekt pünktlich fertiggeworden war), war das der beste Wert an den man sich erinnern konnte. Und für mich selber war es der Anstoss, nur noch so arbeiten zu wollen (was ich mittlerweile auch geschafft habe).

Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - 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, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.

In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.

Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.

Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.¹

Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.²

Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.

Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.

Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.

Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.

Bild: Pexels / Ivan Samkov - Lizenz

Dass "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln, ist leider ein verbreitetes Phänomen. Das ist auch irgendwie verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann schnell 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 beginnt mit einem Problem. In einem Konzern, dessen agile Transformation ich begleiten durfte, galt das Verhältnis zwischen der internen Softwareentwicklung und den Anwendern in den Filialen als zerrüttet. Die Software würde schwer zu verstehen und zu bedienen sein, hiess es von den Filialkräften, umgekehrt beschwerten sich die Entwickler über unvollständige und erratische Anforderungen und Fehlermeldungen. Jede Seite sah das Problem bei der anderen.

Nach kurzem Nachforschen liess sich ein Grund für diese Missstände identifizieren: der Anforderungsmanagement-Prozess war (freundlich gesagt) suboptimal. Neue Anforderungen wurden (wenn sie überhaupt aus den Filialen kamen) von deren Leitern gestellt, die gar nicht mit den jeweiligen Systemen arbeiteten. Auf dieser Basis erstellte die IT-Konzeptionsabteilung eine Detailspezifikation und gab diese ohne Rücksprache mit dem Anforderer an die Entwicklung weiter, die nur noch umsetzte.

Natürlich kam es entlang dieser Strecke fast schon zwangsläufig zu Missverständnissen und Stille Post-Effekten, die dann in den oben genannten Problemen resultierten. Um das zukünftig zu verhindern, sah der neue Prozess etwas für diese Firma geradezu Revolutionäres vor: Anwender und Entwickler sollten diekt miteinander sprechen, und das nicht nur ab und zu sondern regelmässig. Und mit regelmässig war gemeint mindestens einmal pro Monat.

Umgesetzt wurde das, indem der gewählte Arbeitsmodus Scrum etwas angepasst wurde. Nach jedem zweiten Sprint fanden die Sprint Reviews in einer der Filialen statt. Im Mittelpunkt standen dabei nicht die Ergebnisse des letzten Sprints (die wurden in den dazwischenliegenden "normalen" Reviews besprochen) sondern das Feedback der Filialkräfte, und zwar sowohl zu Verständlichkeit und Bedienbarkeit der Anwendungen als auch zur Sinnhaftigkeit der als nächtes geplanten Funktionen.

Diese Filialbesuche brachten regelmässig erhellende Erkenntnisse. Immer wieder kam es vor, dass Funktionen, die Management und IT-Konzeption für zentral gehalten hatten, sich in der Realität als unbenötigt herausstellten, umgekehrt wurden von den Anwendern wiederholt Features gewünscht, die an die niemand gedacht hatte. Und nachdem dieser Arbeitsmodus eine Zeit lang gelaufen war, wurden die Reviewss immer positiver, da mehr und mehr der Wunsch-Features tatsächlich gebaut wurden.

Zur ganzen Wahrheit gehört, dass die Veränderungen nicht für alle Beteiligten positiv waren. Besonders die IT-Konzeptionsabteilung musste damit leben, in der Entwicklung der Filial-Software praktisch nicht mehr benötigt zu werden - und dass noch betont wurde, dass erst durch die direkte Kommunikation zwischen Entwicklern und Anwendern die Zufriedenheit mit der Software besser geworden war, dürfte für die bisher zwischen ihnen vermittelnden IT-Konzepter deprimierend gewesen sein.

Karte: Open Street Map - CC BY-SA 2.0

Weiter geht es mit den "agilen Erfolgsgeschichten". Der Grund für ihre Veröffentlichung bleibt der gleiche: 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, und schlimmstenfalls eine negative Weltsicht entwickeln. Wer sich die durch agile Praktiken und Methoden erzielten Erfolge und Fortschritte vergegenwärtigt, wird sich dagegen leichter damit tun, erfolgreich für sie zu werben.

Zu den Mythen die seit einiger Zeit durch die Arbeitswelt wabern, gehört der, dass Silicon Valley-Firmen (vor allem Google) ihren Mitarbeitern angeblich 20 Prozent ihrer Arbeitszeit zur freien Verfügung stellen, und dass zentrale Produkte wie Adsense und Google News in dieser Zeit "selbstorganisiert entstanden" sind. Zum Wahrheitsgehalt dieser Aussagen findet man unterschiedliche Aussagen, wahr ist aber, dass viele Firmen inspiriert davon ihren Mitarbeitern eine ähnliche, so genannte "Side Project Time" gewähren.

Eine dieser Firmen durfte ich eine Zeit lang begleiten. Die Zeit, die den Entwicklern hier für selbstgewählte Nebenprojekte (→ Side Projects) zur Verfügung stand, war vier Stunden pro Woche, plus längeren Zeiträumen für die in den Ferien arbeitenden Rumpfteams. Die Sinnhaftigkeit dieser Regelung wurde von anderen Abteilungen regelmässig in Frage gestellt, was irgendwann dazu führte, dass die Ergebnisse aller derartigen Seitenprojekte gesammelt und zur Überprüfung veröffentlicht wurden.

Angesichts der Grösse von mehreren hundert Entwicklern war natürlich ein gewisser Anteil an Unsinn dabei, wie z.B. ein Chatbot, der auf alle Fragen zu Konkurrenzunternehmen mit wüsten Beschimpfungen antwortete, oder ein Zufallsgenerator für die Erstellung möglicht absurder User Stories, es gab aber auch einige Ergebnisse, die auch den grössten Kritikern Respekt und Anerkennung abnötigten, und dafür sorgten, dass die Side Project Time erhalten blieb.

Einige Entwickler hatten sich z.B. gemeinsam der Aufgabe verschrieben, die technischen Probleme zu beseitigen, die bis dahin dazu geführt hatten, dass ein Grossteil der Meetings deutlich verspätet begonnen hatte. Als Lösung hatten sie jeden Meetingraum mit einem Computer versehen, der fest mit Beamer und Internet verbunden war und einen eigenen Videoconferencing-Account hatte. Ab da musste man nur den Raum betreten, den Rechner anschalten, und es konnte losgehen.

Ein Team hatte eine Intranet-Website gebaut, auf der alle, die sich dort anmeldeten, zu nach Zufallsprinzip erstellten Mittagessens-Verabredungen zusammengebracht wurden. Auf diese Seite entstanden Bekanntschaften kreuz und quer durch das ganze Unternehmen, wodurch abteilungübergreifende Zusammenarbeit und die Suche nach Ansprechpartnern für selten behandelte Themen deutlich vereinfacht und beschleunigt werden konnten.

Eine weitere Gruppe hatte ein Wiki zu den Kantinen, Restaurants und Imbissbuden der Umgebung aufgesetzt, mit Informationen zu Auswahl und Qualität, aber auch zu Stosszeiten, Geschwindigkeit der Bedienung und der Möglichkeit zu bargeldlosem Bezahlen. Das durch Umfragen festgestellte Ergebnis waren kürzere Mittagspausen, in denen gleichzeitig aber mehr Zeit für Essen und Unterhaltungen zur Verfügung stand als vorher.

Das (intern ) bekannteste Ergebnis erzielte aber das Nebenprojekt, in dem einige Entwickler im Firmen-eigenen Auslieferungslogistik-Leitsystem das für betriebliche Anwendungen kostenpflichtige Google Maps durch das kostenlose Open Street Maps ersetzt hatten. Besonders ein Feature erregte Aufsehen: ein Dashboard, mit dessen Hilfe man für beliebige Zeiträume überprüfen konnte, wieviel Geld durch die Ersetzung von Google Maps gespart worden war - er waren auf Dauer erhebliche Summen.

Wass all diese Side Projects gemeinsam hatten, entsprach genau den Gründen, wegen denen ihnen selbstorganisiert abrufbare Zeit eingeräumt worden war: sie wären im Rahmen des offiziellen Priorisierungsverfahren niemals auf den Roadmaps der Teams gelandet, sie lösten konkrete Probleme, mit denen die Entwickler regelmässig zu kämpfen hatten, und sie sorgten in erkennbarem Ausmass für Effektivitätssteigerungen, Kostenersparnisse und höhere Mitarbeiterzufriedenheit.

Man soll ja Erfolge nicht nur feiern, sondern auch in Erinnerung behalten, denn wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann sonst leicht in Frustration abrutschen. Um es nicht dazu kommen zu lassen, möchte ich von einer weiteren "agilen Erfolgsgeschichte" erzählen, die sich einmal im IT-Systemhaus einer grossen Bankengruppe zugetragen hat, bei der Entwicklung eines neuen Onlinebanking-Systems.

Agiles Arbeiten steckte dort noch in den Anfängen, und wie in vielen anderen Unternehmen auch wurde noch davon ausgegangen, dass es sich dabei nur um eine neue Arbeitsweise für die Software-Entwicklung handeln würde. Andere Organisationseinheiten reagierten nur mit einer Mischung aus Amüsiertheit und Entrüstung, als angeregt wurde, dass auch sie ihren Arbeitsmodus ändern sollten. Ihre Ideen waren klar: sie wollten im Voraus definieren, was sie wollten, und dann warten bis es fertig war.

Was zu ihrer Überraschung anders war, war aber, dass ihnen schon früh mitgeteilt werden konnte, wie (un)realistisch ihre Vorstellungen waren. Durch feature- statt komponentenorientierte Entwicklung, frühe Integration und automatisiertes Testen war der reale Arbeitsfortschritt klar erkennbar, und durch eine grobe Schätzung der noch offenen Anforderungen auch die noch nötige Zeit, beziehungsweise die vermutlichen Liefertermine der fehlenden Features. Und nätürlich - die waren später als gewünscht.

Die ersten Reaktionen darauf waren abwiegeln und abstreiten. Es wäre doch noch viel zu früh für solche Aussagen, die Roadmap wäre schliesslich von Experten gemacht worden, die Entwicklungs-Teams müssten nur bereit sein, "etwas Gas zu geben", dann würde der Zeitplan wieder passen. Und so weiter. Allein - alle drei Wochen bestanden die Entwickler in den Sprint Reviews auf ihren schlechten Botschaften. Im ersten Quartal, im zweiten, im dritten, und am Anfang des vierten.

Wenige Monate blieben damit noch bis zum geplanten Go Live in der ersten Tochtergesellschaft, und plötzlich wollten auch die anderen Organisationseinheiten agil werden. Besonders ein Begriff hatte es ihnen auf einmal angetan: das Minimum Viable Product (MVP), in ihrem Verständnis ein nur auf das absolut Notwendige reduzierter Funktionsumfang, mit dem der anvisierte Termin noch irgendwie zu halten sein müsste. Den wollten sie haben, und den glaubten die Entwickler auch liefern zu können.

In der Folgezeit wurden die Anforderungen Seite um Seite zusammengestrichen. Opulente Redaktions-Workflows? Erstmal nicht. Der komplette Nachbau aller Features des alten Systems im Neuen? Völlig übertrieben. Die Umstellung aller internen CMS-Seiten auf die Fonts, Formen und Farben des Corporate Design? Unnötig. Etc. Am Ende blieb nur ein letztes der unrealistisch grossen Arbeitspakete übrig, das angeblich nicht verhandelbar war. Das so genannte Reporting Center.

Dieses letzte laut Compliance-Abteilung zwingend nötige Feature sollte sicherstellen, dass sich nachvollziehen liess, welcher interne Mitarbeiter wann welche Änderungen in dem Onlinebanking-System vorgenommen hatte. Zu diesem Zweck sollte es möglich sein, sich alle Änderungen anzeigen zu lassen, sie nach Zeitraum, Bearbeiterrolle oder betroffenem Teilsystem zu filtern und grafisch aufbereitet anzeigen zu lassen. "Wenn es das nicht gibt, macht uns die Bafin den Laden zu", hiess es.

Als zwei Wochen vor Weihnachten absehbar wurde, dass auch diese Drohung nicht zu einer wundersamen schnellen Fertigstellung führen würde, fiel auf einmal auch hier das neue magische Wort. "Gibt es nicht auch davon ein MVP, und wenn ja, welches?" Und es gab eines - eine aus dem System exportierte Tabelle aller Bearbeitungsvorgänge, mit dem Angebot der Entwickler, ggf. beim Verständnis zu helfen. Und ein inoffizielles Vorfühlen bei der Bafin ergab: für die erste Version würde das reichen.

Und damit war es geschafft. Das Go Live in der ersten Tochtergesellschaft konnte wie geplant stattfinden, und nicht nur das. Die dort mit dem MVP-System arbeitenden Mitarbeiter konnten gefragt werden, wie sie mit dem System zurechtkamen, ihnen konnte gesagt werden, welche Features sonst noch geplant waren, und was sie vermutlich kosten würden. Und völlig überraschend kam das Feedback, dass viele davon gar nicht benötigt würden und stattdessen etwas Anderes sinnvoll wäre.

Dem Vernehmen nach ist das etwas überdimensionierte Reporting Center irgendwann doch gekommen, aber trotzdem enthält diese Geschichte einigen von dem, was agiles Arbeiten so wirkungsvoll macht: frühe Auslieferung, hohe Transparenz, ständiges Feedback, ein MVP, aus dem man mehr über die echten Bedürfnisse echter Anwender lernen kann und eine Anpassung der Pläne an die Realität (statt des Versuchs das Gegenteil zu erzwingen). Und all das in einer stark regulierten Branche.

Bild: Pexels / Ketut Subiyanto - Lizenz

Es ist mal wieder Zeit für eine Agile Success Story. 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, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.

Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.

Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.

Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.

Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.

Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.¹

Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.

Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.

Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.²

Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.

Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.

Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.

Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.

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.

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.