Scrum Fallen - Scrum Patterns

Die Scrum Teams haben oft die gleichen Probleme, die man Scrum Fallen (Scrum Pitfalls) nennt. 

Die Scrum Patterns sind hilfreiche Prozesse um die Scrum Fallen zu umgehen.

Das Scrum Framework ist einfach und laut Design hilft den Teams mit "sich ergebenden Änderungen" umzugehen, kann aber nicht alle Probleme lösen! Weil immer neue Scrum Patterns entstehen, kann man diese zusammen einsetzen. Das wird "Pattern Language of Programming" oder PLoP genannt.

 Stabile Teams

Halten Sie Ihre Teams nicht nur klein, sondern auch stabil! Versuchen sie zu vermeiden, dass Team-Mitglieder in mehreren Teams %-weise arbeiten und ständig wechseln! Stabile Teams kennen ihre Kapazität und sind besser vorhersagbar für den Business. Team-Mitglieder können sich besser identifizieren, wenn sie nur einem Team zugehören!

Stabile Teams haben auch eine stetige Velocity-Steigerung je Sprint, idealerweise um die 10%, bis sie nicht ihre Hyperproduktivität erreicht haben. Basierend auf die erreichte Velocity vom vorherigen Sprint, kann ein Team die erledigten Punkten +10% (Points) für das neue Sprint einplanen. Das nennt man Pattern " Yesterday's Weather". Es hilft dem Team besser zu planen.

Zum Download des "Yesterday’s Weather " Tools.

Die Regel besagt, dass das Team mit der Story aus dem Product Backlog anfangen soll, die den größten Business Value hat. Meistens hat ein Team Schwierigkeiten erfolgreich den Sprint abzuschliessen, weil es nicht auf eine Story aus dem Backlog fokussiert ist und viel zu viel WiP ( work in progress) hat. Pattern Swarming betrifft genau diese Fokussierung der Aufmerksamkeit und Unterstützung des Teams auf diese Story, bis sie nicht abgeschlossen und auf DONE gesetzt wird. Wenn das Team dem Verantwortlichen nicht tatsächlich helfen kann, sorgt es wenigstens dafür, das der nicht unterbrochen oder abgelenkt wird!

Ein Scrum Team wird oft mit Unterbrechungen konfrontiert, die seine Produktivität beeinträchtigen können. Damit diese nicht zu chronischen Dysfunktion des Teams werden, helfen einfache Regeln:

Das Ziel ist es am Tagesende eine fehlerfrei Codebasis zu haben ( completely clean base of code). Beseitigen Sie die Fehler in weniger als einen Tag! Wenn Sie einen Bug zu der Bugliste oder Sprint Backlog hinzufügen, behandeln Sie ihn doppelt! Ist der Fehler nicht innerhalb eines Tages zu beseitigen, ist das ein Indiz für ernste Probleme in dem Produktdesign! Sie müssen das Problem spätestens in der Sprint-Retrospektive besprechen!

" No problem is a problem!" besagt die Mantra des japanischen Managements! Die Agilität bedeutet sehr schnelle Anpassung zu Veränderung und sehr schnelle Reaktion auf die Veränderung! Entsprechend ist die schnelle Identifizierung von Problemen und deren schnelle und richtige Beseitigung ganz im Geiste der Agilität. Es ist wichtig für das Scrum Team und in der Verantwortung des Scrum Masters eine Emergency Procedure (Notfall-Prozedur) vereinbart zu haben und zu benutzen, falls und sobald sie Risiko identifizieren. Diese Prozedur muss auch den Product Owner involvieren! Die Kaizen Mentalität verlangt die Beseitigung der Problemquelle und eine Veränderung in der Arbeitsweise, die zum Risiko geführt hat. 

Nur wenige Scrum Teams erreichen ihre Überproduktivität ( hyperproductivity state). Der Grund dafür ist, dass nicht jedes Team seine Hindernisse richtig identifizieren und diese dann auch schnell beseitigen kann. Es gibt Hindernisse, deren Beseitigung eine extreme Fokussierung der Anstrengungen des Teams über längere Zeit in Anspruch nehmen kann. Langsame Ergebnisse können das Team demotivieren! Identifizieren Sie bei der Sprint Retrospektive das wichtigste Hindernis und konzentrieren Sie die Kraft des Teams auf seine Beseitigung in dem darauf folgenden Sprint! 

Jedes der Patterns setzt voraus das nächste Pattern. Wenn ein Scrum Master sie zusammen und effizient einsetzt, kann er nicht nur die üblichen Scrum Fallen umgehen, sondern auch die Wettbewerbsfähigkeit des Unternehmens bedeutend steigern.