3 Fehler, die Scrum Teams im Umgang mit ungeplanter Arbeit machen und wie sie vermieden werden können

Ungeplante Arbeit ist die Regel und nicht die Ausnahme.

Scrum Teams entwickeln eben nicht nur Produkte und Services, sondern betreiben diese auch. Ohne den Betrieb einer Anwendung ist es unmöglich, Feedback zu erhalten. Allerdings ist Feedback essenziell für erfolgreiche Scrum Teams, da es die Triebfeder ist, um Nutzer- und Kundenwünsche zu erfüllen. Beim Betrieb von Produkten und Services kommt es zwangsläufig zu ungeplanter Arbeit. Fehler treten auf, Nutzer geben Feedback, Kunden brauchen Support und Notfälle treten ein.

Deshalb müssen Scrum Teams Wege finden, mit ungeplanter Arbeit umzugehen, ohne das Erreichen des Sprint-Ziels zu riskieren.

In den letzten 6 Jahren habe ich als Scrum Master in 9 Scrum Teams gearbeitet. Und alle Teams haben die gleichen Fehler im Umgang mit ungeplanter Arbeit gemacht. Hier meine Top 3 der meistverbreiteten Fehler im Umgang mit ungeplanter Arbeit und Tipps, wie diese vermieden werden können.

Fehler 1: Ungeplante Arbeit wird nicht transparent gemacht

Ein Beispiel aus der Praxis: Ein Support-Mitarbeiter spricht eine Entwicklerin an: „Könntest du dir bitte diesen Fall ansehen? Das dauert bestimmt nicht lange.“ Nach einigen Stunden und einigen Änderungen in einer Konfigurationsdatei ist das Problem behoben.

Warum ist das ein Problem? Scrum funktioniert nur, wenn das Team eine empirische Arbeitsweise implementiert. Die Grundlage empirischer Arbeiten ist, dass alle anfallende Arbeit im Product Backlog transparent gemacht wird. Nur wenn das der Fall ist, können Entscheidungen getroffen werden, die den Wert des Produkts maximieren und das Risiko minimieren.

Dies ist in der geschilderten Situation nicht der Fall. Der Product Owner, welcher die Verantwortung hat, den Wert des Produkts zu maximieren, war nicht eingebunden. Der Support-Mitarbeiter und die Entwicklerin haben dem Supportfall Priorität eingeräumt und dadurch den Product Owner der Möglichkeit beraubt, aktiv den Wert des Produkts zu optimieren.

Dieser Fehler kann vermieden werden. Der Product Backlog ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird. Deshalb muss jede Arbeit, auch die ungeplante, als Erstes dort als Eintrag erfasst werden. Der Product Owner bestimmt durch die Einordnung des Eintrags in den Product Backlog dessen Wichtigkeit. Während unwichtige Aufgaben weiter unten im Product Backlog eingereiht werden kann für wichtige Arbeit, entschieden werden, dass diese im laufenden Sprint erledigt werden muss.

Fehler 2: Leichtfertige Einführung einer Emergency Lane

Bei Scrum Teams, die mit kritischen Fehlern kämpfen, sehe ich häufig die Verwendung eine Fast Track, Expedite Lane oder Emergency Lane. Als „Rettungsgasse“ im Sprint Backlog hilft sie, der Behebung von kritischen Fehlern die höchste Priorität einzuräumen. Diese Praktik macht bei erster Betrachtung durchaus Sinn. Sie macht aktuelle Arbeit des Teams transparent und ermöglicht den Teammitgliedern, die Bearbeitung im Daily Scrum zu koordinieren.

Diese Vorgehensweise birgt aber auch ein Risiko. Dieses wird Teams erst dann bewusst, wenn ein Release-Termin nicht eingehalten werden konnte. Die bloße Einführung einer Emergency Lane macht die aktuelle Arbeit zwar transparenter, aber die Arbeitsabläufe im Sprint gleichzeitig weniger vorhersehbar.

Das bloße Einführen der Emergency Lane reduziert langfristig sogar die Transparenz. Denn wie bei der Bildung einer Rettungsgasse im Straßenverkehr werden aktuelle Arbeiten geparkt, bis der Notfall erledigt ist. Müssen häufig ungeplante Arbeiten verrichtet werden, wird zwangsläufig weniger Arbeit im Sprint fertiggestellt, als sich das Team vorgenommen hat. Im schlimmsten Fall riskiert das Scrum Team die Erreichung des Sprint-Ziels.

Durch das Bevorzugen von ungeplanten Arbeiten wird der Entwicklungsprozess des Scrum Teams weniger vorhersehbar und somit Prognosen unmöglich. Dieser Fehler kann vermieden werden, indem Scrum Teams explizite Regel aufstellen, wie sie mit ungeplanter Arbeit umgehen.

Explizite Regeln umfassen:

• Aufstellung von Kriterien, wann ein Fehler oder Supportfall kritisch ist und deshalb nicht erst im nächsten Sprint bearbeitet werden kann. Nur klare Kriterien ermöglichen die Fokussierung auf die aktuelle Arbeit im Sprint.
• Defintion eines Prozesses, welchem das Team bei der Behandlung von ungeplanter Arbeit folgt. Zum Beispiel: Aufnahme der Arbeit in den Backlog. Sollte die Aufgabe kritisch sein, folgt eine Einberufung einer Ad-hoc-Einplanungssitzung. Auf lange Sicht wird das Befolgen eines geregelten Vorgehens den Scrum Team Zeit sparen.
• Klassifizierung von unterschiedlichen Arbeiten wie Supportfälle, Fehlerbehebung und Neuentwicklung. Das Verhältnis zwischen den verschiedenen Typen liefert dem Team wertvolle Einsichten in ihren Arbeitsprozess und der Qualität des Produkts.
• Messung der Cycle-Time der ungeplanten Arbeiten. Dadurch wird der Fluss der ungeplanten Arbeiten im Sprint transparent gemacht. Dies ermöglicht es, den Umgang mit der ungeplanten Arbeit zu überprüfen und zukünftig zu verbessern.

Indem der Umgang mit ungeplanter Arbeit explizit gemacht wird, wird er messbar. Die Messbarkeit ermöglicht, basierend auf der Vergangenheit, eine verlässlichere Planung und somit robustere Prognosen für die Zukunft.

Fehler 3: Einen Puffer für die ungeplante Arbeit in den Sprint einplanen

Ein der häufigsten Fragen in meinen Professional Scrum Master Trainings lautet: „Wie groß sollte der Puffer für ungeplante Arbeit sein?“ Meine schockierende Antwort lautet: 0 %.

Puffer sind Überbleibsel aus dem Projektmanagement, um Risiken zu managen. In der Produktentwicklung mit Scrum sind sie ein Anzeichen von fehlender Offenheit. Teams denen der Mut fehlt „Nein“ zu sagen und die gezwungen werden, sich auf die Umsetzung des ganzen Sprint Backlogs zu verpflichten, verstecken sich hinter einem Puffer, damit sie ihr Commitment einhalten können.

Transparenz ist die grundlegende Säule von Scrum. Zu wissen wie viel Arbeit noch zu erledigen ist, um das nächste Ziel zu erreichen ist, bildet das Fundament dieser Säule.

Was ein Puffer jedoch bewirkt ist eine bewusste Reduzierung der Transparenz. Ein Puffer im Sprint Backlog stellt ein schwarzes Loch dar.

Zum einen sind alle Arbeiten, die innerhalb dieses Puffers durchgeführt werden, per Definition nicht vorhersehbar und deshalb nicht planbar. Sollte im extremsten Fall kein Notfall eintreten, wird die eingeplante Zeit gar nicht benötigt.

Zum anderen bezieht sich ein Puffer immer auf Zeit. Erfahrene Scrum Teams planen ihre Sprints aber nicht basierend auf Zeit, sondern verwenden Komplexität als Grundlage. Zum Beispiel indem sie Story Points verwenden. Zeit und Story Points sind, wie Äpfel und Birnen, man kann sie nicht vergleichen. Durch das Verwenden von unterschiedlichen Größenskalen, um die Arbeit zu beschreiben, reduziert man die Transparenz vorsätzlich.

Dieser Fehler kann durch folgendes Vorgehen vermieden werden. Anstatt einen Puffer für den Sprint vorzusehen, wird eine bestimmte Menge an Arbeit in das Sprint Backlog eingeplant, die zwar für das Produkt wertvoll wären, aber für das Sprint Goal nicht unbedingt erforderlich sind. Diese Product-Backlog-Einträge sind also „Nice-to-have“ für das Sprint Ziel, die restlichen Einträge „Must-have“. Die „Nice-to-have“-Einträge füllen das Schwarze Loch und stellen zu jedem Zeitpunkt Transparenz her.

Sollte ungeplante Arbeiten auftreten, ermöglicht diese Praktik, den Umfang des Sprints anzupassen, indem das Team entscheidet „Nice-to-have“-Einträge mit ungeplanten Arbeiten zu ersetzen.

Zusammengefasst wird der Zeitpuffer durch einen Umfangpuffer ersetzt. Was den Paradigmenwechsel zwischen Projekt-Mindset und Agilen-Produkt-Mindset noch einmal veranschaulicht: In der agilen Produktentwicklung ist die Zeit fest aber der Umfang der verbleibenden Arbeit variabel. Das Risiko wird kontrolliert, indem der Umfang zu jeder Zeit transparent ist.