Scrum in der Verwaltung  - Teil 3: Die Regeln von Scrum

Stadt-Gespräche — Folge 25

In den Stadt-Gesprächen reden wir, vom städtischen Start-up ShiftDigital, mit Mitarbeiter*innen aus der Verwaltung über Digitalisierung, E-Government und New Work. In dieser Folge sprechen wir mit Ralf Engels über die Regeln von Scrum und wie man diese an die eigenen Bedürfnisse anpassen kann. Am Ende dieses Artikels findest du eine Zusammenfassung der Regeln.

Nina da Costa: Über das Entwicklungsteam im Scrum haben wir in der letzten Folge schon gesprochen. Jetzt wäre es toll, wenn du die Rollen von Scrum Master und Product Owner erklären könntest.

Ralf Engels: Ich beschreibe jetzt, wie wir die Rollen verstehen. Das Wichtigste ist, dass der Scrum Master den Kontakt zu allen anderen Teams hält und sich um eventuelle Abhängigkeiten zu ihnen kümmert. Der zweite Punkt ist, dass er die Termine setzt, dafür sorgt, dass sie eingehalten werden, und auch dafür, dass die Boards gepflegt, also neue Aufgaben angebracht werden. Außerdem organisiert er die Meetings und deren Durchführung und guckt, dass das “Timeboxing” eingehalten wird— also die Zeiten, die vereinbart sind, damit keine Arbeitszeit durch zu lange Besprechungen verloren geht. Es sei denn, es ist notwendig, aber dann muss das gesamte Team zustimmen. Das sind bei uns die Aufgaben der Scrum Master.

Nina: Und die der Product Owner?

Ralf: Die Product Owner legen fest, welche Aufgaben für das Team als Nächstes relevant sind. Das heißt, sie sprechen sich untereinander ab und legen den Grundstein für die nächsten Arbeitspakete, die abgearbeitet werden. Die Product Owner sind bei uns noch nicht optimal ausgebildet, weil die Aufgabe einfach sehr schwierig ist: Wie soll ich jemandem, der noch nicht auf diese Art gearbeitet hat, erklären, dass er eine Aufgabensammlung für ein Ziel erstellen soll, das ihm noch nicht ganz klar ist?

“Am besten bin ich als Product Owner geeignet, wenn das Anliegen meines Kunden auch mein Anliegen ist.”

Nina: Und wie kamen die Leute mit der Rolle klar?

Ralf: Einige derjenigen, die sich als Product Owner bereit erklärt haben, konnten das ganz gut meistern, vielleicht auch aufgrund ihrer Aufgabe in ihrem Team. Bei anderen war es sehr schwierig und hat dazu geführt, dass die Aufgabensammlungen nicht so gut funktioniert haben. Einfach, weil es total schwer war, diese Aufgabe klar zu definieren. Das ist dem ersten Projekt geschuldet, und dann auch noch gleich einem in dieser Größe und Komplexität.

Nina: Product Owner muss aber ja auch nicht jeder sein. Es ist okay, wenn Leute das ausprobieren und merken, dass es ihnen nicht liegt, oder?

Ralf: Das ist ein ganz wichtiger Punkt. Am besten bin ich als Product Owner geeignet, wenn das Anliegen, das mein Kunde hat, auch mein Anliegen ist. Weil ich mich dann am ehesten in den Kunden hineinversetzen und sehr gut definieren kann, was er braucht. Wenn es mir nicht liegt, kann ich in eine andere Rolle des Teams wechseln. Ich gestehe mir damit keine Niederlage ein. Und es kann sein, dass das in einem anderen Projekt oder Kontext anders ist.

Nina: Kommen wir zum Thema Rituale. Wir haben schon ein paar erwähnt, aber wahrscheinlich sollten wir mit dem Sprint anfangen.

Ralf: Der Sprint ist ein festgelegtes Zeitfenster, in dem man bestimmte Aufgaben bearbeitet. Bei uns ist der Sprint immer zwei Wochen lang — wir brauchen kurze Sprints und regelmäßige Treffen, weil wir so viel Abstimmungsbedarf haben.

“Wir haben drei Fragen, die jeder beantwortet: Was habe ich erreicht, was beschäftigt mich, und was möchte ich heute erreichen?”

Nina: Und das “Sprint Planning” oder die Sprint-Planung ist, wie der Name sagt, einfach die Planung von dem, was man im nächsten Sprint schaffen will.

Ralf: Genau. Wir haben das Sprint Planning “Workshop” genannt, weil wir dort die Ergebnisse für alle, die in diesem Prozess mitmachen, in ein Gesamtergebnis zusammenführen.

Nina: Es gibt auch noch das “Daily” Meeting. Wie läuft das bei euch ab?

Ralf: Meistens dauert es eine Viertelstunde. Wir haben drei Fragen, die jeder mit einem Satz oder mehr beantwortet: Was habe ich erreicht; was beschäftigt mich — habe ich Hindernisse, ist irgendwas nicht so gelaufen, wie ich das erwartet habe und kreist mir das noch im Kopf herum — und was möchte ich heute erreichen? Dann schauen wir direkt, wo es Redebedarf gibt. Müssen wir vielleicht sogar eingreifen, um unser Ziel zu erreichen? Das Daily versuchen wir immer zur gleichen Zeit zu machen. Das klappt manchmal, manchmal nicht. Vor allem im Sinne dieses Sich-Dran-Gewöhnens findet es jeden Tag statt. Es sind immer alle dabei, die können. Das ist ganz wichtig, damit alle wissen, wie der Stand ist. Wenn dann nämlich ein oder zwei Tage später irgendetwas aufkommt — es läuft etwas kritisch auf, wir müssen all unsere Ressourcen aktivieren — muss man nicht noch denen, die nichts zu tun hatten, erklären, was los ist.

“Die Retrospektive dient dazu zu schauen, was gut und was schlecht gelaufen ist, wo wir uns verbessern können, und das dann in den Arbeitsalltag zu übertragen.”

Nina: Im Scrum gibt es noch die “Sprint Review”, also den Rückblick auf den letzten Sprint. Normalerweise hat man erst die Sprint Review und macht direkt im Anschluss die Planung für den nächsten Sprint. Und zu guter Letzt gibt es noch die Retrospektive, in der man über die Methode selbst spricht. Macht ihr sowas auch?

Ralf: Die haben wir aus Zeitgründen erstmal weggelassen. Wir machen eine große Retrospektive zum Schluss. Dann wird es darum gehen, die Methode zu besprechen, die Gefühle zu besprechen… Das, was Ingenieure besonders gerne machen (lacht). Darauf freue ich mich sehr, weil ich glaube, dass es eine schöne Mischung aus Kritik und Begeisterung wird. Auf jeden Fall wird es die Grundlage für unsere weitere Arbeit sein. Denn die Retrospektive dient dazu, das, was man methodisch getan hat, zu hinterfragen und zu schauen: was ist gut gelaufen, was ist schlecht gelaufen, wo können wir uns verbessern? Und das wird in den weiteren Arbeitsalltag übertragen.

“Ich glaube, dass es wichtig ist, neben der offiziellen Meinung auch eine anonyme abgeben zu können.”

Nina: Habt ihr Pläne für eine Möglichkeit, anonym Feedback zu geben?

Ralf: Den ersten Aufschlag dessen, was wir da tun werden, geben wir erstmal in die Hand unserer externen Begleitung. Ich finde das aber gut und glaube, dass es wichtig ist, neben der offiziellen Meinung eine anonyme abgeben zu können, um zwischen dem zu unterscheiden, was der Mitarbeiter vielleicht gegenüber seinen Vorgesetzten oder Kollegen sagt, und dem, was er tatsächlich darüber denkt. Ich würde aus anonymen Ergebnissen ja gerne…

Nina (lacht): Statistiken erstellen?

Ralf (lacht): Genau, eine Statistik machen und schauen, wie sich das eigentlich verändert. Das haben wir am Anfang nicht gemacht, aber ich würde mal sagen, wir können davon ausgehen. dass wir da bei ungefähr 100% destruktiver und eher ablehnender Haltung waren. Und wenn wir jetzt bei 50% sind, haben wir ja schon einen ziemlich guten Erfolg.

Nina: Ich finde, das ist eigentlich das perfekte Beispiel für das “Leute mitnehmen”, von dem immer alle reden: ihr habt die Hälfte der Zeit, die ihr für dieses Projekt hattet, darauf verwendet, die Leute mitzunehmen. Was dafür gesorgt hat, dass die andere Hälfte der Zeit ausreicht, das Projekt zu schaffen. Das zeigt ja, wie sich das in die Zukunft übertragen kann, wenn jetzt alle so weiterarbeiten!

Ralf: Genau.

“Die Experten in den jeweiligen Teams entscheiden, wann ein Produkt die ausreichende Qualität hat.”

Nina: Zum Abschluss der Scrum-Erklärung: die Artefakte, wie man so sagt. Ich erkläre das einfach kurz, weil ich es sowieso vorbereitet habe. Der “Product Backlog” beinhaltet alles, was das Produkt am Ende können oder man am Ende eines Projektes erreicht haben soll. Im “Sprint Backlog” hält man fest, welche Sachen aus dem Product Backlog man im nächsten Sprint umzusetzen will. Und am Ende eines Sprints gibt es das “Potentially Shippable Product”, oder das Produkt-Inkrement. Das heißt, dass man im Idealfall etwas Fertiges hat, selbst wenn es nur ein kleines Teilstück ist.

Ralf: Noch ein wichtiger Punkt ist die “Definition of Done”: wann ist eigentlich ein Produkt-Inkrement fertig? Das haben wir in unserem ersten Projekt nicht explizit definiert, sondern es war vielmehr so, dass wir gesagt haben: die Experten in den jeweiligen Teams entscheiden, wann ein Produkt die ausreichende Qualität hat. Und derer konnten wir uns auch relativ sicher sein, weil fast alle Kollegen eher dazu neigen, zu genau zu sein. Das sind aber Dinge, die eine ganz entscheidende Rolle dabei spielen, ob den Teammitgliedern klar ist, wann ihre Aufgabe erledigt ist. Das ist ein Punkt, der erstmal gut funktioniert hat, für den ich bei uns aber für die Zukunft noch mit den größten Handlungsbedarf sehen würde.

“Wir haben uns Gedanken gemacht: wie schaffen wir es, in unsere Arbeit dieses Inkrementelle und Iterative hineinzubekommen?”

Nina da Costa: Ihr habt ja einige Regeln von Scrum an eure Bedürfnisse angepasst. Könntest du zusammenfassen, was ihr geändert habt?

Ralf: Wir sind ein bisschen umgekehrt vorgegangen und haben gesagt: was brauchen wir, damit wir diese andere Art zu arbeiten umsetzen können? Dann haben wir uns Scrum angeschaut und überlegt, was davon wir übernehmen. Wir sind erstmal bei den einfachen Dingen gelandet, wie Daily und Sprint. Zunächst haben wir uns Gedanken gemacht: wie schaffen wir es, in unsere Arbeit dieses Inkrementelle und Iterative hineinzubekommen? Uns war schnell klar, dass wir die vier Rollen im Scrum, also den Scrum Master, den Product Owner, das Entwicklungsteam und eigentlich auch die Kunden unterbringen wollen.

Nina: Die Kunden waren mehr oder weniger die rechtlichen Anforderungen dieses Abwasserbeseitigungskonzepts.

Ralf: Genau. Eigentlich hatten wir einen klassischen Projektplan, denn es stand schon fest, was wir brauchen und in welcher Reihenfolge wir es machen müssen. Wir haben versucht, das klassische Wasserfall-Projekt in ein agiles Projekt zu heben und dafür die entsprechenden Rollen und Methoden zu definieren. Und da war für uns das Kanban-Board ein wichtiges Werkzeug, weil wir so viele Teams hatten: die Teams können untereinander auf das Kanban-Board der anderen Teams schauen, um eine Idee zu bekommen, wo im Prozess sie sich gerade befinden. Ein Kanban-Board ist ja im Prinzip eine ganz einfache Struktur. Ich habe drei Spalten: in der linken stehen alle Aufgaben, die ich noch zu erledigen habe, in der mittleren alle, an denen ich gerade arbeite, und in der rechten alle Aufgaben, die erledigt sind.

“Durch das Kanban-Board haben alle im und auch außerhalb des Teams sehr schnell einen Überblick, wo das Team als Ganzes steht.”

Nina: Was bringt einem Kanban — warum nutzt man das?

Ralf: Das Entscheidende ist, dass alle im und auch außerhalb des Teams sehr schnell einen Überblick haben, wo das Team als Ganzes steht.

Nina: Und es zwingt einen auch, Aufgaben in Teilaufgaben herunterzubrechen.

Ralf: Es ist total spannend, sich diese Gedanken zu machen — die Aufgaben so herunterzubrechen. Wir haben gesagt, dass wir in der Lage sein wollen, möglichst jeden Tag unsere Aufgaben weiterzuschieben. Das heißt, dass keine Aufgabe an unserem Board von ihrem Umfang her einen Tag überschreiten sollte. Das hat nicht immer geklappt, ist aber überhaupt kein Thema.

Nina (lacht): Es wird keiner verprügelt, wenn man das nicht schafft.

Ralf: Ganz im Gegenteil, dann bleibt die Aufgabe eben hängen. Manchmal hängt man sie auch wieder zurück oder nimmt sie ganz ab und sagt: “Ich muss daraus fünf Teilaufgaben machen, weil es richtig viel Arbeit ist — das war mir nicht klar.”

Zusammenfassung der Regeln im Scrum

1. Rollen:

• Team: interdisziplinär und selbstorganisiert, entwickelt das Produkt
• Scrum Master: Methodiker — sorgt für die Einhaltung der Regeln, lädt zu Meetings ein, moderiert diese, hat einen Blick auf die Scrum-Prozesse
• Product Owner: verantwortlich für das Produkt und die Teilergebnisse, legen gemeinsam Aufgaben fest, räumen Hindernisse aus dem Weg
• Kunde: stellt Anforderungen, gibt Feedback

2. Ritale:

• Sprint: Arbeitsphase von 1–4 Wochen, in der ein Teil des Produktes/ Projektes erarbeitet wird
• Daily: 5- bis 15-minütiges tägliches Meeting, bei dem jede*r über die Erfolge von gestern, Aufgaben von heute und mögliche Probleme spricht
• Sprint Review und Planning: Meeting, bei dem die Ergebnisse des letzten Sprints vorgestellt und die Aufgaben für den nächsten festgelegt werden
• Retrospektive: Meeting nach Review und Planning, bei dem über die Methode, Prozesse und die Zusammenarbeit im Team gesprochen wird

3. Artefakte:

• Product Backlog: Aufgabensammlung für das gesamte Produkt/ Projekt
• Sprint Backlog: Aufgabensammlung für den nächsten Sprint
• Produkt-Inkrement: potenzielles Teilergebnis am Ende eines Sprints

Du willst dich weiter über Scrum informieren? Dann empfehlen wir dir den offiziellen Scrum-Guide zum Lesen oder zum Anhören.

Du interessierst dich für die Verwaltung der Zukunft?

Dann abonniere jetzt unseren kostenlosen Newsletter Shift Weekly und erhalte jede Woche spannende Links rund um E-Government, Digitalisierung und New Work!