Agiles Projektmanagement in der Verwaltung?! Das „eRew“-Team der Stadt Lünen zeigt, wie’s gehen kann

Im Mai 2018 bekam Nicole Niermöller den Auftrag, mit einem Projektteam den elektronischen Rechnungseingangsworkflow bei der Stadtverwaltung Lünen einzuführen. Zu der Zeit hatte sie gerade ein Scrum-Seminar besucht und war „angefixt“ von der Frage, ob und wie so etwas in der Verwaltung funktionieren könnte: „Ich hatte selbst nicht so richtig die Idee, wie man das in Verwaltungen hinkriegen kann, aber ich dachte: Vielleicht kann man das einfach mal ausprobieren.“ Beim ersten Projektgruppentreffen stellte sie der Runde Scrum vor und stieß auf offene Ohren: „Yo, lasst es uns einfach versuchen!“

Was es seitdem erlebt hat, hat das Projektteam „eRew“ in einem Interview mit uns geteilt. Überall dort, wo dieses Team auftaucht, scheint ein Funke überzuspringen, den es nach außen hin gar nicht „agil“ oder „Scrum“ nennt, der aber den agilen Spirit spürbar macht. Auch wir haben diesen Funken zu spüren bekommen und hoffen, dass wir über diesen Blog-Beitrag ein bisschen davon weitergeben können.

Das Interview haben wir geführt mit: Nicole Niermöller (Abteilung Organisation, Koordination E-Government), Susanne Kaletta (Fachdezernat Personal und Organisation), Nadine Werkmeister und Sylvia Brohl (Team Finanzwirtschaft), und Ralf Tröster (IT). Darüber hinaus gehören noch zum Team eRew: Marco Brochtrup und Melanie Wagner (Team Finanzwirtschaft) und Eva Brümmer (Rechnungsprüfung).

Vorab sei gesagt: Nur selten lässt sich Scrum in Reinform umsetzen – auch nicht in Verwaltungen. In diesem Beitrag geht es vielmehr darum zu zeigen, wie sich Ideen aus Scrum in die Verwaltung übertragen lassen. Wir nutzen dazu bewusst ein niederschwelliges Beispiel. Natürlich gibt es mittlerweile auch Verwaltungen, die noch viel weitergehend agile Arbeitsformen wie Scrum einführen, die das als strategische Chance verstehen, hierfür Rückendeckung von oben geben und eigene Ressourcen bereitstellen (z.B. interne Scrum-Master, eigene Innovationslabore).

Uns interessiert aber die Frage: Was kann ich als Verwaltungsrebell*in tun, wenn es diese Rahmenbedingungen in meiner Verwaltung (noch) nicht gibt? Dann werde ich schnell an Grenzen stoßen, wenn ich versuche, Scrum „nach Scrum-Guide“ umzusetzen. Und dann bleibt mir nur, es entweder ganz zu lassen – oder Wege zu finden, wie ich zumindest Elemente aus Scrum umsetzen kann. Und genau dafür liefert das eRew-Team ein gutes Beispiel.

Streng genommen ist das dann nicht mehr Scrum. Der Scrum-Guide[1] sagt dazu: „Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen – das Ergebnis ist dann aber nicht Scrum. Scrum existiert nur in seiner Gesamtheit.“

Wir sehen es so: Wenn ein Projektteam die Werte von Scrum, nämlich Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt lebt, wird sich das positiv auf die Projektarbeit in Verwaltungen auswirken – egal, ob die Arbeitsweise dann Scrum heißt oder anders.

Dieser Beitrag setzt Grundwissen über Scrum voraus, das Sie sich durch den 1. Teil dieser zweiteiligen Blog-Reihe anlesen können.

Wir docken hier an der Struktur des vorigen Beitrags an und schauen, wie einzelne Bestandteile aus Scrum im Projekt eRew umgesetzt wurden.

 

1. Werte und Prinzipien – Kultur der Zusammenarbeit

Die Bereitschaft, Ideen aus Scrum auszuprobieren, ohne zu wissen, ob’s funktioniert, zeigt eine Denkhaltung und Kultur, die ziemlich viel von dem verkörpert, was wir in Teil 1 unter dem Stichwort „Agile Werte und Prinzipien“ skizziert haben. Und das, obwohl hier Menschen aus ganz verschiedenen Ecken der Verwaltung zusammenkamen und ohne dass vorab Interesse an agilen Arbeitsweisen abgefragt wurde.

Hilfreich war hier sicherlich die Grundhaltung, mit der Nicole Niermöller Scrum ins Spiel gebracht hat. Nicht: „Dieses Projekt möchte ich gern agil machen“. Sondern mit der ernst gemeinten Frage, die auch ein Nein als Antwort akzeptiert hätte: „Könnt ihr euch vorstellen, so zu arbeiten?“. Und als Echo ein Team, das sich ernst genommen fühlt und dann Verantwortung übernimmt für die ernst gemeinte Antwort: Ja, wir wollen es ausprobieren.

Die folgenden Abschnitte zeigen, wie im eRew-Team die Scrum-Werte konkret gelebt werden.

2. Rollen

Formal gibt es eine klassische Projektstruktur mit einer Lenkungsgruppe, der Nicole Niermöller als Projektleitung berichtet. Dass intern agil gearbeitet wird, wird nicht verheimlicht. „Ich sag auch immer: Wir machen agiles Projektmanagementund versuche, agile Ideen nach oben zu transportieren – etwa das Thema Fehlerkultur und dass wir als Projektteam gemeinsam für die Ergebnisse stehen“, so Niermöller.

Nach innen übernahm Nicole Niermöller die Rolle des Scrum Master. Anfangs war sie in dieser Rolle noch stark gefragt – weil sie die einzige war, die sich mit der Methode auskannte. Mit der Zeit übernahm das Team aber selbst Rituale und Arbeitsformen. „Ich bin dann immer mehr in das Inhaltliche reingerutscht und muss jetzt schauen, dass die Scrum Master Rolle nicht ganz untergeht“.

Die Rolle des Product Owner übernahm zunächst der Vertreter des Pilotbereichs. Es war allerdings nicht immer einfach, die Sicht der Gesamtverwaltung im Blick zu haben, wenn es zunächst um die Umsetzung in dieser Abteilung ging. Manche Aufgaben des Product Owner übernahm das Team auch gemeinsam, z.B. die Priorisierung des Backlogs, Vertreten der Interessensgruppen, offenes Feedback zu Ergebnissen. Andere Aufgaben – Gesamtüberblick, Kontakt zu den Entscheider*innen im Hause – übernahm Nicole Niermöller über ihre Rolle als Projektleitung. Daher beschloss das Team, die Rolle „Product Owner“ aufzulösen.

Die Gestaltung der Rollen weicht somit recht stark von Scrum ab – sowohl Scrum Master, Product Owner und Projektleitung arbeiten allesamt im Projektteam mit. Das Team allerdings verkörpert viele Eigenschaften eines Umsetzungsteams in Scrum:

Selbstorganisation, Eigenverantwortlichkeit, Cross-Funktionalität

Die Verantwortungsübernahme zeigt sich schon früh im Projekt. Nicole Niermöller erinnert sich: „Wir haben das im Juni angefangen und kurz darauf war ich zwei Wochen im Urlaub. Und ich dachte: Oh je, wie das wohl wird. Ich kam wieder, und das Team hatte die Methode übernommen. Ich war total begeistert, das kannte ich so nicht. Das war mein erster positiver Moment, an dem ich dachte: Cool, das funktioniert, weil die Verantwortung in dem Moment von mir auf euch übergegangen ist: Jeder hat ein Stück mit geschultert.“

Sylvia Brohl ergänzt: „Sonst sitzt man immer und hört zu und einer macht. Und hier muss jeder mitmachen, sonst geht es nicht weiter. Jeder fühlt sich in dem Projekt verantwortlich.“

Das Projektteam ist cross-funktional zusammengesetzt: Hier arbeiten Vertreter*innen aus dem Finanzbereich, der IT, der Organisation und der Pilotabteilung zusammen. Auch die Rechnungsprüfung war von Anfang an aktiv eingebunden. Susanne Kaletta, anfangs noch selbst in der Rechnungsprüfung tätig: „Eigentlich soll die Rechnungsprüfung ja nicht mitarbeiten. Wir haben aber gesagt: Sobald wir merken, dass wir aus Sicht der Rechnungsprüfung etwas fordern müssten, was in der Verwaltung in der rechtlich geforderten Form noch nicht vorhanden ist – hier z.B. ein Rollen-Rechte-Konzept –, dann schreiben wir das nicht selbst, aber wir unterstützen dabei, diese Grundlagen gemeinsam zu erarbeiten. Denn das nutzt ja der Verwaltung. Es wäre doch abstrus, nur zu schimpfen, aber nicht im vertretbaren Rahmen aktiv zu unterstützen.“

Jede*r im Team trägt seine fachliche Perspektive zu dem Projekt bei, ist aber auch bereit, über den Tellerrand seiner Zuständigkeit hinauszuschauen. „Oft hat man eine Aufgabe und jeder sagt: Ja, mach du mal, ich bin nicht zuständig. Hier vermittelt niemand dem anderen das Gefühl, das ist jetzt deins. Wenn ich nicht weiß, wie ich weiterkomme, bekomme ich innerhalb der Gruppe Hilfe“, so Sylvia Brohl.

Konsequente Kundenorientierung

Die Kolleg*innen, die später mit dem Rechnungsworkflow arbeiten sollen, wurden von Beginn an konsequent in das Projekt eingebunden.

Dabei greift das Team auch auf ungewöhnliche Maßnahmen zurück: Um besser zu verstehen, was mit einer Rechnung in der Verwaltung passiert, lief es einmal einer Rechnung auf ihrem Weg durchs Haus hinterher. Angefangen bei der Poststelle bis zum Abheften im Aktenordner. Sylvia Brohl: „Wir haben mit den Sachbearbeitungen an den einzelnen Stationen gesprochen: „Was machst du jetzt mit der Rechnung? Wo geht sie als nächstes hin und warum?“. So erfährt man dann auch Dinge, die ansonsten in einem Prozessdiagramm nicht auftauchen würden, die aber für den späteren Workflow wichtig sind.

Eine solche Vorgehensweise fördert das Teambuilding und schafft Kultur, die sich auch nach außen transportiert: „Andere haben gemerkt, was für einen Spaß wir dabei haben und wie wichtig die Erkenntnisse sind, die wir dadurch bekommen. Und das ist auch eine Chance, andere wertzuschätzen und zu motivieren, weil man zurückspiegeln kann, wie wichtig die einzelnen Beteiligten und Stationen für den Gesamtprozess sind.“

3. Artefakte

Sämtliche Projektinformationen werden in OneNote (virtuelles Notizbuch) gesammelt, das als eine Art virtuelles Projektbüro dient.

Auf einer Seite wird der Product Backlog als Tabelle geführt. Hier werden die Anforderungen priorisiert und in eine eindeutige Reihenfolge gebracht, die zuvor im Rahmen der Planungstreffen (dazu gleich mehr) erhoben, geklärt und als User Stories formuliert wurden.

Gemeinsam mit weiteren Erläuterungen (z.B. Akzeptanzkriterien – wann wäre die Anforderung wirklich erfüllt?) wird alles digital festgehalten. Charmant dabei: Das Team kann dazu mittlerweile ein digitales FlipChart nutzen.

Der Sprint Backlog bzw. das Scrum Board wird dagegen auf einem Papier-Flipchart geführt. In die erste Spalte kommen die User Stories (mit einer Nummer, die auf die Detailinfos im digitalen Flipchart verweist). Diese werden in der Spalte TODO in einzelne Aufgaben heruntergebrochen. Der Umfang einer Aufgabe ist möglichst so geschnitten, dass sie bis zum nächsten Daily erledigt werden kann. Im Laufe des Sprints wandern die Zettel dann durch die Spalten DOING und DONE. Das Scrum Board wird nach jedem Treffen fotografiert und in OneNote abgelegt.

Die Idee, abgeschlossene Sprint-Ziele zu formulieren und am Ende jeden Sprints ein lauffähiges Produkt auszuliefern, ließ sich nicht umsetzen. Das Produkt ist hier ja die technische und organisatorische Einführung eines Workflows. „Schnell schon mal ein bisschen einführen“ ist da schwierig. Und auch ein Ergebnis wie z. B. bestimmte technische Voraussetzungen zu schaffen, lässt sich nicht immer in einem Sprint erreichen. Ziel eines Sprints ist es also, die User Stories umzusetzen, die bei der Planung ausgewählt wurden, und die Ergebnisse können dann ganz unterschiedlich aussehen. Nicole Niermöller nennt einige Beispiel: „Manchmal sind es „kleinere“ Recherche-Aufgaben, die wir vor der eigentlichen Entscheidung separiert angegangen sind, manchmal aber auch organisatorische Dinge (Terminorganisation) oder auch tatsächliche Entscheidungen mit Ergebnisdokumenten, die innerhalb des Sprints getroffen wurden“.

Entsprechend war es auch schwierig, eine „Definition of Done“ zu formulieren. Im Laufe der Projektarbeit haben sich aber einige Aspekte herauskristallisiert, die bei jedem Review geprüft werden (z. B. Besonderheiten aus vorangegangenen Abteilungen einbeziehen, über Neues im Projekt berichten) und die einer solchen Definition nahe kommen. Diese laufen als kontinuierliche User Stories in jedem Sprint mit (mit Buchstaben gekennzeichnet).

Zu Beginn wurden auch weitere Hilfsmittel aus dem Scrum-Umfeld eingesetzt: So wurden anfangs die Aufwände für neue Anforderungen mittels “Planning Poker” geschätzt (eine Methode, bei der mit Hilfe von Spielkarten Aufwände gemeinsam im Team abgeschätzt werden). „Das war unglaublich hilfreich. Gar nicht so sehr, um Aufwände kalkulieren zu können. Der größte Nutzen bestand darin, dass wir im Zuge dessen Anforderungen geklärt und ein gemeinsames Bild davon entwickelt haben“, so Nicole Niermöller. Mit zunehmenden Erfahrungen im Projekt war diese Form von Klärung immer weniger notwendig, und es fehlte auch die Zeit dafür. Ähnliche Erfahrungen gab es beim Einsatz eines “Burndown-Charts“, das zu Beginn genutzt wurde, um den Projektfortschritt nachzuverfolgen. Niermöller: „Wir haben diese Methoden bei Besprechungen immer wieder vergessen. Das war ein Zeichen für uns, dass der Nutzen nicht ausreichend war, um den Aufwand zu rechtfertigen. Und dann haben wir uns bewusst entschieden, diese Elemente wegzulassen“.

4. Ablauf und Rituale

Auch bei Vorgehensweisen schafft das eRew-Team den Spagat, nach außen hin „klassisch“ und nach innen agil zu arbeiten:

Klassischer Ablaufplan als äußerer Rahmen

Zu Beginn hatte Nicole Niermöller noch versucht, eine konsequent agile Vorgehensweise durchzusetzen: „Am Anfang wollte ich mich gar nicht auf einen klassischen Zeitplan einlassen, habe gesagt: Das ist so ein komplexes Projekt, wir haben das alle noch nie gemacht, ich kann da keinen Zeitplan aufstellen, tut mir leid.“ Und dann fügt sie grinsend hinzu: „Damit bin ich leider nicht durchgekommen.“

Und so bildet den äußeren Rahmen des Projektes dann doch ein klassischer, aber sehr beteiligungsorientierter Ablaufplan:

• In der Konzeptphase ging es zunächst darum, das Projektziel zu klären. Ausgehend von einer Vision (Was braucht unser Kunde?) wurden Anforderungen abgeleitet. Dann wurden die technischen und organisatorischen Voraussetzungen für die Umsetzung des Workflows geschaffen.
• Anschließend wurde dieser im Pilotbereich eingeführt.
• Aktuell wird der Workflow nun in die anderen Bereiche der Verwaltung ausgerollt – nach einem mittlerweile bewährten Vorgehen: Die Betroffenen werden von Beginn an aktiv eingebunden, es gibt ein Treffen mit den Führungskräften des betroffenen Bereichs , ein Kickoff mit allen Beteiligten, , Schulungen, Besuche am Arbeitsplatz (Ist das, was wir in der Schulung besprochen haben, auch machbar?) eine Testphase mit enger Begleitung („Wir sind an eurer Seite!“) und dann erst die Umstellung in den Regelbetrieb.

Niermöller: „Wir haben uns durch diesen Zeitplan und dadurch, dass wir ihn nach außen kommuniziert haben, auch selbst verpflichtet. Wir passen ihn regelmäßig an – aber nie ohne guten Grund.“ Susanne Kaletta ergänzt: „Das ist ja genau die Agilität: Dass wir auf neue Erkenntnisse im Projekt reagieren, sehr bewusst. Dann entwickeln wir mehrere Varianten, wie wir mit der Veränderung umgehen können. Und wenn die intelligenteste davon ist, den Zeitplan anzupassen, dann machen wir das.“

Eine Schnittstelle, an der sich die andere Arbeitsweise auch nach außen zeigt, ist übrigens der Projektblog im Intranet, der sehr konsequent gepflegt wird. Hier berichtet das Projektteam über den aktuellen Stand des Projektes, teilt aber auch Erfahrungen aus der (agilen) Zusammenarbeit.

Agile Zusammenarbeit im Projektteam – inspiriert durch Scrum

Seit Projektbeginn arbeitet das Team in dreiwöchigen Sprints. Während der Arbeitsphase findet zweimal pro Woche ein „Daily Scrum“ statt, das tatsächlich auch nur 15 Minuten dauert.

Am Ende eines Sprints findet dann ein „Dreifachtermin“ statt, der mittlerweile nur noch eine Timebox von knapp 2 Stunden umfasst:

• Zunächst ein abgewandeltes Review (20-30 Min.), in dem Ergebnisse innerhalb des Teams präsentiert werden. Hier geht es also weniger darum, Feedback von Kundenseite zu bekommen, als darum, sich fachlich im Team abzustimmen und sich zu vergewissern: Sind wir gemeinsam auf dem richtigen Weg? Wichtige Ergebnisse werden in OneNote festgehalten (eigener Abschnitt „Review“).

• Anschließend findet eine Retrospektive statt (20-30 Min.). Früher wurden auf Karten Stärken und Schwächen der Zusammenarbeit festgehalten. Heute läuft das eher als Blitzlichtrunde ab: Was läuft gut, wie können wir noch besser werden? Konkrete Verbesserungsansätze werden als Anforderung in den nächsten Sprint mit aufgenommen.

• Schließlich die Planung für den nächsten Sprint (ca. 60 Min.): Hier werden zunächst die Anforderungen aufgenommen, die im letzten Sprint nicht erledigt werden konnten, und um weitere Anforderungen aus dem Product Backlog ergänzt. Außerdem gibt es Aufgaben, die dauerhaft mitgeführt werden (z.B. Pflege des Projektblogs).

In OneNote erhält jeder Sprint einen eigenen Abschnitt, in dem Fotos von Artefakten und Mitschriften festgehalten und für alle zugänglich gemacht werden (aktuelles Scrum Board, Erläuterungen zu User Stories, Ergebnis-Doku, …).

Früher fanden in der Umsetzungsphase wöchentliche „Feedback Dailies“ mit den Anwender*innen statt. Zu Beginn waren die Rückmeldungen und Fragen wichtig, um Vorgehensweise und Workflow nachzujustieren. Doch mittlerweile ist das Vorgehen gereift und der Workflow gut dokumentiert, und es gibt weniger Bedarf nach solchen Treffen. „Das war ein agiler Prozess, festzustellen, die Feedbackrunden helfen uns nicht mehr weiter. Wir müssen jetzt die Zeit dafür nicht mehr weiter investieren. Was an Rückfragen bleibt, klären wir im Rahmen von Einzelgesprächen“, so Niermöller.

Kultur der Zusammenarbeit – Motor für das Projekt

Neben diesen Ritualen fördert die Kultur der Zusammenarbeit, dass es vorangeht im Projekt:

„Wir wollen Fortschritte machen“. Das Team zieht Motivation daraus, gemeinsam etwas zu schaffen, Ergebnisse zu erzielen, Probleme zu lösen. „Diese Summe, diese Häufigkeit, in der wir etwas schaffen als Team, in dieser Dynamik, mit dieser Art des Zusammenarbeitens, erlebe ich als extrem positiv“, so Susanne Kaletta.

Gelebte Erfahrungskultur: Retrospektiven (Was lief gut, was lief schlecht?) gehören mittlerweile auch außerhalb des „Dreifachtermins“ selbstverständlich dazu. Susanne Kaletta fasst die zugrunde liegende Haltung zusammen: „Wir waren so gut! Aber wir können noch besser werden!“. Die „gelebte Erfahrungskultur“ wird auch nach außen sichtbar. Ralf Tröster: „Es lief ja nicht alles rund von Anfang an. Wir hatten Dubletten u. ä. Probleme im System. Aber das waren Probleme, die wir lösen konnten. Das war uns wichtig: für uns als Team, aber auch weil sich das herumspricht, dass wir Probleme lösen. Das macht positive Mundpropaganda, die für so ein hausweites Projekt enorm wichtig ist“.

Soziale Unterstützung statt sozialer Druck: Es darf vorkommen, dass Anforderungen nicht zum Ende eines Sprints umgesetzt werden. Hier klingeln bei mir die Alarmglocken – ist das doch genau der Punkt, an dem in Projekten häufig die Verbindlichkeit nachlässt. Hier ließ sich das anscheinend durch ein hohes Verantwortungsgefühl und gegenseitige Unterstützung kompensieren. Nicole Niermöller: „Der soziale Druck ist nicht da. Ich würde es eher soziale Unterstützung nennen. Wenn der eine es nicht schafft, fühlen sich auch andere in der Gruppe verantwortlich, Dinge aufzufangen und haben auch Freude daran, dadurch als Team weiterzukommen.“

Fazit

Was wir an dieser Projektarbeit in Lünen so spannend finden, ist die Niederschwelligkeit. Wenn wir in Seminaren agile Arbeitsformen vorstellen, ist eine häufige Reaktion: „Das würde bei uns in der Verwaltung nicht funktionieren, weil die Führungsebene so etwas nicht mitmacht.“ Das eRew-Team zeigt, dass man gar nicht auf die offizielle Erlaubnis von oben warten muss, um Ideen aus Scrum auszuprobieren. Und wie es gehen kann, nach innen konsequent agile Arbeitsweisen aufzunehmen, nach außen aber vorsichtig zu schauen, wie viel Agilität man wem zumuten kann.

Die agile Arbeitsweise wirkt dennoch auch nach außen, sie verändert Kultur auch jenseits des eRew-Projektes. „Es ist eine Arbeitsweise, die hier begonnen hat, die sich aber innerhalb der Verwaltung verbreiten kann“, so Tröster. So fließt z.B. agiles Projektmanagement auch in eine Arbeitsgruppe ein, die derzeit hausweite Projektmanagement-Strukturen aufbaut. Und im Projekt zu neuen Raumkonzepten, mobilem Arbeiten und Arbeit 4.0 wurden neue Wege ausprobiert, um cross-funktionale Projektteams zusammenzustellen: indem per interner Ausschreibung Leute gesucht wurden, die „quer und innovativ denken“.

Natürlich hilft es, wenn – wie in Lünen – die Führungsebene zwar nicht der Impulsgeber für die agile Arbeitsweise ist, den Teams aber auch keine Steine in den Weg gelegt wurden (und werden).

Wie zufriedenstellend diese Art der Zusammenarbeit ist, wie sehr die Beteiligten davon zehren, wie mitreißend und motivierend die Atmosphäre im Team ist, das spürten wir bei dem Interview am eigenen Leib. „Hier interessiert die eigene Meinung und man kann mitwirken bei Veränderungen. Man wird ernstgenommen. Diese Art des Arbeitens bringt mir Zufriedenheit, auch wenn es manchmal mehr Arbeit bedeutet“, so Sylvia Brohl. Die Arbeit in agilen Projektteams kann daher aus unserer Sicht ein guter Ausgleich zu routinehaften und manchmal eher eintönigen Tätigkeiten sein, die nun mal auch wichtig sind, damit eine Verwaltung gut funktioniert. So dass Mitarbeiter*innen unter’m Strich sagen: Ich arbeite gern in der Verwaltung, meine Arbeit ist erfüllend und ich gehe nachmittags zufrieden nach Hause.

Und wenn sich das Team etwas wünschen könnte? „Dass wir alle so arbeiten!“, platzt es sofort aus Nicole Niermöller heraus. „Ich wünsche mir, dass man mit jedem hier in der Verwaltung so offen und so mutig arbeiten kann wie mit diesem Projektteam. Und ich wünsche mir, dass das, was wir hier angefangen haben, auch andere ausprobieren. Weil nur so Verwaltung zukunftsfähig bleiben kann. In Lünen sind wir diesbezüglich zumindest auf einem guten Weg.“

[1] Schwaber, Ken & Sutherland, Jeff (2017): Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. Deutsche Ausgabe verfügbar unter: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf