Team arbeitet nebeneinander statt miteinander

In einem Team, in dem ich als Entwickler tätig war, war Scrum als WaterScrumFall implementiert worden. Eine Stilblüte dieser Implementierung war, dass die Entwickler im zweiten Teil der Sprintplanung alle einzeln an ihre Rechner liefen und dort jeder für sich alleine die “eigenen” Backlog-Einträge durchplante, mit Aufgaben versah und jede der Aufgaben in Stunden schätzte.

Dann traf man sich wieder, wenn alle fertig geschätzt hatten und eventuell schacherte man noch Aufgaben hin und her. Es wurde typischerweise nicht miteinander an Aufgaben gearbeitet, sondern es wurden nur in sich abgeschlossene Pakete getauscht und rücksichtsvoll darauf gewartet, dass sie fertig waren. Sprintziele wurden generell nicht definiert, implizit war immer die Summe Backlogeinträge, die in den Sprint aufgenommen wurden, das Ziel.

Solche fehlgeleiteten Implementierungen sind relativ häufig anzutreffen. Sie gehen sehr weit an den Prinzipien vorbei, auf denen Scrum aufbaut, und das Resultat ist in keinster Weise Scrum. Ein so aufgestelltes Team kann nicht exzellent werden. Schauen wir uns mal an, was in diesem konkreten Fall so passierte.

Sprintziel: nicht dumm dastehen

Die Sprints liefen am Anfang des Projekts relativ gut – jedenfalls für diejenigen Entwickler, die gut schätzen und selbständig arbeiten konnten. Jeder war nur für seine “eigenen” Backlogeinträge zuständig und damit in erster Linie auch nur sich selbst verpflichtet. Das versteckte Sprintziel war, dass niemand im Review dumm da stehen wollte.

Spannend ist, dass sich trotzdem alle Teammitglieder gegenseitig unterstützten. Man wollte niemanden im Stich lassen und jeder half jedem aus – jedenfalls so lange, wie es die eigenen (oft weniger wichtigen) Aufgaben nicht gefährdete.

Die Backlogeinträge, die es nicht zu “Done” schafften, wurden automatisch in den nächsten Sprint gestopft. Meist ohne Diskussion, Neuplanung oder Teillieferungen. Schaffte der Entwickler, der zufällig den für den Product Owner wichtigsten Backlog Eintrag bearbeitete, seine Augaben nicht, so ging der Product Owner disbezüglich leer aus. Natürlich nicht ganz, er bekam ja andere, weniger wichtige Backlog Items geliefert. Die Enttäuschung stand ihm häufig ins Gesicht geschrieben. Ganz besonders, wenn das kurz vor einer formalen Projektinspektion geschah.

Es kam sogar einmal vor, dass es (von zwei Teams) überhaupt niemand schaffte, einen Backlogeintrag auf “Done” zu bringen. Es gab in dem Sprint kein Produktinkrement, kein Review, kein Kundenfeedback und dafür ein sehr langes Gesicht des PO und eine ebenso lange Retrospektive. Die immerhin recht produktiv war.

Einzelne Entwickler leiden

Einzelne Mitglieder im Entwicklungstem kamen mit diesem WaterScrumFall nicht klar und standen regelmäßig unter hohem Druck, den man ihnen auch ansah. Denn sie waren nicht so schnell wie der Rest im Team – dafür brachten sie wichtiges Domänenwissen in das Projekt ein.

In jedem Review war offensichtlich, wer seine Aufgaben geschafft hatte und wer “mal wieder” nicht. Dazu war dann noch die individuelle Leistung anhand der geschafften Story Points pro Entwickler vergleichbar. Klar, so darf man nicht rangehen, und ich wüsste auch nicht, dass jemand wirklich Buch darüber geführt hätte (das wäre Dark Scrum). Doch alle relevanten Daten waren in jedem Review in Form der TFS Tickets mit Namenszuordnung auf dem Projektorbild zu sehen. “Dumm dastehen” ist dann mehr als nur ein heimliches Gefühl und hat durchaus nachteilige Auswirkungen auf die Zufriedenheit und Produktivität dieser Entwickler gehabt.

Wissen und Qualität bleiben auf der Strecke

Mit der Zeit wurde das Projekt größer, komplexer und unübersichtlicher. Vor allem aber wurde es dadurch unübersichtlich, dass jeder nur an seinem eigenen Teil bastelte. Und sich nicht kontinuierlich mit den anderen Teilen beschäftigte. Wem ein Product Backlog Item für den Sprint zugewiesen war, der hatte die Verantwortung. Und niemand schaute mit drauf. Das Team war eben kein Team sondern eine Ansammlung von Individualisten.

In der Folge entstanden viele Wissensinseln: Einzelne Entwickler wussten, wofür eine bestimmte Komponente zuständig ist und wie man diese nutzt. Die einzelnen Komponenten hatte zwar jeder mal im Review gesehen, das war es dann aber auch schon. Kamen dann andere Entwickler mit diesem Teil des Projekts in Verbindung, so mussten diese Entwickler sich erst alles erklären lassen. Wurde jemand krank oder war im Urlaub, blieben oft Fragen offen und es mussten Stunden investiert werden, um sich im Quelltext einzulesen.

Dazu kam, dass die Qualität einzelner Komponenten trotz Codereviews fraglich war: Da niemand groß über seinen Tellerrand blickte, kochte in der Folge auch jeder ein mehr oder weniger individuelles Qualitätssüppchen.

Was sind die Intentionen des Scrum Guide dazu?

Ich schaue an solchen Punkten immer wieder gerne im Scrum Guide, um mir auch die Hintergründe zu vergegenwärtigen, warum etwas gemacht werden soll. Der Scrum Guide sagt zur Planung:

Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams.

Der Scrum Guide

Im Englischen Originaltext wird hier das Wort collaborative verwendet, das wenig Zweifel offen lässt, dass die Übersetzung in gemeinschaftlich eben miteinander zusammen meint und nicht nebeneinander.

Tatsächlich gibt es keine konkreten Angaben im Scrum Guide, wie zusammengearbeitet werden soll. Dies ist absichtlich offen gehalten, damit jedes Team frei ist, seinen eigenen Weg zu finden. Zum Daily Scrum finden sich jedoch wieder deutliche Angaben, dass miteinander und nicht nebeneinander gearbeitet werden soll:

Das Entwicklungsteam plant dabei die Arbeit für die nächsten 24 Stunden. Es überprüft die Arbeitsergebnisse seit dem letzten Daily Scrum und prognostiziert die im Sprint bevorstehende Arbeit, um die Zusammenarbeit und Leistung des Teams zu optimieren.
[…]
Das Entwicklungsteam sollte Tag für Tag im Blick haben, wie es als selbstorganisiertes Team zusammenarbeiten möchte, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zum Sprintende zu liefern.

Der Scrum Guide

Damit ist eigentlich alles gesagt. Denn das Team als Ganzes ist zuständig dafür, die Arbeit täglich zu planen, sich zu organisieren und die Zusammenarbeit zu optimieren. Das Team als Ganzes soll auch die Verantwortung für das gesamte Sprint Backlog übernehmen, nicht einzelne Entwickler für Teile.

Aus Individualisten wird ein Team

Das hier geschilderte Team bestand vermehrt aus Leuten mit längerer Berufserfahrung und einer deutlichen Neigung zu einer unabhängigen Arbeitsweise. Es hat in diesem speziellen Team auch aufgrund anderer Herausforderungen im Prozess etwa ein halbes Jahr und sehr viele Anstubser in die richtige Richtung gebraucht, um das zusammenarbeiten zu etablieren – mit entsprechend häufigen Rückfällen.

Doch es hat geklappt, das Teamwork wurde massiv verbessert. Das Team hat sich in den Monaten der Umstellung neue Fähigkeiten erarbeitet, um Aufgaben miteinander zu bearbeiten. Zum Schluss konnte jeder im Team die Vorteile von gutem Teamwork sehr deutlich benennen und ein zurück zum Individualisten war unerstrebenswert.

Die Sprintziele wurden in der Folge zuverlässiger erreicht, der Product Owner und die Stakeholder waren ebenfalls zufriedener. Ein happy end!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.