Agile Mythen: Teams planen nicht

Stimmt es, 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.

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

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.

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?