In öffentlichen Verwaltungen herrschen traditionelle Rahmenbedingungen. Wie gelingt es dennoch, digitale und einfach zu bedienende Services einzuführen? Mit Design Sprints! Tal Uscher und Nicole Röttger erläutern, was dabei zu beachten ist.
An Amazon-Kindle übertragen
Melden Sie sich bei Ihrem Amazon Konto an und folgen Sie den Anweisungen, um Ihre Datei hochzuladen und auf Ihr Kindle-Gerät zu übertragen. Unter diesem Link können Sie Ihre Amazon-Geräte und Dateien verwalten. Feedback oder Fragen?
In öffentlichen Verwaltungen herrschen traditionelle Rahmenbedingungen. Wie gelingt es dennoch, digitale und einfach zu bedienende Services einzuführen? Mit Design Sprints! Tal Uscher und Nicole Röttger erläutern, was dabei zu beachten ist.
In der öffentlichen Verwaltung wächst der Druck und damit verbunden der Wunsch, Lösungen zu entwickeln, die für Bürger:innen und Unternehmer:innen tatsächlich funktionieren: Services der Verwaltung sollen digital, einfach zu handhaben und leicht zu verstehen sein. Das sind sie bisher oftmals nicht. Es liegt nahe, auch in diesem Kontext Methoden einzusetzen, bei denen die Nutzer:innen im Zentrum stehen, wie beispielsweise Design Sprints.
Design Sprints sind mittlerweile eine agile Standardmethode bei der nutzerzentrierten Lösungsentwicklung. Eine Eins-zu-eins-Übertragung der Methode, wie sie in agilen Organisationen zum Einsatz kommt, wird in der Verwaltung aufgrund der sehr traditionellen Rahmenbedingungen jedoch kaum funktionieren. Worauf sollte man also achten, wenn man Design Sprints in der öffentlichen Verwaltung verwenden möchte? Diese Frage wollen wir im nachfolgenden Artikel anhand eines Praxisbeispiels beantworten.
Wir haben bereits eine Vielzahl an Design Sprints sowohl vor Ort und als auch online mit ganz unterschiedlichen Teams und unter verschiedenen Voraussetzungen durchgeführt. Hier teilen wir unsere Erfahrungen dazu, welche Anpassungen im Verwaltungskontext erforderlich sein können und was in der Umsetzung konkret bedacht werden sollte.
Das 2017 in Kraft getretene Onlinezugangsgesetz (OZG) verpflichtet Bund und Länder, ihre Verwaltungsleistungen auch online zur Verfügung zu stellen. Das bedeutet, dass insgesamt 575 Leistungsbündel und mehrere Tausend Einzelleistungen bundesweit zu digitalisieren sind. Das Landesamt für Straßenbau und Verkehr in Mecklenburg-Vorpommern wollte in einem ersten Schritt zwei Verwaltungsleistungen weiterentwickeln und online über das Landesportal bereitstellen: Das Amt wollte schnell und mit sehr starkem Fokus auf den Bedarf der Nutzer:innen eine bessere digitale Leistung entwickeln. Zusätzlich sollte das Vorhaben als Impuls für ein modernes und agiles Arbeiten im Landesamt dienen.
Das agile Framework Design Sprint erfüllt diese Anforderungen. Insbesondere der Aspekt des begrenzten Zeitraums für Experimente mit getesteten Ergebnissen nach jedem Zyklus machte das Framework besonders attraktiv für das Landesamt, da es im ersten Schritt vergleichsweise wenig Risiko mit sich bringt.
Bitte verstehen Sie die öffentliche Verwaltung in erster Linie als ein Beispiel, da die Notwendigkeit der Anpassung auch für viele andere Organisationen besteht. Dies gilt insbesondere für solche, die bisher wenig bis keine Erfahrungen mit agilen Ansätzen gemacht haben, diese Vorgehensweise aber anstreben. Wir haben dazu in verschiedenen Projekten Erfahrungen in mittelständischen Betrieben sowie Unternehmen der öffentlichen Hand gesammelt. Das Branchenspektrum umfasste u.a. Bau-, Immobilien-, und produzierende Unternehmen oder auch Automobilzulieferer, sowohl mit als auch ohne IT-Bezug. Viele unserer Erkenntnisse können wir deshalb auch auf andere Organisationen und Projekte übertragen.
Das auf dem Design Thinking basierende Konzept des Design Sprints wird eingesetzt, um für komplexe Herausforderungen innerhalb einer Arbeitswoche Lösungsideen in Form von Prototypen zu erarbeiten und mit Kund:innen zu testen. Diese Art des Vorgehens soll Risiken bei neuen Produkten oder Dienstleistungen reduzieren, da die Kund:innen eine Lösung angeboten bekommen, die sie tatsächlich nutzen und brauchen (für mehr Infos siehe den Glossareintrag zum Design Sprint).
Es gibt nach wie vor unzählige Unternehmen und Organisationen, die am Anfang ihrer agilen Reise stehen. Dort existieren Rahmenbedingungen, die eine Einführung agiler Arbeitsweisen erheblich erschweren, wie z.B. eine sehr hierarchiegeprägte Organisationskultur.
Die öffentliche Verwaltung ist ein sehr prägnantes Beispiel dafür, wie man Agilität in einem scheinbar dafür ungeeigneten Kontext anwendbar machen kann. Unsere wichtigste Erkenntnis aus zahlreichen agilen Transformationen: Wegen der besonderen Rahmenbedingungen ist eine Umsetzung "by the book" zum Scheitern verurteilt. Nur durch eine sinnvolle Adaption können Sie mit dem Design Sprint und anderen agilen Frameworks erfolgreich Mehrwert für alle Beteiligten schaffen.
Bevor Sie den Design Sprint zum ersten Mal in einer öffentlichen Verwaltung anwenden, sollten Sie folgende Aspekte bedenken:
Mit all diesen Aspekten müssen Moderator:innen oder Coaches im Design Sprint umgehen – und am besten auch schon davor. Ein erfahrenes Team kann in vielen Fällen auch ohne eine Moderation auskommen, da es den Ablauf kennt und die Notwendigkeit von Entscheidungsfindung, Fokus und Ergebnisorientierung bereits erlebt und nachvollzogen hat.
Anders ist das bei einem neuen und unerfahrenen Team. Hier ist die Unterstützung durch eine Moderation essenziell. Es ist häufig der Fall, dass Teams sich tief in Diskussionen und Problemdenken verstricken, ohne zu den eigentlichen Ergebnissen zu kommen. Es kann auch vorkommen, dass noch viele Detailfragen zur Methode gestellt oder sogar noch Machtpositionen ausgehandelt werden, wenn das Team auf sich allein gestellt ist. Hier sorgt die Moderation für das Einhalten des Prozesses, vermittelt Wissen zur Methode und bietet Hilfestellung bei der Konfliktlösung.
Die aufgeführten Aspekte zeigen deutlich, dass eine Anpassung an den entsprechenden Kontext zwingend ist, um die Beteiligten und am Ende auch die Gesamtorganisation nicht zu überfordern. Hier sind Fingerspitzengefühl und ein gutes Verständnis des Status Quo im Veränderungsprozess und der Kultur der Organisation sehr wichtig und hilfreich.
Das Ziel des Onlinezugangsgesetzes (kurz: OZG) ist es, die wesentlichen Verwaltungsleistungen (mehrere Tausend Einzelleistungen) bis Ende 2022 zu digitalisieren, um damit den Zugang zu Verwaltungsangeboten nachhaltig zu verbessern – im besten Fall nutzerzentriert.
In diesem Zusammenhang entwickelten zwei Teams in einem Design Sprint jeweils eine Verwaltungsleistung des Landesamtes für Straßenbau und Verkehr Mecklenburg-Vorpommern. Wir begleiteten die beiden Teams bei diesem nutzerzentrierten Prozess.
Es war in zweifacher Hinsicht ein Experiment:
Die Leistung "Ausnahmegenehmigung für Fahrzeuge, deren Abmessungen, Achslasten oder Gesamtgewichte die gesetzlich zugelassenen Grenzen überschreiten gem. §29 ("Mähdrescher")" war bereits als einfache PDF-basierte digitale Lösung zugänglich. Darüber können Landwirt:innen oder Hersteller:innen von landwirtschaftlichen Fahrzeugen die Genehmigung für die Straßennutzung mit den übergroßen Fahrzeugen während der Saison beantragen und anschließend erhalten. Für diese Leistung wurde das Ziel definiert, sie mit Nutzer:innen weiterzuentwickeln, um ihnen eine noch komfortablere Lösung zu bieten z.B. mit integrierter Zahlungsoption. Bisher wurde nach Beantragung der Genehmigung eine Zahlungsanweisung versendet, woraufhin der:die Antragstellende den entsprechenden Betrag überweisen musste.
Bei der Verwaltungsleistung "Genehmigung von Baustellenzufahrten an Bundestraßen" ging es um eine komplett neue nutzerzentrierte digitale Lösung. Hierbei wird eine Genehmigung beantragt, um an Bundesstraßen auf Baustellen auf eine zu diesem Zeitpunkt noch nicht formell vorhandene Zufahrt fahren zu dürfen. Damals existierte lediglich der Weg über das Telefon und per E-Mail.
Beide Leistungen sind heute nutzbar im MV Serviceportal, dem Onlineportal des Landes Mecklenburg-Vorpommern:
Darüber hinaus ist durch dieses Projekt im Landesamt das Interesse an agilen Methoden so sehr gewachsen, dass in einem Folgeprojekt das Redesign des Intranets der gesamten Straßenbauverwaltung Mecklenburg-Vorpommern auf Basis eines Design Sprints unter Einbeziehung der Beschäftigten entstanden ist.
Auf der Ebene des Landesministeriums wurde nachgewiesen, dass das Entwickeln von Leistungen auf eine nutzerzentrierte Art nicht nur möglich, sondern auch schnell umsetzbar ist.
Für den Erfolg des Projekts berücksichtigten wir mehrere Aspekte und passten das Design Sprint Framework folgendermaßen an:
In einem Design Sprint ist es wichtig, die notwendigen Kompetenzen im Sprint-Team zu haben, die es für die Entwicklung der Lösung braucht. Je nachdem, um welchen Kontext es sich handelt, sind das z.B. Menschen mit Kompetenzen in den Bereichen UX-Design, Softwareentwicklung, Betriebswirtschaft und Geschäftsmodellentwicklung sowie Marketing. Das Ziel ist, möglichst unterschiedliche Expertisen im Team zu haben, um die Lösungsentwicklung aus vielen unterschiedlichen Perspektiven zu beleuchten und zu reflektieren. Das wirkt der Entwicklung reiner Silo- oder Expertenlösungen entgegen, die zu sehr von der technischen Basis her gedacht sind und von Nutzer:innen nicht verstanden werden. Zudem verbessert dies die Voraussetzungen für eine schnelle Umsetzung der Lösung, da die notwendigen Expertisen bereits im Team sind und vergleichsweise wenige Abstimmungen mit Bereichen außerhalb des Teams in der Entwicklungsphase nötig sind.
In der öffentlichen Verwaltung ist das Zusammenstellen heterogener Teams aus verschiedenen Gründen nicht trivial: Zunächst arbeiten viele Verwaltungen nicht in Teams. Die Beschäftigten gehören zwar einer Abteilung an und haben häufig auch ein gemeinsames Meeting (die sogenannte Dienstberatung), aber konkrete Teamarbeit ist die Ausnahme. Die meisten Organisationen sind noch in Fachsilos mit klaren Zuständigkeiten strukturiert. Gleichzeitig ist eine Verwaltung sehr hierarchisch geprägt und es existiert eine ausgeprägte Siez-Kultur.
Hinzu kommt, dass Expertise für agile Arbeitsweisen und Know-how für die Nutzerfreundlichkeit von digitalen Lösungen erst aufgebaut werden müssen. Solche Expertisen liefern oftmals Dienstleister:innen, z.B. im Rahmen externer Softwareprojekte.
Wie kann also ein Design Sprint Team zusammengestellt werden, wenn zentrale Voraussetzungen fehlen? Und wie kann das funktionieren, wenn die Beschäftigten nicht komplett von ihren regulären Aufgaben freigestellt werden bzw. sie versuchen, diese im Sprint noch parallel zu erledigen?
Im Fall des Design Sprints des Landesamts haben wir als Apiarista GmbH Anforderungen zur Heterogenität des Teams formuliert. Diese bezogen sich vor allem auf die Fachgebiete und die Hierarchie. Es war der erste Design Sprint und ein neues Vorgehen im Haus. Deshalb sollten die Teilnehmenden folgende Eigenschaften mitbringen:
Zusammengekommen sind zwei Teams, die sich trotz anfänglicher Skepsis auf das neue Vorgehen einließen, gut zusammenarbeiteten und sehr konstruktive Diskussionen führten. Das Duzen wurde sofort umgesetzt und von allen akzeptiert, was aufgrund der verschiedenen Hierarchieebenen keine Selbstverständlichkeit war.
Wir wussten, dass die Arbeit mit der Methodik für alle eine neue Erfahrung war. Umso wichtiger war es, dass die Charaktere zusammenpassten und veränderungsbereite, aber gleichermaßen kritische Persönlichkeiten zusammenkamen. Denn wir sollten das agile Arbeiten nicht nur ausprobieren, sondern auch überprüfen, ob eine solche Arbeitsweise aus Sicht der Beteiligten als sinnvoll und zielführend erachtet wurde.
Ein Design Sprint folgt einem sehr stringenten Muster und einem engen Zeitplan. Dieser ist zu Beginn der Sprint-Woche bereits festgelegt (siehe Glossareintrag "Design Sprint"). Verzögerungen werden dank Timeboxing vermieden. Vertiefungs- und Entscheidungspunkte ermöglichen ein hochwertiges Ergebnis, ohne alles bis ins Detail ausdiskutieren zu müssen. In den Folge-Sprints, die nach dem gleichen Muster ablaufen, wird der Methodeneinsatz in den einzelnen Tageseinheiten angepasst. Die Basis dafür ist das Feedback der Nutzer:innen zu den Prototypen.
Wenn beispielsweise die Tests ergeben haben, dass das eigentliche Nutzerproblem nicht ausreichend verstanden wurde, dann wird es dazu einen spezifischen Methodenmix geben, der diese Analyse unterstützt. Wenn wiederum bei den Prototypen die Handhabung noch nicht intuitiv genug ist, braucht es hier etwas mehr Methoden rund um das Prototyping. Hier ist der Methodenkoffer der Coaches oder Sprintbegleiter:innen gefordert, da im Folgesprint mit den Erkenntnissen des ersten Sprints umgegangen werden muss. Der Wochenablauf mit den jeweiligen Phasen bleibt in der Chronologie und der grundsätzlichen Vorgehensweise erhalten. Das bedeutet, dass die Woche mit der Analyse beginnt und am fünften Tag mit den Tests der neuen Prototypen und einer ersten Auswertung der Tests endet.
Offene Diskussionspunkte lassen sich in den nachfolgenden Sprint aufnehmen, wenn sie weiterhin relevant sind. Wenn das Prototyping z.B. ergibt, dass sich die zentralen Hypothesen bestätigt haben und lediglich die Nutzerführung in einem spezifischen Bereich der Lösung Probleme bereitet, dann sollte sich das Team auf die damit verbundenen Fragen konzentrieren.
Bei unseren vergleichsweise unerfahrenen Teams mussten wir das Framework trotzdem nicht komplett umstellen. Zum einen waren die zu bearbeitenden Herausforderungen in ihrer Komplexität noch handhabbar und zum anderen gab es für die zu entwickelnden Lösungen Vorarbeiten.
Wir verwendeten also die Grundstruktur, passten aber einzelne Bausteine an, um ein paar Herausforderungen zu lösen: Zunächst wollten wir sicherstellen, dass die Teilnehmenden sich mit der Methode vertraut machen könnten und möglichst wenig Widerstand aufgrund von Ängsten oder Überforderung entwickelten. Noch vor dem eigentlichen Design Sprint führten wir deshalb einen Kick-off durch, der eine Einführung in die agile Arbeitsweise und erste Praktiken der agilen Arbeitsweise enthielt (z.B. Timeboxing, Visualisierung und das Arbeiten in Zyklen). So konnten sich die Teilnehmenden vorab auf die neue Art des Arbeitens einstimmen und für sich prüfen, ob sie sich darauf einlassen könnten.
In den zwei Design Sprints bauten wir zudem zusätzliche Blöcke für Erläuterungen und Wiederholungen ein, damit die Beteiligten trotz der vielen neuen Eindrücke vergleichsweise schnell Sicherheit im Umgang mit der Methode gewinnen konnten.
Normalerweise startet man mit simplen Prototypen aus Papier und steigert sich im Folgesprint, indem man einen digitalen Prototypen erstellt; aufgrund der Corona-Lage benötigten wir die digitale Lösung bereits für den ersten Prototypen. Im Team gab es niemanden mit entsprechenden Kenntnissen, und ein Onboarding hätte dem Team Kapazitäten für die fachliche Entwicklung genommen.
Ein passender externer Dienstleister stand erst für den zweiten Sprint zur Verfügung, sodass wir die Wochenplanung anpassten: Die Teams mussten mit den wesentlichen Elementen der Prototypen bis zum Mittwochabend fertig sein, am Donnerstag durften sie vormittags lediglich noch etwas Finetuning betreiben.
Am Donnerstagnachmittag bereiteten sie die Nutzerinterviews vor. Die Instrumente Nutzertest und Interview waren neu, weshalb es dem Team half, sich intensiv mit diesen Instrumenten zu beschäftigen. Die Teams stellten einen Zeitplan auf, organisierten die Interviewpartner:innen, die zu großen Teilen aus Produktion und Vertrieb der Mähdrescherhersteller kamen. Dazu kamen zuständige Sachbearbeitende aus den regional verteilten Dienststellen, die die Freigaben für die Zufahrten an den Bundesstraßen bisher erteilt hatten.
Außerdem probten wir den Ablauf und stimmten die Rollenverteilung ab. Währenddessen passten wir die Prototypen auf Basis des Teamfeedbacks leicht an, sodass sie den Teilnehmer:innen am Freitag in adaptierter Form zur Verfügung standen.
Normalerweise dient der ganze Freitag der Testvorbereitung und der Durchführung der Nutzerinterviews. Im Landesamt sollte am Nachmittag die Präsentation der Sprint-Ergebnisse vor der Leitungsebene inkl. Staatssekretärin des Energieministeriums erfolgen. Die Ergebnisvorstellung sollte zentralen Entscheider:innen des Landesamtes und der Landesverwaltung einen Einblick in die neue Arbeitsweise geben und damit auch Überzeugungsarbeit auf dieser Ebene leisten.
Im zweiten Sprint (also der zweiten Woche mit den Teams) konnten wir deutlich mehr Zeit in das Verfeinern der Lösungen stecken, da beide Teams die Methode nun einigermaßen gut kannten und deutlich fokussierter in den Diskussionen waren. Besondere Flexibilität benötigten wir in der zweiten Woche, weil der externe IT-Dienstleister die digitale Lösung nicht pünktlich für beide Teams erstellen konnte. Daraufhin setzten die Teams gemeinsam die Priorität fest (sie entschieden sich dafür, dass der Dienstleister die Mähdrescher-Lösung umsetzt). Teamseitig war das ein schwieriger, aber gleichzeitig für die Teamdynamik sehr wertvoller Moment, da es ein kollegiales Miteinander war und keine Konkurrenzsituation.
Das zweite Team nutzte für die Tests eine simplere digitale Lösung, die auf demselben Tool basierte wie der Prototyp der ersten Woche (die im Gegensatz zu der anderen den Vorgaben des Landesamts nicht entsprach) und erhielt zum Ausgleich eine weitere verkürzte Sprintwoche. Sie konnten zwar keinen visuell anspruchsvollen Prototypen präsentieren, die Gewinnung der Erkenntnisse und die Generierung der Nutzerfeedbacks gelang mit dem einfacheren Prototypen aber genauso gut.
Der Design Sprint lebt davon, dass alle Bausteine in einen festen Zeitplan und damit in Timeboxes gegossen sind. Der Gedanke dahinter ist, dass die zeitliche Verknappung einen starken Fokus ermöglicht und man sich dadurch auf das Wesentliche beschränkt. In der agilen Welt ist die Timebox ein geschätzter Freund, da sie allen Beteiligten klarmacht, dass sie schnell zum Kern der Diskussion und damit ins Lösen kommen sollten.
Im Landesamt war die Timebox ebenfalls stets präsent. Jedoch mussten wir sie anfangs etwas dosiert einsetzen. In der Verwaltung gilt das Prinzip der 120%: es reichen weder 80% noch 100%, sondern es muss gefühlt darüber hinaus noch weiter geprüft werden. Das bedeutet, dass man sehr präzise und vollständig prüft, in der Hoffnung, sämtliche Risiken und Barrieren identifiziert zu haben, bevor man den nächsten Schritt geht. Diese Herangehensweise macht es nahezu unmöglich, sich auf das Wesentliche zu beschränken, denn alle Ausnahmefälle und Eventualitäten müssen berücksichtigt werden. Diesen Mindshift mussten einige erst vollziehen, damit sie sich auf das zeitliche Limit einlassen konnten.
Wir haben also am ersten Tag mit Puffern gearbeitet, aber den Timer schon miteingesetzt. Erst am zweiten Tag (bei der Entwicklung der Ideen) war dieser deutlich präsent. Das Instrument wurde akzeptiert, und selbst intensive Diskussionen konnten wir nach Ablauf der Timebox in den meisten Fällen ohne Widerstand abbrechen.
Für die Diskussionen gaben wir anfangs mehr Raum, mussten die Teams jedoch immer wieder dabei unterstützen, sich wieder auf den eigentlichen Kern zu besinnen und zu fokussieren. Mehrmals gab es Momente, in denen das Bedürfnis der Teilnehmer:innen sehr stark war, bereits die perfekte Lösung zu entwickeln und zu diskutieren. Hier brauchten wir Moderationsgeschick inklusive der Kunst der gezielten Steuerung über Fragen, um im Problemraum zu bleiben.
Am Ende wussten die Beteiligten den Timer und die Timebox als solche zu schätzen und nutzen sie inzwischen auch in ihrer täglichen Arbeit deutlich bewusster.
Die Frage, wie die Ergebnisse des Sprints ausgearbeitet werden, damit die Nutzer:innen fertige Dienstleistungen erhalten, ist erfolgsentscheidend. In vielen agilen Organisationen ist das kein Problem, denn die festen Teams bleiben auch nach dem Design Sprint bestehen und arbeiten den Prototyp weiter aus.
Da uns klar war, dass sich die beiden Teams nach dem Design Sprint direkt wieder auflösen würden, befürchteten wir, dass der Prototyp anschließend "vor sich hindümpeln" würde. Um die Fortführung der Arbeit sicherzustellen, entwickelten wir mit einigen Mitgliedern des Projektteams und Personen aus der Betriebsorganisation einen Implementierungsplan und verfolgten diesen.
Die vollständige Umsetzung beider Leistungen dauerte ca. drei Monate (die OZG-Umsetzung besteht allein aus mehreren Tausend Leistungen). Darauf war der Inbetriebnahmeprozess nicht ausgerichtet. Diese Umsetzungsphase war für alle Beteiligten anstrengend, aber die Mühe lohnte sich, denn wir identifizierten hier wertvolle Beschleunigungs- und Verbesserungsbedarfe für das Gesamtprogramm. Die nächsten Umsetzungen weiterer Verwaltungsservices im Rahmen der gesamten OZG-Umsetzung profitierten davon massiv.
Entscheidend für die Umsetzung dieser zwei Leistungen war jedoch ein beharrliches Dranbleiben. Diese Phase wird branchenunabhängig häufig massiv unterschätzt. Viele fokussieren sich ausschließlich auf den Mikrokosmos des Design Sprints und lassen den Teil der Implementierung völlig außer Acht. Eine erfolgreiche Umsetzung gelingt nur, wenn die neue Lösung in das bestehende Gesamtsystem integriert wird. Wir empfehlen hier immer, entsprechende Ressourcen und Zeit entsprechend mitzudenken und vorzusehen, damit die Umsetzung auch nach dem Design Sprint weiterlaufen kann.
Bereits bei der Vorbereitung der Design Sprints achteten wir auf einige Aspekte besonders. Das lag daran, dass diese Art des Arbeitens neu war:
Die Einführung der Design Sprints im Landesamt war ein voller Erfolg. Die Erfahrungen der Beteiligten waren nachhaltig und hatten den gewünschten Effekt auf das gesamte Amt. Im Folgenden fassen wir die Erkenntnisse aus der Umsetzung und die darüberhinausgehenden Effekte zusammen.
Ein Design Sprint ist sehr fokussiert auf die Herausforderungen von Nutzer:innen, und es wird vergleichsweise viel Zeit darauf verwendet, diese zu verstehen, zu analysieren und eine adäquate Lösung zu entwickeln. Der Grundgedanke dahinter ist, dass man eine Lösung entwickeln möchte, die auch tatsächlich genutzt wird. Ansonsten ist das Risiko recht hoch, in der Entwicklungsphase viel Geld zu investieren und am Ende ein nutzloses, weil ungenutztes Produkt zu erhalten. Es werden daher an Nutzergruppen orientierte Personas entwickelt und genutzt (siehe dazu auch die Methode Personas).
In der öffentlichen Verwaltung ist die Nutzerperspektive eine völlig neue Sichtweise. Das bedeutet nicht, dass eine Verwaltung nicht auch an einer Kundenperspektive interessiert ist. Priorität haben jedoch bei jeder Verwaltungsleistung der Blick durch die Verwaltungsbrille und die Erfüllung der rechtlichen Anforderungen. Aus diesen Gründen muten Verwaltungsservices den Nutzer:innen meist als sehr kompliziert an und scheinen in einer fremden Sprache – der Verwaltungssprache – formuliert zu sein. Das erschwert es den Bürger:innen, die Angebote zu nutzen, und erzeugt oftmals viel Frust.
Für die Design Sprints im Landesamt war es deshalb wichtig, den Beteiligten diese Perspektive an verschiedenen Stellen sehr bewusst zu machen und auch immer wieder in Erinnerung zu rufen. So wurde bei jeder Diskussion die Persona in den Mittelpunkt gerückt. Wir stellten dazu Fragen wie: "Würde sich Bauer Lindemann mit diesem Weg leichttun?" oder "Könnte Susi Sachbearbeiterin mit dieser Formulierung etwas anfangen? Wüsste sie, wie sie damit weitermachen könnte?" oder auch "Ist das für die Aufgabe der Persona relevant oder ist es ausschließlich für das Landesamt relevant?".
Am schwersten fiel der Perspektivwechsel den Fachexpert:innen, die das jeweilige Verfahren bisher aus der Verwaltungssicht heraus betreut hatten. Für diese war es hilfreich, dass sie mit ihren Kolleg:innen den Perspektivwechsel intensiv reflektieren und gemeinsam die möglichen Optionen mit Kenntnis der Verwaltung und deren Denkweise betrachten konnten. Für die Fachexpert:innen war es von größter Bedeutung, dass das Verfahren juristisch sauber abgebildet wird. Das heißt, für sie stand aufgrund ihrer Zuständigkeit primär die Verwaltungssicht im Vordergrund. Die Reflexion mit den Kolleg:innen, die in diesem Fall mehr Abstand zum jeweiligen Verfahren hatten, half den Fachleuten ebenfalls, den nötigen Abstand hinzubekommen.
Letztlich gelang allen der Perspektivwechsel. Insbesondere die Erfahrung der Nutzertests und Nutzerinterviews unterstützte den Wechsel. Die Feedbacks der Befragten gaben den Beteiligten derart viel Input und wichtige Impulse zur Optimierung, dass im zweiten Sprint eine neue Dynamik entstand: Die Teammitglieder zitierten regelmäßig Sätze aus den Interviews, um die Weiterentwicklung zu optimieren oder noch einmal gemeinsam die Weiterentwicklungsidee zu reflektieren.
Eine besonders erfreuliche und intensive Erfahrung für die Kolleg:innen war die enorme Wertschätzung, die die Befragten für die Möglichkeit der Nutzertestteilnahme äußerten. Die Qualität der Feedbacks verstärkte die Erkenntnis, dass bereits in sehr frühen Entwicklungsstadien Nutzer:innen einbezogen werden sollten: Obwohl die ersten Prototypen vergleichsweise simpel waren, lieferten sie wertvolle Hinweise zu ihren Nutzerbedarfen und Herausforderungen.
Am Anfang herrschte Skepsis, wir sahen viel Stirnrunzeln: Die Arbeitsweise war fremd und die Beteiligten konnten sich nur schwer vorstellen, was konkret auf sie zukommen würde. Bereits während des ersten Design Sprints zeigte sich recht schnell, dass die Teammitglieder ein gutes Verständnis für die Methoden und Praktiken sowie untereinander bereits eine eigene Dynamik entwickelten. Sie begannen mit den Begrifflichkeiten zu spielen und übertrugen sie Stück für Stück in ihren Austausch mit anderen Kolleg:innen.
Das geschah allein schon deshalb, weil sich die Kolleg:innen aus den anliegenden Fluren sehr dafür interessierten, was es mit den ganzen bunten Zetteln in den Räumen auf sich hatte. Die Zurückhaltung im Umgang mit den neuen Begrifflichkeiten nahm stetig ab und stellte recht schnell keine Barriere mehr dar.
Das Experimentieren und das Arbeiten in Zyklen empfanden die Teams als sehr nützlich. Dennoch konnten sie sich kaum vorstellen, die Zyklen im Verwaltungsalltag zu etablieren. Hier wird es noch einiges an Adaption erfordern, um diese Ansätze im Verwaltungskontext nutzbar zu machen. Aber das Denken in Experimenten und in Prototypen erschien ihnen sehr logisch.
Durch das "Durchleben" des Sprints haben die Teams den Mehrwert von Experimenten erkannt: Mit den gefühlt unfertigen Prototypen verbanden sie die Sorge, dass die Nutzer:innen die Ergebnisse als minderwertig empfinden und sie direkt "zerreißen" würden; umso überraschter waren sie, als diese nicht nur Wertschätzung äußerten, sondern auch wertvolle Erkenntnisse lieferten, die im Falle von einer der beiden Lösungen zu einer vollkommen neuen und besseren Lösung führten: Bei der Genehmigung der Baustellenzufahrten entstand ein anders gelagerter Prozess, der nun aus der Sicht der Nutzer:innen abläuft. Bei den Mähdreschern wurde der bisherige Prozess weiter verkürzt und auf das Wesentliche beschränkt und dadurch noch weiter vereinfacht. Auch das ist im Sinne der Nutzer:innen.
Die positive Haltung gegenüber Experimenten nahmen die Teammitglieder mit in den Verwaltungsalltag. Eine Teilnehmerin sagte dazu in einem Folgegespräch: "Ich sage jetzt immer zu den Kolleg:innen: Lasst uns das doch einfach testen. Wir werden dann schon erfahren, ob unsere Idee funktioniert."
Agile Methoden und Frameworks gelten inzwischen als Heilsbringer und werden auch für die öffentliche Verwaltung immer interessanter und relevanter. Doch eine Einführung exakt nach Lehrbuch ist die beste Voraussetzung für Misserfolg und eine frustrierte Belegschaft: Ein Framework liefert letztlich nur einen methodischen Rahmen und ist wie ein Modell zu verstehen – als Orientierung oder als Idee. Die Realität in der Verwaltung ist deutlich komplexer, als es ein Framework abbilden kann.
Zudem sind agile Methoden nicht auf den hierarchisch geprägten Verwaltungskontext zugeschnitten. Agile Teams sind deshalb so erfolgreich, weil sie autark und selbstorganisiert sind. Gleichzeitig geht es bei agilen Vorgehensweisen darum, über Testen und Lernen in sehr kurzer Zeit neue Wege und Lösungen zu identifizieren. Die Verwaltung ist dagegen geprägt vom Einhalten von Prozessen und Verordnungen, die schon über Jahre und teilweise Jahrzehnte existieren. Entscheidungen fällen vor allem die Vorgesetzten, auch wenn die Arbeitsebene die Expertise hat.
Um einen sinnvollen Einsatz agiler Frameworks zu ermöglichen, müssen die Rahmenbedingungen beachtet werden, da sie großen Einfluss auf den Verlauf der Umsetzung haben. Eine Auseinandersetzung mit den Startbedingungen für das entsprechende Framework ist erfolgsentscheidend, damit sinnvolle Anpassungen erfolgen können und das Framework hilfreiche Effekte zeitigen kann.
Wir sind davon begeistert, dass Agilität in der öffentlichen Verwaltung nach und nach ankommt, und stolz darauf, einen wertvollen Teil dazu beitragen zu dürfen. Agilität muss jedoch nicht zwingend der richtige Weg sein. Wenn Sie mit einer agilen Methode liebäugeln, sollten Sie sich daher vor dem Methodeneinsatz intensiv fragen, was das spezifische Problem ist und ob Agilität den Weg zur passenden Lösung tatsächlich unterstützen kann. Daran schließen sich die Fragen an, welches Framework grundsätzlich geeignet ist und wie es für die vorliegenden Rahmenbedingungen angepasst werden kann.
Lassen Sie sich aber auch nicht entmutigen, wenn beim ersten Mal nicht der gewünschte Effekt eintritt. Verstehen Sie die Einführung und den Umgang mit agilen Methoden stattdessen als Lernreise, die für jede Organisation – ob öffentlich oder nicht öffentlich – anders aussehen kann.
