Ist jeder im Scrum Team beschäftigt, aber am Ende des Sprints ist nichts fertig? Meine bewährte Strategie für mehr Team-Performance

Führt bessere Planung und Aufteilung der Arbeit zu mehr Team-Performance?

Nein, denn die Arbeit zur Lösung eines komplexen Problems, wie die Entwicklung eines Features mit voneinander abhängigen Aufgaben, verteilt sich selten gleichmäßig auf die Personen und Fähigkeiten in einem interdisziplinären Team. Da sich die Arbeitsbelastung der einzelnen Personen von Feature zu Feature ständig ändert, sind Scrum Teams sehr anfällig für Engpässe.

Allerdings bestimmen Engpässe den Durchsatz unseres Teams!

Wollen wir also die Performance des Teams verbessern, müssen wir diese Engpässe beheben. Hier mein Ansatz, welcher sich in den letzten Jahren bereits bei unterschiedlichen Scrum Teams bewährt hat. 

Visualisierung des Arbeitsablaufs, um Engpässe zu entlarven

 

In der Softwareentwicklung sind Fortschritt oder Stillstand nur schwer zu beobachten und zu beurteilen.

Das ist ein Problem, denn wir können Engpässe nur entlarven, wenn wir erkennen, an welcher Stelle der Entwicklungsprozess ins Stocken gerät.

Wir können dieses Problem lösen, indem wir die Arbeit visuell repräsentieren. Aus meiner Erfahrung reicht ein einfaches Scrum-Board mit den Spalten „to-do“, „in Arbeit“ und „bearbeitet“ nicht aus, um Engpässe zu entlarven. Hierfür müssen wir den Fluss der Arbeit abbilden. Gute Dienste leistet hier ein Board, welches in den Spalten die Aktivitäten des Arbeitsablaufs auflistet. Wichtig ist, dass die Aktivitäten den Lebenszyklus der Arbeit widerspiegeln sollten und nicht die Rollen der Teammitglieder, die zur Fertigstellung der Arbeit beitragen. Um den tatsächlichen Stand der Arbeit zu beurteilen, muss das Board regelmäßig aktualisiert werden. 

Hier ein Beispiel:


Im Beispiel können wir unschwer erkennen, dass sich die Arbeit in der Spalte „Entdeckung“ aufstaut. Wir haben also einen Engpass entlarvt.

Berechnung des Bus-Faktors, um den Engpässen in Zukunft aus dem Weg zu gehen

 

Die Berechnung des Bus-Faktors gibt uns Auskunft darüber, wie problematisch der Engpass ist. 

Den Bus-Faktor können wir über eine einfache Skill-Matrix des Teams bestimmen. Ein Stern in der Matrix bedeutet, dass jemand diese Fähigkeit solide beherrscht und ein Buch bedeutet, dass er nur rudimentäre Kenntnisse besitzt.

Sind in einer Spalte weniger als zwei Sterne zu finden, bedeutet dies, dass der Bus-Faktor kleiner als zwei ist. Das heißt: Sollte jemand mit diesen Fähigkeiten vom Bus überfahren werden, gibt es keinen anderen, der die Aufgabe erledigen kann.

Korreliert jetzt ein ermittelter Engpass im Board mit einem Bus-Faktor von weniger als zwei in der Skill-Matrix, handelt es sich um einen problematischen Engpass. Diesen kann das Team langfristig nur auflösen, indem es diese Fähigkeit im Team entwickelt. 

In unserem Beispiel erkennen wir, dass das Team einen schwerwiegenden Engpass im Bereich „Design“ hat.

In „Scrum“ arbeiten, so wie es eigentlich in Scrum vorgesehen ist

 

Um die fehlenden Fähigkeiten aufzubauen, könnten wir ein Teammitglied auf eine Schulung schicken. Allerdings eignet sich aus meiner Sicht nichts besser, um ständige Weiterentwicklung im Team zu fördern, als Mob-Programming.

Mob-Programming hat folgende unschlagbare Vorteile:

  • Es ermöglicht den Teammitgliedern, „hands on“ zu lernen.
  • Kein Wissenstransfer ist nötig, somit entsteht auch kein Wissensverlust.
  • Keine zusätzlichen Code-Reviews sind mehr nötig.
  • Collective-Code-Ownership wird zur Norm.
  • Es führt zu qualitativ hochwertigen Entscheidungen, da jeder weiß, was vor sich geht.
  • Es liefert einen optimalen Arbeitsfluss, da das Team nur an einem Feature gleichzeitig arbeitet

Aus meiner Sicht kommt Teamarbeit in Form von Mob-Programming am besten an die ursprüngliche Bedeutung des Wortes Scrum heran – wie wir im folgenden Bild erkennen können. 

Setzung eines Ziels für den Sprint, um Team-Performance an die erste Stelle zu rücken


Den Arbeitsfluss zu visualisieren und Skill-Engpässe mit Mob-Programming zu begegnen, führt noch nicht automatisch zu einem Team.

Ein Team unterscheidet sich von einer Gruppe dahin gehend, dass die Mitglieder ein gemeinsames Ziel vereint. In der Vergangenheit musste ich leider häufig beobachten, dass Teammitgliedern nur wichtig war, dass sie ihre eigene Arbeit erledigt haben. Die Wahrheit, die sie aber noch einsehen mussten, lautet: 

Gutes Design, guter Code, gute Tests allein führen nicht zum Erfolg. Produkte sind nur dann erfolgreich, wenn das Team die Kombination aus Design, Code und Test findet, die die Kunden begeistert. 

Design, Code oder Tests sind für sich genommen wertlos!

Ein Sprint-Ziel ist aus meiner Sicht die beste Möglichkeit, um diese Tatsache in den Vordergrund zu stellen und somit den Teamerfolg über den individuellen Erfolg zu stellen. 

Ich hoffe, meine bewährte Strategie hilft auch dir, die Einsicht, die ich über die Jahre erhalten habe, in die Tat umzusetzen: Nur weil jeder im Team beschäftigt ist, bedeutet das nicht, dass wir als Team auch performen. Performance eines Scrum Teams sollte nicht daran gemessen werden, wie viel Arbeit angefangen wird, sondern wie viel davon abgeschlossen wird.

Simon Flossmann
Simon Flossmann
Als Professional Scrum Trainer bei Scrum.org hilft Simon Scrum Masters, Product Ownern und Agile Leaders, Scrum effektiv einzusetzen, um agiler zu werden.

Noch mehr lernen

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Ich freue mich, Dich kennenzulernen

Pascal Gugenberger

Pascal

Ich freue mich auf unser Gespräch!

Such Dir einfach einen Termin aus und wir quatschen.

Weiterleitung an Calendly, siehe Datenschutzerklärung.

Lust auf Input?

Newsletter

Melde Dich an und erhalte regelmäßig spannende Beiträge!