Eine digitale Verwaltung kann man nicht kaufen

Hinweis: Dieser Beitrag wurde von den Referent:innen des Workshops Öffentliche IT-Projekte besser steuern verfasst. Die Anmeldung zum Workshop ist geöffnet und hier möglich.

Wieso Behörden eine aktivere Rolle bei der Softwareentwicklung spielen müssen

Zu teuer, zu langwierig, zu kompliziert – IT-Projekte der öffentlichen Verwaltung haben einen schlechten Ruf. Zwar investiert die deutsche Verwaltung jährlich Milliarden in den Einkauf und die Entwicklung von IT-Infrastruktur und Software, doch die Ergebnisse bleiben oft dürftig. Die Erfahrungen der Corona-Pandemie haben uns den Handlungsbedarf einmal mehr schmerzlich vor Augen geführt.

Verwaltungen brauchen gute Software, um effizient arbeiten zu können und um Bürger:innen nutzerfreundliche Online-Angebote zu bieten. Wir glauben aber, dass dieses Ziel nur erreicht werden kann, wenn wir die Perspektive auf die öffentliche Beschaffung digitaler Produkte grundlegend ändern. Verwaltungen müssen sich dazu mit den andernorts längst gängigen Prinzipien agiler Softwareentwicklung vertraut machen, mehr Verantwortung für ihre digitalen Produkte übernehmen und eine wesentlich aktivere Rolle während des gesamten Entwicklungsprozesses spielen.

Wir wollen im Rahmen unseres Piazza-Workshops eine Diskussion darüber anstoßen, wie dieser Perspektivwechsel gelingen kann. Wir sind besonders interessiert an den Erfahrungen von Verwaltungsbeschäftigten, die Software-Projekte begleitet haben. Dabei interessieren uns Erfolgsgeschichten genauso wie Frusterfahrungen: Wir wollen besser verstehen, wo Vorschriften und Bürokratie die Anwendung agiler Prinzipien behindern, aber natürlich auch, welche kreativen Wege es gibt, bestehende Hindernisse zu überwinden.

Mit diesem kleinen Blogbeitrag möchten wir eine erste Diskussionsgrundlage liefern, die wir gerne perspektivisch zu einem Leitfaden erweitern wollen. Wir freuen uns natürlich über Feedback zu unseren Gedanken, direkt im Workshop oder über andere Kanäle.

Zeit für einen Perspektivwechsel

Verwaltungen betrachten Software in der Regel als ein Produkt, das am Markt beschafft werden kann. Entsprechend gehen Behörden beim Einkauf von Software auch ähnlich vor, wie bei der Beschaffung herkömmlicher Produkte: Die gewünschte Leistung wird im Rahmen einer öffentlichen Ausschreibung möglichst umfassend beschrieben, der wirtschaftlichste Bieter erhält den Zuschlag und liefert einige Zeit später ein Ergebnis. Die Verwaltung selbst beschränkt sich auf das Vergabe- und Vertragsmanagement, hält sich aus der Produktentwicklung aber weitestgehend heraus.

Es mag Situationen geben, wo ein solches Vorgehen sinnvoll ist, etwa bei der Beschaffung von handelsüblichen Office-Programmen oder der Nutzung von Software-as-a-Service (SaaS)-Angeboten. In den meisten Fällen sind digitale Verwaltungsprodukte aber Maßanfertigungen: Die je spezifischen Anforderungen einzelner Behörden machen es erforderlich, dass entweder eine am Markt existierende Lösung umfassend angepasst oder sogar gleich eine Neuentwicklung in Auftrag gegeben werden muss. 

In diesen Fällen greift die der analogen Welt entstammende Beschaffungs- und Produktlogik ins Leere: Es ist ein Grundsatz der agilen Softwareentwicklung, dass sich digitale Produkte eben nicht schon im Vorfeld umfassend beschreiben lassen und dann nur noch entwickelt werden müssen. Stattdessen entsteht Software in eng getakteten, iterativen Zyklen, bei denen ein zunächst rudimentärer Prototyp schrittweise und in enger Abstimmung mit Kund:innen und Nutzer:innen getestet, angepasst und verfeinert wird.

Das Prinzip der öffentlichen Produktbeschaffung samt Lastenheft lässt für solch ein exploratives Herantasten an die beste Lösung wenig Raum. So passiert es regelmäßig, dass Behörden ein gewünschtes Produkt vorab akribisch beschreiben (und dafür einen hohen Aufwand betreiben, denn ein Lastenheft schreibt sich nicht von selbst), dass sich der vorgesehene Weg in der Entwicklung aber dann schon nach kurzer Zeit als nicht gangbar erweist. Dass während des extrem dynamischen Vorgangs der digitalen Produktentwicklung unvorhergesehene Umstände auftreten, lässt sich tatsächlich kaum vermeiden. Die Frage ist nur, wie man damit umgeht.

Aus eben diesem Grund ist es bei der agilen Softwareentwicklung üblich, die Kundenperspektive nicht nur am Anfang und am Ende, sondern über den ganzen Prozess hinweg einzubeziehen. In agilen Teams wird diese Perspektive durch die Rolle der „Product Ownerin“ vertreten. Die Product Ownerin beschreibt funktionale Anforderungen an das Produkt aus Sicht einer Nutzerin, testet Zwischenergebnisse und priorisiert die jeweiligen Zielsetzungen für den nächsten Entwicklungs-Sprint. Sie ist folglich ein fester Bestandteil des Projektteams und maßgeblich für den Erfolg des Projektes verantwortlich.

Neue Rollen schaffen neue Chancen

Wir halten es für entscheidend, dass bei der Entwicklung von Verwaltungssoftware die Rolle der Product Ownerin durch eine in der entsprechenden Verwaltung beschäftigte Person selbst ausgefüllt wird. Die dafür notwendigen Kenntnisse und Methoden lassen sich zur Not auch unterwegs erlernen. Idealerweise findet sich eine Person, die Erfahrungen mit digitaler Produktentwicklung hat, mindestens aber eine gewisse Leidenschaft für digitale Anwendungen mitbringt. Vertiefte technische Kenntnisse sind für die Rolle gar nicht unbedingt notwendig, da es ja gerade darum geht, das Produkt mit der Nutzer:innenbrille zu betrachten. Wichtiger sind die grundsätzliche Bereitschaft und Kapazitäten, sich auf die – zeitintensive, aber sehr gewinnbringende – agile Projektarbeit einzulassen.

Übernimmt die Verwaltung bei der Entwicklung digitaler Anwendungen eine aktive und gestaltende Rolle, ändert sich mit der Position auch die Perspektive: Statt Software als Produkt zu betrachten, das am Markt beschafft werden muss, erscheint diese nun als Ergebnis eines Entwicklungsprozesses, den Verwaltungen selbst umsetzen und verantworten, und bei dem sie natürlich trotzdem auf externe Unterstützung (zum Beispiel Programmier-, UX- oder Designleistungen) zurückgreifen können.

Der Perspektivwechsel hat auch Konsequenzen für die Art des Einkaufs: Statt ein fertiges Produkt für einen Festpreis am Markt zu beschaffen, kauft die Behörde nun eine Dienstleistung in Form von Entwicklungskapazitäten. Statt zu versuchen, alle erdenklichen Details der gewünschten Anwendung vorab festzuschreiben, begeben sich Beschäftigte der Verwaltung mit einem Team aus Programmierer:innen in einen Entwicklungsprozess, mit dem Ziel, in einem vorgegebenen Zeit- und Budgetrahmen die bestmögliche Lösung für ein Problem zu finden.

Der Verzicht auf eine klare Definition sämtlicher Funktionalitäten des Produkts vorab mag riskant erscheinen, ist aber tatsächlich ein Weg, Risiko zu reduzieren. In agilen Prozessen lässt sich das Scheitern eines zuvor gewählten Ansatzes sehr viel früher antizipieren, so dass noch Zeit bleibt, umzuschwenken. Selbst ein einmal gewählter Dienstleister lässt sich theoretisch im Prozess ersetzen, falls die Zusammenarbeit nicht funktioniert. Zumindest dann, wenn sich die Verwaltung als Product Ownerin um eine transparente Dokumentation des Prozesses kümmert und auf Offenheit der entwickelten Quellcodes besteht (was sie natürlich ohnehin tun sollte).

Angesichts knapper Ressourcen mag die Vorstellung einer Verwaltung, die aktiv digitale Produktentwicklung betreibt, für manche Behörden wenig realistisch erscheinen. Allerdings fehlt es beim Thema Digitalisierung vielerorts längst nicht mehr am Geld, sondern an den Fähigkeiten und Kapazitäten, dieses Geld effektiv einzusetzen. Aber Fähigkeiten lassen sich erlernen, und Kapazitäten lassen sich schaffen. Es wäre eine Investition in die Zukunft einer digital handlungsfähigen Verwaltung.

Titelbild: Gibt es nicht im Supermarkt: Gute Software für Verwaltungen (Dietmar Rabich / Wikimedia Commons / „Los Angeles (California, USA), Shop, South Olive Street — 2012 — 4845“ / CC BY-SA 4.0)