Kennen Sie das? Sprint für Sprint bleiben Stories auf der Strecke, die „Blocked“-Spalte quillt über und das Team verliert zunehmend die Motivation. Was einst als ambitioniertes Ziel startete, wird zur sich selbst erfüllenden Prophezeiung: „Das schaffen wir eh nicht…“
Die Symptome …
Häufig zeigt sich folgendes Bild: Das Team steht eigentlich noch am Anfang seiner agilen Transformation. Die Scrum-Ereignisse finden zwar statt, zeigen aber kaum Wirkung – schon weil sie nicht ineinander greifen. Das Daily Scrum wird zur Status-Update-Runde, keiner weiß so richtig was er sagen soll, im Sprint Planning wird lieblos ein Sprintbacklog zusammengeschoben und schulterzuckend der Sprint gestartet, in der Retropektive schreiben wir gerade an einem Zeitungartikel über uns und wie toll wir in einem Jahr sein könnten aber so richtig weiter hilft das gerade auch nicht.
Gleichzeitig offenbart sich, dass DevOps tatsächlich irgendwas mit Betrieb zu tun haben muss: ständige Störungen von irgendwo draußen, die eine ohnehin halbherzige Sprintplanung dann endgültig über den Haufen werfen.
Über die Zeit haben sich Wissensilos gebildet – es sind jeweils nur noch einzelne Teammitglieder, die bestimmte Aufgaben überhaupt noch übernehmen können. Das „Truck-Test“- (aka „Bus Faktor“-) Risiko ist gewaltig, das Team verwundbar.
Und empirisches Arbeiten? Not in my house. Metriken schaut sich schon lange keiner mehr an. Das Burndown Chart verstaubt in den Tiefen von Jira. Von Velocity und Fokus-Faktor will keiner was hören – wer auch, viele der Beteiligten sind ja akut damit beschäftigt, sich gegenseitig mangelnde Agilität und unzureichendes Mindset vorzuwerfen.
Und während dessen bilden sich in den Spalten – die wir für Tickets erfunden haben auf die grade keiner Bock hat – die ersten Häufchen (na kommt, wer hat keine „Blockiert“-Spalte auf dem Sprintbacklog?).
Diese wiederum formen eine beeindruckende „Bugwelle“ aus offenen Stories die von Sprint zu Sprint mitgeschleppt werden (müssen) obwohl eigentlich niemand daran arbeitet. Das führt aber zu den aberwitzigsten Commitments, für die man locker 4-5 Sprints bräuchte und die von Planning zu Planning immer noch gewaltiger werden weil natürlich auch neue Anforderungen den Weg in die Umsetzung finden müssen und weil sich der Manager von heute leider immer noch mehr mit Auslastung beeindrucken lässt als mit Ergebnissen.
Was ist passiert?
Wahrscheinlich haben wir zugelassen, dass sich unser Team und manchmal auch andere Teile der Organisation den Transformationsprozess so hingebogen haben, dass er sich inzwischen schmerzfrei um die Gewohnheiten und Muster des Team herumschmiegt. Schmerzfrei deswegen, weil er mausetot ist. Alles was uns in unbequemer Art und Weise daran erinnert hat, dass wir hier eigentlich mal was transformieren wollten, haben wir ausgebaut oder schauen einfach nicht mehr hin, Scrum ist ja ein Framework das man an seine Bedürfnisse anpassen kann. War doch so, oder?!
Soll eine Agile Transformation jetzt unser Team transformieren oder unsere Interpretation von Agilität?
Ein Beispiel: das Commitment
Es gab – oder gibt ihn noch – einen Trend, Scrum durch Kanban oder dann auch ScrumBan (oder wie auch man das schreibt) zu ersetzen. Sah am Ende in der Regel aus wie vorher, nur halt jetzt ohne dieses deprimierende Anhängsel eines Commitments.
Das Commitment ist so die erste echte Hürde, die erste Herausforderung der wir begegnen, da wird dann zum ersten Mal klar, das könnte auch mal anstrengend werden, das wird kein Selbstläufer.
„Fokus, Mut, Offenheit, Commitment und Respekt„, wisst ihr noch?
Zunächst müssten wir uns darauf einigen, dass Commitment in Scrum nur eines bedeuten kann: Am Ende des Sprints ist das Sprint Backlog leer. Alle Akzeptanzkriterien erfüllt, Definition of Done eingehalten, Status „Done“. Punkt.
S.M.A.R.Te Ziele., messbare Ziele … haben wir oft genug drüber geredet, hier ist unsere Chance.
Noch ein Beispiel:
Wie mache ich das?
Ganz ehrlich? Abreißen, neu machen. Oder vielleicht konstruktiver: wenn die Handlungsfähigkeit des Teams gefährdet ist, bekommen wir mit Prozess-neu-aufsetzen deutlich schneller wieder ein arbeitsfähiges Team als wenn wir versuchen den kaputten Prozess kleinteilig zu reparieren. Ist wirklich so.
Und ist auch relativ geräuschlos umsetzbar, die nötigen Rollen, Artefakte, Zeremonien und Metriken sind da, wir müssen sie nur benutzen.
Trotzdem – kann man gar oft genug sagen – braucht eine solche Transformation Zeit. Wir müssen relativ kleinteilig, oft über Jahre eingeübte Verhaltensmuster ändern, da wird man sehr, sehr viele Dinge, sehr, sehr oft wiederholen müssen. Da kann schonmal ein Jahr vergehen bis man mit einem stabilem Prozess dasteht. Seid bitte, bitte, bitte geduldig.
Und da es ganz ohne Disziplin nicht gehen wird, treffen wir erstmal die folgende Vereinbarung:
- Wir vereinbaren ab jetzt alle Prozessänderungen gemeinsam, daher besteht auch eine gewisse Erwartungshaltung, dass diese Absprachen auch eingehalten werden. Jeder hat zu jeder Zeit das Recht eine Vereinbarung in Frage zu stellen. Aber geschlossene Vereinbarungen bleiben in Kraft bis wir gemeinsam etwas anderes beschließen.
Ich konzentriere mich in so einem Vorhaben dann auf mehr oder weniger vier Punkte:
- bevor ein Item aka Story aus unseren Refinement-Prozess verlässt
- beschreibt so exakt wie nötig was wir liefern sollen
- beschreibt so exakt wie nötig was wir tun um müssen um das Versprochene zu liefern
- eine numerische Größenbeschreibung die wir im Planning zur Vorhersage verwenden können. Genau genug, dass in einem abgeschlossenen Sprint die Durchlaufzeiten zu den Story Points passen.
- im Sprint Planning errechnen wir aus der Verfügbarkeit des vergangenen und des kommenden Sprints und der Velocity des letzten Sprints eine Prognose für den nächsten Sprint. Auf der Basis dieses Prognose verhandeln wir unser Commitment. Das ist eine ziemlich geräuschlose Sache: Prognose, SBL auffüllen, Sprint starten, fertig. Allerdings nur wenn man hier nicht mehr endlos über den Inhalt der Stories diskutiert, also nicht wenn man Refinements hat (was man meistens sollte).
- der Sprint wird vor jeglichen Störungen geschützt. Alles was Verfügbarkeit kostet ist transparent auf unserem/n Board/s zu erkennen. Der Umfang von Stories wird im Refinement besprochen, nicht im Daily. Wir können liefern was wir versprechen.
- so lange das mit dem leeren Sprintbacklog am Sprintende noch nicht klappt (und #Erwartungsmanagement: das wird eine ganze Weile noch so sein, wir leben damit) nutzen wir unsere Retrospektiven dazu den Abstand zwischen uns und „Sprinbacklog leer“ Schritt für Schritt zu verringern. Das, sonst nichts weiter.
Störungen aus dem Tagesgeschäft, sollten wir sofort im Daily betrachten, da würde ich nicht bis zur nächsten Retro warten – alles andere sollte für den Moment nicht wichtiger sein.
Und als Empfehlung sozusagen auf Kosten des Hauses: geht eins nach dem anderen an. Den nächsten Schritt immer erst wenn der letzte auch wirklich abgeschlossen ist.
[ So, ab hier müsste man dem geneigten Leser mit blumigen Worten klar machen, dass, sofern er sich mit der oben beschriebenen Vorgehensweise identifizieren kann, er herzlich ein geladen ist, mit uns eine Retrospektive zu seinem Thema zu machen. ]
Neueste Kommentare