„Lasst alles stehen und liegen! Diese Anforderung muss bis morgen erledigt sein.“
Dieser Satz lässt jeden Scrum Master zusammenzucken.
In den letzten Jahren hörte ich ihn mehrfach von Geschäftsführern. Die Konsequenzen für das Team liegen auf der Hand: Das Sprintziel ist gefährdet, die Velocity für diesen Sprint im Keller und die Laune der Entwickler steigt nicht unbedingt. Natürlich ist nicht jede Unterbrechung so drastisch und offensichtlich. Häufig schleichen sich Unterbrechungen verdeckt an. Nur ein Entwickler oder Mitarbeiter des Vertriebs oder Supports wird angesprochen:
„Könntest du mir kurz bei einer Anfrage helfen? Dauert nicht länger als eine Stunde. Versprochen.“
Wir sind uns einig, dass eine einmalige Unterbrechung dieser Art kein Grund zur Sorge ist.
Häufig passiert es allerdings mehrfach. Da nur einzelne Personen im Team angesprochen werden, bekommt es auch niemand so wirklich mit. Im Sprint-Review kam es dann aber heraus. Die Stakeholder beschweren sich, dass ihre Anforderung nicht fertig ist, obwohl im Sprint daran gearbeitet wurde. Der Qualitätsmanager möchte wissen, warum es für das neue Feature weniger Testfälle als bisher gibt. Die Führungskraft ist mit der Velocity nicht mehr zufrieden und bittet den Scrum Master zum Gespräch unter vier Augen.
In dieser Situation willst du nicht stecken. Glaub mir.
Wie kannst du eine solche Situation verhindern?
Das erfährst du in diesem Artikel.
Ich werde dir die drei häufigsten Hindernisse vorstellen, die in der Vergangenheit in meinen Teams dazu geführt haben, dass das Team immer langsamer wurde und hinter den Erwartungen der Stakeholder zurückblieb. Darüber hinaus verrate ich dir auch, wie du vorgehen kannst, wenn du diese Hindernisse aufdecken und überwinden willst.
Das Hindernis vom Anfang lautet:
Hindernis #1: Häufige Unterbrechungen
Für mich war damals das Sprint-Review ein Weckruf.
Den Vorwurf, dass unser Team immer langsamer wird, wollte ich nicht auf mir sitzen lassen. Gleichzeitig hatte ich keine Argumente, ihn zu entkräften. Die Tatsachen waren gegen mich. Der Rückgang der Velocity von 45 Punkten auf 33 Punkte war unbestritten.
Deshalb fing ich an, alle Unterbrechungen zu protokollieren.
Mein Ziel war es, die Unterbrechungen zu sammeln, auszuwerten und die Auswirkungen davon sichtbar zu machen. Dazu nutzte ich eine Tabelle mit diesen Spalten:
- Datum: Datum der Anfrage
- Anfrage: Beschreibung der Anfrage
- Quelle: woher die Anfrage stammt (z. B. Vertrieb, Support, anderes Team usw.)
- Teammitglieder: die Mitglieder unseres Teams, die an der Anfrage arbeiten
- Geschätzter Aufwand: die geschätzte Zeit, die für die Bearbeitung der Anfrage veranschlagt wurde
- Tatsächlicher Aufwand: die tatsächlich aufgewendete Zeit bis zum Abschluss der Anfrage
Hier ein Beispiel der Tabelle:
Wie kannst du die Tabelle nutzen?
Jetzt muss ich dich leider einer Illusion berauben:
Wenn du glaubst, dass dir diese Zahlen bereits helfen, damit dein Team nicht mehr so häufig unterbrochen wird, dann muss ich dich enttäuschen. Nüchtern betrachtet gibt es kein Problem. Angenommen, ein Team wird 28 Stunden unterbrochen. Bei 400 verfügbaren Stunden pro Sprint ist das meistens kein Problem.
Deshalb musst du eine Sprache finden, die die Stakeholder sprechen.
Hier zwei Beispiele, wie ich vorgegangen bin:
Beispiel 1: Tatsächlichen Aufwand verwenden
Du fragst dich bestimmt bereits:
Warum habe ich sowohl den geschätzten als auch den tatsächlichen Aufwand in die Tabelle aufgenommen?
Ursprünglich hatte ich das nicht. Allerdings habe ich gemerkt, dass es mir im Gespräch mit den Stakeholdern vom Vertrieb half, sie damit zu konfrontieren, was „nur mal kurz“ in Wirklichkeit bedeutet: zum Beispiel einen ganzen Arbeitstag.
Beispiel 2: Einsatz von Ressourcen berechnen
In Unternehmen gibt es eigentlich nur zwei Ressourcen: Zeit- und Geldeinsatz.
Deshalb: Wenn du mit der Zeit kein Gehör findest, dann berechne den Geldeinsatz. Was meine ich damit? 28 Stunden Unterbrechungen klingen nicht viel. Aber wie klingen 4.200 Euro? Hierzu habe ich die Anzahl der Stunden mit den üblichen Kosten eines Softwareentwicklers pro Stunde (150 Euro) multipliziert. Und hierbei habe ich den Zeitverlust durch Kontextwechsel noch nicht eingerechnet.
Dieser wären nochmals weitere 20 %.
Was kannst du davon erwarten?
Erstmal keine Wunder.
Die Gespräche mit Vertrieb und Management haben nicht dazu geführt, dass es keine Unterbrechungen mehr gab. Allerdings konnte ich bewirken, dass von nun an die Anfragen zuerst an den Product-Owner gestellt wurden und nicht direkt an die Entwickler. Das zeigte sich schnell in der Velocity.
Und ich konnte auf den Vorwurf „das Team wird immer langsamer“ nun mit Daten reagieren und begründen, warum das so ist.
Nun zum nächsten Hindernis:
Hindernis #2: Fehlende Fähigkeiten
Unterbrechungen sind eine schwierige Art von Hindernissen.
Da sie ungeplant auftreten, sind sie am schwersten zu beheben. Es gibt aber auch Hindernisse, die mit Ansage kommen.
Du erkennst sie vielleicht daran:
- Kommt es im Team zu Engpässen, weil nur eine Person in der Lage ist, die Arbeit zu testen?
- Blockiert ein Entwickler das Team, indem er etwas implementiert, worauf alle anderen warten?
- Beginnen andere Mitglieder im Team damit, irgendwelche belanglosen Aufgaben anzufangen, nur weil sie nichts anderes zu tun haben?
Dies deutet alles auf ein Hindernis hin, wovor uns bereits der Scrum Guide warnt, und deshalb sage ich auch, dieses Hindernis kommt mit Ansage:
„Scrum Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“
Fehlt es dem Team an Fähigkeiten oder sind die Fähigkeiten nicht breit im Team gefächert, dann wird es zu Verzögerungen kommen.
Wie erkennst du Engpässe in den Fähigkeiten?
Hierfür hat sich für mich eine Fähigkeitsmatrix bewährt.
Hier ein Beispiel von einem meiner Teams:
Wenn du dir die Matrix ansiehst, welche Engpässe kannst du erkennen?
Ein Engpass ist die Fähigkeit „UX Design“. Sollte Susi im Lotto gewinnen und entscheiden, morgen nicht mehr zur Arbeit zu erscheinen, dann würde die UX-Arbeit liegen bleiben und die Einträge des Sprint-Backlogs, die UX-Arbeiten erfordern, könnten nicht mehr abgeschlossen werden. Wie du sehen kannst, macht diese Matrix weitere Hindernisse sichtbar. Werden diese nicht aufgelöst, ist es nur eine Frage der Zeit, bis sich dies in der Velocity oder Cycle-Time des Teams widerspiegelt.
Was uns zur Frage führt:
Wie kannst du Engpässe in den Fähigkeiten beheben?
Hierfür gibt es kein Patentrezept.
Von Neueinstellungen über Umstrukturierungen des Teams bis hin zu Pair-Programming ist alles möglich.
Ich empfehle dir, dieses Hindernis zum Gegenstand der nächsten Sprint-Retrospektive zu machen. Dort kannst du dir mit dem Team erste Maßnahmen überlegen, um das Hindernis zu beheben.
Im Beispiel von oben hat sich das Team damals auf drei Maßnahmen geeinigt:
- Susi darf kein Design mehr machen, sondern nur noch John, Max und Rosi dabei anleiten.
- John soll eine Schulung in diesem Bereich machen. Der Scrum Master kümmert sich darum.
- Im nächsten Sprint arbeiten wir unbedingt an einer Story, die Design enthält, damit wir gleich mit dem Wissenstransfer beginnen.
Woran erkennst du, dass diese Maßnahmen hilfreich sind?
Langfristig sollten die Velocity oder Cycle-Time dann nicht mehr weiter fallen.
Tun sie es doch, dann könnte ein weiteres Hindernis vorliegen:
Hindernis #3: Zu viele Abhängigkeiten
Engpässe in den Fähigkeiten sind ein Beispiel für ein besonderes Hindernis:
Abhängigkeiten.
Fehlende Fähigkeiten im Team führen zu Abhängigkeiten. Eine User-Story, die Arbeit am Design erfordert, kann erst angefangen werden, wenn Susi zur Verfügung steht. Diese ist aber leider nicht die einzige Quelle von Abhängigkeiten. Es kann auch zu Abhängigkeiten innerhalb der Bearbeitung von User-Stories kommen, etwa wenn mehrere Teams zusammen an einem Produkt arbeiten. Solche Abhängigkeiten lassen sich nicht immer verhindern. Allerdings führen sie unerkannt dazu, dass dein Team langsamer wird.
Deshalb: Decke sie auf.
Wie kannst du teamübergreifende Abhängigkeiten sichtbar machen und lösen?
Gehe hierfür in drei Schritten vor:
- Diskutieren
- Visualisieren
- Koordinieren
Betrachten wir die drei Schritte im Detail:
Schritt #1: Diskutieren
Sind mehrere Teams nötig, um eine neue Version der Software bereitzustellen?
Dann gilt es, mögliche Abhängigkeiten früh zu besprechen. Hierfür können Mitglieder deines Teams an Refinement- oder Planning-Meetings der anderen Teams teilnehmen. Oder du berufst ein dediziertes Meeting ein. Lade dazu dann Mitglieder aus allen Teams ein, um mögliche Abhängigkeiten zu diskutieren.
Probleme nur zu diskutieren, reicht nicht aus.
Deshalb:
Schritt #2: Visualisieren
Visualisiere die Probleme auch.
Dadurch stellt sich schneller ein gemeinsames Verständnis ein und auch Personen, die nicht am Meeting teilnehmen konnten, erhalten die erforderlichen Informationen.
Nutze hierzu am besten ein Cross-Team-Refinement-Board:
Auf dem Board siehst du Einträge des Product-Backlogs, an denen die drei Teams in den nächsten Sprints arbeiten wollen. Die grauen Pfeile symbolisieren die Abhängigkeiten zwischen den Einträgen.
Schritt #3: Koordinieren
Das Cross-Team-Refinement-Board ermöglicht einen Überblick über alle bekannten Abhängigkeiten.
Jetzt kann versucht werden, die Abhängigkeiten zu eliminieren.
Einige Ideen hierzu:
- User-Stories können vielleicht zwischen den Teams getauscht werden.
- User-Stories können neu geschnitten werden.
- Vielleicht kann die technische Lösung neu gedacht werden, damit nur ein Team für die Umsetzung nötig ist.
- Oder ein Mitglied eines Teams kann temporär in ein anderes Team wechseln.
Ist eine vollständige Eliminierung einer Abhängigkeit nicht möglich, dann zumindest die Koordination. Die stellst du sicher, indem du täglich einen kurzen Termin zur Koordination der Arbeit zwischen den Teams ins Leben rufst.
Woran erkennst du, ob du Abhängigkeiten reduzieren konntest?
Wie gut du deinen Teams helfen kannst, Abhängigkeiten zu diskutieren, zu visualisieren und am Ende auch zu eliminieren, lässt sich an der Cycle-Time ablesen.
Denn:
Abhängigkeiten machen sich immer in Verzögerungen bemerkbar.
Werden ungeplante Unterbrechungen, Engpässe bei Fähigkeiten im Team oder Abhängigkeiten zwischen Teams nicht entdeckt und behoben, dann führen diese Hindernisse dazu, dass Scrum Teams immer langsamer werden.
Dies zu verhindern, ist eine Aufgabe eines Scrum Masters.
Willst du noch mehr über die Aufgaben eines Scrum Masters erfahren und weitere Methoden und Techniken lernen, um diese effektiv zu erfüllen?
Dann besuche unser nächstes „Professional Scrum Master – Advanced“-Training. Dort helfen Marc Kaufmann und ich dir, alle Facetten der Scrum Masterei zu verbessern.