Seit ich im Jahr 2011 meine Zertifizierung zum Scrum Master gemacht habe und seit dem eine ganze Reihe der unterschiedlichsten Teams begleiten durfte, habe ich immer wieder ein Phänomen beobachtet das ich leider nicht genauer als eben ein „broken team“ oder „irgendwie dysfunktional“ beschreiben kann. Damit will ich nicht das nächste Buzzword erfinden sondern es ist wie ich sage: es ist irgendwie nicht greifbar, es ist nicht das eine Ding, das nicht funktioniert, es scheint irgendwie ständig irgendwo „der Wurm drin“ zu sein.
Die Symptome …
Das Scrum-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 und in der Retrospektive 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 die 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 Sprintboard?).
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 immer 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 im Sprint ist so die erste echte Hürde, die erste Herausforderung der wir begegnen, da wird den meisten Teams zum ersten Mal klar: das könnte auch mal anstrengend werden, das wird kein Selbstläufer. Da kann die Reaktion doch nicht sein: dann schaffen wir das lieber ab.
„Fokus, Mut, Offenheit, Commitment und Respekt„, wisst ihr noch?
Zunächst müssten wir uns darauf einigen, dass z.B. in Bezug auf das Sprintziel ein 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.
Wenn wir unsere Teams dazu befähigen wollen, Versprechen abzugeben die sie auch einhalten können, dann fiele mir kein anderes Herangehen ein. Wenn wir das nicht wollen, ist Scrum vielleicht nicht das richtige Werkzeug.
Und jetzt?
Ganz ehrlich? Abreißen, neu machen. Oder ein bisschen 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.
Tatsächlich ist das deutlich weniger aufwändig als es klingt. Die nötigen Prozesse, Rollen, Artefakte, Zeremonien und Metriken sind ja da, wir müssen sie nur benutzen und das kann man lernen.
Natürlich 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. Wir können auch nicht alles auf einmal ändern, sonst riskieren wir unsere Arbeitsfähigkeit. Ergo werden wir Wege finden müssen, mit den Unzulänglichkeiten an denen wir gerade nicht arbeiten, eine Weile zu leben. So kann schonmal ein Jahr vergehen bis man mit einem stabilen end-to-end-Prozess dasteht.
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.
Warum auch nicht? Wir sind als Scrum Team eine überschaubare Truppe von höchstens 10 Leuten, da kann jeder gehört werden, da kann sich jeder einbringen. Da haben wir dediziert einen Scrum Master der sich um den größten Teil der organisatorischen Herausforderungen kümmern kann.
Wir haben alles was wir brauchen, wir müssen es nur einfach mal machen. Und der perfekte Zeitpunkt dafür ist immer JETZT.
Also los …
In der nächsten Retrospektive wendet der Scrum Master all seinen Charme auf, um dem Team zu erklären, dass und warum es wichtig ist, dass wir alle unsere Bemühungen in den Retrospektiven darauf richten die folgenden Dinge zu erfüllen:
- bevor ein Item aka Story unseren Refinement-Prozess verlässt
- beschreibt es so exakt wie nötig was wir liefern sollen
- beschreibt es so exakt wie nötig was wir tun um müssen um das Versprochene zu liefern
- hat es eine numerische Größenbeschreibung die wir im Planning zur Vorhersage verwenden können. Genau genug, dass in einem abgeschlossenen Sprint die Durchlaufzeiten zu dieser Größenbeschreibung passen.
Wenn wir Scrum machen, wäre die Empfehlung sich da einer DoR zu bedienen und per Planning Poker eine Größenbeschreibung in Story Points zu verwenden. Wer Userstories mag, bitte. Wer nicht, wird einen anderen Weg finden.
- 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, Sprintbacklog 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. Wenn Betrieb, Störungs- und Fehlerbeseitigung zum Störfaktor geworden ist, wird das in einen eigenen Prozess ausgelagert. Produktanforderungen werden mit dem PO besprochen. Der Umfang von Stories wird im Refinement besprochen, nicht im Daily. Alles was Verfügbarkeit kostet ist transparent auf unserem/n Board/s zu erkennen. Wir können liefern was wir versprechen.
Das Sprintbacklog ist ein Kanban-Board, das funktioniert am besten wenn die Items geräuschlos darüberlaufen. Punkt 1.) wäre eine wichtige Voraussetzung dafür, die andere ist: aus dem laufenden Sprint werden keine Ressourcen abgezogen und es werden keine Änderungen am Umfang einzelner Stories vorgenommen.
Ja, manchmal ist das unvermeidlich. Dann ist es eben so: Sprintabbruch (wem das zu martialisch ist: Sprintunterbrechung), hinsetzen, neu planen.
„respond to change“ – wollten wir doch schon immer mal versuchen. - 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.
Ich kann das Entsetzen im Gesicht des Lesers schon ahnen, der sich haareraufend fragt: „Wie soll man denn das alles …???“
Vorschlag: iterativ und inkrementell. Ein Schritt nach dem anderen, erstmal die dicken Brocken aus dem Weg räumen, über die Frage ob ein Daily wirklich exakt 15 Minuten dauern muss, können wir uns Gedanken machen, wenn es sonst keine größeren Baustellen mehr gibt. Dann ist auch wieder Zeit fürs visionieren und – für die die möchten – die „Zeitung von morgen“.
Für den Moment jedoch ist ein stabiler Prozess, der Entwicklung und Betrieb in einem Team und eine praktikable Zuordnung von Ressourcen (aka Arbeitszeit) ermöglicht, unsere erste Priorität und wir müssen wirklich nichts weiter tun, als endlich anzufangen, das in unser Tagesgeschäft zu tragen.
Und wo wir gerade von anfangen reden: zu unseren Grundwerten gehören Mut und Commitment, auch das klingt nach einem guten Anfang.