8 Anzeichen, dass dein Scrum-Prozess Aufmerksamkeit braucht

[caption id="attachment_23971" align="alignright" width="240" caption="Foto: S is for Smoke von Stuart Anthony (Lizenz: CC-BY-NC-ND)"][/caption]

Scrum ist wie eine Beziehung: Du musst dran arbeiten.

Und zwar nicht nur dafür, dass Scrum sein volles Potenzial ausspielt und deinem Team ermöglicht, ihre Arbeitsweise und -ergebnisse kontinuierlich zu verbessern. Sondern auch gegen die Verwässerung des Prozesses von außen.

Damit euer Prozess sich nicht komplett auflöst, achte auf diese Warnsignale:

1. Das Team schreibt die User Stories selbst

Normalerweise sollten die User Stories vom Product Owner geschrieben werden. Dabei kann er durchaus vom Team unterstützt werden, wenn es etwa um Formulierungen geht. Wenn der Product Owner nur noch eine Reihe von Anforderungen bellt und das Ordnen in User Stories dem Team überlässt, stimmt etwas nicht.

2. Die letzte Retrospektive war vor mehreren Monaten

Retrospektiven sind das Mittel der Wahl, um Arbeitsabläufe zu verbessern sowie Produktivität und Zufriedenheit im Teams zu steigern. Manche sagen sogar, Retrospektiven können als Einstieg in die agile Entwicklung genutzt werden.

Fakt ist: Wer längere Zeit keine Retrospektive gemacht hat, läuft Gefahr, sich im Kreis zu drehen.

3. Der Scrum Master wurde abberufen

Scrum Master sorgen für eine störungsfreie Arbeitsatmosphäre des Teams und haben eine vermittelnde Funktion zwischen Team und Product Owner. Teams sollten durch sie nicht nur gegen den Product Owner, sondern auch vor sich selbst geschützt sein.

Für die Rolle des Scrum Masters muss Budget vorhanden sein. Die Rolle darf nicht einfach wegdefiniert werden. Sonst kann man den Prozess eigentlich gleich lassen.

4. Für Schätzungen ist „keine Zeit“

Auch wenn Schätzungen in manchen Augen überbewertet sind, erfüllen sie ihren Zweck: Fortschritt messbar machen und Entscheidungshilfe sein für die nächsten Aufgaben — etwa wenn es darum geht, was bis zu einem Termin noch alles fertig werden kann.

Ohne Schätzungen arbeitet jeder nur vor sich hin, man weiß weder, was zu schaffen ist noch was geschafft wurde.

5. Es gibt keinen Burndown pro Sprint

Der Burndown ist eine grafische Übersicht über den Fortschritt im aktuellen Sprint. Das geht Hand in Hand mit Schätzungen: Ohne Schätzungen kein Burndown. Ohne Burndown kein Indikator, ob die zweite Hälfte des Sprints zu schaffen ist. Ohne diesen Indikator keine Möglichkeit gegenzusteuern. Ohne Gegensteuerung keine Selbstorganisation.

6. Der Product Owner legt fest, dass Sprints nicht abgebrochen werden dürfen

Natürlich darf das Team einen Sprint abbrechen. Und natürlich muss ein triftiger Grund dafür vorliegen (wenn etwa am Tag nach dem Planning klar wird, dass einige Grundannahmen im Planning grundsätzlich falsch waren).

Kein Team bricht mutwillig einen Sprint ab -- dafür ist der zeitliche Aufwand viel zu hoch. Dem Team den Abbruch zu verwehren ist ein Eingriff in die Selbstorganisation der Gruppe.

7. Spikes werden zu Produktcode

Spikes sind minimale prototypische Implementationen einer Funktionalität und werden typischerweise zur Evaluation neuer Ideen und Technologien und deren Machbarkeit verwendet.

Solche Programmteile sind häufig nicht von der Qualität, die für ein Produkt in Frage kommt. Leuchtet ja auch ein: Wenn du etwas ausprobierst und damit möglichst schnell zu einer Entscheidung kommen willst, halten Qualitätsansprüche nur auf. Deshalb sollte Programmcode aus Spikes möglichst nicht wiederverwendet, auf keinen Fall aber im Ganzen ins Produkt übernommen werden.

8. Die Vision für das Produkt ist dem Team nicht (im Ganzen) bekannt

Um gute Arbeit zu leisten, muss man gut informiert sein. Bei agiler Softwareentwicklung mag man zwar immer nur für einen kurzen Zeitraum detailliert planen. Aber trotzdem müssen solche Teams zwecks Orientierung die Vision des Produktes immer vor Augen haben.

Fazit

An einer guten Beziehung muss man ständig arbeiten, sonst geht sie kaputt. Ähnlich sieht es mit Scrum aus.

Ich könnte natürlich sagen, dass beides Selbstläufer wären. Aber wir wollen hier doch ehrlich bleiben, oder?

Scrum ist harte Arbeit und Disziplin. Als Team muss man um den Prozess kämpfen, wenn man etwas davon haben will.

Diese Liste lässt sich sicher noch erweitern. Welche sind deine Warnsignale? Woran merkst du, dass du dich um deinen Prozess kümmern musst?

Aktualisiert: