Agiles Projektmanagement in der Verwaltung?! Einführung zu „Scrum“

Bildquelle: „Gedränge im 7-er Frauen-Rugby“ von JuTa [CC BY-SA 3.0]

Dieser Beitrag wurde ursprünglich im November 2019 veröffentlicht und basierte auf dem damals gültigen Scrum Guide 2017. Im Juni 2021 haben wir ihn entsprechend der Änderungen des neuen Scrum Guide 2020 überarbeitet. 

Wenn von „agil“ die Rede ist, ist „Scrum“ oft nicht weit. Gemeint ist damit ein Vorgehensmodell für Projektmanagement nach agilen Prinzipien. Doch Scrum ist aus unserer Sicht noch mehr. In 20 Minuten erklärt, gibt es einen guten Eindruck davon, was es bedeutet, agil zusammenzuarbeiten. Die Kultur und die Prinzipien von Scrum lassen sich auch jenseits von Projekten anwenden.

Wir freuen uns schon darauf, im nächsten Beitrag ein konkretes Praxisbeispiel vorzustellen, das zeigt, wie Scrum in Verwaltungen funktionieren kann: Das „EREW“-Team der Stadt Lünen hat den elektronischen Rechnungseingangsworkflow in der Stadtverwaltung eingeführt und sich dabei an Scrum orientiert. Zunächst möchten wir in diesem Beitrag aber ein paar Grundlagen vermitteln: Wer oder was ist „Scrum“? Und was ist bloß dran an diesem Konzept, dass es den Weg von der Softwareentwicklung bis hinein in die Verwaltungen gefunden hat? Dabei wollen wir auch die vielen denglischen BEGRIFFE aufdröseln, die zunächst etwas befremdlich wirken (unten rot hervorgehoben, zum schnellen Nachschlagen). Und wir wollen immer auch einen ersten Transfer auf Verwaltungen vornehmen (im Text blau formatiert): Wo stößt Scrum hier an Grenzen? Welche Elemente lassen sich dennoch übertragen? Und wie könnte man die Methode anpassen, damit sie auch in Verwaltungen funktioniert?  

Dieser Artikel ist länger als unsere sonstigen Blogbeiträge. Neulinge sollen einen guten Überblick über Scrum bekommen – sozusagen das, was wir in 20 Minuten innerhalb unserer Seminare vermitteln. Und für alle, die mit der Methode schon etwas vertraut sind, ist der Beitrag hoffentlich so aufbereitet, dass Sie gezielt einzelne Bestandteile und Begriffe nachschlagen können.

Wer es dann noch genauer wissen will, schaut am besten in den „Scrum Guide“, den offiziellen Leitfaden von Ken Schwaber und Jeff Sutherland, die in den 90er Jahren Scrum entwickelt haben: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf

Wer oder was ist „Scrum“?

SCRUM ist ein Rahmenwerk, um Projekte nach den Prinzipien des agilen Projektmanagements durchzuführen. Der wesentliche Unterschied zum klassischen Projektmanagement: Ein Projekt wird nicht von Anfang bis Ende detailliert durchgeplant, Ergebnisse werden vielmehr iterativ in festen Zeitfenstern von wenigen Wochen (sogenannten „Sprints“) entwickelt und dann einer Feedbackschleife unterzogen werden. So lassen sich der Stand und die Ergebnisziele des Projektes kurzgetaktet überprüfen und man kann schnell auf Änderungen und Probleme reagieren. Damit eignet sich agiles Projektmanagement insbesondere für Projekte mit großer Unsicherheit, d. h. wenn das Ergebnis und der Weg dorthin zu Beginn nicht ganz klar sind. Und das trifft auch auf viele Projekte in Verwaltungen zu.

Scrum stammt eigentlich aus der Softwareentwicklung, wird mittlerweile allerdings auch auf zahlreiche andere Anwendungsbereiche übertragen (z. B. in der Organisationsentwicklung). Die Methode ist eigentlich für „Vollzeit-Projektteams“ gedacht – also wird eine der wichtigsten Anpassungsfragen sein: Wie funktioniert das ganze für „Neben-dem-Alltagsgeschäft-Projekte?

„Scrum“ ist übrigens ein Begriff aus dem Rugby-Sport. Es steht für das angeordnete Gedränge der Spieler um den Ball, mit dem das Spiel nach kleineren Regelverstößen oder einem Aus neu gestartet werden kann.

Scrum umfasst im Wesentlichen die folgenden Bestandteile, die wir gleich genauer vorstellen:

• Werte & Prinzipien, die dem Projekthandeln zugrunde liegen,
• Rollen in Projekten, die sich von denen im klassischen Projektmanagement unterscheiden,
• Artefakte, das sind Hilfsmittel, die zur Steuerung und Überprüfung des Projektprozesses eingesetzt werden,
• Ein Ablauf, der sich an festen Ritualen orientiert.

Anmerkung vorab: Wir haben Scrum nicht „studiert“. Wir bemühen uns darum, die Methode sauber wiederzugeben, aber falls ein Scrum-Profi beim Lesen über eine Formulierung stolpert, die angepasst werden sollte, freuen wir uns über eine kurze Rückmeldung.    

1. Werte und Prinzipien

Agiles Projektmanagement fußt auf den Werten und Prinzipien des AGILEN MANIFEST (s. http://agilemanifesto.org/iso/de/). Dieses entstand 2001, als sich eine Gruppe unabhängiger Softwareentwickler in einer Skihütte in Utah traf, um über flexible Alternativen zu dem schwergewichtigen traditionellen Projektmanagement zu sprechen, das an vielen Stellen an Grenzen stieß. Das agile Manifest umfasst 4 Werte und 12 Arbeitsprinzipien, die daraus abgeleitet sind:

Bei der Übertragung auf Verwaltungen müssen wir etwas Übersetzungsarbeit leisten, z.B. so:

• Individuen und Interaktionen stehen über Prozessen und Werkzeugen könnte man übersetzen in:
  Die Menschen (innerhalb und außerhalb der Verwaltung), die das Projekt durchführen oder von ihm betroffen sind und die Art, wie sie im Projekt zusammenarbeiten sind wichtiger als die Excel-Tabellen, Planungsinstrumente und Dienstanweisungen, mit denen das Vorhaben gebändigt werden soll.
• „Funktionierende Software steht über einer umfassenden Dokumentation“ könnte man übersetzen in:
  Dass Konzepte praktisch umgesetzt werden (und nicht in der Schublade landen) und dass die Ergebnisse für diejenigen funktionieren, die mit ihnen leben müssen, ist wichtiger als eine detaillierte Beschreibung und formale Absicherung der Konzepte.
• „Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung“ könnte man übersetzen in:
  Dass der Auftraggeber und die betroffenen internen und externen Interessensgruppen im laufenden Projekt einbezogen werden, ist wichtiger als ein penibel ausgearbeiteter Projektauftrag zum Projektstart.
• „Reagieren auf Veränderung steht über dem Befolgen eines Plans“ könnte man übersetzen in:
  Dass wir im laufenden Projekt die Augen offen halten für neue Erkenntnisse über Anforderungen, für veränderte Rahmenbedingungen und neue Möglichkeiten und darauf flexibel reagieren und die Planung entsprechend anpassen, ist wichtiger, als vorab detailliert zu planen und diesen ggf. inzwischen veralteten Plan dann strikt abzuarbeiten.

Immer gilt: „steht über“ heißt nicht, dass das andere unwichtig ist! Nur: Dass das erste stärker in den Fokus rückt.

In unseren Workshops fassen wir das, was aus unserer Sicht eine agile Kultur und Denkhaltung ausmacht, so zusammen:

Im Scrum-Guide sind folgende Werte aufgeführt, die Grundvoraussetzung für eine erfolgreiche Anwendung von Scrum sind (Schwaber & Sutherland 2020[1]):

• Commitment: Das Scrum Team widmet sich seiner Aufgaben mit Hingabe und verpflichtet sich, die abgestimmten Ziele zu erreichen und sich dabei gegenseitig zu unterstützen.
• Fokus: Das Scrum Team orientiert sich auf die Arbeit und Ziele einer Arbeitsetappe („Sprint“), um hier einen bestmöglichen Fortschritt zu erreichen.
• Offenheit: Das Scrum Team und die Interessensgruppen gehen offen mit ihrer Arbeit, dem Projektfortschritt und Herausforderungen um und machen diese sichtbar.
• Respekt: Die Mitglieder des Scrum Teams respektieren und vertrauen sich als fähige, eigenverantwortliche Personen und werden vom Projektumfeld als solche akzeptiert.
• Mut: Die Mitglieder des Scrum Teams bringen den Mut mit, auch an schwierigen Problemen zu arbeiten. Sie sind ehrlich zu sich selbst und verkünden auch unangenehme Nachrichten.

Klar, eine solche Kultur der Zusammenarbeit entspricht nicht unbedingt dem, was in Verwaltungen (und vielen Unternehmen auch noch) üblich ist… Und das ist auch der Grund, warum Scrum zwar in 20 Minuten erklärt, in der Umsetzung aber unglaublich schwierig ist. Und warum viele dann sagen: „Siehst du, so ein Quatsch – die Methode funktioniert nicht!“. Die Methode funktioniert sehr gut. Aber nur, wenn die Kultur passt.

Wenn die Kultur (noch) nicht passt, ist das aber kein Grund, Scrum (und agiles Arbeiten insgesamt) an den Nagel zu hängen. Denn: Indem einzelne Pionier*innen, denen diese Denkhaltung nahe liegt, anfangen, mit solchen Methoden zu experimentieren, wirkt sich das nach und nach auch auf die Kultur aus. Das zeigen die Praxisbeispiele in diesem Blog, und das wird auch das Beispiel Lünen zeigen.

2. Rollen

Eine einfache Projektstruktur im klassischen Projektmanagement umfasst ein Projektteam mit einer Projektleitung und eine Lenkungsgruppe mit einer Auftraggeber*in. In Scrum kommen andere Rollen ins Spiel, die zunächst etwas ungewohnt sind und aufgrund der englischen Bezeichnungen auch etwas befremdlich klingen.

Das Scrum-Team ist eine geschlossene Einheit von bis zu 10 Fachleuten[2], die sich auf ein Ziel konzentrieren. Es ist interdisziplinär („CROSS-FUNKTIONAL“) aufgestellt, d.h. das Team besteht aus Expert*innen unterschiedlicher Fachbereiche, die gemeinsam über alle Fähigkeiten verfügen, die es braucht, um das Projektziel zu erreichen.

Ein Scrum-Team arbeitet hierarchiefrei. Eine Projektleitung gibt es in dem Sinne nicht mehr. Vereinfacht könnte man sagen, die Rolle wird in Scrum auf zwei andere Rollen aufgeteilt: „Product Owner“ und „Scrum Master“. So ganz stimmt das aber nicht, weil in Scrum ein Teil der Verantwortung auch auf das Team übergeht, das sich in weiten Teilen selbst managt.

Auch eine klassische Projektleitung hat ja zwei Verantwortungsbereiche:

• Zum einen kümmert sie sich um die Projektergebnisse.
• Zum anderen um den Projektprozess, also die Zusammenarbeit im Projektteam und zwischen Projektteam und den Interessensgruppen.

In Scrum werden diese beiden Perspektiven getrennt, damit keine davon im laufenden Projekt zu kurz kommt:

Der PRODUCT OWNER übernimmt Verantwortung für das Projektprodukt. Er / sie …

• ist Ansprechpartner*in für den Inhalt des Projektes,
• sorgt dafür, dass ein Produkt-Ziel entwickelt und klar kommuniziert wird,
• fördert, dass das Projektergebnis einen maximalen Nutzen bringt,
• gibt Feedback zu Ergebnissen,
• vertritt die Interessensgruppen außerhalb des Projektteams und bindet sie bei Bedarf in das Projekt ein,
• erhebt Anforderungen, sortiert und priorisiert sie,
• stellt sicher, dass die Anforderungen transparent und für alle klar sind,
• sorgt dafür, dass notwendige Entscheidungen getroffen werden.

Der Product Owner kann diese Aufgaben auch an andere im Scrum Team delegieren. Je nach Organisation, Scrum-Team und Individuum können die Aufgaben unterschiedlich ausgefüllt werden (neu in Scrum Guide 2020). Damit der Product Owner erfolgreich sein kann, muss die gesamte Organisation seine / ihre Entscheidungen respektieren.

Der SCRUM MASTER übernimmt Verantwortung für den Projektprozess. Er / sie …

• ist Ansprechpartner*in für die Zusammenarbeit im Prozess, unterstützt diese und hilft dabei, sie zu verbessern,
• coacht das Scrum Team bei der Anwendung von Scrum, bei der Selbstorganisation und interdisziplinären Zusammenarbeit (im Sinne „Hilfe zur Selbsthilfe“),
• sorgt dafür, dass die Rituale und Praktiken von Scrum eingehalten werden,
• kann für die Moderation von Besprechungen, Retrospektiven usw. hinzugezogen werden,
• unterstützt einen reibungslosen Arbeitsprozess, räumt Schwierigkeiten aus dem Weg,
• unterstützt den Product Owner methodisch (d.h. ohne sich inhaltlich einzumischen!) bei seinen Aufgaben,
• sorgt für die Verbreitung, Kenntnis und Akzeptanz von Scrum in der Organisation.

Neben diesen beiden Rollen gibt es noch das Team, die „Macher*innen“:

Die DEVELOPER:INNEN setzen Anforderungen in konkrete Ergebnisse um. Sie …

• arbeiten eigenverantwortlich. Der Product Owner vermittelt die Anforderungen (das „WAS“), aber es liegt allein in der Entscheidung der Developer:innen, WIE es diese in konkrete Ergebnisse umsetzt,
• erstellen selbst einen Plan für eine Projektetappe („Sprint“) und passen diesen regelmäßig an,
• sichern die Qualität ihrer Arbeit durch Einhaltung einer DEFINITION OF DONE (d.h. eine eindeutige Beschreibung, was „fertig“ heißt)
• ziehen sich gegenseitig als Expert:innen zur Verantwortung.

Team, Scrum Master und Product Owner bilden gemeinsam das SCRUM-TEAM.

Neu im Scrum Guide 2020: Die Rollenbezeichnung „Developer:innen“ wurde eingeführt und ersetzt die frühere Bezeichnung „Development Team“ (Schwaber & Sutherland 2020). Auf diese Weise möchte man das Konzept eines separaten Teams innerhalb eines Scrum Teams beseitigen, das zu einer Hierarchie oder Abgrenzung zwischen den Rollen führen kann. Es wird betont, dass alle Mitglieder des Scrum Teams gleichermaßen Verantwortung für das Projekt tragen – nur eben durch unterschiedliche Beiträge.

Die Abbildung verdeutlicht das Zusammenspiel zwischen den Rollen aktualisiert gemäß Scrum-Guide 2020):

Diese Rollen lassen sich im Verwaltungsalltag meist nicht konsequent umsetzen. Das fängt schon bei der cross-funktionalen Zusammensetzung von Teams an. „Raus aus den Fachbereichssilos“ – das ist leichter gesagt als getan. Wenn Sie dann noch Begriffe wie “Scrum Master” oder “Product Owner” ins Spiel bringen, kassieren Sie oft nur Kopfschütteln (“Buzzwords…”) oder Witzchen („Höhö, Master of Desaster“). Zudem verlangt die Hierarchie oft eine klassische Projektleitung als Ansprechpartner (und das ist dann gern die hierarchisch folgende Führungskraft) und tut sich schwer damit, Anforderungen zu priorisieren (geschweige denn, dies einem Product Owner zu überlassen).

Hier muss Scrum also in der Regel abgewandelt werden, zum Beispiel, indem Sie nach außen klassische Rollen verwenden und nach innen Scrum-Rollen. Der Product Owner tritt dann nach außen als klassische Projektleitung auf, lässt nach innen aber Selbstorganisation zu (ja, das erfordert eine gehörige Portion Vertrauen). Wenn Sie keinen unterstützenden Scrum Master an die Seite gestellt bekommen, übernimmt die Rolle eben jemand aus dem Umsetzungsteam, am besten jemand mit Moderationserfahrung (ja, nicht optimal, aber besser, als wenn die Rolle komplett unter den Tisch fällt – was oft passiert, wenn sie behelfsmäßig dem Product Owner zugeordnet wird).

Neu im Scrum Guide 2020: Dass der Scrum Guide nun offener und weniger vorschreibend formuliert ist, macht Scrum aus unserer Sicht verwaltungstauglicher. In Bezug auf die Rollen gilt: Wie das Scrum Team sich managt und mit den Rollen Developer, Scrum Master und Product Owner umgeht, kann es intern sehr flexibel gestalten – und dann unabhängig davon schauen, wer wie als „Außenminister“ agiert. So wurde es auch im Praxisbeispiel der Stadt Lünen gelöst.

3. Artefakte

„Artefakte“ in Scrum sind Hilfsmittel oder Ergebnisse, die zur Steuerung und Überprüfung des Projektprozesses verwendet werden. Die wichtigsten im Überblick:

PRODUCT BACKLOG

• Sammlung von Anforderungen, die zur Produktverbesserung benötigt werden.
• Einträge werden vom Product Owner laufend priorisiert und in eine eindeutige Reihenfolge gebracht: Oben stehen wichtige Anforderungen, die bereits über ausreichend Klarheit und Details verfügen, um umgesetzt zu werden.
• Einträge können jederzeit vom Product Owner geändert, hinzugefügt, verfeinert oder entfernt werden.
• Anforderungen werden häufig in Form von USER STORIES formuliert: Wer braucht was wozu?

Neu im Scrum Guide 2020: Hier wurde das PRODUKT-ZIEL eingeführt, um das Scrum Team auf ein übergeordnetes langfristiges Ziel auszurichten. Jede Projektetappe soll das Produkt dem Ziel näherbringen. Es ist Teil des Product Backlogs. Ein PRODUKT wird definiert als: „Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stekeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein (Schwaber & Sutherland 2020).

SPRINT BACKLOG

• Plan für die nächste Projektetappe („Sprint“), mit dem die Developer:innen ein Sprint Ziel verfolgen (Wofür). 
• Sie wählen dazu die Menge der Einträge aus dem Product Backlog aus, von der sie glauben, dass sie sie in der nächsten Etappe umsetzen können (Was).
• Jeder Eintrag aus dem Product Backlog (d.h. jede User Story) wird in Aufgaben („Tasks“) von maximal einem Tag Dauer heruntergebrochen (Wie).
• Das Sprint Backlog bildet die Basis für die Selbstorganisation der Developer:innen während des Sprints und wird meist in Form eines Kanban-Boards visualisiert (hier auch “Scrum-Board” genannt):

Neu im Scrum Guide 2020: Das SPRINT-ZIEL, das bereits in früheren Scrum Guides erwähnt wurde, wird fester Bestandteil des Sprint Backlogs. Zu dem Sprint Ziel committen sich die Deveolper:innen zu Beginn eines Sprints: Welchen Wert und Nutzen schaffen wir mit dem Sprint? Es schafft Kohärenz und Fokus und bleibt bei der Umsetzung immer im Hinterkopf (Schwaber & Sutherland 2020).

INKREMENT / Ergebnis

• das (Zwischen-)Ergebnis, das nach einer Projektetappe präsentiert wird
• Es muss bereits in einem verwendbaren Zustand sein („potentiell einsatzfähiges Produkt“).
• Die DEFINITION OF DONE – d.h. eine eindeutige Beschreibung, was „fertig“ heißt – erfolgt vorab durch das Team.

Aus unser Sicht stecken in den Artefakten drei Kernideen, die sich gut auch auf Verwaltungen übertragen lassen:

• Anforderungen sollten konsequent und eindeutig priorisiert werden (anstatt: “Abstriche machen tut weh, daher ist irgendwie alles wichtig”).
• Die Nutzung eines Kanban-Boards und regelmäßiger Treffen davor für die laufende und selbstorganisierte Projektsteuerung im Team nutzen. Diese Art des Aufgabenmanagements schafft Transparenz und sorgt dafür, dass es voran geht.
• Schon nach kurzer Zeit und fortlaufend konkrete Ergebnisse produzieren, um schnell in die Umsetzung zu kommen und laufend Feedback zu erhalten (anstatt laaange zu planen oder gute Konzepte zu entwickeln, die oft in der Schublade landen).

4. Ablauf und Rituale

Ein Scrum-Projekt besteht aus einer Aneinanderreihung von SPRINTS, die immer die gleiche Länge haben sollten (max. einen Monat). Innerhalb eines Sprints realisiert das Scrum Team ein (Zwischen-)Ergebnis, das im Anschluss präsentiert wird. Der Scrum Guide 2020 bezeichnet Sprints als „Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden“ (Schwaber & Sutherland 2020).

Sprints ermöglichen auch in komplexen Projekten, bei denen das finale Ergebnis nicht vorhersehbar ist, eine gewisse Planbarkeit und Zuverlässigkeit. Spätestens nach einem Monat werden Zwischenergebnis-se präsentiert und kann der Projektfortschritt geprüft und angepasst werden. Sprints sind Lernzyklen, in denen alle Beteiligten immer besser verstehen, was noch zu tun ist, um das Produkt-Ziel zu erreichen.

Wesentliche Elemente zur Steuerung des Ablaufs in Scrum sind Rituale – wiederkehrende Meetings und Arbeitsphasen, die nach einem strengen TIME BOXING abgehalten werden: Termine werden nicht verschoben, Besprechungen nicht ausgedehnt.

Die Besprechungen und Arbeitsphasen im Einzelnen (aktualisiert gemäß Scrum-Guide 2020):

SPRINT PLANUNG

Sie findet zu Beginn jedes Sprints statt und teilt sich in drei Teile (neu nach Scrum Guide 2020, davor waren es zwei Teile). Für einen einmonatigen Sprint soll-te die Besprechung max. 8 Std. dauern (bei kürzeren Sprints kürzer). Der Product Owner stellt sicher, dass die Teilnehmenden gut vorbereitet sind, um die wichtigsten Einträge des Produkt Backlogs zu besprechen. Der Scrum Master unterstützt die Kommunikation zwischen den Beteiligten. Bei Bedarf können weitere Personen zu Beratungszwecken hinzugezogen werden:

Sprint Planung I: WOFÜR ist dieser Sprint gut?

Das Scrum Team erarbeitet gemeinsam das Sprint Ziel, das verdeutlicht, warum der Sprint für die Stakeholder:innen wertvoll ist und wie das Produkt durch den Sprint seinen Nutzen steigern kann.

Sprint Planung II: WAS kann in diesem Sprint fertiggestellt werden?

In Abstimmung mit dem Product Owner wählen die Developer:innen aus, WAS sie im Sprint erledigen:

• Der Product Owner stellt den aktuellen Stand des Product Backlogs vor. Fragen werden geklärt, Einträge verfeinert.
• Neue Anforderungen werden geklärt und ihr Realisierungsaufwand geschätzt.
• Das Team gibt eine Prognose ab, welche Einträge aus dem Product Backlog es im nächsten Sprint umsetzen kann.

Sprint Planung III: WIE wird die ausgewählte Arbeit erledigt?

Hier entscheiden die Developer:innen eigenständig, wie sie die Anforderungen umsetzen:

• Das Sprint-Ziel und die umzusetzenden Einträge des Product Backlog werden in den Sprint Backlog überführt.
• Die Anforderungen werden in konkrete Aufgaben (Tasks) von max. 1 Tag Aufwand zerlegt.

DAILY SCRUM

Die Developer:innen synchronisieren sich täglich für maximal 15 Minuten vor dem Sprint Backlog (gleiche Zeit, gleicher Ort). Sie tauschen sich zum Fortschritt ihrer Arbeit aus und planen den anstehenden Arbeitstag. Herausforderung ist hier, nicht inhaltlich in einzelne Aufgaben abzutauchen. Gibt es fachlichen Beratungsbedarf, tauschen sich die Developer:innen im Laufe des Tages dazu aus.

Falls Product Owner oder Scrum Master auch aktiv an Einträgen des Sprint Backlogs arbeiten, nehmen sie ebenfalls als Developer:innen an dem Treffen teil. Unabhängig davon kann der Scrum Master (gerade in Teams mit wenig Scrum Erfahrung) für die Moderation und Unterstützung bei Störungen hinzugezogen werden.

Neu im Scrum Guide 2020: Die Struktur und Technik des Daily Scrum wird den Developer:innen freigestellt. Anders als in früheren Versionen, bei denen sich das Ritual an den folgenden Fragen orientierte:

• Was habe ich seit gestern erledigt? –> die entsprechenden Aufgaben wandern in die Spalte „Review“
• Was will ich heute tun? –> die entsprechenden Aufgaben wandern in die Spalte „Doing“
• Was behindert meine Arbeit? –> hier sollte der Scrum Master unterstützen

Diese Fragen können trotzdem nützlich sein – aber sie sollen nicht zu einer leeren Hülle oder „gebetsmühlenartigen“ Dauerschleife werden. Für verschiedene Teams und verschiedene Phasen können andere Impulsfragen hilfreich sein.

SPRINT REVIEW

Das Scrum Team präsentiert das Ergebnis des Sprints, beantwortet Fragen dazu und erhält Feedback und Anregungen. Teilnehmer*innen  Alle Teilnehmer*innen, also Kund*innen und Scrumteam gemeinsam, erarbeiten,  was als nächstes zu tun ist, ergänzen ggf. den Product Backlog und liefern damit Input für die nächste Sprint Planung.Es handelt sich somit um ein Arbeitstreffen (keine reine Präsentation!). Das Scrum Team kann hierzu Vertreter*innen der Interessensgruppen einladen.

Für einen einmonatigen Sprint sollte die Besprechung max. 4 Std. dauern.

RETROSPEKTIVE

Anstatt gleich in die Planung des nächsten Sprints einzusteigen, reflektiert das Scrum Team hier zu-nächst die bisherige Zusammenarbeit, macht sich Stärken bewusst und vereinbart Maßnahmen zur Verbesserung. Ziel ist es, die Qualität und Effektivität zu steigern. Die vielversprechendsten Verbesse-rungen können in den Sprint Backlog für den nächsten Sprint übernommen werden.

Bei einem einmonatigen Sprint sollte die Besprechung max. 3 Std. dauern.

Der Ablauf ist ein wichtiger Knackpunkt bei der Übertragung auf den Verwaltungsalltag. Scrum in Reinform setzt voraus, dass die Teammitglieder in Vollzeit nur dem Projekt zur Verfügung stehen. Das funktioniert natürlich nicht, wenn Projekte neben dem Alltagsgeschäft gestemmt werden müssen. Was dann hilft, ist die Taktung und Dauer der Besprechungen zu verändern – zum Beispiel:

• Aus einem „Daily Scrum“ ein „Weekly Scrum“ machen (und es dafür ggf. auf 30 Minuten ausdehnen).
• Die Dauer von Planung, Review und Retrospektive verringern: Wenn Sie hier nicht vier Wochen Vollzeitarbeit, sondern „Nebenbeiarbeit“ planen, präsentieren und reflektieren, kommen Sie gut mit jeweils 1-2 Stunden hin.

Und dann haben wir in einem Blog-Beitrag von Wolf Steinbrecher (Forum Agile Verwaltung) noch die interessante Idee der „Umsetzungsmeetings“ entdeckt [3]:

„Angenommen, die Anwendervertreter (ihre Zeitressourcen sind meist der Flaschenhals) haben (…) vier Wochenstunden Zeit für das Projekt. Dann setzen wir ein vierstündiges Meeting an mit festem Termin und Timebox. Zum Beispiel „Mittwoch 13-17 Uhr“. In dieser Zeit sitzen alle Mitglieder des Umsetzungsteams in einem gemeinsamen Raum (nicht für Dritte erreichbar am Arbeitsplatz) mit einem Schild „Bitte nicht stören“ an der Tür. Das Team setzt gemeinsam die Tasks um. Das kann durchaus arbeitsteilig erfolgen: Alice macht Task 1, Bob und Charly kümmern sich um Task 2, Denis macht Task 3 und Eric Nr. 4. Aber

• das Abschotten gegen die Außenwelt;
• das gemeinsame Zusammenarbeiten als ein Team;
• das Nachverfolgen, wie die Tasks über das Scrumboard wandern –

all dies zusammen stärkt die Motivation und erhöht die Geschwindigkeit. Die Teammitglieder fühlen sich energiereich und getragen.“

 

So, das war nun eine Menge Stoff, der zunächst ruhig etwas sacken darf, bevor wir im nächsten Beitrag anhand des Praxisbeispiels der Stadt Lünen zeigen, wie Scrum in der Verwaltung funktionieren kann.

 

[1] Ken Schwaber & Jeff Sutherland (2020): Der Scrum Guide Der gültige Leitfaden für Scrum: Die Spielregeln. Verfügbar unter: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf

[2] Für größere Projekte werden mehrere Teams aufgesetzt und gibt es entsprechende Erweiterungen von Scrum (z.B. Large Scale Scrum – LeSS).

[3] Steinbrecher, Wolf (2018): Agiles Projektmanagement in der Öffentlichen Verwaltung: Wie muss Scrum angepasst werden? Blog-Beitrag abrufbar unter: https://agile-verwaltung.org/2018/03/01/agiles-projektmanagement-in-der-oeffentlichen-verwaltung-wie-muss-scrum-angepasst-werden/