Scrum Smells – oder: Schlechte Angewohnheiten

Vor einiger Zeit bin ich über ein interessantes Paper von Mike Cohn gestolpert (siehe hier), in dem er eine Liste von „Scrum Smells“ zusammenstellt. Darunter versteht er Anhaltspunkte, die darauf hindeuten, daß etwas in einem Scrum-Projekt nicht in die richtige Richtung läuft. Das muß zwar nicht direkt ein Problem bedeuten, verdient aber eine genauere Betrachtung. Diese Liste, ergänzt mit eigenen Gedanken, möchte ich daher nun gerne aufgreifen um auch hier mal zu einer Übersicht über „schlechte“ Verhaltensweisen in einem Scrum-Projekt zu kommen:

Rhythmusverlust

• Symptom: Sprints haben unterschiedliche Länge
• Diskussion: Sprints sind so etwas wie der „Herzschlag“ eines Scrum-Projekts. Ähnlich dem biologischen Herzschlag ist es nämlich auch hier von Vorteil, wenn es regelmäßig schlägt. Dadurch soll ein gewisser natürlicher Rhythmus ins Projekt gebracht werden, angefangen von der Planung, über die täglichen Statusmeetings, bis hin zum Sprint Review. Nicht zuletzt sollen die Teams auch ein Gefühl dafür kriegen, wieviel Arbeit sie in einem Sprint typischerweise schaffen. Dies ist natürlich schwierig, wenn Sprints unterschiedlich lang sind. Der Erfahrung nach werden Teams dann eher vorsichtig in ihren Schätzungen, wodurch sie insgesamt weniger Arbeit erledigen, als wenn Sprints immer dieselbe Länge hätten.

Sprechende „Chickens“

• Symptom: Chickens wird erlaubt, im täglichen Statusmeeting zu sprechen
• Diskussion: Die Unterscheidung zwischen Pigs und Chickens geht zurück auf einen Cartoon (siehe hier). Pigs sind danach alle, die direkt am Projekt beteiligt sind (Product Owner, Scrum Master und Team). Chickens all diejenigen, die ein sonstiges Interesse am Projekt haben (etwa User, Kunden oder Manager). Der normale Rahmen, in denen Chickens Rückmeldungen zum Projekt geben können, ist das Sprint Review Meeting. In den anderen Meetings ist es ihnen zwar jederzeit erlaubt daran teilzunehmen (Transparenz ist bei Scrum ein sehr wichtiges Thema), nicht aber zu sprechen. Hier einen Präzedenzfall zu schaffen ist problematisch. Denn so sinnvoll und passend ein Kommentar zum jetzigen Zeitpunkt auch sein mag, zu einem späteren Zeitpunkt muß dies nicht unbedingt hilfreich sein. Hier eine Linie zu ziehen ist jedoch schwierig, weswegen getreu dem Slogan „Wehret den Anfängen“ man am besten an der ursprünglichen Regel festhalten sollte.

Abwesende „Pigs“

• Symptom: Teammitglieder erscheinen nicht zum täglichen Statusmeeting
• Diskussion: Das tägliche Statusmeeting ist eins der wichtigsten Artefakte in Scrum. Es dient u.a. auch als Grundlage der Selbstorganisation des Teams. und ist explizit nicht als Statusupdate an den Scrum Master gedacht (obwohl er diese Informationen natürlich gerne für seine Zwecke benutzen kann), sondern dient vor allem dem Team selbst. Einerseits als fällt es hier ziemlich schnell auf, wenn ein Teammitglied Probleme bei seiner Arbeit hat („Hast du daran nicht schon gestern gearbeitet?“). Andererseits soll jeder im Team immer wissen, was der andere tut, um ihn möglichst gut bei seiner Arbeit unterstützen zu können („Ich hatte dieses Problem auch schon mal. Hier meine Lösung von damals.“). Natürlich ist es in der heutigen Zeit mit ihren flexiblen Arbeitszeiten nicht immer einfach einen Termin zu finden, an dem jedes Teammitglied anwesend ist (und wir alle wissen, daß gerade Softwareentwickler in dieser Hinsicht etwas schwierig sind“). Jedoch sollte ab einem gewissen Zeitpunkt auch der letzte Spätaufsteher anwesend sein. Bei uns hat sich übrigens 11:45 bewährt. Der aufkommende Hunger sorgt hier nämlich fast automatisch für ein kurzes Meeting :). Tauchen nun einige Teammitglieder mit einiger Regelmäßigkeit nicht zum Statusmeeting auf, so funktioniert der teaminterne Informationsaustausch nicht mehr so gut wie gewünscht, was sich durchaus auf die Produktivität auswirken kann. Das Team könnte dadurch weniger schnell vorwärts kommen als gedacht. Deswegen sollte der Scrum Master unbedingt darauf achten, daß das Team vollzählig erscheint. Ausnahmen sind selbstverständlich okay (z.B. bei Schulung, Krankheit etc.), sollten allerdings nicht zu Regel werden.

Dauerhafte Signaturen

• Symptom: Die wilden Fluktuationen auf den Burndown-Charts der ersten Sprints setzt sich auch in späteren Sprints noch fort
• Diskussion: Wie Ken Schwaber und Mike Beedle im Buch „Agile Software Development with Scrum“ erläutert, hat jedes Team eine eigene Signatur. Manche nehmen sich zuerst zu viel Arbeit vor und streichen später wieder etwas raus, andere unterschätzen ihre Geschwindigkeit und fordern im Laufe des Sprints Aufgaben nach und so weiter. Nach einiger Zeit, wenn ein Team sich seiner Sache sicherer wird, und auch die Schätzungen genauer werden, sollte sich dieses Verhalten jedoch stabilisieren. Wenn nicht, so deutet das darauf hin, daß ein Team nicht aus seinen Fehlern lernt. Jedenfalls sollte der Scrum Master diesem Hinweis nachgehen und z.B. in einem der nächsten Retrospektiven ansprechen.

Der Scrum Master weist Arbeit zu

• Symptom: Die Arbeitspakete werden vom Scrum Master zugewiesen, anstatt daß sich die Teammitglieder sich diese selber aussuchen.
• Diskussion: Die Idee hinter Scrum sind ja genau selbstorganisierte Teams. Die Selbstorganisation soll dafür sorgen, daß das Team sich verantwortlich fühlt für das Projektergebnis und sich seine Arbeit selbst einteilen kann. Dies wird natürlich unterlaufen wenn ein Scrum Master im Sinne eines traditionellen Projektmanagers Arbeit austeilt. Sollte eine Organisation tatsächlich auf dieser Arbeitsweise bestehen, so ist es vielleicht besser, Scrum gar nicht erst einzuführen. Die hinter Scrum und allen anderen agilen Methoden stehende Vertrauenskultur passt dann wohl nicht zur jeweiligen Firmenkultur. In diesem Falle würde ich eher ein dokumentengetriebenes Vorgehensmodell empfehlen (V-Modell XT?)

Sprint-Planung wird nur von einem Teil des Teams gemacht

• Symptom: Am Sprint Planning Meeting nimmt nur ein Teil des Teams teil.
• Diskussion: Auch dies ist schlecht für die Selbstorganisation und die Identifikation des Teams mit dem Projektziel. Dadurch, daß das gesamte Team an der Sprint-Planung teilnimmt soll u.a. der Eindruck vermieden werden, daß dies einer besonderen Auszeichnung gleichtkommt. Dies birgt aber die Gefahr, daß der ausgegrenzte Teil des Teams sich auch bei der Umsetzung nicht mehr voll einbringt. Bei Scrum gibt es ganz grundsätzlich nur „das Team“. Alle Teammitglieder sind als gleich anzusehen. Es gibt keine Mitglieder, die noch gleicher sind :).

Ein Team von Spezialisten

• Symptom: Es gibt klare Beschreibungen für die Positionen im Team, z.B. Architekt, Entwickler, Tester, DB-Administrator etc.
• Diskussion: Scrum-Teams sollen sich gemeinsam für den Erfolg einsetzen. Das wird u.a. dadurch erreicht, daß es keine feste Aufgabenverteilung gibt, sondern prinzipiell jeder jeden Task übernehmen kann. Führt man nun feste Aufgaben ein, so läuft man Gefahr, daß sich die Teammitglieder nur noch für ihren eigenen Bereich verantwortlich fühlen, nicht aber für das große Ganze. So könnte sich etwa ein Entwickler fragen, wozu er seinen Code überhaupt noch testen soll, wenn es ja einen spezialisierten Tester im Team gibt, der extra hierfür eingestellt wurde. Das heißt natürlich nicht, daß ein erfolgreiches Scrum-Team nur aus Generalisten bestehen darf (meistens wird man auch gar nicht genügend davon finden). Man sollte hier jedoch noch mehr als sonst darauf achten, daß sich das Team gemeinsam verantwortlich fühlt, und wenn es nur heißt, daß ich einem Spezialisten bei Bedarf Arbeit abnehme, damit er sich um ein dringendes Problem kümmern kann.

Soweit für heute nun die Übersicht über schlechte Angewohnheiten in Scrum. Bei Gelegenheit werde ich sie nochmal erweitern.
BFI