Scrum – da lese man den Scrum Guide (https://www.scrumguides.org/scrum-guide.html), mache die Zertifizierung, halte sich an den Text und schon wird Scrum erfolgreich…

Wer das Agile Mindset – die agilen Werte – dahinter nicht lebt, wird scheitern. Das ist wie bei allen Prozessen. Nur wer versteht, was sie bewirken sollen und warum sie da sind, kann Prozesse auch zielführend anwenden und individuell aufeinander abstimmen.

Woran aber lässt sich erkennen, dass ein Team die Agilen Werte (Scrum Werte) so richtig lebt? Die Agilen Werte als Fundament der alltäglichen Arbeit schätzt?

Meine Antwort: An dem Sprintwechsel – genauer gesagt, den drei Sprint-Events: Review, Retrospektive, Planning.

Gehen wir die drei Sprint-Events mal durch. In jedem verbergen sich mindestens drei Fallstricke, die leider immer wieder übersehen werden, wenn die Agilen Werte zu wenig Berücksichtigung finden.

Dabei fange ich mal beim Review an, da er beim Sprintwechsel immer den Anfang macht und dann von der Retrospektive und dem Planning gefolgt wird.

DER SPRINT-REVIEW

Der Zweck des Sprint-Reviews besteht darin, das Ergebnis des Sprints zu überprüfen und zukünftige Anpassungen zu bestimmen. Das Scrum-Team präsentiert die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern und diskutiert die Fortschritte auf dem Weg zum Produktziel.

Alle sitzen im Meeting und dann passiert es….

REIHUM TRÄGT JEDER IM TEAM DIE USER STORY VOR, AN DER ER/SIE MASSGEBLICH GEARBEITET HAT

Die Intention:

• Jede(r) im Team soll auch für seine/ihre Erfolge gefeiert werden. Also dürfen alle ran und es trägt nicht der “PL” alles vor, als ob es sein Verdienst ist. 

Die Nachteile:

• Die Vorstellung des Ergebnisses wird für den Product Owner (PO) und die Stakeholder zu einer zerklüfteten Geschichte mit Unterbrechungen und verschiedenen Erzählstilen. Das reduziert die Wahrnehmung der Leistung und es wird auch nicht deutlich, was das Sprint-Ziel eigentlich war. Die Gefahr, dass es sich wie ein “Kessel Buntes” anfühlt, steigt unnötig.

Wie könnte man es anders machen?

• Das Team entscheidet, wer aus dem Team den gesamten Sprint vorstellt und dabei ein Story Telling verwenden kann, welches passend erscheint. Idealerweise führt diese einheitlich, und am besten fachlich strukturierte Präsentation zu einem schnelleren Verständnis der Features und des Kontextes bei den Anwendern. Gelingt dies, schließt man den Sprint meist mit der idealen Reaktion der Anwender: “Wann kann ich das alles haben?”
• Das setzt aber voraus, dass das Team sich als Team begreift und auch gemeinsam an dem Sprint arbeitet, also jede(r) genügend von den Arbeiten der anderen weiß und idealweise kein Cherry-Picking stattfindet oder aber Inselwissen aufgebaut anstatt abgebaut wird.

=> Zum Commitment gehört, dass jede(r) im Team sich mit seinen Bedürfnissen als Individuum dem Erreichen der Teamziele unterordnet und mit den Kollegen an “einem Strang” zieht. Idealerweise ist beim nächsten Review ein anderes Teammitglied an der Reihe.

ES WERDEN UNVOLLENDETE USER STORIES VORGESTELLT

Die Intention:

• In einer User Story wurde schon einiges umgesetzt. Das möchte man nicht unter den Tisch fallen lassen, es gehört doch auch zu dem, was das Team in dem Sprint erreicht hat.

Die Nachteile:

• Unvollendete User Stories sollten nicht in einem Release zur Verfügung gestellt werden, welches der Abnehmer (also PO und die Stakeholder) aber benötigen, um den Sprint zu nutzen. 
• Schlimmstenfalls wird dadurch zusätzlich sichtbar, dass das Team den Fokus auf die “dem PO wichtigen User Stories” zuerst verloren hat oder aber die Aufgaben zu groß waren.

Wie könnte man es anders machen?

• Im Review kurz und deutlich darauf hinweisen, dass man von den 6 User Stories die ersten 5 geschafft hat, die letzte aber nicht.  Ganz unabhängig davon, ob diese gänzlich nicht oder aber nur teilweise nicht umgesetzt wurde.
• Damit kann das Team auch deutlich machen, dass es den Fokus im Blick hat, um Nutzen zu erzeugen. Lieber 4/5 fertig als alle 5 angefangen und keine fertig. Das hilft dem Product Owner nämlich gar nicht.

Ausnahme:

• Eine User Story kann durchaus viele Akzeptanzkriterien enthalten, die alle eine unterschiedliche Priorisierung haben. Damit kann es durchaus sein, dass auch eine unvollendete User Story bereits ausreichend Nutzen für den PO erzielt hat und er diese in diesem Moment splitten möchte – in einen Teil der als abgeschlossen betrachtet wird und einen neuen Teil, der noch offen ist. Diese kommt in das Backlog zurück und muss vom PO priorisiert und vom Team geschätzt werden. Üblicherweise erkennt das Team diese Situation schon vor dem Review und geht frühzeitig auf den PO zu und stimmt sich gemeinsam ab.
• Diese Ausnahme tritt in unseren Projekten eher selten auf. Anderenfalls ist es eher ein Zeichen von fehlendem Fokus.

=> Der Fokus ist ein sehr relevanter Agiler Wert, der im Grunde die Basis für wirtschaftliches Handeln des Teams darstellt und besonders viel dazu beiträgt, dass das Vertrauen des PO in die Selbstorganisation des Teams entsteht. Zudem ist die Offenheit des Teams wichtig, um dem PO frühzeitig einen Verzug anzumelden und entsprechend reagieren zu können.

IM REVIEW WERDEN USER STORIES WIEDER AUFGEMACHT

Die Intention:

• Das Feedback des PO wird sehr ernst genommen. Da er die Abnahme des Ergebnisses vornimmt, darf auch er entscheiden, ob eine Story geschlossen wird bzw. eine wieder eröffnet wird.

Die Nachteile:

• Iteratives Vorgehen baut darauf, dass man fortwährend Erkenntnisse gewinnt und nutzen kann. Wenn das aber dazu führt, dass User Stories zu Langläufern werden und von Sprint zu Sprint gereicht werden, ist dies eher demotivierend für das Team. 
• Zudem sollte davon ausgegangen werden, dass das Team die Definition of Done (DoD) kennt und auch entsprechend alles getan hat. Die DoD gehört zu der Vereinbarung zwischen PO und Team, auf die sich das Team und der PO verlassen können muss.
• Schlussendlich raubt sich der PO die Möglichkeit den Nutzen zu maximieren, denn es fehlt die Feedback-Schleife (Backlog Priorisieren), ob diese neue Anforderung gegenüber allen anderen im Backlog wirklich am wichtigsten ist.

Wie könnte man es anders machen?

• Sollte im Review also etwas auffallen, was dem Produkt noch fehlt, ist also eher die User Story unvollständig gewesen. Dann sollte eine neue Story eröffnet werden, bei der auch der Titel überarbeitet wird. Diese kommt ebenfalls ins Backlog und gelangt erst mit vollständiger Definition of Ready (DoR) im Planning wieder in einen Sprint.

=> Zu den Agilen Werten Offenheit und Mut gehört, dass Fehler angesprochen werden und die Einhaltung der Regeln für alle – also auch den PO – gelten.

DIE RETROSPEKTIVE

Ziel der Retrospektive ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

Alle sitzen im Meeting und dann passiert es….

MAN ÜBERSPRINGT DAS GEMEINSAME REFLEKTIEREN DER FAKEN

Die Intention:

• Das Ziel einer Retrospektive ist es doch, die Zusammenarbeit zu verbessern. Dazu muss man doch nur die guten Dinge weitermachen und Dinge, die schlecht laufen, ändern.
• Ganz schnell geht das mit einer Starfish-Retro oder aber gleich dem Klassiker von Norman Kerth, “The Original 4”. Am Ende clustern und Maßnahmen beschließen. Fertig.

Die Nachteile:

• Das Rekapitulieren einer Zeitspanne, auch von nur 2-4 Wochen, ist stark beeinflusst von den letzten Tagen/Stunden. Es gehen mitunter wichtige Informationen verloren, wenn man sich gleich auf den Kern der Retro stürzt ohne sich die Zeit zu nehmen, sich zu erinnern, was seit dem letzten Sprintwechsel passierte und sich darüber auch im Team mittels Fakten (und nicht Bewertungen) auszutauschen. 

Wie könnte man es anders machen?

• Norman Kerth – der Erfinder der Retrospektive – hat explizit 5 Phasen definiert:  Set the stage, Gather Data, Generate Insights, Decide what to do, Close the Retro
• Leider werden Phase 1 und 2 häufig übersprungen und man begnügt sich mit Phase 3 und 4. Dabei stellen Phase 1 und 2 das Fundament her, welches bei Phase 3 und 4 genutzt wird. Die beiden ersten Phasen helfen dem Team auch dabei, sich ihrer Wahrnehmung des letzten Sprints gegenseitig bewusst zu werden und erleichtern später (also in Phase 3-4) auch das Verständnis für das was wirklich getan werden sollte.
• Bei https://retromat.org/bekommt man unzählige tolle Methoden (auch per Zufallsgenerator) an die Hand für alle Stages einer Retro.

=> Die ersten Phasen in einer Retro fördern Offenheit, Mut und Respekt. Das wiederum fördert den Fokus und das Commitment.

DIE LISTE DER MASSNAHMEN IST LANG UND VOLLER MAMMUTAUFGABE

Die Intention:

• Die Erkenntnisse der Phase 3 (Generate Insights) einer Retro führen in Phase 4 (Decide what to do) zu einer Liste möglicher Aktivitäten, wie man die Zusammenarbeit verbessern könnte.
• Alles trägt doch dazu bei. Deswegen ist die Liste lang und hat auch größere Aufgaben.

Die Nachteile:

• Lange Listen mit großen Aufgaben müssen auch angegangen werden. Sie verschwinden selten von alleine. Wer aber soll das alles wann tun?
• Zudem sind Aufgaben, die länger als ein Sprint dauern, schwer in Scrum sichtbar zu machen und voranzutreiben.

Wie könnte man es anders machen?

• Das Team sollte gemeinsam entscheiden, was es tut und was nicht. Mehr als zwei Aufgaben in dem nächsten Sprint umzusetzen ist aus eigener Erfahrung schwierig, zumal damit auch Aufwände verbunden sind, die beim Sprint-Review nicht so deutlich mit dem Nutzen gegenüber dem PO und Stakeholdern verkaufbar sind.
• Die Größe der Aufgaben muss berücksichtigen, dass im Sprint vorrangig User Stories umgesetzt werden sollten. Daher ist es von Vorteil sie SMART zu formulieren.
• Idealerweise haben diese beiden Aufgaben auch die höchste Prio, damit sie nicht am Ende des Sprints hinten runter fallen und der erarbeitete Mehrwert verloren geht.

=> Alle Dinge, die man nicht getan hat, hatten einen geringeren Nutzen und haben auch die Chance, in der nächsten Retro erneut genannt zu werden. Hier kommen wieder der Fokus und das Commitment zum Tragen, die mit einer ellenlangen und unrealistischen Retro-Aufgabenliste sabotiert würde.

AM ENDE GEHEN ALLE EINFACH AUSEINANDER

Die Intention:

• Phase 5 kann man doch überspringen. Alle haben sich auf gemeinsame Maßnahmen geeinigt. Reicht doch.

Die Nachteile:

• Es findet keine reflektierte Bewertung statt, ob die Retro eine wirklich gute Retro war oder nicht. Iterative Maßnahmen könnten auch die Retro an sich betreffen.
• Das Team kann Maßnahmen beschließen, die unrealistisch sind. Einzelne Mitglieder können überhört worden sein ohne es zu erkennen.

Wie könnte man es anders machen?

• Phase 5 ist das Closing der Retro. Genauso wie das Eröffnen mit dem Set the Stage, sollten am Ende alle im Team die Möglichkeit bekommen die Retro kurz mit einer Mini-Retro zu bewerten.
  

  

• Das geht verdammt schnell. Mein Favorit ist “Constellation”, also die Abfrage der Teamzufriedenheit mit den vier Dimensionen: Die Themen waren mir wichtig, ich habe offen gesprochen, die Zeit war gut investiert und unsere Maßnahmen sind erreichbar. Es findet keine Diskussion statt, aber alle wissen den Zustand der Wertigkeit der aktuellen Retro.

=> Unstimmigkeiten und Fehler in der Retro werden schnell sichtbar. Die Agilen Werte Offenheit, Mut und Respekt zahlen hiermit deutlich auf das Commitment ein.

DAS PLANNING

Die Sprint-Planung leitet den Sprint ein, indem sie die für den Sprint auszuführenden Arbeiten festlegt. Dieser resultierende Plan wird durch die Zusammenarbeit des gesamten Scrum-Teams erstellt.

Alle sitzen im Meeting und dann passiert es….

DAS PLANNING ENTARTET ZUM BACKLOG-REFINEMENT

Die Intention:

• Im Planning muss der PO doch nur die User Stories benennen, die in den nächsten Sprint sollen und dem Team erklären, warum diese jetzt so wichtig sind.
• Unklarheiten können im Planning doch aufgelöst werden, wenn sowieso alle dabei sind. Das spart Zeit.

Die Nachteile:

• Unklarheiten müssen aufgelöst werden. Dabei sollte aber auf keinen Fall Zeitdruck aufgebaut werden, um ein Commitment des Teams zu erzeugen.
• Damit die Zeit eingehalten werden kann, stimmt das Team einem Sprint-Backlog voreilig zu. Es werden oft die DoR und die DoD nicht komplett angewandt, obwohl doch gerade diese die Form der Zusammenarbeit regeln. 
• Sobald DoR und DoD ihre Bedeutung verlieren, ist ein Sprint schon am Anfang verloren.

Wie könnte man es anders machen?

• Der PO sorgt während der Sprints kontinuierlich für das Backlog-Refinement, welches idealerweise die nächsten drei geplanten Sprints modelliert und damit auch vorzeitig Umfang, Prioritäten und Unklarheiten anzeigt.
• Dabei sollte das ganze Backlog geschätzt sein (wozu gibt es beim Planning Poker eigentlich die Karten mit 20, 40 und 100?) – mindestens aber alle User Stories des kommenden Sprints.
• Die Backlog-Refinements für den nächsten Sprint sollten mit dem Team abgestimmt auch während des aktuellen Sprints stattfinden. Inklusive Schneiden und Schätzung.

=> Ein gut vorbereitetes Sprint-Backlog ermöglicht ein klares und schnelles Planning, da das Commitment des Teams deutlich erleichtert wird. Ebenso ermöglicht ein vorgelagertes Backlog-Refinement den Blick in die Zukunft und das Team kann technische Details ohne Zeitdruck berücksichtigen, um Blocker im Sprint zu vermeiden. Am Ende steigt sogar die Velocity.

DAS PLANNING 2 WIRD ÜBERSPRUNGEN

Die Intention:

• Mit dem Planning wird der kommende Sprint aufbereitet. Bei Planning 1 und 2 sind ja eh die gleichen Personen anwesend. Dann legen wir es mal eben zusammen. Das spart Zeit.

Die Nachteile:

• Das Team hat zu wenig Raum, um sich alleine selber den Sprint aufzuteilen. Die Gefahr, dass der anwesende PO aktiv bei der Aufgabenverteilung eingreift ist hoch!
• Das kann wiederum dazu führen, dass die User Stories nicht zerlegt werden, sondern jedem aus dem Team eine ganze Story gegeben wird. Das führt zu schwerwiegenden Folgeproblemen:
  • User Stories sind nicht fachlich sondern eher technisch ausgerichtet, damit diese auf die Team-Mitglieder passen. Das wiederum führt zu Problemen bei der Schätzung, da nicht das Team sondern nur einzelne Mitarbeiter*innen schätzen.
  • Inselwissen wird verstärkt. Bei Urlaub und Krankheit können gewisse Arbeiten gar nicht vom verbleibenden Team geleistet werden.
• Am Ende arbeitet das Team an allen User Stories gleichzeitig, damit alle “was zu tun” haben. Und am Sprintende wächst die Gefahr, dass User Stories nicht beendet werden, da Unterstützung im Team fehlt, weil jeder seine User Story fertig bekommen will. Schlimmstenfalls wird dann auch noch auf das Ticket-Review verzichtet, da das grundsätzliche Wissen im Team eben nur bei einer Person liegt. Das reduziert die Qualität.

Wie könnte man es anders machen?

• Gehen wir davon aus, dass die User Stories überwiegend fachlich formuliert sind. Zudem setzen wir voraus, dass das Team die User Stories auch schon vor dem Planning geschätzt hat und dabei schon eine Vorstellung gewonnen hat, was im Hintergrund alles zu tun ist, um es mit Referenzstories in Form von Story Points zu schätzen.
• Der Scrum-Guide unterscheidet deutlich zwischen Planning 1 und Planning 2. Während das Planning 1 dazu dient, dem Team den Fokus auf die Inhalte – also das WAS – zu geben, sollte im Planning 2 das Team selbständig über das WIE befinden. Dafür ist die Anwesenheit des PO in der Regel nicht nötig. Eine saubere Trennung der Teilnehmer*innen beider Termine ist leicht.
• Im Planning 2 sollte das Team die User Stories in weitere Tickets zerlegen, deren Inhalte das Team selber entscheidet. Diese Tickets sind ausschließlich für das Team und nicht für den PO gedacht. 
• Mit Hilfe dieser Tickets sollte ermöglicht werden, dass das Team sich auf die wichtigsten User Stories zuerst fokussieren kann – und zwar (so gut es geht) gemeinsam. Wenn der fachliche Kontext des Teams gleich ist, sind gegenseitige Hilfe und Absprachen mit deutlich weniger Overhead verbunden. Ein cross-funktionales Team schafft es, dass fast jede(r) an jeder User Story mitarbeiten kann.
• Nebenbei verschafft sich das Team mit dem Schritt des Zerschneidens auch einen besseren Überblick über die Detailaufgaben, die es einzuplanen gilt. Ebenso wird schnell erkenntlich, ob diese zur Schätzung passen oder nicht. In diesem Fall wird der PO involviert.

=> Das Team arbeitet als Team und nicht als eine Gruppe von Einzelkämpfern. Das ist wichtig für das Commitment. Zudem ist der gemeinsame Fokus auf die am höchsten priorisierten User Stories wichtig, um am Ende des Sprints garantiert die User Stories geschafft zu haben, die für den PO den größten Nutzen hatten.

DAS SPRINTZIEL IST UNKLAR BZW. SCHWAMMIG

Die Intention:

• Es gibt viele Baustellen, die alle gleichzeitig angegangen werden müssen. Die User Stories lassen sich schwierig unter einem Mission Statement zusammenfassen. Das Mission Statement: “Der Sprint muss geschafft werden!”, sollte doch reichen. 

Die Nachteile:

• Ein Sprint-Backlog ohne Mission Statement, welches den Nutzen des eigenen Schaffens verdeutlicht, erschwert es dem Team sich mit dem Sprint zu committen, zu identifizieren, stolz darüber zu sprechen, was am Ende den Nutzern tolles verkauft wird.
• Für das Team ist es zudem auch schwieriger den Fokus im Sprint zu halten, wenn alle User Stories zu lose verknüpft sind. Fokuswechsel kosten mehr Zeit und sind auch immer Fehlerquellen. Der Flow fehlt.

Wie könnte man es anders machen?

• Es gibt zahlreiche Methoden im Produktmanagement, die auch ein Product Owner beherrschen sollte. Story Telling, Kano, Roadmap Planung, u.v.a.m.
• Diese Methoden helfen dabei, das Ergebnis am Ende den Anwender*innen/Kund*innen schmackhaft zu machen. Sie sind auch dazu geeignet User Stories in Epics zusammenzufassen.
• Nebenbei hat jede(r) im Team es leichter anderen das Mission Statement zu erklären: “Wir ermöglichen es der Buchhaltung ihren Monatsabschluss digital an DATEV zu übermitteln”. 

=> Die Identifikation mit dem Gegenstand des Projektes ist erleichtert und damit wiederum das Commitment des Teams. Ein deutlicher Fokus im Sprint führt auch zu mehr Effektivität und Effizienz und damit zu besseren Ergebnissen.

FAZIT

Das Leben der Agilen Werte im Team ist wichtiger als der Prozess Scrum. Denn das fehlende Mindset ist Ursache Nummer 1 für scheiternde Scrum-Projekte.