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

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

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, über das Interview zu berichten, das wir in der letzten Woche mit dem „EREW“-Team der Stadt Lünen geführt haben. Das Projektteam hat den elektronischen Rechnungseingangsworkflow in der Stadtverwaltung eingeführt und sich dabei an Scrum orientiert. Bevor wir mit diesem Praxisbeispiel zeigen, wie Scrum in Verwaltungen funktionieren kann, möchten wir in diesem Beitrag zunächst 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: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.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 im Folgenden 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:

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.

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 organisiert.

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 die Projektergebnisse. Er

  • ist Ansprechpartner*in für den Inhalt des Projektes,
  • fördert, dass das Projektergebnis einen maximalen Nutzen bringt,
  • gibt Feedback zu Ergebnissen und nimmt diese ab,
  • 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 SCRUM MASTER übernimmt Verantwortung für den Projektprozess. Er

  • ist Ansprechpartner*in für die Zusammenarbeit im Prozess, unterstützt diese und hilft dabei, sie zu verbessern,
  • coacht das Team und den Product Owner bei der Anwendung von Scrum (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,
  • 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“:

Das TEAM (auch Entwicklungs- oder Umsetzungsteam genannt) setzt Anforderungen in konkrete Ergebnisse um.

  • Es ist interdisziplinär bzw. 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.
  • Es arbeitet selbstorganisiert. Der Product Owner vermittelt die Anforderungen (das „WAS“), aber es liegt allein in der Entscheidung des Teams, WIE es diese in konkrete Ergebnisse umsetzt.
  • Es umfasst 3-9 Mitglieder. Für größere Projekte werden mehrere Teams aufgesetzt und gibt es entsprechende Erweiterungen von Scrum (z.B. Large Scale Scrum – LeSS).

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

Die Abbildung verdeutlicht das Zusammenspiel zwischen den Rollen:

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).

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 der Product Owner ermittelt hat.
  • Einträge werden vom Product Owner 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 oder entfernt werden.
  • Anforderungen werden häufig in Form von USER STORIES formuliert: Wer braucht was wozu?

SPRINT BACKLOG

  • Plan für die nächste Projektetappe („Sprint“ – dazu gleich mehr)
  • Das Team wählt dazu die Menge der Einträge aus dem Product Backlog aus, von der es glaubt, dass es sie in der nächsten Etappe umsetzen kann.
  • Jeder Eintrag aus dem Product Backlog (d.h. jede User Story) wird in Aufgaben („Tasks“) von maximal einem Tag Dauer heruntergebrochen.
  • Das Sprint Backlog bildet die Basis für die Selbstorganisation des Teams während des Sprints und wird meist in Form eines Kanban-Boards visualisiert (dann auch „Scrum-Baord“ genannt):

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 (z.B. einen Monat). Innerhalb eines Sprints realisiert das Team ein (Zwischen-)Ergebnis, das im Anschluss präsentiert wird.

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:

SPRINT PLANUNG

Sie findet zu Beginn jedes Sprints statt und teilt sich in zwei Teile:

Sprint Planung I: Was kann in diesem Sprint fertiggestellt werden?

Dieses Treffen organisiert der Product Owner. Für einen vierwöchigen Sprint sollte die Besprechung max. 4 Std. dauern. Der Scrum Master unterstützt die Kommunikation zwischen den Beteiligten. Bei Bedarf können Gäste (z.B. Vertreter*innen von Interessensgruppen) hinzugezogen werden. Inhalte:

  • Der Product Owner stellt den aktuellen Stand des Product Backlogs vor.
  • 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. Gemeinsam mit dem Product Owner wird daraus das Ziel für den Sprint festgelegt.

Sprint Planung II: Wie wird die ausgewählte Arbeit erledigt?

Diesen Teil der Planung führt das Team unter sich durch (optional kann der Product Owner für Rückfragen hinzugezogen werden). Auch dieser Teil sollte max. 4 Std. dauern. Inhalte:

  • 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 Mitglieder des Teams treffen sich täglich für maximal 15 Minuten vor dem Sprint Backlog und schildern:

  • 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

Bei Bedarf können Product Owner (für inhaltliche Rückfragen) und Scrum Master (für die Moderation und Unterstützung bei Störungen) hinzugezogen werden.

SPRINT REVIEW

Das Team präsentiert das Ergebnis des Sprints, beantwortet Fragen dazu und erhält Feedback und Anregungen. Der Product Owner kann hierzu Vertreter*innen der Interessensgruppen einladen. Für einen vierwöchigen Sprint sollte die Besprechung max. 4 Std. dauern.

Die Teilnehmer*innen erarbeiten außerdem gemeinsam, was als nächstes zu tun ist, ergänzen ggf. den Product Backlog und liefern damit Input für die nächste Sprint Planung.

RETROSPEKTIVE

Anstatt gleich in die Planung des nächsten Sprints einzusteigen, reflektiert das Team hier zunächst die bisherige Zusammenarbeit, macht sich Stärken bewusst und vereinbart Maßnahmen zur Verbesserung. Da der Scrum Master für den Projektprozess verantwortlich ist, sollte er an der Retrospektive teilnehmen und kann hier coachend und moderierend unterstützen. Bei einem vierwöchigen 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 [1]:

„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 erstmal sacken kann, bevor wir in der nächsten Woche anhand des Beispiels Lünen zeigen, wie Scrum in der Verwaltung funktionieren kann.

 

[1] 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/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.