Scrum stellt ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte dar, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Es basiert auf der Theorie empirischer Prozesssteuerung. Dies bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden.
Jede empirische Prozesssteuerung wird von drei Säulen getragen: Transparenz (Transparency), Überprüfung (Inspection) und Anpassung (Adaption).
Transparenz bedeutet eine Offenlegung aller wesentlichen Aspekte des Prozesses für die Ergebnisverantwortlichen und fordert für ein gemeinsames Verständnis eine für alle Beteiligten verständliche Sprache. Das gemeinsame Ziel von Überprüfung und Anpassung ist, Schwachstellen im Prozess sowie nicht ausreichende Qualität von Scrum-Artefakten frühzeitig zu erkennen. Auf dieser Grundlage werden Anpassungen vorgenommen, um weitere Abweichungen zu minimieren. Für die Überprüfung und Anpassung schreibt Scrum die Ereignisse „Sprint Planning“, „Daily Scrum“, „Sprint Review“ und „Sprint-Retrospektive“ vor.
Im Sprint Planning fokussieren sich Überprüfung und Anpassung auf die Product-Backlog-Einträge, also auf den fachlichen Inhalt des kommenden Sprints. Im Daily Scrum hingegen stehen die Arbeitsergebnisse seit dem letzten Daily Scrum und die Prognose auf die bevorstehende Arbeit, also die aktive Umsetzung der zu erledigenden Arbeit im Vordergrund.
Das Ergebnis des abgelaufenen Sprints steht im Sprint Review auf dem Prüfstand. Abhängig davon, wie viel der ursprünglich für den Sprint geplanten User Storys erfolgreich umgesetzt werden konnten, wird das Product Backlog einer Überprüfung und ggf. Anpassung unterzogen.
Das interessanteste Ereignis in Bezug auf Überprüfung und Anpassung stellt die Sprint-Retrospektive dar. In der Retrospektive hinterfragt sich das Entwicklungsteam kritisch selbst. Das Entwicklungsteam erörtert, welche Abläufe oder Prozesse besonders gut abgelaufen sind, aber auch, was nicht optimal durchgeführt wurde und verbessert werden kann. Die gefundenen Aspekte mit Optimierungsbedarf werden nach ihrer Wichtigkeit und/oder Dringlichkeit priorisiert. Für die hochprioren Themen werden Verbesserungsvorschläge erarbeitet, deren Umsetzung dann für den folgenden Sprint eingeplant werden.
Die Sprint-Retrospektive ist damit ein enorm wichtiges Ereignis in Scrum, um Verbesserungen hinsichtlich optimierter Arbeitsweisen zu effektiverem und befriedigendem Arbeiten zu erreichen. Damit gehen automatisch auch Verbesserungen in der Produktqualität einher. In der Praxis stellt sich aber heraus, dass die Retrospektive allein nicht ausreicht, um einen kontinuierlichen Verbesserungsprozess (um den geht es nämlich) effizient zu gestalten.
Positiv festzuhalten ist, dass mit der Sprint-Retrospektive dem Entwicklungsteam überhaupt die Gelegenheit gegeben wird, diese Reflexion auf sich selbst und seine Arbeit als Team durchführen zu können. Allerdings bleiben folgende Probleme bestehen:
- Die Zeitspanne zwischen den Sprint-Retrospektiven ist oft zu lang, um spontan auftretende, aber dringende Probleme zu lösen. Für diese Probleme müssen schnell Lösungen erarbeitet werden und können nicht auf die nächste Retrospektive geschoben werden.
- Die in der Sprint-Retrospektive aufgedeckten Probleme werden priorisiert, aber aus Zeitgründen werden nur für die höchstprioren Probleme Verbesserungsvorschläge erarbeitet und in den kommenden Sprint eingeplant. Die als weniger wichtig priorisierten Probleme bleiben unbearbeitet, sie werden unter Umständen nie gelöst, auch wenn eine Lösung leicht und schnell umzusetzen wäre.
Diese Erkenntnisse waren für unser Scrum-Team Anlass, nach einem geeigneten Vorgehen zu suchen, das die beschriebenen Nachteile verhindert, zumal Scrum ausdrücklich weitere Prozesse und Techniken in seinem Rahmenwerk erlaubt. Ein Blick auf das Kanban-Board zeigte schnell, dass dies nicht die Lösung zu den Problemen sein kann. Mit einem Kanban-Board werden die Status aller Arbeitspakete im Überblick dargestellt, woraus sich der aktuelle Stand des Gesamtprojekts ableiten lässt. Dies hat zur Folge, dass Engpässe frühzeitig identifiziert und daraus gezielte Maßnahmen abgeleitet werden können. Auf die Frage „Wie können wir unsere Arbeitsweise verbessern?“ liefert das Kanban-Board dennoch keine Antworten. Damit bleiben unsere Probleme nach wie vor ungelöst.
Die weitere Suche führte uns zur Methode des „PopcornFlow“ von Claudio Perrone. Was PopcornFlow ist und wie wir es als Scrum-Team einsetzen, das beschreiben wir im zweiten Teil unserer Blogserie. Bleiben Sie dran!
MID Blog Newsletter abonnieren