Kein Fortschritt im Sprint? Wie du als Scrum Master die 3 größten Probleme sichtbar machst und behebst

„Alle sind beschäftigt, aber Fortschritt ist nicht zu erkennen.“

Etwa so würde ich das Gespräch zusammenfassen, welches ich mit einer Scrum Masterin am diesjährigen Scrum Day hatte. 

In unserem Gespräch sind wir auf drei Probleme gestoßen:

• kein Fokus im Sprint
• zu viel Ablenkung für das Team
• keine Daten, wann Arbeit wirklich fertig ist

Da ich mir vorstellen kann, dass diese Probleme auch vielen anderen Scrum Mastern bekannt vorkommen – ich habe sie bereits mehrfach erlebt –, formuliere ich meine Tipps als Artikel aus.

Los geht es mit dem ersten Problem:

 

Problem 1: Kein Fokus im Sprint

Kein Ziel bedeutet nicht, kein Ziel zu haben.

Kein Ziel im Sprint zu definieren, wird höchstwahrscheinlich dazu führen, dass das Team als Ziel annimmt:

„Alle Arbeiten im Sprint abschließen.“

Die Auswirkung dieses impliziten Ziels?

Es fehlt der Fokus, was im Sprint wirklich wichtig ist. Dadurch darf (oder muss) jeder im Team selbst entscheiden, was er als wichtig erachtet. Der Business-Analyst erachtet die Beschreibung des Anwendungsfalls als das Wichtigste. Der Testerin ist eine möglichst hohe Testabdeckung besonders wichtig und sie beginnt mit der Spezifikation der Testfälle. Ein Entwickler möchte unbedingt seine Fertigkeiten in Kotlin verbessern und beginnt mit einer Programmieraufgabe, bei der er die Technologie einsetzen kann. Thomas, dem Designer, ist es wichtig, die Prioritäten des Product Owners zu berücksichtigen und er entwirft die neue Anmeldemaske. Diese Situation lässt sich gut mit dem Sprichwort zusammenfassen: „Wenn alles wichtig ist, dann ist nichts wichtig.“ Und wirklicher Fortschritt bleibt dabei auf der Strecke.

Wenn du Fortschritt im Team sichtbar machen willst, dann unterstütze dein Team im Sprint Planning. Hilf dabei, auch ein Ziel für den Sprint zu definieren.

In diesem Video bespreche ich ausführlich, wie du dabei vorgehen kannst. 

Hier nochmal die Zusammenfassung der Tipps:

• nur einen Product-Backlog-Eintrag wählen
• etwas Luft im Sprint Backlog lassen
• Sprintlänge hinterfragen
• die Sprint-Ziel-Gegner vor die Wahl stellen

Behalte dabei im Hinterkopf: Es geht nicht darum, das perfekte Sprint-Ziel zu finden, sondern nur ein konkreteres Ziel als das implizite Ziel „Alle Arbeiten im Sprint abschließen“. Wenn dein Team ein Ziel definiert hat, dann hilf ihm, den Fortschritt bei der Erreichung im Sprint sichtbar zu machen.

Hier ein Format, welches ich im Jahr 2018 in einem Team genutzt habe und das damals auf viel Zustimmung bei den Entwicklern traf.

Ich nenne es Sprint-Wetterbericht.

Es geht so:

Zu Beginn jedes Daily Scrums frage ich jedes Mitglied im Team: „Wie zuversichtlich bist du heute, dass wir zum Ende des Sprints das Sprint-Ziel erreichen?“

Die Antwort sollen die Teammitglieder dann in Form eines Wetterberichts geben:

• Sonnig: Ich bin sehr zuversichtlich, dass wir das Sprint-Ziel erreichen können.
• Bewölkt: Ich bin ziemlich zuversichtlich, aber es gibt einige Risiken und Unsicherheiten.
• Regen: Das Erreichen unseres Sprint-Ziels wird schwierig sein.
• Gewitter: Auf keinen Fall, unser Sprint-Ziel ist in großer Gefahr.

Nachdem jedes Teammitglied die Möglichkeit hatte, abzustimmen, werden die Stimmen zusammengefasst und mit einem kleinen Symbol für die heutige Vorhersage festgehalten. Dieser Wetterbericht wird dann als Diskussionsgrundlage im Daily Scrum verwendet.

Das Hilfreiche dieser Technik ist neben der Diskussion im Daily Scrum über das „Wetter“ die Auswertung, die das Format am Ende des Sprints ermöglicht. Mit diesem Format hat man rückblickend für jeden Tag einen Wetterbericht. Wir nutzen die Sprint-Retrospektive, um „Wettertrends“ zu analysieren und Einsichten zu gewinnen. Mit den Einsichten zum Fortschritt während des Sprints leiten wir Maßnahmen zur Verbesserung für den nächsten Sprint ab.

Ein Ziel im Sprint liefert Fokus. Dieser Fokus ermöglicht Fortschritt. Bleibt dieser Fortschritt dennoch aus, dann könnte es am nächsten Problem liegen:

Problem 2: Zu viel Ablenkung für das Team

Obwohl jeder im Team beschäftigt ist, bleibt der Fortschritt aus?

Diese Situation kenne ich nur zu gut. Wenn du diesem Problem auf den Grund gehen willst, dann musst du verstehen, woran jeder im Team wirklich arbeitet. Hierfür habe ich bisher immer das folgende Vorgehen genutzt.

Nutze als Sprint Backlog ein einfaches Board mit drei Spalten. Die Spalten können „To-do“, „Doing“ und „Done“ sein.

Die Arbeiten, die ihr im Sprint Planning für den Sprint plant, kommen in die „To-do“-Spalte. Diese Aufgaben müssen alle die gleiche Farbe haben. Etwa Gelb. Wenn jemand im Team eine Aufgabe bearbeitet, dann verschiebt er sie in die „Doing“-Spalte. Ist die Arbeit abgeschlossen, dann kommt sie in die „Done“-Spalte. Bisher also nichts Außergewöhnliches. Jetzt kommt der wichtige Punkt:

Wenn jemand im Team an einer Sache arbeitet, die nicht im Sprint Planning geplant wurde, dann muss er dafür eine Aufgabe erstellen. Diese Aufgabe durchläuft dann auch die drei Spalten. Wichtig dabei ist nur, dass die Aufgabe in einer anderen Farbe gekennzeichnet ist. Etwa in Rot.

Bitte die Mitglieder deines Teams, wirklich alles als Aufgaben zu erfassen.

Hier einige Beispiele:

• Fehlerbehebungen: Wenn etwa ein Fehler in der Produktionsumgebung auftritt und dieser sofort behoben werden soll.
• Unterbrechungen: Zum Beispiel, wenn jemand vom Support kurz einen Entwickler um Hilfe bittet.
• Workshops: Zum Beispiel, wenn ein Entwickler an einem Anforderungsworkshop für ein neues Projekt teilnimmt.
• Meetings: Wenn beispielsweise jemand aus dem Team ein Einzelgespräch mit seiner Führungskraft hat.

Während des Sprints solltet ihr diesen Aufgaben keine gesonderte Aufmerksamkeit widmen. Wartet damit bis zur Sprint-Retrospektive. In der Retrospektive analysiert ihr den letzten Sprint auf Basis dieser Daten.

Hier einige Fragen, die euch helfen, tiefere Erkenntnisse zu erhalten:

• Wie können wir die Aktivitäten thematisch gruppieren?
• Welche ungeplanten Aktivitäten sind wiederkehrend?
• Welches Verhältnis besteht zwischen geplanter und ungeplanter Arbeit im Sprint?

Aus meiner Erfahrung liefert die letzte Frage schockierende Einsichten in die Arbeit im Sprint. In mehr als einem Team war die Anzahl der geplanten Arbeiten geringer als die Anzahl der ungeplanten Arbeiten. Was erklärte, warum das Team zwar jede Minute im Sprint beschäftigt war, aber das Sprint-Ziel am Ende doch nicht erreicht hat.

Diese Vorgehensweise liefert dir ein absolutes Verhältnis zwischen geplanter und ungeplanter Arbeit. Wenn du die Arbeit im Sprint noch besser verstehen willst, dann empfehle ich dir das dritte Vorgehen:

Problem 3: Keine Daten, wann Arbeit wirklich fertig ist

Mit der letzten Methode hast du einen Anhaltspunkt, warum Arbeit länger braucht als erhofft und Fortschritt ausbleibt.

Dies kannst du mit folgendem Vorgehen noch besser verstehen. Für jeden Eintrag aus dem Product Backlog, der im Sprint bearbeitet werden soll, musst du dazu drei Daten erfassen:

• Startdatum: Wann wurde die Arbeit am Eintrag begonnen? Also wann wird der Eintrag von der „To-do“- in die „Doing“-Spalte gezogen?
• Enddatum: Wann wurde der Eintrag abgeschlossen? Also wann ist er in der „Done“-Spalte?
• Cycletime: Nachdem ein Eintrag die „Done“-Spalte erreicht hat, hältst du auf dem Eintrag fest, wie lange seine Bearbeitung gedauert hat, indem du das Startdatum vom Enddatum abziehst. Als Resultat erhältst du die Zeit der Bearbeitung in Tagen. Diese Zeit wird als „Cycletime“ bezeichnet.

Hierzu noch zwei Bemerkungen zu diesem Vorgehen:

• Betrachte nur Einträge des Product Backlogs und keine Aktivitäten, diese Einträge umzusetzen.
• Werden Einträge in einem Sprint nicht fertig, ziehen sich also über mehrere Sprints, dann verfolge sie so lange, bis die Arbeit abgeschlossen wird.

Am Ende des Sprints oder nach einigen Sprints kannst du die „Cycletime“-Daten der Einträge verwenden. Diese Daten dienen dann als Grundlage für eine Sprint-Retrospektive.

Hier einige Fragen, die dein Team gemeinsam in dieser Retrospektive beantworten kann:

• Welche Einträge wurden am schnellsten fertiggestellt und welche haben am längsten benötigt?
• Was ist die durchschnittliche Bearbeitungszeit eines Eintrags des Product Backlogs?
• Was können wir unternehmen, damit die Einträge früher fertig werden?

Mit dieser Retrospektive erhaltet ihr Einsichten in euren Arbeitsprozess. Sie ermöglicht euch auch, präziser die Frage zu beantworten, wie lange es dauert, bis Arbeiten abgeschlossen werden. Die Beantwortung dieser Frage hilft, den Fortschritt deines Teams sichtbar zu machen.

Wie du sehen kannst, verfolge ich bei der Lösung dieser Probleme immer die gleiche Strategie:

Ich versuche, einen Weg zu finden, um das Problem und dessen negative Auswirkungen sichtbar zu machen. Dann hoffe ich darauf, dass das Team zur gleichen Einsicht kommt und Maßnahmen zur Lösung ergreifen will. Bei der Umsetzung dieser Maßnahmen kann ich das Team dann wieder unterstützen.

Wenn das Team keine Maßnahmen ergreifen will, dann gibt es dafür zwei Gründe:

• Das Problem ist kein wirkliches Problem für das Team.
• Ich konnte das eigentliche Problem nicht wirklich sichtbar machen.

Im letzten Fall versuche ich, die Auswirkungen auf eine andere Art und Weise aufzuzeigen.

Dieses Vorgehen macht für mich die „dienende“ Haltung eines Scrum Masters aus.