Heute geht es ums Sprint-Planning.
Willst du dieses Meeting verbessern, musst du es besser facilitieren. Allerdings werde ich dir keine Liste von 25 Techniken zur Moderation geben. Denn das ist nicht, was du brauchst.
Du brauchst ein Verständnis der Psychologie.
Du musst wissen, welche Denkfehler sich in der Planung des Sprints im Team einschleichen. Bleiben diese Fehler unerkannt, führen sie dazu, dass schlechte Entscheidungen getroffen werden – und dadurch User-Stories nicht abgeschlossen, Sprintziele nicht erreicht oder falsche Prioritäten gesetzt werden. Kennst du diese Fehler jedoch, dann kannst du sie vermeiden. Und damit hilfst du deinem Team, den Sprint realistischer zu planen und Deadlines sicherer einzuhalten.
Beginnen wir mit dem ersten Fehler:
Denkfehler #1: Der Planungsfehlschluss
Vor vielen Jahren bin ich das erste Mal auf das ungeschriebene Gesetz 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ätzen, ob wir Planning-Poker nutzen oder „nur der erfahrenste Entwickler schätzt“. Egal, ob wir uns viel oder wenig Zeit zur Diskussion nehmen.
Es passte nie.
Da das für mich keine zufriedenstellende Antwort war, fing ich an, nachzuforschen. Und beim Vergleich der „Bearbeitungszeit“ und des Zeitpunkts der Fertigstellung von Tickets 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 diesen Zusammenhang erkannt hat. Und das Ausmaß dieses Problems ist noch viel größer, als mir damals bewusst war.
Wie lautet nämlich das ungeschriebene Gesetz in der Softwareentwicklung?
Alles kostet doppelt so viel und braucht doppelt so lange.
Ich denke, wenn du bereits einige Zeit in der Softwareentwicklung verbracht hast, erkennst du es bestimmt wieder.
Was steckt hinter diesem ungeschriebenen Gesetz?
Die Ursache des Problems nennt die Psychologie den Planungsfehlschluss.
Dieser Fehlschluss wurde von den Psychologen Lovallo und Kahneman im Jahr 2003 beschrieben. Sie definieren den Planungsfehlschluss als die Tendenz, die Zeit, Kosten und Risiken künftiger Handlungen zu unterschätzen. Konkret auf die Situation im Sprint-Planning bezogen bedeutet das:
Scrum Teams 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.
Nochmal zurück zum Beispiel: Was ich entdeckte, war auch, dass der zeitliche Aufwand bis zur wirklichen Fertigstellung eines Tickets unterschätzt wurde. Und zwar um den Faktor vier.
Wie kannst du diesen Fehler vermeiden?
Die Antwort lautet nicht: besser schätzen.
Ich habe viel versucht, aber es ist unmöglich, alles miteinzubeziehen, was passieren kann. Der Planungsfehlschluss bestätigt auch, dass wir Menschen es schlicht nicht können. Wenn Entwickler User-Stories schätzen, dann schätzen sie nur die Zeit, die sie benötigen würden, um das Feature zu implementieren. Sie berücksichtigen jedoch nicht, dass die Implementierung zwei Tage „rumliegen“ könnte, bis jemand Zeit für ein Code-Review hat.
Deshalb lautet die bessere Antwort:
Einen zeitlichen Puffer einplanen oder nur 50 – 70 % der theoretischen Kapazität verplanen.
Nach dem Planungsfehlschluss widmen wir uns nun einem weiteren Fehler:
Denkfehler #2: Das Herdenverhalten
Im Jahr 1985 führten die Psychologen Garold Stasser und William Titus ein Experiment durch:
Zwei Gruppen zu je vier Personen mussten entscheiden, welcher von drei Kandidaten am besten für das Amt des Studentenschaftspräsidenten geeignet war. Die Forscher erstellten Dossiers, die die positiven und negativen Eigenschaften der einzelnen Kandidaten enthielten. Auf dieser Grundlage war Kandidat A der Geeignetste für dieses Amt.
In der ersten Gruppe lasen alle Mitglieder das Dossier im Vorfeld, gaben ihre persönliche Präferenz an und wählten dann in einer Abstimmung als Gruppe Kandidat A. Soweit nichts Ungewöhnliches.
Nun zur zweiten Gruppe:
Hier waren die Dossiers für die Mitglieder unvollständig. Sie enthielten einige gemeinsame Informationen über jeden Kandidaten, aber die restlichen Informationen waren über verschiedene Dossiers verstreut. Aufgrund der Verteilung der positiven und negativen Informationen gaben die meisten Mitglieder vor der Abstimmung Kandidat A nicht den Vorzug. Obwohl die Mitglieder dieser Gruppe wussten, dass ihre Dossiers nicht alle Informationen enthielten, stellte sich in der Gruppendiskussion schnell ein Konsens ein.
Und dann geschah etwas Unerwartetes:
Sobald die Mitglieder der Gruppe sahen, dass sich ein Konsens bildete, wurde es zunehmend unwahrscheinlicher, dass Mitglieder mit abweichenden Informationen (negative über den Konsenskandidaten oder positive über die nicht bevorzugten Kandidaten) diese Informationen weitergaben. Anders als in den Gruppen mit vollständigen Informationen, in denen Kandidat A gewählt wurde, wählten diese Gruppen fast immer einen der anderen Kandidaten.
Nochmal überspitzt formuliert:
Ein Team von klugen Menschen trifft dümmere Entscheidungen, weil jeder seine Meinung dem vermeintlichen Konsens anpasst.
Wie kannst du diese Erkenntnis für deine Sprint-Planung nutzen?
Einfach wäre es, Gruppendiskussionen zu unterbinden.
Allerdings weiß ich aus Erfahrung, dass sich darauf niemand einlassen wird. Dafür sind wir Menschen einfach zu soziale Wesen. Besonders, wenn wir entscheiden, wie das Ziel des Sprints lauten soll oder welche Einträge auf dieses Ziel einzahlen und welche nicht. Deshalb brauchen wir einen praktikablen Ansatz. Dieser lautet:
Differenzen fördern.
Hierfür kannst du eines dieser beiden Vorgehen wählen:
- Beiträge anonymisieren: Bitte jedes Teammitglied, anonym ein Sprintziel zu formulieren. Danach werden alle Ziele vorgestellt und diskutiert. Dadurch förderst du mögliche Differenzen.
- Den „Advokaten des Teufels“ spielen: Einer im Team sollte immer entgegen der Meinung des Teams argumentieren. Diese Person stellt dann ständig kritische Fragen wie: „Was, wenn ein Teammitglied ausfällt? Was, wenn wir später fertig sind als geplant? Was, wenn die Technik nicht funktioniert?“
Zum Schluss noch ein letzter Fehler:
Denkfehler #3: Sunk-Cost-Fallacy
In den Weihnachtsferien haben wir die Fortsetzung von „Drei Engel für Charlie“ angesehen.
Nach einer halben Stunde meinte meine Frau: „Lass uns etwas anderes anschauen, ich langweile mich.“ Sie hatte recht. Ich fand den Film auch schlecht. Und zwar wirklich. Trotzdem habe ich ihn bis zum Ende angesehen.
Wieso habe ich noch weitere 60 Minuten meiner Zeit in einen langweiligen Film investiert?
Ich hätte doch auch einen anderen Film ansehen können. In meiner Situation wurde die bereits investierte Zeit zur Begründung, weiterzuschauen. Auch wenn es objektiv betrachtet keinen Sinn ergab. Mein irrationales Handeln ist ein Beispiel für das Phänomen der Sunk-Cost-Fallacy. Diese Falle schnappt immer dann zu, wenn wir besonders viel Zeit, Geld, Energie oder Liebe investiert haben. Je größer die „Sunk Costs“ sind, desto stärker ist der Drang, die Investition fortzuführen.
Dieses Phänomen findet sich in vielen Bereichen unseres Lebens – etwa beim Aktienhandel. Dort halten wir weiter an einer Aktie fest, obwohl sie bereits lange unter dem Einkaufswert gehandelt wird. Der Bau der Concorde oder des Berliner Flughafens sind weitere Beispiele. Vielleicht erkennst du die Falle auch bei dir, wenn es um das Lesen von Büchern geht. Sagst du dir dort auch manchmal: „Ich habe schon so viele Seiten in diesem Buch gelesen ...“?
Dann bist du in die Falle getappt.
Was hat das mit der Sprint-Planung von Scrum Teams zu tun?
Lass uns genauer hinschauen, indem ich dir einige Fragen stelle:
Was passiert mit den User-Stories, die im letzten Sprint nicht abgeschlossen wurden? Werden die Tasks dann einfach im kommenden Sprint weiterbearbeitet, bis sie fertig sind? Was hat dann Priorität: die nicht abgeschlossenen User-Stories oder die neuen, die auf das Sprintziel einzahlen?
Werden die unfertigen User-Stories dann mit einem der folgenden Argumente priorisiert?
- „Wir haben schon so viel Zeit investiert.“
- „Es ist nicht mehr viel zu tun, dann ist die Story auch fertig.“
Dann ist dies ein klares Zeichen dafür, dass auch dein Team in diese Falle getappt ist. Der unfertigen Arbeit wird dadurch mehr Wichtigkeit eingeräumt als den eigentlichen Prioritäten des neuen Sprints. Und all das nur, weil euch das Gehirn einen Streich spielt.
Deshalb: Hilf deinem Team, diese Falle zu erkennen.
Frage zum Beispiel:
Wenn wir das Sprintziel im letzten Sprint erreicht haben, warum sollten wir noch weitere Kapazitäten investieren, um diese User-Stories abzuschließen?
Zum Abschluss: Lass uns noch einen Mythos über Facilitation entkräften
Wie versprochen kennst du jetzt die Fehler, die sich schnell in Sprint-Plannings einschleichen.
Bleiben diese unerkannt, können sie zu schlechten Entscheidungen führen. Dadurch werden User-Stories nicht abgeschlossen, Sprintziele nicht erreicht oder falsche Prioritäten gesetzt. Kurz gesagt: Dein Scrum Team kann keinen realistischen Plan fassen. Das Erkennen von Denkfehlern ist ein erster Schritt, um dich zum Facilitator zu entwickeln.
Und noch etwas:
Facilitation wird häufig mit Moderation gleichgesetzt.
Allerdings ist das ein Irrglaube. Facilitation ist mehr als nur Moderation. Im Kern geht es darum, den Weg des Teams zum Erfolg zu erleichtern. Dies kann durch Techniken und Methoden der Moderation geschehen, aber auch dadurch, dass du deinem Team hilfst, gängige Denkfehler im Sprint-Planning zu vermeiden.
Willst du den nächsten Schritt deiner Scrum-Master-Karriere gehen? Suchst du konkrete Tipps für deine Situation? Möchtest du dich mit anderen Scrum Mastern austauschen? Dann besuche unser nächstes „Professional Scrum Master - Advanced“-Training. Dort unterstützen Marc und ich dich auf deinem Weg, ein besserer Scrum Master zu werden.