Agile Methoden in Behörden

Warum Agilität im öffentlichen Dienst den Unterschied macht

Warum geraten so viele IT‑Projekte im öffentlichen Dienst ins Stocken? Starre Prozesse, lange Entscheidungswege, umfangreiche Abstimmungen – und am Ende enttäuschte Auftraggeber.

Dabei geht es in Behörden nicht um ‚hippe‘ Methoden, sondern um verlässliche Ergebnisse, Transparenz und Wirtschaftlichkeit. Genau hier können agile Methoden ihren Mehrwert ausspielen: Sie verkürzen Feedbackzyklen, schaffen Klarheit über ‚fertig‘ vs. ‚angefangen‘ und binden Auftraggeber und Nutzer kontinuierlich ein.

In diesem Artikel zeige ich anhand eines realen Projekts in einer Bundesbehörde, wie wir aus einer schwierigen Ausgangslage heraus mit Scrum‑Elementen und pragmatischen Anpassungen deutlich bessere Resultate erzielt haben. Ich beschreibe die gefundenen Ursachen, einige Lösungsansätze, sowie besondere Herausforderungen. Das Ziel: Ein realistischer Werkzeugkasten, der in klassischen Verwaltungsstrukturen funktioniert und auch auf andere Projekte übertragbar ist.

Projektkontext: Vom klassischen Vorgehen zur Ernüchterung

Das Projekt umfasste die Umstellung und Erweiterung einer IT‑Service‑Management‑Lösung (ITSM) in einer Bundesbehörde. Die erste Phase lief klassisch: Prozesshandbücher, Lastenhefte, umfangreiche Vorab‑Dokumente und ein detaillierter Projektplan. Die Umsetzung startete formal sauber, die Realität war es nicht:

• Unvollständige bzw. uneindeutige Unterlagen und Lücken zwischen Konzeption und Implementierung.
• Kommunikationshemmnisse: unklare Verantwortlichkeiten, wenig verfügbare Ansprechpartner, Priorisierung zugunsten des Tagesgeschäfts.
• Späte Validierung: Der erste echte gemeinsame Test fand nach rund 18 Monaten statt – mit ernüchterndem Ergebnis. Erwartung und Implementierung klafften auseinander; zwischenzeitliche Entwicklungen beim Kunden waren nicht abgebildet.

Die Folge: Verzögerte Einführung, Nacharbeiten nach Go‑Live und ein deutlicher Vertrauensverlust. Zwar konnten wir nachbessern und das Vertrauen zurückgewinnen, aber klar war: So konnten wir die nächsten Erweiterungen nicht fortführen.

Ursachenanalyse: Drei Kernprobleme

1) Ungenügende Anforderungsdefinition

Trotz vieler Dokumente waren die Anforderungen nicht präzise genug, teilweise veraltet und nicht sauber auf das konkrete ITSM‑Produkt übertragbar. Wissenslücken ließen sich durch sporadische Rückfragen kaum schließen.

2) Zu geringe Einbindung des Kunden

Auftraggeberseitig standen nur begrenzte Kapazitäten zur Verfügung. Entscheidungen verzögerten sich, und das Team setzte teilweise Best Practices statt expliziter Kundenwünsche um. Als der Kunde erstmals intensiv testete, war es für grundlegende Korrekturen spät und teuer.

3) Big‑Bang‑Lieferung statt inkrementeller Ergebnisse

Das System sollte in einem Stück abgelöst werden. Tests starteten erst, als die Entwicklung ‚fertig‘ schien. Fehlerkosten stiegen, Lerneffekte kamen zu spät.

Der Turnaround: Agile Lösungsansätze aus der Praxis

Wir stellten das Setup für die nächsten Phasen so um, dass ca. 25 Entwickler in fünf Teams parallel arbeiten konnten – mit agilen Bausteinen, angepasst an die Rahmenbedingungen einer Behörde.

Vision, Epics, User Stories: Von grob zu fein

Statt monolithischer Lastenhefte nutzten wir eine kaskadierte Struktur:

• Vision: Ein klarer Zielkorridor für 6–12 Monate (z. B. ‚Change‑Management‑Prozess implementieren‘, ‚Asset‑Verwaltung für Server‑ und Clientsysteme aufbauen‘).
• Epics: Größere Themenpakete mit fachlicher Klammer über mehrere User Stories.
• User Stories & Tasks: Konkret und umsetzungsnah, priorisiert und feinjustiert kurz vor der Umsetzung.

Wichtig: Auf Kundenseite übernahmen Product Owner (PO) pro Team die fachliche Verantwortung. Sie erarbeiteten gemeinsam mit Anwendern, Administrierenden und dem Entwicklungsteam die Vision, priorisierten den Backlog und waren durchgängig ansprechbar.

Klare Start‑ und Zielkriterien: DoR & DoD

Zwei Definitionen machten den Unterschied und sorgten für gemeinsames Verständnis:

Definition of Ready (DoR) – Was muss vorliegen, um starten zu können?

• Anforderungen klar beschrieben
• Akzeptanzkriterien definiert
• Abhängigkeiten geklärt
• Ressourcen verfügbar (z. B. Testdaten, Ansprechpartner, Zugang)

Definition of Done (DoD) – Wann ist eine Aufgabe wirklich fertig?

• Umsetzung getestet und dokumentiert
• Akzeptanzkriterien erfüllt und abgenommen
• Ergebnis betriebsbereit bzw. produktiv nutzbar

Damit reduzierten wir Nachfragen, Schleifen und ‚Überraschungen‘ am Sprint‑Ende.

Kontinuierliche Einbindung: Feste Taktung, pragmatisch skaliert

Agil bedeutet nicht endlose Meetings, sondern regelmäßige, sinnvolle Touchpoints:

• Sprint Planning – Auswahl und Planung der Stories für den nächsten Sprint
• Sprint Review – Live‑Demos, Ergebnispräsentation, unmittelbares Feedback
• Sprint Retrospective – Prozessreflexion, konkrete Verbesserungsmaßnahmen

Wir hielten den Sprint‑Rhythmus von vier Wochen ein, verkürzten jedoch die Meetingzeiten (insgesamt 2–4 Stunden pro Team und Sprint), angepasst an Verfügbarkeit und Reifegrad. Entscheidend war die Konsistenz der Taktung, nicht die dogmatische Regelbefolgung.

Inkrementelle Lieferung: Früh sichtbarer Nutzen

Nach jedem Sprint zeigten wir funktionierende Software – zunächst in der Testumgebung, später zeitnah produktiv. Anfangs migrierten wir alle zwei bis drei Sprints, mit wachsender Routine meist eine Woche nach dem Review. Vorteile:

• Frühes Feedback, geringe Fehlerrisiken
• Schneller Nutzen für Nutzerinnen und Nutzer
• Gesteigertes Vertrauen in Team und Vorgehen

Einwände (‚nicht alles ist perfekt‘, ‚Fehler sind möglich‘) entkräften agile Zyklen von selbst: In vier Wochen steht der nächste Korrekturslot bereit.

Herausforderung 1: Reporting an Lenkungsausschuss & Management

Agile Teams organisieren sich oft selbst – Lenkungsausschüsse erwarten jedoch klassische Transparenz zu Zeit, Kosten, Leistung. Wir haben deshalb die Rolle des Projektmanagers nicht abgeschafft, sondern fokussiert:

• Kein Task‑Mikromanagement in den Teams
• Sehr wohl: Personaleinsatz, Budgetsteuerung, Risikomanagement und Zusammenführung der Teamergebnisse in ein Management‑Reporting

Jedes Team benannte einen Teamlead als Schnittstelle. Für die Berichte kombinierten wir agile Metriken mit klassischen Steuerungsgrößen:

• Agile Sicht: Velocity/Throughput (Trend, nicht Ziel!), Burn‑Up (Wertzuwachs), Cycle Time/Lead Time, Vorhersagbarkeit (Plan vs. Done)
• Klassische Sicht: Meilenstein‑Status, Budgetverbrauch (Ist/Plan), Risiko‑Heatmap, Entscheidungsbedarfe

So konnten wir dem Lenkungsausschuss verlässlich zeigen, wo wir stehen, was wir liefern und wo Unterstützung nötig ist, ohne die Teams mit Statusfolien zu überlasten.

Herausforderung 2: Nicht agilfähige Software & aufwendige Migrationen

Viele ITSM‑Plattformen sind nicht als Code‑First‑Systeme konzipiert, welches Agile Vorgehensweise unterstützt. Unsere Migrationen zwischen Entwicklungs‑, Test‑ und Produktionsumgebung waren anfangs manuell und zeitintensiv (bis zu ein Tag). Unser Gegenmittel:

• Entwicklung eines eigenen Toolsets zur Dokumentation der Änderungen
• Teil‑Automatisierung der Migration (Skripte, wiederverwendbare Schritte)
• Dokumentierte Prozesse (Dokumentierter Ablauf, Verantwortungen)
• Übung durch regelmäßige Anwendung
• Standardisierte Release‑Fenster und Backout‑Pläne für schnelle, kontrollierte Rücksprünge
• Daten‑ und Konfigurationsdifferenzen bewusst klein halten durch kurze Release‑Zyklen

Ergebnis: Produktive Migrationen dauerten am Ende meist < 1 Stunde – mit deutlich weniger Risiko und Stress.

Ergebnisse: Was sich für Auftraggeber und Teams verbessert hat

• Höhere Ergebnisqualität: DoR/DoD und kurze Feedbackschleifen reduzierten Fehlentwicklungen.
• Mehr Transparenz: Regelmäßige Reviews, klare Metriken, belastbares Reporting.
• Schnellerer Nutzen: Inkrementelle Lieferungen erzeugten frühe, sichtbare Verbesserungen.
• Gestärktes Vertrauen: Auftraggeber sahen Fortschritte, Teams erhielten Wertschätzung.
• Bessere Zusammenarbeit: Value Co‑Creation statt ‚Wer hat’s verbockt?‘

Mit der Zeit entwickelte sich das Vorhaben beim Kunden zum Vorzeigeprojekt. Nicht, weil alles perfekt war, sondern weil wir durch ständige Lieferung neuer Funktionen auf allen Ebenen an Sichtbarkeit gewonnen haben.

Übertragbarkeit: Was andere Behörden sofort übernehmen können

Viele Behörden fragen sich, wie sie agile Methoden in ihre bestehenden Strukturen integrieren können. Die gute Nachricht: Es braucht keine vollständige Umstellung. Schon mit einem schlanken Setup lassen sich erste Erfolge erzielen – pragmatisch, anschlussfähig und ohne Bruch mit bestehenden Governance-Strukturen.

1) Minimal‑Setup definieren

• Rollen: Pro Team ein Product Owner (kundenseitig), ein Teamlead (Schnittstelle zum PM), Projektmanager für Budget/Personal/Reporting.
• Zyklus: Zwei bis vier‑Wochen‑Sprints, kompakt geplante Planning/Review/Retro.
• Artefakte: Backlog mit Vision → Epics → Stories, DoR/DoD je nach Bereich.

2) Reporting anschließen statt ersetzen

• Bestehende Meilensteine durch Visionen ersetzen und mit agilen Lieferplänen unterfüttern.
• Management‑Kennzahlen mit agilen Indikatoren kombinieren (Burn‑Up, Durchsatztrend).
• Entscheidungsvorlagen schlank halten: Klarer Bedarf, Optionen, Empfehlung.

3) Migration und Betrieb mitdenken

• Release‑Rhythmus festlegen (z. B. alle 4–8 Wochen).
• Runbooks, Checklisten, Backout‑Strategien standardisieren.
• Automatisierung soweit wie möglich – auch kleine Skripte summieren sich.
• Regelmäßige Übung macht das Betriebsteam schneller.
• Nach jedem Release Lessons Learned dokumentieren.

4) Kapazitäten realistisch planen

• Auftraggeberseitig Verfügbarkeit für PO und Key‑User fest zusagen (z. B. Jour‑Fixe).
• Priorisierung ehrlich machen: Wenn alles ‚Prio 1‘ ist, ist nichts priorisiert.
• Puffer für Unwägbarkeiten (z. B. Sicherheits‑/Compliance‑Nachforderungen) einplanen.
• Pflege des Backlogs (Backlog Refinement) als Aufgabe für die Entwickler und PO berücksichtigen.

Häufige Stolpersteine und wie Sie sie umgehen

Natürlich gibt es typische Stolpersteine, die den Erfolg gefährden können. Einige wesentliche sollen hier kurz dargestellt werden:

• Agil ohne Auftraggeber: Wenn PO/Key‑User nicht verfügbar sind, verpufft der Effekt. Lösung: Verbindliche Zeitfenster und Stellvertreterregelungen.
• Dogmatisches Scrum: Regeln sind Mittel zum Zweck. Lösung: Pragmatisch anpassen, aber Takt und Transparenz bewahren.
• Statusberichte vs. echte Steuerung: Zu viel Reporting, zu wenig Entscheidung. Lösung: Entscheidungsbedarfe explizit machen, Meetings outcome‑orientiert.
• Technische Schulden: Sie wachsen still. Lösung: Pro Sprint Wartungs‑/Automatisierungsanteil fest verankern (z. B. 10–20 %).
• Zu große Inkremente: Feature‑Pakete werden wieder monolithisch. Lösung: Schneiden trainieren, Feature‑Flags/Schrittfolgen nutzen (wo möglich).