Kategorie:Adapted Scrum Framework

Dass auch Kommunalverwaltungen von der VUCA-Welt betroffen sind, hat sich herumgesprochen. Dass Agile Methoden helfen können, damit fertig zu werden, hat man auch schon gehört und vielleicht auch schon umgesetzt. Wie ist es aber mit Scrum? Lässt sich das Framework, das so erfolgreich bei IT-Projekten eingesetzt wird, gewinnbringend in der Verwaltung verwenden?

Spezifische Rahmenbedingungen

In Kommunalverwaltungen trifft man sehr spezifische Rahmenbedingungen für die Arbeit an Projekten an:

• Verwaltungsprojekte können sehr unterschiedliche Inhalte haben – von der Neuorganisation des Bürgerservices, über das Verfassen einer Dienstanweisung bis hin zu Einführung der E-Rechnung.
• Die Projekte können sehr unterschiedlich hinsichtlich des Umfangs sein.
• Häufig handelt es sich um „Teilzeitprojekte“. Das heißt, alle oder ein Teil der Teammitglieder haben neben den Projektaufgaben noch Linienaufgaben, die in der Regel höhere Priorität haben.
• Projektteams sind häufig räumlich im Gebäude oder sogar über verschiedene Gebäude verteilt.
• Es gibt in der Regel keine festen Projektteams. Vielmehr wird für jedes Projekt ein anders zusammengestelltes Team gebildet. Projektmethoden müssen daher immer wieder neu vermittelt und geübt werden.
• Es ist schwierig die Projekte ohne Beeinflussung der sie umgebenden Linienorganisation durchzuführen. Noch schwieriger wird es, wenn die Projekte die Zuständigkeit mehrerer Ämter berühren, also „quer zu den Silos“ liegen

Die Frage ist also: Kann man Scrum an die genannten Rahmenbedingungen anpassen, so dass es der Verwaltung hilft, Projekte mit veränderlichen Rahmenbedingungen oder nicht genau beschreibbaren Zielen erfolgreich zu meistern? Besser zu meistern, als mit klassischem Projektmanagement oder einem Methodenmix aus klassisch und agil?

Adapted Scrum Framework

Die Antwort ist: Ja, das geht. Das Adapted Scrum Framework (man könnte es auch – cum grano salis – GRUM für „Government Scrum“ nennen), das im Folgenden vorgestellt wird, hat sich bereits bei kommunalen Projekten bewährt. Dabei hat sich gezeigt, dass es vorteilhaft ist, möglichst dicht am Scrum-Framework zu bleiben. Anstatt, wie es häufig empfohlen wird, mit einer Mischung klassischer Methoden und kleineren Agilen Praktiken und Workhacks zu starten und die Methoden nach und nach auszuweiten, ist es günstiger, vom Scrum-Framework auszugehen und pragmatisch zu schauen, wo man um Anpassungen und Auslassungen nicht herumkommt. Mit diesem Entwicklungsweg – sozusagen von oben nach unten – werden die Potenziale von Scrum besser ausgeschöpft, weil mehr von den Werten und Prinzipien von Scrum erhalten bleibt. Mit diesem Entwicklungsweg werden die Potenziale von Scrum besser ausgeschöpft, weil mehr von den Werten und Prinzipien von Scrum erhalten bleibt.

Was ist bei Adapted Scrum anders?

Die auffälligsten Anpassungen betreffen die Sprints. Sie können bei Adapted Scrum in Abhängigkeit vom Sprintziel unterschiedliche Arbeitsweisen beinhalten und entsprechend unterschiedlich lang sein.

Das vollständige Schema kann unter folgendem Link aufgerufen werden: Mindmap: Adapted Scrum Im Schema sind mögliche Sprintarten und Minimal Viable Products (MVP), die Aufgaben der Rollen und geeignete Praktiken für die unterschiedlichen Sprints dargestellt.

Vorbereitungssprint

Besonders zum Projektstart sollte man etwas Zeit investieren, um einen Vorbereitungssprint und einen Sprint 0 durchzuführen. Der Vorbereitungssprint dient dazu – wie der Name schon sagt, das Projekt gut vorzubereiten, beispielsweise die Epics aus verschiedenen Sichten zu formulieren und das initiale Backlog aufzustellen. Insbesondere sollte man sich bei der Vorbereitung genügend Zeit nehmen das Team zusammenzustellen.

Sprint 0

Steht das Team, kann man den ersten Sprint als Sprint 0 durchführen. Das heißt, es wird noch nicht voll produktiv gearbeitet, sondern Zeit in das Teambuilding und die Methodenschulung investiert. Sinnvoll ist auch, zunächst ein gemeinsames Verständis der Aufgabe zu erarbeiten. Die Zeit die hier investiert wird, holt man später wieder rein, weil die Grundsatzdiskussionen dann schon erledigt sind.

Sondersprints

Im Verlauf des Projekts kann es sinnvoll sein, Sondersprints durchzuführen:
Je nach Projekt kann es sinnvoll sein, auf breiter Basis Feedback einzuholen, beispielsweise mit einem World-Café oder einem Barcamp zu denen die „Verwaltungsöffentlichkeit“ eingeladen wird. Die Vorbereitung und Auswertung eines solchen Events beansprucht so viel Ressourcen, dass in dieser Zeit eine reguläre Projektbearbeitung normaler Weise nicht möglich sein dürfte. Gerade bei „Teilzeitprojekten“, die sich wegen der geringen Zeitressourcen gerne lange hinziehen, kann es hilfreich sein, zwischendrin einen oder zwei FeedEx-Tage als motivierenden Zwischensprint einzubauen. Das Team zieht sich gemeinsam mit Scrum-Master und Product-Owner zu einer Arbeitsklausur zurück. Am besten in Räume abseits vom Dienstbetrieb, um ungestört arbeiten zu können. Es hat sich gezeigt, dass so etwas gut organisiert werden kann, solange der Rahmen bei ein, zwei Tagen bleibt, also den Umfang einer Fortbildung hat. Hilfreich ist auch, wenn die Entsendedienststellen offiziell angeschrieben werden und die Erlaubnis daran teilzunehmen von der Dienststellenleitung erteilt wird.

Rollen / Verantwortlichkeiten

Die Rollen bei Adapted Scrum unterscheiden sich nicht wesentlich vom Scrum Framework. Auf die Product-Owner-Rolle kommt aber mehr Arbeit hinzu, denn in einer Verwaltung lassen sich Projekte in der Regel nicht durchführen, ohne die Linie zu berücksichtigen. Um am Projektende keine bösen Überraschungen zu erleben, weil erforderliche Mitzeichnungen nicht erfolgen, empfiehlt es sich, kontinuierlich und aktiv Feedback einzuholen, um alle Stakeholder mitzunehmen.

Events

Die im Scrum-Framework vorgesehenen Events sind auch bei Adapted-Scrum alle vorhanden. Nur die Häufigkeit und die Dauer unterscheiden sich. Bei Teams, die das Projekt als Teilzeitprojekt bearbeiten, wird das Daily zu einem Weekly. Bei verteilten Teams (in verschiedenen, räumlich auseinander liegenden Gebäuden), wird man allerdings wenig Erfolg haben, das Team für einen 20-Minuten-Termin zu versammeln. Alternativ kann man auf ein Online-Format ausweichen oder an das Weekly eine zwei bis drei-stündige gemeinsame Arbeitsphase anschließen (statt sich im Weekly Tickets zu ziehen und diese bis zum nächsten Weekly am eigenen Arbeitsplatz abzuarbeiten). Letzteres funktioniert überraschend gut, weil der Zeitaufwand überschaubar ist und wie eine längere Besprechung empfunden wird. Vorteilhaft ist auch, dass man in der Zeit nicht am Arbeitplatz ist und nicht gestört werden kann. Analog dazu ist es sinnvoll, die Reviews und Retros mit einem Weekly zusammen zu veranstalten. Wenn man die Sprintlänge eines normalen Sprints auf vier Wochen ansetzt, ergibt sich ein Rhythmus von drei wöchentlichen Weeklys + gemeinsame Projektarbeit und einem kombinierten Weekly-, Review-, und Retrotermin alle vier Wochen. Das Ganze läßt sich sehr einfach mit Besprechungsserien organisieren. Das folgende Schema zeigt exemplarisch diese Sprintstruktur.