Hier ist eindeutig etwas schiefgelaufen.
Bei vielen Scrum Teams sieht von Weitem alles gut aus. Der Sprint beginnt mit einem Sprint-Planning. Jeden Tag findet ein Daily Scrum statt, Sprint-Review und eine Sprint-Retrospektive beenden den Sprint. Sprechen wir aber mit den Teammitgliedern, erfahren wir, dass Scrum sie wenig unterstützt. Es fühlt sich eher wie eine lästige Pflicht an. Christiaan Verwijs, Johannes Schartau und Barry Overeem vergleichen ein solches Scrum mit einem Zombie, der in einer nebligen Nacht auf dich zuschlurft. Aus der Ferne sieht alles gut aus: Zwei Beine, Check. Zwei Arme, Check. Ein Kopf, klar! Aber bei näherer Betrachtung wird offensichtlich, dass du um dein Leben rennen musst.
Woran erkennst du, ob dein Scrum Team auf die Scrum-Zombie-Apokalypse zusteuert?
Hier 3 Krankheitsbilder, über die ich in meiner Arbeit der letzten Jahre mehrfach gestolpert bin.
Los geht’s:
Krankheit #1: Der Kunde sieht keine echte Software, sondern hört nur Versprechen
Der Kunde sieht Sprint für Sprint keine funktionierende Software.
Vielleicht bekommt er Präsentationen, Tabellen oder Berichte über den vermeintlichen Fortschritt aufgetischt. Wenn er Glück hat, vielleicht mal ein technisches Konzept, eine Designskizze oder einen Prototyp. Aber die aktuelle Version der Software kann er nicht selbst in Betrieb nehmen. Seine Nutzer können sie nicht testen, obwohl ein Sprint nach dem anderen vergeht.
Das erste Versprechen von Agilität wird hier für den Kunden niemals eingelöst.
Das Resultat: Das Vertrauen in die Arbeit des Teams sinkt von Sprint zu Sprint und der Wunsch nach mehr Kontrolle steigt. Im Review dreht sich zunehmend alles nur noch um Velocity-Zahlen, Projektpläne und die Anzahl von „versprochenen vs. fertiggestellten“ User-Stories.
Für diese Krankheit wirst du nur ein Heilmittel finden, wenn du dir drei unbequeme Fragen stellst:
- Wieso ist die Arbeit so groß, dass sie nicht in einem Sprint fertig wird?
- Kann das Team nicht oder will das Team nicht liefern?
- Wer verhindert den Zugang zum Kunden und Nutzer?
Mit einem „User-Story-Splitting“-Workshop wirst du eher an den Symptomen herumdoktern.
Was ich aus leidvoller Erfahrung weiß, denn die wahre Ursache liegt irgendwo tiefer im Unternehmen vergraben. Vielleicht gibt es sogar Kräfte, die Angst vor einem möglichen Gesichtsverlust haben, wenn das Team frühzeitig feststellt, dass die Software den Kunden nicht begeistert.
Krankheit #2: Die große Planungsillusion: Schätzungen treffen nie zu
Vor 10 Jahren bin ich das erste Mal auf eine weitverbreitete Krankheit in der Softwareentwicklung gestoßen:
Damals habe ich mich gefragt, warum die Schätzungen unserer Teams nicht wirklich genau sind – egal, ob wir in Story-Points oder Personentagen schätzten, ob wir Planning-Poker nutzten oder „nur der erfahrenste Entwickler schätzt“. Egal, ob wir uns viel oder wenig Zeit zur Diskussion nahmen.
Es passte nie.
Da ich mich mit dieser Krankheit nicht abfinden und für unser Team nur darum herum planen wollte, fing ich an nachzuforschen. Vielleicht gibt es doch ein verborgenes Heilmittel. Als ich die „Bearbeitungszeit“ und den Zeitpunkt der Fertigstellung von Tickets verglich, fiel mir etwas auf: Die Bearbeitungszeit betrug im Durchschnitt nur ein Viertel der gesamten Zeit bis zur Fertigstellung. Mit anderen Worten: An einem Ticket wurde an einem Tag der Woche gearbeitet, wirklich fertig wurde es allerdings erst am Ende der Woche. Natürlich bin ich nicht der Erste, der den Zusammenhang erkannt hat.
Softwareentwicklung kostet immer doppelt so viel und braucht doppelt so lange, wie vorher angenommen wurde.
Allerdings ist das Ausmaß dieser Krankheit viel weitreichender, als mir damals bewusst war. Es ist eine förmliche Epidemie. Zahlen habe ich leider nicht, aber ich glaube, sie ist für die meisten Fälle von Zombie-Scrum der letzten Jahre verantwortlich. Bei meiner Arbeit in den letzten Jahren, diese Krankheit einzudämmen, habe ich feststellen müssen, dass die gängigen Heilmittel aus dem Projektmanagement-Medizinkasten oder Hausmittelchen aus dem agilen Kräutergarten nur wenig Wirkung zeigen. Es braucht etwas Stärkeres.
Wenn die Krankheit so tief sitzt, dann brauchen wir einen ganzheitlicheren Ansatz. Wir brauchen nicht nur ein Mittel gegen die Symptome, sondern eine psychologische Therapie.
Wenden wir uns also an einen Psychologen.
In der Psychologie ist dieses Phänomen nämlich bereits bekannt und heißt Planungsfehlschluss. Dieser Fehlschluss wurde von den Psychologen Lovallo und Kahneman im Jahr 2003 beschrieben. Sie definieren den Planungsfehlschluss als die Tendenz, Zeit, Kosten und Risiken künftiger Handlungen zu unterschätzen. Konkret auf die Situation, Sprints verlässlich zu planen, bedeutet das:
Die Entwickler im Team neigen dazu,
- den Zeitaufwand zu unterschätzen,
- die Kapazität des Teams zu überschätzen,
- Risiken zu ignorieren und
- nur „Best-Case-Szenarien“ zu betrachten.
Und das Perfide an dieser Krankheit ist, dass das Spitzenmittel „30 % Puffer pro Schätzung“, das jeder Projektleiter gerne verabreicht, nicht wirkt. Denn der Planungsfehlschluss besagt gerade, dass Entwickler den Aufwand für Aufgaben unterschätzen – selbst dann, wenn sie versuchen, ihre eigene Fehleinschätzung auszugleichen.
Wirres Krankheitsbild, oder?
Wenn ein Team am Ende des Sprints nichts ausliefert, ist das ein Anzeichen dafür, dass die Krankheit der Planungsillusion bereits ausgebrochen ist. Peter Götz hat in den letzten Jahren nach einem Heilmittel dafür gesucht und mittlerweile ein wirksames Rezept zusammengestellt, wie du den Befall in deinem Unternehmen eindämmen kannst. In seinem Flow-Crash-Kurs teilt er es kostenlos mit jedem, der sein Team von unrealistischen Schätzungen und späten Lieferungen kurieren will.
Deshalb mein Appell:
Lass uns mit Peters Hilfe diese Zombie-Epidemie eindämmen.
Nichts liefern und unrealistische Schätzungen sind bereits zwei schlimme Krankheiten. Leider sind Zombie-Scrum-Teams auch noch von einer weiteren Krankheit befallen.
Krankheit #3: Kein Feedback von Stakeholdern im Sprint-Review
Das Herz des Scrum-Prozesses hört allmählich auf zu pulsieren.
Diese Krankheit zeigt sich in zwei Ausprägungen:
- Es sind keine Stakeholder im Sprint-Review anwesend.
- Die Stakeholder geben kein Feedback.
Schauen wir uns die Ausprägungen eine nach der anderen gemeinsam an, um mit der Reanimation zu beginnen. Starten wir mit der ersten Ausprägung: keine Stakeholder im Sprint-Review.
Hier hat sich für mich bisher immer dieses Vorgehen bewährt:
- Stakeholder finden
- Stakeholder einladen
- Stakeholder aufsuchen
Besprechen wir die Schritte im Detail.
Als Erstes geht es darum, überhaupt die Stakeholder für das Produkt ausfindig zu machen. Hierfür nutze ich immer diese Matrix:
Sie hilft deinem Team zu bestimmen, wer ein Interesse am Erfolg des Produkts haben könnte und wer Einfluss auf die Entwicklung des Produkts nehmen könnte. Ins Review solltest du dann „Promotoren“ einladen – was bereits den zweiten Schritt beschreibt. Häufig reicht ein Kalendereintrag nicht als Einladung. Deshalb gilt es hier, kreativ zu sein. Sprich die Stakeholder persönlich an. Oder, wenn sie ein Ticket für dein Team erstellen, dann informiere sie, dass ihr nur daran arbeitet, wenn sie im Anschluss zum Review kommen.
Wenn diese kleinen Tricks nicht wirken, dann musst du das Review umdrehen. Das meine ich mit dem letzten Schritt „Stakeholder aufsuchen“. Nirgendwo steht geschrieben, dass das Sprint-Review in eurem Teambüro stattfinden muss. Das Review kann auch bei eurem Kunden oder im Büro eurer Stakeholder stattfinden. Häufig heißt es dann nicht mehr Review, sondern vielleicht „Nutzer-Test-Session“, „Kundenabnahme“ oder „Verkaufspräsentation“. Das bedeutet aber nicht, dass ein Team es nicht als Review nutzen kann.
Was uns zur zweiten Ausprägung dieser Krankheit bringt:
Die Stakeholder geben kein oder unzureichendes Feedback.
Damit nimmt die Krankheit langsam und unbemerkt ihren Lauf. Du erkennst die ersten Anzeichen daran, dass das Sprint-Review in einer planlosen Diskussion mündet. Ich habe es bisher immer so kuriert: Anstatt am Ende in eine Diskussion zu verfallen, habe ich um strukturiertes Feedback gebeten. Nachdem die neue Version des Produkts vorgestellt wurde und jeder Stakeholder sie ausprobiert hat, bitte ich die Stakeholder, diese vier Fragen zu beantworten:
- Mir gefällt: Dinge, die ich mag oder die mir gefallen haben …
- Konstruktive Kritik: Ich hätte mir gewünscht …
- Fragen? Fragen, die sich aus der Erfahrung oder Präsentation ergeben haben …
- Ideen? Ideen, die sich aus der Erfahrung oder Vorstellung ergeben haben …
Die Antworten sammle ich, um sie im Anschluss im Scrum Team auszuwerten. Damit reanimierst du das Herz des Scrum-Prozesses und ermöglichst ein konstruktives Arbeiten im nächsten Sprint.
Verdacht auf Zombie-Scrum in deinem Team?
Wenn auch du Zombie-Scrum in deinem Team vermutest, dann ergreife die Chance, es zu heilen.
Nutze die drei unbequemen Fragen, die Erkenntnisse aus dem kostenlosen Flow-Crash-Kurs von Peter und die Feedback-Matrix – und lass uns gemeinsam die Zombie-Scrum-Epidemie eingrenzen.
Los geht’s …