Scrum bei einer Behörde – geht das?!

Klassisches Projektmanagement im Wasserfall war jahrelang der Standard in der öffentlichen Verwaltung. Doch der Wunsch nach Veränderung ist da. Unser Autor zeigt, wie die Agilität ins Projekt einzog.

Die Rechte, Pflichten und Aufgaben der öffentlichen Verwaltung sind in Deutschland durch Gesetze festgelegt. Das betrifft nicht nur die Kernaufgaben der Verwaltung, sondern auch die Kommunikation zwischen Behörden und nachgelagerten Organisationen.  

Durch eine Gesetzesänderung wurden die in diesem Projekt betroffene öffentliche Verwaltung und externe Partner verpflichtet, in festgelegten Fachdomänen die Kommunikation zu digitalisieren und auf Papier zu verzichten. Das betraf den öffentlichen Träger und mehr als 100 unabhängige externe Partner.  

(Agile) Herausforderungen in Behörden 

Die besagte Verwaltung selbst arbeitet seit längerem daran, agiles Vorgehen nach Scrum in Kombination mit DevSecOps-Teams zu etablieren. Im Vorfeld des Projekts wurden mithilfe der Domain-Driven-Design-Methodik (DDD) die Bounded Contexts definiert. Ziel war es, die Teams möglichst voneinander zu entkoppeln und unabhängiges Arbeiten und damit perspektivisch unabhängige Deployments zu ermöglichen. Ein Bounded Context ist ein klar von den anderen Kontexten abgetrennter fachlicher Bereich, in dem eine gemeinsame Sprache (sog. ubiquitous language) gesprochen wird. Pro Bounded Context wurde ein Microservice gebaut. Im Projekt selbst wurde dann nach Scrum vorgegangen, wobei die Anforderungen und daraus folgend die User Storys iterativ entwickelt wurden. 

Das stellt eine öffentliche Verwaltung vor verschiedenen Herausforderungen: 

• Der wesentliche Unterschied zwischen Scrum und dem klassischen Wasserfallvorgehen ist das Management des Umfangs. Bei gesetzlich vorgegebenen Zielen und einem festgelegten GoLive-Termin (der Tag, an dem das Gesetz in Kraft tritt) ist es nicht ohne weiteres möglich, Umfang zu streichen. 

• In einer klassischen Verwaltungsstruktur gibt es viele betroffene Stakeholder und Nutzer:innen, für die eine genaue Planbarkeit wichtig ist. Da ist ein zweiwöchiges Planungsfenster wie in Scrum ungewohnt und entspricht nicht der benötigten Planbarkeit. So mussten in der Verwaltung zum Beispiel ca. 20.000 Nutzer:innen geschult werden. Hierfür wird ein entsprechender Vorlauf benötigt. 

• In der Verwaltung werden sehr hohe Datenmengen ausgetauscht (beispielsweise legt einer der im Projekt entwickelten Services mehr als 100 Millionen Dokumente jedes Jahr in den Akten ab)  – diese wirken sich direkt auf das Leben von Bürger:innen aus. Daher sind Fehler doppelt schmerzhaft: Aufgrund der hohen Datenmenge können Mitarbeiter:innen nicht manuell eingreifen und korrigieren und die Auswirkungen sind direkt für die Bürger:innen spürbar. 

Management von Scope 

Wenn der GoLive-Termin fest vorgegeben ist und die Teamgröße ohne Effizienzverluste nicht beliebig skaliert werden kann, sieht Scrum das Management von Scope als Lösung für in der Regel aufkommende Knappheit vor. In diesem Fall waren allerdings grundlegende Funktionalitäten gesetzlich vorgegeben. Diese Anforderungen und Stories wurden durch den Fachbereich einheitlich als „Prio 1“ klassifiziert. Alle weiteren Anforderungen wurden als „Prio 2“ (erforderlich für den Projekterfolg) oder „Prio 3“ (nice-to-have) einsortiert. Damit waren alle Prio 2- und Prio 3-Anforderungen Verhandlungsmasse und im Projekt konnte darüber diskutiert werden, ob diese wirklich für den GoLive nötig sind.  

In den Diskussionen stellte sich heraus, dass Anforderungen vorhanden waren, die zwingend für den GoLive erforderlich waren, obwohl sie „nur“ als Prio 2 klassifiziert waren. Das liegt daran, dass der Gesetzgeber beispielsweise vorschreibt, dass die Kommunikation mit den externen Partnern digital und automatisiert zu erfolgen hat. Ob aber innerhalb der Verwaltung Verbesserungen durch mehr Automatisierung geschaffen werden, ist nicht gesetzlich geregelt. Aufgrund der hohen Menge und mit Blick auf die Zukunftsfähigkeit der Verwaltung waren für den Fachbereich die Automatisierungsanforderungen allerdings genauso relevant für den GoLive – aber im gängigen Klassifikationsschema eben nur Prio 2 und damit auf den ersten Blick vermeintlich vernachlässigbar. 

Um ein einheitliches Verständnis zu gewinnen, was benötigt wird und was nicht, haben der Fachbereich und der PO ein Anforderungsbacklog aufgebaut. In diesem Backlog wurden aber nicht nur die Anforderungen des Fachbereichs aufgenommen. Auch das Scrum Team hat sich zusammengesetzt und überlegt, welche technischen Themen unbedingt zum GoLive vorhanden sein müssen – schließlich war das Team als DevSecOps-Team unterwegs und musste in der Lage sein, die Services in der Produktion zu betreiben. Gemeinsam mit dem Fachbereich wurden die Anforderungen in eine abgestimmte Reihenfolge gebracht und eine Linie definiert, was bis zum GoLive unbedingt benötigt wird. Gegen diesen Umfang wurde das Fortschrittscontrolling durchgeführt, das auch für die Planbarkeit der Umsetzung wichtig ist.

Planbarkeit der Umsetzung

Im Sprint-Review wird vorgestellt, was das Scrum Team in der vergangenen Iteration umgesetzt hat. Zusätzlich wird Feedback eingesammelt und im besten Fall mit den Stakeholdern besprochen, was in der nächsten Iteration relevant ist. In diesem Fall war eine Iteration zwei Wochen. Bei einem GoLive-Termin, der aber noch ein bis zwei Jahre in der Zukunft liegt, ist eine Abschätzung, was bis dahin fertig sein wird, schwierig. Diese Abschätzung ist aber aus zwei Gründen notwendig: Im Austausch mit externen Partnern:innen, um eine potenziell drohende Verschiebung oder Einschränkung der Funktionalität frühzeitig zu kommunizieren. Und zur internen Kommunikation und Planung der Schulungen für ungefähr 20.000 Nutzer:innen. Diese Schulung muss aufgesetzt und im laufenden Betrieb durchgeführt werden und benötigt damit einen entsprechenden Vorlauf.

Im Projekt wurde dies gelöst, indem die fertig beschriebenen Anforderungen wurden in Epics heruntergebrochen. Diese Epics wurden durch die im Projekt beteiligten Product Owners (POs) besprochen und grob geschätzt. Die Schätzung wurde in Fibonacci-Zahlen mit dem Faktor 10 abgegeben. Die Grundüberlegung dabei: Wenn Entwickler User Storys mit den regulären Fibonacci-Zahlen schätzen, sollten alle Storys innerhalb dieses Epics zusammenaddiert ungefähr die Schätzung des Epics ergeben.

Die Schätzung aus der PO-Runde wurde nach Schätzung der Storys durch die Entwicklung korrigiert, da deren Schätzung präziser ist. Die Epics wurden dann in einem Burnup zusammengefasst. Dieses bestand also sowohl aus noch grob durch die POs geschätzten Epics  und schon feingranularer durch die Entwicklung geschätzten Epics  (basierend auf der Schätzung der darunter liegenden User Stories).

Da am Ende die Schätzung der Entwicklung Vorrang hatte, wurde im Burnup die durchschnittliche Velocity des Teams dagegen gelegt. Die Ziellinie lag bei der im Anforderungsbacklog definierten Grenze, die unbedingt für den GoLive erreicht sein musste. Natürlich gab es im Backlog und den Schätzungen entsprechende Schwankungen und es kamen neue Anforderungen hinzu, die sich dann auch im Burnup und der Hochrechnung widerspiegelten.

Das Burnup wurde jeden Sprint betrachtet und in der Zwei-Monatsplanung, die zusätzlich eingeführt wurde, ausführlich besprochen. In dieser war das Scrum Team durch den PO vertreten und es wurde nicht nur das Burnup besprochen, sondern auch geplant, welche Epics in den kommenden zwei Monaten umgesetzt werden. So wurde eine höhere Gewissheit bei gleichzeitig geringem Planungsaufwand erreicht. Zudem wurden Scheingenauigkeiten vermieden, die oft daher resultieren, dass ein zu langer Zeithorizont detailliert geplant wird.

Kritischer Live-Betrieb

Es war klar, dass die Services ab GoLive sehr hohe Datenmengen verarbeiteten, die manuelle Eingriffe schwierig und sehr aufwändig machen würden – Datenschutz- und Nachvollziehbarkeitsbedenken bei manuellen Eingriffen kamen noch hinzu. Darum war es elementar einen stabilen und fehlerfreien Betrieb sicherzustellen.

Leider lassen sich Fehler in komplexen Systemen mit vielen Schnittstellenpartnern nicht vermeiden. Darum entschied man sich früh, auf ein DevSecOps-Vorgehen zu setzen. Im Verlauf des Projekts wurden dann noch weitere Weichen gestellt, um die Geschwindigkeit von Fehlerbehebungen zu erhöhen: Nicht nur Continious Integration (CI), sondern Continious Deployment (CD; zusammen: CI/CD) war das Ziel. Dafür mussten im Projekt die entsprechenden Grundlagen gelegt werden. So lautete von Anfang an ein Teil der Definition of Done (DoD): Alle umgesetzten Storys sind durch automatisierte Tests abgedeckt.

Automatisierte Tests sind eine der wichtigsten, wenn nicht die wichtigste Grundlage für zuverlässige und wartbare Software. Und damit das Fundament von CI/CD. In den Microservices wurden die in der klassischen Testpyramide genannten Testarten bis auf den Abnahmetest durch Automatisierung abgedeckt (zu den technischen Details siehe hier)

Zusätzlich wurde von Anfang an in jedem Sprint nicht nur an fachlichen, sondern auch an technischen Storys gearbeitet. Es konnte damit eine typische Falle vermieden werden: Erst wird Fachlichkeit umgesetzt. Kurz vor dem GoLive stellt man dann die ganzen Probleme in der Infrastruktur und den Pipelines fest. Für stabile CI/CD benötigt man einen hohen Grad an Automatisierung, nicht nur in den Tests, sondern auch in den Pipelines, und ein starkes Monitoring und Logging um die Services adäquat betreiben zu können. Damit diese Anforderungen nicht aus dem Blick geraten, wurde wie oben beschrieben der technische Teil genau wie der fachliche Teil bewertet und gleichrangig in das Anforderungsbacklog sortiert. 

Der spannende Moment – der GoLive

Zum GoLive standen alle benötigten Anforderungen, sowohl vom Fachbereich als auch vom Scrum Team, in der Produktion bereit. Bei den ersten „echten“ Datenübertragungen zu dem externen Partner kam es dann aber doch zu Problemen. Hier zeigt sich, dass Schnittstellen kompliziert bleiben und durch die Termine der externen Partner das gemeinsame Testen zu spät gestartet wurde.

Wenngleich sich die erste Woche als herausfordernd gestaltete – die stark genutzte Möglichkeit, korrigierte Fehler schnell in die Produktion einzuspielen, hat die Probleme und Ausfälle sehr gering gehalten. Nachdem die Schnittstellen stabilisiert waren, konnte Schritt für Schritt in den normalen Betriebs- und Weiterentwicklungsmodus gewechselt werden (zusätzlich wurde durch das Team noch ein komplett neuer Service entwickelt).

Im vergangenen Jahr konnten so über 1.000 Deployments in die Produktion erfolgen. Die Wertstiftung durch Verbesserungen und Korrekturen fand also unmittelbar nach Fertigstellung statt und nicht erst zum nächsten Release. Auch durch den Fachbereich oder durch Nutzer:innen gemeldete Fehler konnten oft schon nach wenigen Stunden in der Produktion behoben werden – ein nicht alltägliches Vorgehen und Erlebnis!

Weiterführende Links: https://f4p.online/2024/03/15/kann-die-bundesagentur-agil/

Titelbild: Christian Lue von Unsplash