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.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie du deinem Team zu mehr Performance verhilfst, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.