Kolumne: EnterpriseTales

DevOps Stories: Planung ersetzt Zufall durch Irrtum – Scrum und mittelfristige Planungen

Konstantin Diener

© S&S Media

Lukas’ Cousine hat geheiratet und die Familie zu einer großen Feier eingeladen. Lukas sitzt mit seinem Cousin Robert zusammen. Robert hat nach Abschluss seines Studiums eine Weltreise gemacht und ist seit ca. eineinhalb Jahren bei einem IT-Dienstleister als Entwickler tätig.

  • Lukas: „He, wir haben uns ja super lange nicht mehr gesehen! Ich habe gehört, du warst auf Weltreise, oder?“
  • Robert: „Ja, aber das ist ja auch schon wieder mehr als ein Jahr her. Ich arbeite jetzt als Softwareentwickler.“
  • Lukas: „Wo hat dich deine Reise überall hingeführt?“
  • Robert:„Mein Ziel war es ursprünglich, in Asien, Südamerika und Afrika jeweils mindestens fünf Länder zu besuchen – zusätzlich noch Australien und Neuseeland. In den USA war ich vorher schon für mein Auslandssemester.“
  • Lukas: „Und, hast du das so durchgezogen?“
  • Robert: „Naja, ich habe in Asien festgestellt, dass es da unglaublich viele spannende Länder gibt und in Südamerika auch. Deshalb habe ich mir dort wesentlich mehr angesehen und Afrika ist deutlich zu kurz gekommen. Aber das werde ich später mal mit einer weiteren Reise nachholen.“
  • Lukas: „Wie hast du die Reise finanziert? Hattest du etwas gespart oder Work and Travel gemacht?“
  • Robert: „Teils, teils. Ich hatte einiges gespart und wollte eigentlich damit die komplette Reise bestreiten. In Südamerika ging mir dann aber langsam das Geld aus. Deshalb habe ich dort ein wenig gearbeitet, um den Rest zu finanzieren.“
  • Lukas: „Das klingt sehr spannend!“
  • Robert: „Ich wollte dich aber mal was ganz anderes fragen, Lukas. Du arbeitest doch auch in einem agilen Team, oder?“
  • Lukas: „Ja“
  • Robert: „Nach der Reise habe ich als Softwareentwickler angefangen und bei uns wurde vor einem halben Jahr alles auf Agile umgestellt. Funktioniert das bei euch? Bei uns gibt es im Moment riesigen Ärger und die Geschäftsführung möchte die Umstellung wieder zurückdrehen.“
  • Lukas: „Es gibt natürlich immer wieder Dinge, die nicht funktionieren, aber im Großen und Ganzen sind wir sehr zufrieden. Gibt es bei euch ein besonders schwieriges Thema?“
  • Robert: „Oh ja, das Thema Planung erzeugt den größten Ärger! Unsere Entwickler sagen, dass im agilen Manifest steht, man soll keine Planung mehr machen, weil das Waste sei. Das finden die Kunden, für die wir Software entwickeln, natürlich überhaupt nicht lustig. Die wollen eine ungefähre Vorstellung haben, wie teuer die Software wird. Und Abteilungen wie Marketing und Vertrieb brauchen auch Aussagen, wann ungefähr bestimmte Features entwickelt sind.“
  • Lukas: „Ui, das klingt tatsächlich nach ganz schön viel Ärger.“

 

Abb. 1: Lukas und Robert unterhalten sich über Reise- und Projektplanung

Abb. 1: Lukas und Robert unterhalten sich über Reise- und Projektplanung

Mittelfristige Planung hilft den Stakeholdern und dem Team

Was Robert aus seinem Team erzählt, ist leider ein verbreiteter Irrglaube. Der Satz „Responding to change over following a plan“ wird oft so interpretiert, dass im agilen Kontext Planung obsolet oder sogar schädlich ist. Der Satz sagt aber nur, dass es wichtiger ist, auf Änderungen zu reagieren, als stur an einem Plan festzuhalten. Tatsächlich gibt es in Scrum mit dem Sprint Planning und dem Sprint Backlog eine Aktivität und ein Artefakt, die explizit der Planung dienen. Die Aversion richtet sich meist gegen eine Planung, die über den Sprint hinausreicht, da die beteiligten Softwareentwickler aus dem klassischen Projektmanagement aufwendige und langlaufende Pläne gewohnt sind. Sie fassen ihre Kritik in dem Wort „Waste“ oder Verschwendung zusammen. Dieser Begriff kommt aus der Lean Production bzw. aus Kanban. Er bezeichnet Tätigkeiten, die nicht direkt der Wertschöpfung dienen.

David J. Anderson beschreibt im Buch „Kanban“ [1], wie er vorgehen würde, den Zaun zu streichen – worum seine Frau ihn gebeten hat. Anhand dieses Beispiels verdeutlicht er, dass es neben der wertschöpfenden Tätigkeit (den Zaun streichen) immer auch notwendige, nicht wertschöpfende Tätigkeiten gibt (grobe Planung, Pinsel vorbereiten und säubern, Farben einkaufen etc.). Notwendig sind sie nicht nur für David selbst. Seine Frau möchte auch wissen, wann er ungefähr mit dem Streichen fertig ist und wie viel der Anstrich kosten wird.

Offensichtlich sind die Kunden der Firma auch nicht besonders begeistert darüber, dass die Teams keine Aussagen zu Budget und Zeitplanung machen wollen. In vielen Unternehmen erfolgt die kaufmännische Planung und Steuerung anhand von Budgets. Dafür braucht der Kunde zumindest eine ungefähre Vorstellung, wie viel die Software(-änderung) kosten wird. Für Stakeholder wie das Marketing und den Vertrieb ist es überdies wichtig, eine Vorstellung davon zu bekommen, wann mit bestimmten Features zu rechnen ist. Ein sehr extremes Beispiel beschreibt Jeff Patton in „User Story Mapping“ [2]: Die Firma Globo.com muss bis zur Fußballweltmeisterschaft eine neue Softwareversion fertig haben. Eine zu späte Auslieferung wäre wertlos.

Wir sehen, dass Planungen sowohl für das Entwicklungsteam als auch für die Stakeholder wichtig sind. Weil es sich um nicht wertschöpfende Tätigkeiten handelt, müssen die Erstellung und die Pflege der Planung so schlank und einfach wie möglich sein.

Ausgangspunkt für diese Planung ist ein Ziel. Kein Softwareentwicklungsvorhaben erfolgt ohne konkrete Ziele (Absatz steigern, Marktsegment vergrößern, Supportanfragen reduzieren). Wir überlegen uns in Form eines Plans, wie wir dieses Ziel erreichen können. Das ist vergleichbar mit Roberts Reise. Sein Ziel war es, mit seinem Ersparten möglichst viel von den vier Regionen zu sehen, die er noch nicht kannte. Dazu hat er einen initialen Plan aufgestellt, wie er dieses Ziel erreichen könnte (fünf Länder pro Region).

Abb. 2: Product Vision Sheet

Abb. 2: Product Vision Sheet

Zu Beginn eines Softwareentwicklungsvorhabens machen wir einen groben Plan als Startbasis

Dieses Vorgehen lässt sich auf die Softwareentwicklung übertragen. Das Ziel liegt z. B. in Form einer Produktvision (Abb. 2) und eines strategischen Ziels („In den nächsten drei Quartalen möchten wir den Umsatz mit Produkt X um 25 % steigern“) vor. Ausgehend von diesem Ziel entsteht ein initialer Plan. Getreu dem Geist des agilen Manifests werden wir den Plan immer anpassen, sobald sich eine Änderung ergibt – so wie Robert seine Reiseplanung auch angepasst hat, weil sich seine Ziele verändert haben („So viele spannende Länder in Asien und Südamerika, Afrika hole ich nach“). Da es einen initialen Plan gibt, werden Änderungen zu bewussten Entscheidungen – da die Ziele, Prioritäten oder andere Parameter (Aufwand oder Kosten) in der Realität anders sind als geplant.

Wie sehen die „Reisevorbereitungen“ für ein agiles Softwareentwicklungsvorhaben aus? Sie münden in einem initialen Backlog. Dieses Backlog kann auf verschiedene Weise entstehen:

  • Impact Mapping: Impact Mapping ist eine Methode, die Gojko Adzic im gleichnamigen Buch [3] beschreibt. Die Impact Map – eine spezielle Mind Map (Abb. 3) – visualisiert, ausgehend von einem bestimmten Ziel, wie und mit Hilfe welcher Akteure dieses Ziel erreicht werden soll.
  • User Story Mapping: Anhand der User Journey wird ein „Skelett“ aufgespannt. Dabei bilden die groben Prozessschritte die Wirbelsäule und die detaillierteren User Stories die Rippen [4].
  • Reverse Engineering: In vielen Projekten existiert eine Anforderungsliste des Kunden. In diesem Fall lässt sich oft eine User Story Map bzw. eine Impact Map „rückwärts“ aufbauen.

 

Abb. 3: Beispiel für eine Impact Map (www.impactmapping.org/drawing.html)

Abb. 3: Beispiel für eine Impact Map (www.impactmapping.org/drawing.html)

Im Nachgang werden die Einträge des initialen Backlogs geschätzt. An dieser Stelle ist es am wichtigsten, darauf zu achten, die nicht wertschöpfenden Tätigkeiten so gering wie möglich zu halten. Die oberen Einträge im Backlog sollten detaillierter beschrieben sein. Je weiter eine mögliche Umsetzung in der Zukunft liegt, desto gröber. Für sein erstes Ziel hat Robert sicher vor Abflug bereits ein Hotel gebucht, doch für die Afrikaetappe wäre das sinnlos gewesen.

Es wird in jedem Fall immer Bereiche des Backlogs geben, die detaillierter und andere, die weniger detailliert sind. Um einen Eindruck für den Aufwand des gesamten bisher bekannten Scopes zu bekommen, bietet es sich an, per Äquivalenzschätzung von den detaillierteren Bereichen auf die weiter in der Zukunft liegenden zu schließen. In Abb. 4 ist ein Backlog dargestellt, das durch User Story Mapping entstanden ist. Die groben Prozessschritte sind mit T-Shirt-Größen geschätzt. Was die einzelnen Größen bedeuten, lässt sich an den „Rippen“ erkennen, die im Detail geschätzt wurden. Dieses Verfahren ist auch aus dem Kontext des agilen Festpreises bekannt [4].

Abb. 4: Beispiel für Äquivalenzschätzungen in einer User Story Map

Abb. 4: Beispiel für Äquivalenzschätzungen in einer User Story Map

Budgetverbrauch und Liefertermine werden während des Projekts laufend aktualisiert

Robert hat während seiner Weltreise kontinuierlich überprüft, ob seine Ziele sich verändert haben – auch wenn das in seinem Fall vermutlich eher unbewusst passiert ist – und die aktuelle Situation gegen dieses Ziel gespiegelt.

Um den Stakeholdern ein Gefühl dafür zu vermitteln, wie sich der Zieltermin eines Features oder Releases entwickelt, und welche Auswirkungen Scope-Änderungen auf den Termin haben, bietet sich die Verwendung eines Release-Burnup-Diagramms an (Abb. 5). Die obere Linie stellt den gesamten Scope und die untere den bereits abgearbeitet Scope dar. Schreibt man beide Linien fort, ergibt sich ein Schnittpunkt. Dieser Schnittpunkt gibt einen Eindruck über den aktuell realistischen Fertigstellungstermin.

Abb. 5: Burnup-Graph

Abb. 5: Burnup-Graph

Für das Budget lässt sich ebenfalls ein Burnup-Graph verwenden. Normalerweise ist für den Kunden oder andere Stakeholder aber weniger interessant, wann das aktuelle Budget aufgebraucht sein wird. Vielmehr geht es darum, welche User Stories bis zu diesem Zeitpunkt umgesetzt worden sind. Dazu bietet es sich an, eine Wasserlinie im Backlog zu visualisieren (Abb. 6). Diese Wasserlinie beruht im Wesentlichen auf den Kosten eines Sprints und der aktuellen Velocity des Teams:

  • Wie viele Sprints sind mit dem aktuellen Budget noch möglich?
  • In welchen Sprint fällt eine User Story bei der aktuellen Velocity?

Diese Berechnung kann durch statistische Simulationen [5] erfolgen, oder sehr einfach indem man die aktuelle Velocity fortschreibt. In jedem Sprint Review kann das Team mit dem Product Owner bzw. den Stakeholdern besprechen, ob sie mit dem innerhalb des Budgets Erreichbaren zufrieden sind. Alternativ können sie – wie Robert durch seinen zwischenzeitlichen Zuverdienst – das Budget erhöhen und damit die Wasserlinie weiter nach unten bewegen.

Abb. 6: Product Backlog mit Wasserlinie

Abb. 6: Product Backlog mit Wasserlinie

Lukas hat seinem Cousin Robert ein paar Tipps zur Planung gegeben und Robert möchte sie mit den Kollegen in den nächsten Monaten ausprobieren. Die Metapher mit seiner eigenen Reiseplanung hat ihm besonders gut gefallen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: