Agile Entwicklung für Behördenprojekte: Wenn Verwaltung lernen darf

Bei Behördenprojekten reicht manchmal ein Wort, um Missverständnisse auszulösen: Agilität. Die einen denken an Scrum-Boards, tägliche Abstimmungen und Sprints. Andere hören vor allem Kontrollverlust: weniger Planung, weniger Verbindlichkeit, mehr Unruhe. Beides greift im Alltag zu kurz.

Ich meine mit Agilität hier kein festes Methodenpaket. Agile Entwicklung heißt in diesem Kontext: eine digitale Lösung in überschaubaren Schritten bauen, Annahmen früh prüfen und Erkenntnisse einarbeiten, solange Änderungen noch möglich sind. Nicht erst am Ende, wenn der Dienst eigentlich fertig sein soll.

Gerade in der Verwaltung ist das anspruchsvoll. Ein Antrag soll nicht heute so und morgen anders bearbeitet werden. Entscheidungen müssen begründbar sein, Verfahren prüfbar, Zuständigkeiten klar. Verwaltung braucht Stabilität. Gleichzeitig entstehen digitale Verwaltungsleistungen fast immer unter Unsicherheit: Wie läuft der Prozess wirklich? Welche Daten liegen bereits vor? Welche Sonderfälle sind relevant? Was entlastet Bürger:innen und Sachbearbeiter:innen tatsächlich?

Der Denkfehler beginnt dort, wo Stabilität und Lernfähigkeit gegeneinander ausgespielt werden. Gute agile Arbeit stellt nicht alles zur Disposition. Sie klärt, was feststehen muss und wo ein Projekt lernen darf: Ziele, Zuständigkeiten, rechtliche Anforderungen und Entscheidungswege brauchen Verlässlichkeit. Die konkrete Lösung muss sich an der Wirklichkeit messen lassen.

Das ist nüchterner als die üblichen Agilitätsversprechen und genau deshalb für Behördenprojekte belastbarer. Ein paar Rituale aus der Softwarewelt machen Verwaltung noch nicht lernfähig. Dafür muss sie neue Erkenntnisse aufnehmen dürfen und weiterhin nachvollziehbar entscheiden.

Agil heißt nicht, Regeln zu ignorieren

Ein häufiger Einwand gegen agile Entwicklung in Behördenprojekten ist schnell erzählt: Verwaltung könne das nicht. Zu viele Regeln, zu viele Zuständigkeiten, zu viel Dokumentation, zu wenig Spielraum.

Ich finde diesen Einwand nicht falsch. Er ist nur unvollständig.

Eine Behörde kann nicht so arbeiten wie ein kleines Produktteam in einem Start-up. Sie ist an Haushaltsrecht, Vergaberecht, Datenschutz, Barrierefreiheit, Aktenführung, politische Beschlüsse und Fachgesetze gebunden. Diese Bindungen sind kein Betriebsunfall, sondern Teil ihrer Aufgabe. Verwaltung darf nicht nach Gefühl entscheiden. Sie muss nachvollziehbar, gerecht und prüfbar handeln.

Agilität wird dort problematisch, wo sie so tut, als seien diese Anforderungen nur störende Altlasten. Dann entsteht das schlechte Bild, das viele Menschen in Verwaltungen völlig zu Recht skeptisch macht: bunte Klebezettel, neue Begriffe, aber am Ende mehr Abstimmungsaufwand und weniger Klarheit.

Gute agile Arbeit in Behördenprojekten schafft früher Ordnung. Ein Projektteam hält Annahmen fest, macht offene Punkte sichtbar und prüft regelmäßig, ob die Lösung noch zum Problem passt. Ein gut gepflegtes Backlog ist keine wilde Wunschliste, sondern ein Arbeitsinstrument, mit dem fachliche, technische und organisatorische Entscheidungen nachvollziehbar werden.

Der Perspektivwechsel liegt in einer anderen Art von Verbindlichkeit. Ein Projekt behauptet nicht, heute schon alles zu wissen. Verbindlich sind das gemeinsame Problemverständnis, die Entscheidungswege und der Umgang mit neuen Erkenntnissen.

Lernen muss Folgen haben

Damit dieses Lernen mehr ist als ein gutes Gefühl, muss es Folgen haben dürfen. Zeigt ein Nutzendentest, dass ein Nachweis regelmäßig fehlt oder ein Begriff missverstanden wird, darf die Erkenntnis nicht bei einem Ticket mit niedriger Priorität enden. Reviews und Retrospektiven sind nur hilfreich, wenn daraus Entscheidungen entstehen.

Die entscheidende Frage ist: Darf das Projekt während der Umsetzung klüger werden? Wenn die Antwort nein lautet, helfen auch Sprints, Boards und Backlogs nur begrenzt.

In echten Verwaltungsprojekten liegen viele Risiken nicht in der Programmierung selbst. Sie liegen in Annahmen über den Ablauf: Wer darf entscheiden? Welche Daten liegen schon vor? Welcher Nachweis ist wirklich nötig? Was passiert mit Fällen, die nicht ins Standardmuster passen? Typisch sind Nachweise, die in der Leistungsbeschreibung selbstverständlich wirken, aber im Alltag schwer auffindbar sind: eine alte Bescheidkopie, ein bestimmtes Aktenzeichen, eine Vollmacht oder die richtige Arbeitgeberbescheinigung. Solche Fragen lassen sich vorbereiten, aber selten vollständig am Anfang beantworten. Manche Dinge versteht man erst, wenn Menschen mit einem Prototyp arbeiten oder Testdaten durch einen Prozess laufen.

Das ist kein Versagen der Planung. Es ist der Regelfall komplexer Softwareentwicklung. Mehr Vorab-Dokumentation beseitigt diese Unsicherheit nicht; sie verschiebt sie nur in ein sauber formatiertes Dokument.

Digitale Verwaltungsleistungen sind keine abgeschlossenen Projekte

Ein ähnliches Problem entsteht, wenn digitale Verwaltungsleistungen wie Projekte organisiert werden, obwohl sie eigentlich Produkte sind.

Ein Projekt hat ein Startdatum, ein Budget, einen Umfang und irgendwann eine Abnahme. Ein Online-Dienst passt schlecht in diese Logik. Er lebt weiter. Rechtsgrundlagen und Schnittstellen ändern sich, Nutzer:innen melden Probleme, Sicherheitsanforderungen steigen. Manchmal stellt sich erst nach dem Go-live heraus, dass eine Funktion zwar formal korrekt ist, aber im Alltag nicht gut genug funktioniert.

Der Produktmanagement-Ansatz der FITKO beschreibt IT-Planungsratsprodukte ausdrücklich als dauerhafte Lösungen für konkrete Probleme, nützlich für Bürger:innen, Verwaltungsmitarbeitende, Unternehmen und andere staatliche Stellen. Damit verschiebt sich der Blick von der Lieferung zur dauerhaften Verantwortung für eine Lösung.

Dort liegt in der Praxis oft der Engpass. Nach dem ersten Release gibt es vielleicht noch ein Restbudget, ein Wartungskontingent und ein Ticketsystem. Aber wer beobachtet, ob der Dienst tatsächlich genutzt wird? Wer priorisiert Verbesserungen? Wer entscheidet, ob ein umständlicher Nachweisschritt vereinfacht werden kann?

Wenn dafür niemand zuständig ist, entsteht schnell eine digitale Fassade. Vorne sieht es modern aus, hinten bleibt der alte Alltag: Ausdrucke, manuelle Nachfragen, Excel-Listen, E-Mails mit Anhängen, Sonderfälle auf Zuruf.

Agile Entwicklung hilft nur, wenn Menschen das Produkt fachlich und technisch steuern dürfen. Ohne diese Verantwortung ist ein Backlog bloß eine sortierte Warteliste. Ein Release bleibt dabei ein Zwischenstand, kein Schlusspunkt.

Nutzerzentrierung ist kein Bauchgefühl

Damit Produktverantwortung nicht abstrakt bleibt, braucht sie Kontakt zum Alltag. Nutzerzentrierung heißt dabei nicht, dass Bürger:innen oder Sachbearbeiter:innen sich einfach wünschen dürfen, was gebaut wird. Fachrecht, Datenschutz und Haushaltslogik bleiben relevant. Aber man muss genau hinschauen, an welcher Stelle Menschen hängen bleiben: beim Begriff, beim Nachweis, beim Login, bei einer Frist oder bei einer Frage, die nur aus Verwaltungssicht eindeutig ist.

Das beginnt selten beim hübscheren Formular. Wenn Bürger:innen in einem Online-Antrag regelmäßig an derselben Stelle abbrechen, kann das an schlechtem Design liegen. Es kann aber auch bedeuten, dass ein Begriff aus dem Fachrecht unverständlich ist, dass ein Nachweis nicht verfügbar ist oder dass der Prozess eine Lebenssituation falsch voraussetzt. Wenn Sachbearbeiter:innen eingehende Anträge ständig nachbearbeiten müssen, ist das nicht nur ein internes Komfortproblem. Es sagt etwas darüber aus, ob der digitale Dienst seine Arbeit macht.

Das OZG formuliert in § 7 mittlerweile klar, dass Nutzerfreundlichkeit und einfache Bedienbarkeit sicherzustellen sind und Nutzende in die Entwicklung neuer elektronischer Angebote einbezogen werden sollen.

Auch der Servicestandard und die zugrunde liegende DIN SPEC 66336 gehen weiter als ein Methodenhinweis. Seit Oktober 2025 verweist auch die OZSV in § 2 bei Qualitätsanforderungen an neue oder grundlegend überarbeitete Systeme auf diese DIN SPEC.

Für die Praxis folgt daraus: Komplexe Onlineservices brauchen früh Kontakt zur Realität. Ein Nutzendentest ist ein fachlicher Realitätsabgleich. Verstehen Menschen, was sie tun müssen? Kommen sie an die nötigen Informationen? Entlastet der Dienst auch die Verwaltung oder verschiebt er nur Arbeit von einem Schreibtisch auf einen anderen?

Der eGovernment MONITOR 2025 zeigt, dass viele Menschen Behördenkontakte weiterhin als anstrengend erleben und digitale Angebote oft nicht die erwartete Entlastung bringen. Das deckt sich mit dem, was man in Projekten immer wieder sieht: Online verfügbar ist nicht automatisch gut digitalisiert.

Beschaffung muss Unsicherheit aushalten

An dieser Stelle kommt die Beschaffung ins Spiel. Und ja, sie macht agile Behördenprojekte anspruchsvoller.

Öffentliche Auftraggeber müssen Leistungen beschreiben, Angebote vergleichbar machen, Vergaben dokumentieren und Entscheidungen prüffest treffen. Schwierig wird es, wenn daraus der Anspruch entsteht, ein komplexes Softwareprodukt vor der Umsetzung vollständig zu kennen.

Dann entstehen umfangreiche Leistungsbeschreibungen, die an entscheidenden Stellen trotzdem vage bleiben. Man beschreibt Funktionen, bevor das Problem verstanden ist. Beide Seiten bekommen einen Vertrag, der Sicherheit verspricht und Veränderung teuer macht.

Agile Beschaffung heißt nicht, ohne Ziel einzukaufen. Beschrieben werden müssen Ziel, Zusammenarbeit und Entscheidungslogik. Nicht jede fachliche Erkenntnis kann schon im Vergabetext stehen.

Dafür gibt es in der öffentlichen IT-Beschaffung Anknüpfungspunkte. Die UfAB ist als Praxisleitfaden für IT-Beschaffungen darauf ausgelegt, Ausschreibungen strukturiert, nachvollziehbar und bedarfsgerecht vorzubereiten. Bei IT-Verträgen bieten die EVB-IT standardisierte Muster. Die 2026 überarbeiteten EVB-IT-Muster berücksichtigen Open Source deutlich stärker und erleichtern neue Softwareprojekte, die nachnutzbar veröffentlicht werden können, etwa über openCode.

Standardisierte Muster ersetzen kein Produktmanagement. Zugleich ist der Rechts- und Beschaffungsrahmen nicht automatisch die größte Hürde. Häufig liegt das Problem darin, dass Fachbereich, Vergabestelle, IT, Datenschutz, Betrieb und externe Umsetzung zu spät über die Art der Zusammenarbeit sprechen.

Ich würde deshalb früher über Arbeitsweise sprechen als über Features: Wer darf priorisieren? Wann wird eine Erkenntnis verbindlich? Wer sagt Nein, wenn ein alter Prozess nur digital nachgebaut wird? Und wie bleiben Datenschutz, Barrierefreiheit und IT-Sicherheit laufend beteiligt?

Weil diese Absprachen Verantwortung sichtbar machen, werden sie leicht vertagt.

Nach dem Go-live zählt der Alltag

Viele Projekte investieren viel Energie in die Zeit vor dem öffentlichen Start. Verständlich. Der Go-live ist sichtbar, politisch relevant und organisatorisch aufgeladen. Danach soll endlich Ruhe einkehren. Nur ist digitale Verwaltung selten ruhig.

Im Betrieb sieht man, wie ein Dienst wirklich funktioniert. Welche Fragen landen beim Support? Wo brechen Menschen den Vorgang ab? Welche Angaben werden falsch verstanden? Wo entstehen neue Belastungen in der Sachbearbeitung?

In klassischen Projektlogiken wirken solche Erkenntnisse schnell wie Mängel. In einer produktorientierten Logik liefern sie die Grundlage für die nächste Verbesserung. Nicht angenehm, aber wertvoll.

Für Sachbearbeiter:innen ist das besonders wichtig. Wenn ein Online-Dienst nur den Eingang digitalisiert, aber die interne Bearbeitung komplizierter macht, ist wenig gewonnen. Dann entstehen neue Rückfragen, Medienbrüche und Workarounds. Und diese Workarounds sind oft unangenehm langlebig.

Agile Entwicklung muss deshalb beide Seiten ernst nehmen: die Menschen, die eine Leistung beantragen, und die Menschen, die sie bearbeiten. Ein guter Verwaltungsdienst endet nicht beim Formular im Browser. Er verbindet Rechtsgrundlage, Prozess, Daten, Fachverfahren, Kommunikation und Betrieb.

Hier wird Agilität konkret: Probleme früh erkennen und klären, wer daraus welche Entscheidung ableiten muss.

Wenn Verwaltung lernen darf

Agile Entwicklung hilft Behördenprojekten, wenn sie Verantwortung sichtbar macht. Ein Methodenset, das nur über die alte Projektlogik gelegt wird, genügt dafür nicht, und schwierige Entscheidungen verschwinden dadurch ebenfalls nicht. Wer Agilität als Garantie für schnellere, günstigere und unkompliziertere Projekte verkauft, verspricht zu viel.

Agile Entwicklung in der Verwaltung braucht klare Zuständigkeiten, saubere Dokumentation und Respekt vor rechtlichen Anforderungen. Die Beschaffung muss die Zusammenarbeit verlässlich rahmen, ohne jedes Detail vorzugeben. Hinzu kommen Produktverantwortung über den Go-live hinaus, echte Tests mit Bürger:innen und Verwaltungsmitarbeitenden sowie die Bereitschaft, Erkenntnisse nicht als Störung zu behandeln.

Kulturell ist das vermutlich der schwierigste Punkt. Verwaltung ist darauf trainiert, Fehler zu vermeiden. Agile Arbeit macht falsche Annahmen früher sichtbar. Ihre Korrektur kann unangenehm sein, ist an einem Prototyp aber deutlich günstiger als nach zwei Jahren Umsetzung, wenn Verträge, Erwartungen und politische Kommunikation schon festgefahren sind.

Für mich liegt darin der Wert agiler Entwicklung: Sie hilft Behördenprojekten, Annahmen zu prüfen, Erkenntnisse aufzunehmen und Verantwortung für die nächste Entscheidung zu übernehmen, obwohl sich nicht alles im Voraus planen lässt.