Zusammenarbeit sichtbar machen

Die Zusammenarbeit der Developer im Daily Scrum ist ein Erfolgsfaktor von Scrum. Die Grad der Zusammenarbeit kann mit diesem einfachen Hilfsmittel gemessen werden und bietet damit die Möglichkeit zur Verbesserung.

Was ist das Problem?

“Ich”-Perspektive verhindert Zusammenarbeit

Die Developer* im Scrum-Team sind in einer Arbeitskultur geprägt worden, welche nicht die Gruppe, sondern die Einzelperson in den Mittelpunkt stellt. Führungskräfte und Personaler sind mit dieser Auffassung groß geworden und haben entsprechende Prozesse entwickelt und in Betrieb genommen, die diese Dysfunktion weiterhin am Leben halten. Persönliche Zielabsprachen und Performance-Bewertungen des Einzelnen sind Auswirkungen dieser Denkweise. Deshalb sind viele Developer in einer agilen Transformation geneigt, weiterhin ihre persönliche Arbeit zu optimieren und permanent neue Arbeitspakete aus dem Backlog zu ziehen. So gewollt diese Arbeitsauffassung früher war, so schädlich wirkt sich diese Kultur heute im Scrum-Framework aus, denn

Scrum stellt das Team und die gemeinsame Leistung in den Mittelpunkt.

Dies bedeutet aber für viele Mitglieder von Scrum-Teams eine neue Arbeitsauffassung anzunehmen. Es kommt sogar eine Veränderung der Arbeitskultur gleich.

Konkret haben viele Scrum-Teams Probleme beim Abbrennen des Sprint Backlogs. Das Sprint-Backlog besteht aus den ausgewählten Product Backlog Einträgen, die zum Erreichen des Sprintziels notwendig sind. Auch wenn das Sprintziel erreicht werden kann, ohne dass alle Sprint Backlog Einträge getan wurden, liegt hier ein anderes Problem vor: Die getane Arbeit nähert sich überhaupt nicht der Null-Linie. Im Sprint Burndown-Chart entstehen typischerweise solche Darstellungen.

Burndown Chart ohne Zielannäherung

Die Developer schliessen Sprint Backlog-Items ab, ziehen aber auch neue Themen in den Sprint (fallende und steigende Flanken). Dadurch wird die Arbeit nie weniger. Die graue Ideallinie der getanen Arbeit wird nicht erreicht. In der Wahrnehmung des Einzelnen tritt dieser negative Effekt kaum auf, weil die Arbeitstage mit steter Arbeit gefüllt sind. Ein Developer kann dadurch für sich alleine das Gefühl von hoher Produktivität haben. Insgesamt betrachtet hat das Scrum-Team aber Produktivität eingebüsst [1], weil die Optimierung nur lokal stattgefunden hat.
In der Darstellung sind am Ende des Sprints fast genau so viele Punkte nicht abgeschlossen, wie am Anfang des Sprints. Die dazugehörigen Tickets tauchen als “nicht abgeschlossen” auf dem Taskboard auf. Ggfs. fehlt der Review-Schritt, die Dokumentation oder der Test.

Weil jeder Developer eine Ich-Perspektive einnimmt, steht die Optimierung der persönlichen Arbeitsauslastung, anstatt die gemeinsame Zielerreichung bei den Betroffenen im Vordergrund.

Warum ist das Thema wichtig?

Zusammenarbeit der Developer ist ein Erfolgskriterium

Im Jahr 2021 ist Agile und Lean der Mega-Trend in der Produktentwicklung, nicht nur für Software, sondern in Zunehmenden Maße auch für Hardware. Der Kundennutzen rückt wieder in den Mittelpunkt der Unternehmensaktivitäten. Die agile Transformation ist gestartet: Viele Unternehmen und Teams sind unterwegs auf ihrem Pfad durch die Transformation. Je schneller ein Unternehmen diese Transformation durchläuft, desto größer sind seine Vorteile gegenüber den langsamen Konkurrenten. In dieser Übergangsphase von Abteilungen zu Produkt-Teams ist ein neues Denken und Handeln erforderlich. Mehr noch: Die Betroffenen, vor allem die Developer, müssen VERGESSEN und UMLERNEN.
Mehr Zusammenarbeit bedeutet, die Developer stellen mehr Arbeit an denselben Themen zur Verfügung. Die kognitiven Leistung erhöht sich. Verschiedene Herangehensweisen tragen gemeinsam zur Vollbringung der Arbeit bei. Die Team-Moral steigt. Die Entwicklung zu einem echten Team wird beschleunigt.

Wie kann das Problem behoben werden?

Als Scrum Master die Zusammenarbeit im Daily Scrum fördern

Als Scrum Master kannst du die Zusammenarbeit der Developer im Daily Scrum unterstützen, indem du den Grad der Zusammenarbeit sichtbar machst. Du verwendest ein Tabellenkalkulationsprogramm und erfasst für jedes Daily Scrum die Präsenz der Developer.

Beispiel für den 1. Donnerstag im Sprint: Wenn ein Team 7 Developer hat, im Daily aber nur 5 anwesend sind, trägst du in “Präsenz Dev-Team” für diesen Tag “=5/7” (71%) ein. Dann sprechen die Developer über Sprint Backlog Item 1. Für jeden aktiven Developer, der am Gespräch teilnimmt, gibt es 1 Punkt. Im Beispiel haben 3 der 7 Developer teilgenommen, also trägst du in “Interaktion” den Wert 3/7 (43%) ein (b).
So machst du das für jedes Daily Scrum im Sprint. Im weiteren Sprintverlauf entsteht so eine Präsenzkurve (d) der Developer und eine Interaktionskurve (a). Wenn sich beide Kurven treffen, gibt es 100% Interaktion der Anwesenden, d.h. alle haben sich eingebracht (c). Der Bereich (e) zwischen den Kurven ist das Potential der Zusammenarbeit, die das Team noch nicht ausgeschöpft hat.

Ermittlung des Grades der Zusammenarbeit mit Hilfe von Tabellenkalkulation

In der nächsten Retrospektive kannst du diese Kurve dem Team zeigen und eine Diskussion zur Zusammenarbeit anstoßen.

Warnhinweise

⚠️ Dieser Beitrag ist für erfahrene ScrumMaster gedacht. Velocity, Story Points, Burndown-Charts können in den falschen Händen viel Schaden anrichten und das Scrum-Framework diskreditieren. Die Scrum-Values sind immer zu beachten.
⚠️ Ein hoher Interaktionsgrad bedeutet nicht, dass die Developer fokussiert am wichtigsten Sprint-Backlog Eintrag arbeiten, noch das die Zusammenarbeit ausserhalb des Daily Scrum auch weiterhin stattfindet.

Links

[1] Lean Software Development, M. und T. Poppendiek. Siehe Local Optimization, S. 157. Dies ist nicht nur für Software-Entwicklung zutreffend.


*Als Developer werden alle Personen nach aktuellem Scrum-Guide bezeichnet, die am Sprint Backlog arbeiten. (Entwickler, Tester, UX und alle anderen Professionen).

Schreibe einen Kommentar

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