Vom Suchen und Finden eines Projektplans

Anfangs sind Scrum-Implementationen recht übersichtlich. Dem Aufsetzen von Teams folgt eine intensive Lern- und Ausbildungsphase. Wenn alle Akteure ihre Rolle kennen und selbständig ausüben können, ist diese Phase zu Ende. Manche glauben dann, die agile Transformation sei nun ebenfalls abgeschlossen.Das aber ist ein Irrtum. Denn Teams, die nach Scrum arbeiten, sind die eine Herausforderung. Die andere Herausforderung besteht im Umbau des gesamten Unternehmens hin zu einer Organisation, die erfolgreiche Produktentwicklung in den Mittelpunkt all ihrer Tätigkeiten stellt.Und spätestens hier brauchen wir ihn: Den Projektplan für die Scrum-Implementierung. Ihn zu schreiben, ist keine leichte Sache. Auf unserem aktuellen Projekt glaubten wir schon, ihn zu haben. Für die kommenden sechs Monate hatten wir Woche für Woche die jeweils zu erreichenden Ziele eingetragen. Neulich habe ich ihn mir im Rückblick angeschaut und musste feststellen: Die zeitliche Schiene hat nichts gebracht außer der Illusion von Kontrolle. Das, was wir für Anfang Januar eingeplant hatten, ist tatsächlich im März aktuell geworden. Manches hat sich zwischenzeitlich als irrelevant erwiesen. Und vieles, das wir überhaupt nicht auf dem Schirm hatten, beherrscht jetzt unsere Arbeit.Was war passiert? Wir hatten versucht, in die Kristallkugel zu blicken und dabei das festzumachen, was sich nicht festmachen lässt. Die Zukunft heißt nicht umsonst Zukunft - und jeder, der sie vorauszusagen können glaubt, übernimmt sich ein wenig.Drei Monate später. Wir stehen vor folgender Situation: Die Scrum-Implementation nimmt vollen Lauf. Das Unternehmen hat beschlossen, die gesamte Entwicklung auf Scrum umzustellen. Das Fehlen eines Projektplans ist jetzt umso deutlicher. Unsere Kalender platzen vor Terminen, wir arbeiten sie nur noch ab. Und noch schlimmer: Keiner weiß so richtig, wo wir in der Implementation stehen. Die ersten fangen an zu glauben, wir seien jetzt mit Scrum fertig - und reagieren mit Unverständnis auf die Forderung des Managements nach weiteren Veränderungen.In dieser Situation setzen wir uns nochmal hin - und schreiben alle Themen runter, die uns einfallen. Wir sortieren es - was ist Aufgabe des Transition Teams, was gehört zu den ScrumMastern und was zu den Product Ownern? Und wir versuchen es erneut auf eine zeitliche Achse zu bekommen. Wir wissen aus vergangener Erfahrung: Kalenderwochen sind eine zu kleine, zu detaillierte Einheit, um eine erste Orientierung zu bieten.Also gehen wir gröber ran und ordnen die Themen vier Entwicklungsstufen zu:

• Laufen - hier geht es darum, nach Scrum zu arbeiten (mit Sprints anfangen, das Team etablieren, von Scrum erzählen).
• Sich öffnen - auf dieser Stufe geht es um die Herstellung von Transparenz (erste Impediments werden sichtbar, das Team schafft sein Commitment nicht).
• Erkennen - jetzt fängt die Organisation an, zu wissen, wohin sie gehen möchte (warum machen wir überhaupt Scrum, was ist unsere Produktvision und wie möchten wir sie erreichen?).
• Meistern - auf dieser letzten Stufe sind die Akteure ihrer Organisation immer einen Schritt voraus, Veränderung und permanentes Lernen wird zum Normalzustand.

Der Vorteil: Sind diese Stufen erstmal hinreichend klar charakterisiert, können wir einschätzen, wo die Scrum-Implementierung gerade steht und was noch alles vor uns liegt. Wir können auch sagen, welche Themen zwar wichtig, aber in der jetzigen Entwicklungsstufe noch nicht relevant sind. Noch deutlicher wird das Bild, wenn in einem weiteren Schritt für jedes Team (Transition Team, SM- und PO-Team) möglichst eindeutig beschrieben wird, woran wir erkennen können, auf welcher Stufe sich die Teams gerade befinden. Ein SM-Team, das von seinen vielen Impediments geradezu erschlagen wird, weil es nicht weiß, wohin es damit gehen soll, steht vermutlich auf der zweiten Stufe: Denn die Probleme sind sichtbar geworden, aber der Blick der ScrumMaster ist noch auf die Probleme, nicht auf die Lösungen gerichtet.Woran merken wir, ob unser Projektplan funktioniert?Wenn wir jeden Freitag in den Plan blicken können und daraus unsere Aufgaben für die kommende Woche entwicklen können. Wenn wir Kurs halten können, steuernd eingreifen können - und dann auch erkennen, welche Themen gerade gar nicht wichtig sind, und wo wir unbedingt noch nachhaken müssen. Wenn wir einem Product Owner den Plan zeigen können - und er ohne viel Nachdenken sagen kann, auf welcher Implementierungsstufe wir uns gerade befinden - und was wir als nächstes erreichen möchten.Wie ist Eure Erfahrung bei größer angelegten Scrum-Implementationen? Woran habt ihr gemerkt, ob die Implementation noch auf Kurs ist? Und wie stellt ihr fest, was als nächstes kommt, was überhaupt noch zu tun ist, bevor die Implementation abgeschlossen ist? Ich bin gespannt auf Eure Erzählungen.