Agile Mythen: Agile Teams planen nicht

Wenn wir die Arbeit von mehreren Menschen an einem Thema nicht absprechen, entstehen Doppelarbeiten, es wird an den falschen Themen gearbeitet oder die Arbeit bleibt schlichtweg liegen. Planung ist also essentiell, um die Arbeit von mehreren Menschen in einem Team zu koordinieren. Es ist dabei egal, ob das Team klassisch entwickelt oder agil. Der Unterschied zwischen den beiden Vorgehensweisen liegt in der Zeit. Agile Teams planen evolutionär bzw. inkrementell, beim klassischen Vorgehen findet die Planung verstärkt zu Beginn eines Projektes statt. Inkrementelle Planung senkt die Kosten ein Projekt zu starten und erlaubt uns schnell auf Änderungen zu reagieren (z.B. bei Anforderungen, Prioritäten) im fortschreitenden Projekt.

Agile Teams planen nicht

Dieses Vorgehen gilt Grundsätzlich erst mal für alle agilen Methoden. Da das agile Framework Scrum sich derzeit so großer Beliebtheit erfreut, wollen wir im Folgenden uns am Beispiel eines Scrum Teams einmal ansehen, wie Planung im Scrum genau statt findet.

Scrum & kurzfristige Planung

Die kürzeste Zeiteinheit in der ein Scrum Team plant ist der Daily Scrum. Das Entwicklungsteam und der Scrum Master treffen sich täglich zum Daily Scrum (Daily). Der Daily dient dem Entwicklungsteam dazu, ihre tägliche Arbeit zu koordinieren und ihren Fortschritt im Sprint zu überwachen. Bei der Koordination der täglichen Arbeit nutzt das Entwicklungsteam drei Fragen, diese helfen den Daily auf die wichtigsten Punkte zu fokussieren. Viele Entwicklungsteams nutzen Burndown – oder Burnup Charts, um ihren Fortschritt im Sprint zu überwachen. So kann das Team eine Aussage gegenüber dem Produkt Owner oder Stakeholdern treffen, ob sie die für den Sprint geplanten Anforderungen pünktlich umsetzen können. Und dies bringt uns zur nächsten Planungseinheit von Scrum Teams der Sprint Planung.

Scrum & mittelfristige Planung

Product Owner

In jedem Sprint plant das Scrum Team, welche Anforderungen es innerhalb eines Sprints umsetzen wird. Ein Sprint ist ein festes Zeitintervall von 1, 2, 3 oder 4 Wochen. Es ist die Aufgabe des Produkt Owners für eine Sprint Planung, ausreichend Anforderungen vorbereitet zu haben und diese untereinander zu priorisieren. Je höher die Priorität einer Anforderung ist, desto großer ist die Chance, dass sie im nächsten Sprint vom Team gezogen wird. Diese regelmäßige mittelfristige Planung führt dementsprechend dazu, dass sich der Produkt Owner:

  • fortwährend mit seinen Anforderungen auseinandersetzt,
  • diese so verfeinert, dass sie innerhalb eines Sprints fertig gestellt werden können
  • und sie zueinander priorisiert.

Um diesem Job gerecht zu werden, muss er sich also regelmäßig während des Sprints mit seinen Stakeholdern und dem Team treffen und an den Anforderungen arbeiten. Dies geschieht im Backlog Refinement Meeting.

Scrum & langfristige Planung

Vielen Kunden und Organisationen genügt es jedoch nicht nur ein paar Wochen, sprich einen Sprint weit zu planen. Spätestens wenn dies der Fall ist sollte ein Scrum Team weiter als bis zum nächsten Sprint denken.

Hilfsmittel Produkt Roadmap

Erfahrene Produkt Owner haben durchschnittlich bis zu 5 Sprints vorbereitet. Vorbereitet heißt in diesem Fall:

  • die Anforderungen sind mit dem Team im Refinement besprochen,
  • Akzeptanz Kriterien sind definiert,
  • das Team hat die Anforderung geschätzt,
  • eine Priorisierung ist festgelegt und
  • die Anforderung zahlt auf das Produkt Inkrement des jeweiligen Sprints ein.

Außerdem sind die Feedbackgeber, die für diese Anforderung besonders wichtig sind, vom Produkt Owner informiert in welchem Sprint die Anforderung dran kommt. Denn es ist für Scrum Teams extrem wichtig, dass sie die entsprechenden Feedbackgeber bei Fragen in diesem Sprint erreichen können, außerdem müssen diese beim Sprint Review anwesend sein.

Jeder Produkt Owner weiß, dass sich der geplante Inhalt für einen Sprint noch verändern kann, da wir bei der Entwicklung Dinge dazu lernen und andere nicht so klappen wie wir es angenommen haben. Aber ist mehr als ein Sprint vorbereitet, bringt dies Ruhe in das Scrum Team. Es erleichtert die Zusammenarbeit mit Schnittstellen und verschafft Zeit sich rechtzeitig mit Anforderungen zu befassen die noch unscharf sind. Im Umkehrschluss heißt dies allerdings auch, dass ein Produkt Owner genügend Zeit haben muss, um sich wirklich um sein Produkt Backlog zu kümmern und das Scrum Team direkten Zugang zu den Feedbackgebern braucht. Denn nur so können Scrum Teams kurze Feedbackschleifen erreichen, wirkliche Entscheidungen bekommen und dementsprechend weiter arbeiten.

Fazit

Im Scrum wird also regelmäßig auf verschiedenen Zeithorizonten geplant. Im Gegensatz zu klassischen Ansätzen mit langen Planungsphasen wird in Scrum zeitnah umgesetzt. Für eine langfristige Planung ist es jedoch entscheidend, dass Produkt Owner genügend Zeit haben, um an den Anforderungen zu arbeiten und eine enge Zusammenarbeit mit Feedbackgebern ist notwendig.

Wir fragen uns daher, wo kommt dieses Gerücht eigentlich her? Schauen Organisationen nicht auf die wirklichen Probleme und schieben das Argument „Agile Teams planen nicht“ nur vor? Was ist eure Meinung dazu?

3 Gedanken zu „Agile Mythen: Agile Teams planen nicht“

  1. Hallo,

    ich denke, das hat sehr viel damit zu tun, dass man dem Management SCRUM als „easy to learn“ verkauft hat.
    Wenn es einfach zu lernen ist und der SCRUM-Guide ja nur so ein paar Seiten hat, wozu muss ich dann noch großartig planen?

    Deshalb fallen ja auch so viele Organisationen mit SCRUM auf die Nase und sind dann enttäuscht, wenn es dann doch alles nicht so einfach ist, wie man sich das erhofft hat!

    Viele Grüße

    Olaf

    1. Stimmt Olaf, das ist auch oft ein Grund dafür.

      In der Umsetzung ist Scrum nicht so einfach wie es sich liest, außerdem ist Scrum nicht das Allheilmittel .
      Ich sehe aber auch oft Scrum Teams oder POs die von der Organisation so vereinnahmt sind, das sie gar nicht mehr dazu kommen mehr als einen Sprint weit zu planen. Oder auch glauben, dass das ausreicht bzw. das man im Scrum nicht weiter denken muss.

      Anna

    2. Hallo Olaf,

      da bin ich völlig deiner Meinung!

      Diese „Münze“ hat zwei Seiten: leicht zu verstehen, gerade am Anfang noch nicht leicht umzusetzen. Echtes Verständnis und Meisterschaft kommen dann erst im tun!

      Der offizielle ScrumGuide (https://www.scrumalliance.org/why-scrum/scrum-guide) ist da auch sehr transparent. Da steht ganz am Anfang in der Definition von Scrum:

      Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

      Scrum is:
      – Lightweight
      – Simple to understand
      – Difficult to master

      Leider wird das häufig „überlesen“.

      Liebe Grüße,
      Sascha

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Deine E-Mail-Adresse wird nicht veröffentlicht, an Dritte weitergeleitet oder anderweitig genutzt.