Agile Mythen Teil 3 - Bei Scrum wird nicht geplant (Chaosgefahr!)

Ja, das ist richtig. Einer der Werte aus dem Agilen Manifest spricht ja davon, dass wir das Reagieren auf Änderungen wichtiger sehen, als das Folgen eines Plans.

"Responding to change over following a plan"

So weit so gut. ABER:

Viele verstehen das Agile Manifesto falsch und denken, dass die Werte auf der rechten Seite (siehe www.agilemanifesto.org) im agilen Umfeld nicht mehr gebraucht werden. Das ist natürlich quatsch, denn unter den vier Werten steht ja auch: "That is, while there is value in the items on the right, we value the items on the left more."

Das spricht dafür, dass es in der agilen Entwicklung doch irgendwie Pläne geben muss. Und Prozesse, Tools, Dokumentation und Verträge. Aber halt irgendwie anders, als es in vielen klassischen Projekten der Fall ist.

Frühzeitiges Planen birgt Gefahren

Heute gehe ich nur auf das Planen in agilen Projekten ein. Theoretischerweise ist es ganz einfach: Wir planen in agilen Projekten genau so viel, wie nötig ist. Aber eben nicht im Vorfeld den ganzen Scope des ganzen Projektes per Feinspezifikation.

Nicht selten habe ich erlebt, dass Teams Anforderungen umsetzen, die eine Fachabteilung Monate vor der Umsetzung "im stillen Kämmerlein" formuliert hat. Häufig sind das 1:1 Beschreibungen vorhandener Funktionen, die neu ("Aber irgendwie besser!") entwickelt werden sollen und zusätzlich noch um einige "moderne" Features erweitert werden sollen. Nach der Umsetzung stellen alle fest, dass es so eigentlich nicht sein sollte oder keinen Sinn mehr ergibt, weil sich die Marktlage oder das Kundenverhalten geändert hat. Die Folge sind Verhandlungen über Änderungswünsche und ob die extra berechnet werden und frustrierte Entwickler, weil ihre Arbeit im schlimmsten Fall komplett umsonst war.

Schnelles Scheitern ist erwünscht

In einem agilen Umfeld herrscht Vertrauen und Fehler machen ist explizit erwünscht, weil man dadurch lernen und sich gegenseitig weiterbringen kann. Schnelles Scheitern heißt aber auch, ich entwickle nicht jede Funktion komplett "fertig", bis sie der Spezifikation entspricht, sondern ich entwickle sie inkrementell weiter, so dass ich früh bewerten kann, ob sie (noch) Sinn ergibt.

Stelle ich fest, dass Änderungen nötig sind, wird die Funktion entsprechend angepasst und wird am Ende wahrscheinlich von dem abweichen, was ich am Anfang für richtig gehalten habe.

Spätestens jetzt wird auch deutlich, warum umfassendes Planen am Anfang eines Projektes nicht agil ist. Aber wie planen wir dann?

Evolutionäres Planen

Komplett fixe Anforderungen in einem Projekt sind in den seltensten Fällen sinnvoll. Auch das in einigen Projekte vielleicht sinnvolle Entwickeln von ausführlicher Dokumentation bevor programmiert wird, steht dem agilen Gedanken im Wege.
In einem agilen Projekt werden Anforderungen früh und sehr grob (in Story Points, T-Shirt-Größen oder Gummibären) geschätzt. Diese Schätzungen sind relative Größen, die die unterschiedlichen Komplexitätsstufen von Anforderungen darstellen (dazu folgt noch ein eigener Blog-Eintrag).

Die Anforderungen enthalten am Anfang aber teilweise nur eine sehr grobe Beschreibung oder gar nur die Überschrift. Man muss sich im agilen Umfeld daran gewöhnen mit Unsicherheiten zu leben. Natürlich sind diese groben Anforderungen nicht die Anforderungen, mit denen ein Team mit der Entwicklung beginnt. Vorher gibt es sogenannte Refinements, bei denen alle Beteiligten Fragen klären, die Anforderungen detaillierter beschreiben und Kriterien festgelegt werden, die erfüllt sein müssen, damit diese Anforderungen als erfolgreich umgesetzt gelten (Akzeptanzkriterien).

Je näher der Zeitpunkt der Umsetzung rückt, desto detaillierter wird die Anforderung. D.h. es ist normal, dass Product Owner und Entwicklungs-Team eine Anforderung 3-4 angesehen/besprochen hat, bevor mit der Umsetzung begonnen wird. Erst dann besteht ein klares Bild, was genau umgesetzt werden soll.

Natürlich kann man im agilen Umfeld auch eine Release-Planung machen - mit genügend Anforderungen, die grob beschrieben und geschätzt sind, läßt sich ein Plan entwickeln, wie die Evolution des Produkts ablaufen soll. Die Summe der Story Points, Gummibärchen oder die "Summe" der T-Shirt-Größen ist nach circa 2-3 Sprints eine ausreichend valide Zahl, um in agilen Projekten planen zu können. Natürlich nicht so detailliert und fein heruntergebrochen, wie in klassischen Projekten, aber die Release-Planung basiert auf einer Strategie, die das Produkt erfolgreich machen soll. Wie genau ein bestimmter Teil in z.B. 6-8 Monaten aber umgesetzt wird bleibt hier absichtlich offen, um auf die Entwicklung des Produktes oder des Marktes/der Umstände geeignet schnell und ohne viel Aufwand reagieren zu können.

Das klingt verrückt - aber es gibt sie: diese Erfolgsgeschichten von Projekten, wo sich Auftraggeber und -nehmer so weit vertrauen, dass erfolgreiche Produkte agil entstehen können. Ohne Verlierer. Ich bin froh, dass ich das schon erleben durfte. Lassen wir das doch zu einem Standard werden. :)

Dieser Beitrag ist Teil der Reihe Agile Mythen

Teil 1 - Wir sind doch heute alle agil!

Teil 2 - Das Daily ist Zeitverschwendung
 
Teil 3 - Bei Scrum wird nicht geplant (Chaosgefahr)
Teil 4 - Retrospektiven nur nach Bedarf