New Work und Agilität – verständlich erklärt – Glossar von A bis Z – Teil 5: Instrumente in Scrum-Projekten
Im 5. Teil des Glossars werfen wir einen Blick auf häufig genutzte Techniken des agilen Arbeitens. Wir knüpfen damit an Teil 4 an, in dem es um Scrum ging. Die beschriebenen Instrumente wurden schon vor vielen Jahrzehnten genutzt, um Arbeitsweisen und den Fluss von Arbeit zu verbessern. Sie werden heute nicht nur in Projekten genutzt und ermöglichen es, nach den agilen Werten vorzugehen.
Agile Projekte sind oft zeitkritisch. Deswegen setzen wir bewusst einen kurzen Takt, der alle Beteiligten „zwingt“, regelmäßig auf die Ergebnisse zu schauen und um den Stand zu aktualisieren.
Bei Scrum nennen wir diesen Takt Sprints. Alle Sprints sind gleichlang und dauern nicht länger als einen Monat. (Wir haben auch schon mit Sprints von einer Stunde Dauer gearbeitet.)
Vor dem Beginn eines agilen Projekts wird entgegen der häufigen Meinung sehr wohl geplant. Alles, was wir vorab wissen, dürfen und sollen wir für die Planung verwenden. Irgendwann gibt es einen Punkt, an dem weitere Planung keinen weiteren Nutzen mehr bringt. Erst wenn die Projektbeteiligten zusammen arbeiten, lernen sie dazu. Das ist die Idee eines Sprints: Ergebnisse liefern, um danach zu schauen, wie es am besten weiter geht.
Daher beginnt jeder Sprint mit einer gemeinsamen Planung (Sprint Planning). Dort legt das Scrum Team fest, was der Inhalt des Sprint ist und wie die Ergebnisse konkret geliefert werden sollen.
Am Ende schaut sich das Scrum Team am besten zusammen mit echten Anwender:innen der Ergebnisse an, was erreicht wurde. Auf Basis dieses Feedbacks wird entschieden, wie es am besten weitergeht. In Scrum nennen wir dieses Ereignis einen sog. Sprint Review.
Nach einen Sprint Review versteht das Scrum Team, was es geleistet hat. Jetzt kommt es noch einmal zusammen. Es bespricht, welche 1-2 konkrete Maßnahmen sinnvoll wären, um die Lieferfähigkeit im nächsten Sprint zu verbessern. Das kann die Zusammenarbeit im Scrum Team intern und mit Stakeholdern betreffen. Aber auch Abläufe und Werkzeuge sind oft Thema dieser sog. Sprint Retrospektive. Danach startet auch schon wieder der nächste Sprint mit einem Sprint Planning.
Leistungsfähige Teams kommen täglich zusammen, um zu prüfen, ob man noch auf dem richtigen Weg ist. Dabei schauen sich die Umsetzer:innen den Stand der Arbeit an und machen sich einen Plan bis zum nächsten Abgleich. In Scrum nennen wir dieses Ereignis Daily Scrum. Es gibt agile Teams, die noch keinen Weg gefunden haben, täglich und voller Konzentration an einer Baustelle zu arbeiten. In solchen Fällen treffen sich die Umsetzer:innen vielleicht einmal in der Woche um sich abzugleichen.
Bei Scrum nutzen wir also fünf Ereignisse, um die Umsetzung aktiv zu steuern. Die Sprints geben den Takt vor. Das Scrum Team plant und begutachtet gemeinsam die Arbeit. Es gibt einen verbindlichen Haltepunkt, an dem alle über bessere Lieferfähigkeit nachdenken müssen. Zwischen Planung und Review gleicht es sich so häufig wie möglich ab, um bei Hindernissen oder Fehlern keine Zeit zu verlieren.
Wenn ein Team nach Scrum arbeitet, nutzt es oft drei sog. Artefakte. Das ist erstens die Liste der Ergebnisse, die wir im finalen Endprodukt erwarten. Das ist das sog. Product Backlog mit dem Produktziel. Scrum macht keine Vorgaben zum Format des Product Backlogs. Der Scrum Guide spricht einfach von Einträgen im Product Backlog (Product Backlog Item – PBI). Agile Teams nutzen oft das Format User Story, weil man damit gut festhalten kann, wer welche Funktion und warum braucht.
Zweitens gibt es einen konkreten Arbeitsplan für einen Sprint. Dort steht, welche Ideen in einen Sprint gehen und wie diese Idee konkret umgesetzt werden. Das ist das Sprint Backlog mit einem motivierenden Sprintziel. Das Sprint Backlog wird häufig auf einem physischen oder elektronischen Board dargestellt. Dieses Board ist so gestaltet, dass alle im Scrum Team sofort erkennen, was der Stand eines Product Backlog Items ist. (Entgegen einer häufigen Meinung handelt es sich bei diesem Board NICHT um ein Kanban-Board.)
Schließlich gibt den aktuellen Produktstand, zu dem sich ein Scrum Team am Ende eines Sprints immer Feedback holt. In Scrum nennen wir diesen Zwischenstand das Inkrement. (Das Produkt wächst inkrementell.)
Scrum ist ein guter Rahmen, wenn es darum geht komplexe Probleme zu lösen oder um neue Produkte auf den Markt zu bringen. Das regelmäßige Planen und Überprüfen ist eine Reaktion auf die Unsicherheiten bei den Anforderungen und in der Technologie. Wir können eben nie sicher sein, ob wir die Anwender:innen richtig verstanden haben und ob wir die neue Technologie richtig beherrschen.
Wenn wir allerdings Arbeitspakete haben, die wir wirklich gut verstehen, sind das gemeinsame Planen und Begutachten nicht nötig. In diesem Fall wechseln wir in einen anderen Arbeitsmodus und nehmen von Scrum Abstand. Sprint Planning und Sprint Review entfallen.
Der Vorteil der gemeinsamen Planung ist, dass die Arbeit begrenzt wird. In der Planung sagen die Umsetzer:innen was zu schaffen ist.
Wenn es keine gemeinsame Planung gibt, brauchen wir einen anderen Mechanismus, um die Menge der Arbeit zu begrenzen. Schließlich wollen wir uns nicht übernehmen. Hier können wir uns mit einer anderen Technik, Kanban, helfen.
Wir machen dazu den Lieferprozess auf einem Board sichtbar. Die Arbeit fließt (wie auch bei Scrum) von links nach rechts durch das Board. Wir wenden nun einen Trick an und legen fest, dass es in jedem Schritt nicht mehr als eine bestimmte Menge an Arbeitspaketen oder Aufgaben geben darf. Die Idee ist, dass nichts Neues angefangen wird, wenn nichts fertig wird. Die Anzahl der erlaubten Jobs pro Schritt wird WIP-Limit genannt (Work in progress).
Die bisherigen Teile des Glossars findest Du hier:
Teil 3: https://agile-verwaltung.org/2024/11/07/new-work-und-agilitat-einfach-erklart/
