4Max/shutterstock.com

10. Dezember 2014 / von Markus L. Dechert

Waterfalling
the
Sprint

Eine kleine Bildergeschichte über ein beliebtes Anti-Pattern.

Vermutlich kennt das der ein oder andere: der Sprint geht los und auf dem Tisch liegt eine Anforderung, die eigentlich zu groß und zu unverstanden ist, um umgesetzt zu werden. Da heißt es Zeit sparen und die erst schlechteste Methode wählen, um die User Story doch noch mit ruhigem Gewissen anzufangen. Diese Methode ist oft der Mini-Wasserfall über einen oder mehrere Sprints.

Doch mal ganz von vorne. Es ist ein nasskalter Novembermorgen. Das Team trifft sich zum Sprint Planning [1]. Von der 45-Minuten-Timebox sind noch 43 Minuten übrig.

        Scrum-Team mit ScrumMaster und Product Owner

Dirk, der Product Owner, legt einige User Stories auf den Tisch. Er möchte möglichst viele davon umgesetzt bekommen. “Diese Story hier hat prio”, hört man Dirk sagen, “das Hauptfenster brauchen wir möglichst schnell”. Paul, der Scrum Master mit dem treuen Schäferhundeblick, wird hellhörig [2]. Er bemerkt “Das Teil haben wir letzte Woche mit 20 Punkten gepokert!”. Dirk hat keine Lust auf diese Diskussion und kontert: “Ja, und? Unsere Velocity liegt bei 23 Punkten, sollte doch passen oder?

Product Owner stellt zu große Anforderung vor

Kurze Stille. Dirk überlegt sich, dass das Argument garnicht so gut war, weil er gerne auch noch seine zweite Prio-1-Story platzieren möchte. Aus seiner jahrelangen Erfahrung in der Erstellung von Projektstrukturplänen fällt ihm schnell eine Planungsalternative ein: “Passt auf, wir teilen das Ding einfach in kleinere Arbeitspakete auf und schätzen die neuen Stories dann schnell. Am Besten definieren wir erstmal was gemacht werden muss und designen die GUI, dann setzt ihr sie um und dann machen wir noch den Test und die Doku.

Die Anforderung wird in Arbeitsschritte aufgegliedert

Ellen und Frank aus dem Team schauen ein wenig skeptisch. Paul hadert, kann sein Bauchgefühl aber auch nicht artikulieren.

Nach der Schätzung stehen Nummern auf den Pappkarten: 5 Story Points auf der Design-Karte, 8 Punkte auf der Implementierungskarte und 3 auf der Karte für Test und Doku. Tatsächlich schienen Paul, Ellen, Frank und Hans die Einzelaufgaben für sich kleiner und weniger komplex zu sein. Hans ist skeptisch und fragt in die Runde “Ich weiß auch nicht so richtig, aber ist es richtig, dass aus den 20 Punkten nun 16 geworden sind?” Paul ist zwar selbst nicht so recht überzeugt, beruhigt Hans aber “Bei User Stories ist es doch normal, dass die Punktzahl sich beim Herunterbrechen auf kleinere Stories ändert. Manchmal wird’s mehr und manchmal eben weniger.

Nun könnte die Geschichte auf zwei Art und Weisen weiter gehen.

Variante 1: Der flache Wasserfall mit dem langsamen Strom

Frank meint “Ich kann ja schlecht mit der Umsetzung anfangen, wenn ein anderer noch die GUI definiert.”. “Schon klar.”, meint Dirk, “deswegen bringe ich die anderen Stories dann für die nächsten Sprints mit.” Außerdem freut er sich, dass er neben der 5-Punkte-Design-Story nun seine zweite Prio-1-Story unterbringen kann.

 Flacher Wasserfall - Arbeitsschritte werden in aufeinanderfolgende Sprints geplant

Im Review nach dem ersten Sprint stellt das Team fest, dass sie das Design zwar fertigstellen konnten, aber mit dem Ergebnis eigentlich nichts wirklich Werthaltiges geschaffen haben. “Naja, gut, das haben wir ja auch so gesagt. Morgen kommt ja dann die Implementierungs-Story.” Ohne es sich anmerken zu lassen, ärgert Dirk sich ein wenig, da er für sich feststellt, dass Implementierung und Test des Themas “Hauptfenster” das Team nun für zwei weitere Sprints beschäftigen wird und ihm das die eigentlich schon eingeplanten Kapazitäten nimmt.

Flacher Wasserfall - Arbeitsschritte werden in aufeinanderfolgende Sprints geplant

Tatsächlich schafft es das Implementierungs-Kärtchen ans Board für den nächsten Sprint. Ellen ist echt fit und hat den Dialog mit Hilfe von Franks Beschreibung in Rekordzeit herunter programmiert und präsentiert das Ergebnis stolz im Review. Dirk ist zufrieden und froh, dass nun wieder Raum ist für die nächste dringende User Story.

Am darauf folgenden Tag ist erneut Sprint Planning. Dirk möchte seine Story einbringen und hat die Test-Story im Product Backlog weit nach unten priorisiert. Paul ist verärgert. Dirk zitiert das agile Manifest “Respond to Change over Following a Plan!” [3]. Paul kontert mit den schlechten Erfahrungen entfallener Regressionstests aus der Vergangenheit. Nach einem kurzen Wortwechsel, legt Dirk die Test-Karte auf den Tisch und äußert den Wunsch, dass die eigentlich nächste User Story aber bitte mit höherer Prio angegangen werden soll.

Flacher Wasserfall - Arbeitsschritte werden in aufeinanderfolgende Sprints geplant

Variante 2: Der steile Wasserfall mit Verwirbelungen im Tal

Nach der Schätzung rechnet Ellen vor: “5 plus 8 plus 3 sind 16 Punkte. Wir hätten sogar noch 7 Luft.”. Der ruhige Hans meldet sich zu Wort und erinnert “Stimmt, aber die 20 Punkte-Story hätten wir ja auch nur mit Bauchschmerzen mitgenommen, oder?”. Das Team nimmt die drei User Stories in den nächsten Sprint.

 Steiler Wasserfall in einem Sprint - Alle Arbeitsschritte sind in einem

Im Review stellt Frank entschuldigend fest: “Irgendwie sind wir uns ständig auf den Füßen herum getreten. Die Design-Story haben wir jetzt fertig. Mit der Implementierung haben wir angefangen aber beim Testen konnten wir noch garnichts machen.

Dunkle Wolken ziehen über’s Land

Dunkle Wolken

Im ersten Fall hat das Team drei Sprints auf einmal geplant und sich so die Freiräume genommen, die es braucht, um auf Änderungen zu reagieren.

Im zweiten Fall waren die Stories abhängig voneinander, sodass einer auf den anderen warten musste und so Zeit verschwendet wurde.

In beiden Szenarien hat es das Team eine unterdurchschnittliche Leistung gezeigt seine bisherige Velocity nicht erreicht. Viel schlimmer noch, es hat im zweiten Fall sein Commitment gebrochen. Wer das einmal erlebt hat, weiß: das macht keinen Spaß!

 

Was ist passiert?

Die letzte gute Entscheidung in der Geschichte war es, “Nein!” zu sagen und die User Story “Hauptfenster” nicht aufzunehmen. Warum eigentlich? Ist “Hauptfenster” denn überhaupt eine User Story und wenn ja, warum ist sie schlecht?

Die klassische Form für eine User Story ist “Als <Rolle> möchte ich <Ziel/Funktion>, um <Nutzen>” [4]. “Hauptfenster” ist also eher ein Merker für eine umzusetzende Anforderung, denn eine Art User Story. Anforderungen sind nicht automatisch schlecht formuliert, wenn sie in anderer Gestalt daher kommen.

Was der Anforderung “Hauptfenster” fehlt sind einige wesentliche Eigenschaften. Eine praxistaugliche Methode zur qualitativen Betrachtung von Anforderungen im Allgemeinen bieten die INVEST-Kriterien [5]. Eine gute User Story bzw. Anforderung soll sein:

IIndependent (Unabhängig, ihre Umsetzungsreihenfolge spielt keine Rolle)
NNegotiable (Verhandelbar in Bezug auf Details oder Aufteilung)
VValuable (Werthaltig, sodass die Lieferung unmittelbar zur Wertschöpfung beiträgt)
EEstimatable (Schätzbar und damit auch verstanden, so können Aufgaben abgeleitet werden)
SSmall (Klein und damit überschaubar)
TTestable (Testbar und klar hinsichtlich der Akzeptanzkriterien)

Mit diesem Wissen sieht man, dass nicht nur die ursprüngliche Anforderung, sondern auch die drei abgeleiteten Anforderungen schlecht formuliert sind:

  • Unabhängig: Hinsichtlich der Anforderung “Hauptfenster” kann man nicht sagen, ob diese unabhängig ist, die drei abgeleiteten Anforderungen bauen jedoch aufeinander auf.
  • Verhandelbar: Hat das Team verstanden, wie das Hauptfenster aussehen soll? Vermutlich nicht. Ohne zu wissen, welche Teile wichtig sind, können Sie nicht mit ihrem Product Owner darüber verhandeln, ob weniger wichtige Teile vielleicht später umgesetzt werden könnten. Mit der gleichen Argumentation bleiben auch die abgeleiteten Anforderungen atomar.
  • Werthaltig: Code ohne Regressionstests lässt sich schwer erweitern und taugt nicht als Grundlage für weitere Entwicklung. Aber mit Testfällen alleine wird der Kunde kein Geld verdienen. Daher liefern nur Code und Tests zusammen eine werthaltige Einheit. Wir können außerdem davon ausgehen, dass das erstellte Design-Konzept auf kein Geschäftsziel des Kunden einzahlt. Im Idealfall landet es nach der Entwicklung im Papierkorb, im Negativfall wird es Mitleid zur Dokumentation geadelt und verursacht weitere Pflegeaufwände.
  • Schätzbar: Je klarer eine Anforderung, desto präziser ist eine Schätzung möglich. Stories mit 13 Punkten oder mehr sind erfahrungsgemäß eher unverstanden und die Schätzung ist wenig akkurat [4, 7].
  • Klein: 20 Punkte hören sich nicht klein an und die Anforderung ist wahrscheinlich nicht immanent komplex.
  • Testbar: Die Anforderungen beschreiben noch nicht einmal, wem sie welchen Nutzen sie stiften sollen. Insbesondere hinsichtlich der Anforderung “Testen” ist es schwer vorstellbar, wie hierfür zusammen mit Stakeholdern des Fachbereichs Akzeptanzkriterien aufgestellt werden sollen.

Aus der Diskussion geht bereits das Kernproblem hervor. Das Team und sein Product Owner suchten nach einer schnellen und einfachen Lösung. Sie teilten die große User Story in Arbeitsschritte. Wer mit INVEST arbeitet, weiß dass es mühsam ist, gute User Stories zu schreiben, sich die Mühe aber auszahlt.

Natürlich ist das Eingangsproblem eher die Größe. Große Anforderungen sind in der Regel auch unverstanden. Das ist allerdings normal. Der Product Owner diskutiert mit Testern und Entwicklern sowie den Stakeholdern aus den Fachbereichen, um das Verständnis zu entwickeln und die Anforderung in kleinere, überschaubare Teile aufteilen zu können.

Die symptomatischen Probleme sind im Beispiel die Abhängigkeit zwischen den Arbeitsschritten sowie deren mangelnde Werthaltigkeit.

Das Anti-Pattern

Ein Anti-Pattern […] ist in der Softwareentwicklung ein häufig anzutreffender schlechter Lösungsansatz für ein bestimmtes Problem. […] In der Regel entstehen Anti-Pattern wider besseres Wissen, durch mangelnde Erfahrung oder fehlende Qualifikation. Zu beobachten ist allerdings auch die bewusste Verfolgung in bestimmten Szenarien, um einen bestimmten Zweck zu erreichen. Die Auswirkungen des Auftretens von Anti-Pattern reichen von marginal bis unternehmenskritisch.

Das Anti-Pattern in unserer Geschichte wird auch “Waterfalling the Sprint” genannt [8].

Waterfalling the Sprint” bedeutet die Anwendung einer zeitlich orientierten Strategie, aus der Projektstrukturplanung des klassischen Projektmanagements, auf die agile Planung [9]. Ein Projektstrukturplan dient der Planung und Kontrolle von Arbeitspaketen. Kontrollaufwände gelten im agilen Umfeld als Verschwendung, weil der Kunde aus Kontrollergebnissen keinen Wert schöpfen kann. Das agile Gegenstück ist die Transparenz, also das ständige Sichtbarmachen von Fortschritt und Problemen durch das Team.

Typischerweise sind Arbeitspakete im klassischen Projektmanagement größer. Neben einem zeitlich orientierten Schnitt in Arbeitsschritte, folgen sie auch gerne mal dem Schnitt technischer Komponenten (z.B. Datenbank, GUI). Eine gute Praxis der agilen Entwicklung ist es Anforderungen fachlich zu schneiden. Dieser Praxis schließt sich auch die Empfehlungen des Project Management Institutes (PMI) an [8].

Bezogen auf unser Beispiel könnte eine fachliche Zergliederung in werthaltige Pakete wie folgt aussehen. Sie können besser verstanden und überblickt werden und sind in der Regel unabhängiger voneinander.

Sinnvolle Unterteilung der Anforderung

Fazit

Nein!” sagen ist eine Tugend! Für das Team gilt es, dabei auch konsequent zu bleiben und sich auf keinen Kuhhandel einzulassen. Product Owner und Team können Anforderungen mit dem Charakter von Arbeitsschritten einfach erkennen. Derartige Anforderungen führen vorhersagbar zur Eintrübung der Team-Produktivität sowie zu einer reduzierten Kapazität für neue Aufgaben während der folgenden Sprints. Erfahrene Product Owner wissen daher, dass eine vom Team abgelehnte Anforderung nichts Schlechtes ist. Im Gegenteil, sie nutzen den Hinweis und stoßen Diskussionen mit Stakeholdern und den Entwicklern und Testern des Teams an. Sind die Anforderungen hinreichend gut verstanden, leitet er anhand fachlicher Gesichtspunkte neue User Stories ab. Sie sind anschließend kleiner und besser verstanden. Im Idealfall erfüllen diese User Stories die INVEST-Kriterien, zumindest aber sind sie untereinander unabhängig und jede für sich ist werthaltig. Zeitlich orientierte oder nach technischen Komponenten orientierte Arbeitspakete lassen diese Eigenschaften in der Regel vermissen.

Links

  1. Einen netten kleinen Überblick über Scrum gibt’s hier:
    http://www.dasscrumteam.com/scrum
  2. Scrum does have a secret handshake […] also involves ‘woofing’ like a sheepdog
    http://edgibbs.com/2007/03/04/scrum-handshake/
  3. Ein Wertebekenntnis, das Software Engineering nachhaltig verbessert hat:
    http://www.agilemanifesto.org/
  4. User Stories kommen noch aus dem eXtreme Programming. Scott Ambler schrieb dazu:
    http://www.agilemodeling.com/artifacts/userStory.htm
  5. Original-Artikel von Bill Wake zu den INVEST- und SMART-Kriterien für User Stories:
    http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  6. Ein PSP dient der Planung und Kontrolle im klassischen Projektmanagement:
    http://de.wikipedia.org/wiki/Projektstrukturplan
  7. Ein Statement von Mike Cohn gegen eine spitzfindige universelle Trennung von User Stories versus Epics versus Themes.
  8. Im Scaled Agile Framework (SAFe) wird auch auf die Gefahren für die Sprint-Durchführung hingewiesen:
    http://scaledagileframework.com
  9. Auch das PMI empfiehlt in seinem Body of Knowledge (PMBoK) einen Schnitt nach Lieferartefakten:
    https://www.workbreakdownstructure.com/work-breakdown-structure-according-to-pmbok.php

 

Autor

Markus L. Dechert Markus ist seit August 2013 als Managing Consultant bei der Accso – Accelerated Solutions GmbH und beschäftigt sich mit agilem Projektmanagement, betrieblichen Themen sowie Java- und .NET-Entwicklung.
Weitere Artikel

Das könnte Sie auch interessieren