Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

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.

  • Enrico

    Hallo,

    ich selber handhabe Scrum Implemntierungen so gut es geht agil. Nach dem Leitsatz „Planung ist in Scrum alles, der Plan ist nichts“ erstelle ich mir ein Backlog mit den wichtigsten Schritten bei der Scrum Implementierung und gehe diese mit meinem Team synchron zu den Teamsprints an. Dieses Backlog ändert sich, je nach auftauchen neuer Aspekte oder Anforderungen und wird von uns priorisiert.

    Ein häufiges Problem sehe ich darin, dass man vorausschauend nicht sagen kann, wann ein Team, eine Abteilung oder ein Unternehmen bereit ist einen weiteren Schritt bei der Implementierung zu machen. Daher bekommen alle meine Schritte prüfbare Prerequisites auf die wir hin arbeiten. Sobald diese erfüllt sind, geht es mit den nächsten Schritten bei der Implementierung weiter.

    Anhand des Backlogs können wir letztendlich sehen, welche Schritte noch vor uns liegen – Anhand des Release Backlogs, aber auch was wir schon erreicht haben.

    Und ich stimme grundsätzlich zu: Die Scrum Implementierung endet nicht, wenn alle Beteiligten ihre Rollen verstanden haben und ausführen können. Ich würde sogar weiter gehen und sagen, dass hier die Implementierung erst richtig anfängt, da man sich nun um tieferliegende Herausforderungen (z.B. Schnittstellen zu bisher unabhängigen Abteilungen, Verfeinerung der Entwicklungsprozesse, Änderung von Unternehmensstrukturen, etc.) kümmern kann und muss.

    BTW: Ich habe auch die Erfahrung gemacht, dass Entwicklungsteams sich wesentlich schneller im agilen Umfeld zurecht finden bzw. agile Mechanismen annehmen, als POs und sonstige Führungspersonen dies im Change Prozess tun. Dies sollte man klar bei der Planung berücksichtigen und entsprechende Prozesse entwickeln, die für diesen „Personenkreis“ den Einstieg und das Umsetzen des Scrum Prozesses leichter machen (insbesondere im Multiprojektumfeld mit verteilten Teams)

    Herzliche Grüße

    • Bernd Krehoff

      Enrico, danke für Deine Antwort. Den Aufbau eines „parallelen Backlogs“, wie Du ihn beschreibst, finde ich spannend, zumal sich das ja dann auch visuell darstellen lassen kann, z.B. als Agile Map (http://guide.agilealliance.org/subway.html).

      Mich würde noch interessieren, wie die Implementierungsschritte bei Dir aussehen und was die dazu gehörigen Prerequisites sind. Kannst Du mir vielleicht ein Beispiel nennen?

      Herzlichen Gruß
      Bernd