On Lean and Agility

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.