Product Owner 101: 9 Gründe für gescheiterte Projekte (Part 1)

Projekte scheitern. Als die britische Supermarktkette Sainsbury ein Projekt plante, ihre Lieferkette durch ein neues System zu automatisieren, verloren sie letztendlich etwa 526 Millionen US-Dollar. Nach Newswise. Why Software Fails (2005) sorgten Planungsfehler dafür, dass eine enorme Anzahl an Artikeln im Lager feststeckten und nicht rechtzeitig in die Läden kamen. Aber wie konnte es überhaupt dazu kommen?

„Manche machen Pläne für die Gegenwart, wundern sich aber, dass sie in der Zukunft nicht eintreffen.“ –  Erhard Blanck (*1942)

In diesem dreiteiligen Blogpost möchte ich 9 Gründe aufdecken, die zum Scheitern deines IT-Projekts führen können. Im ersten Teil geht es um die Projektplanung, auf die du als Product Owner oder in deiner Rolle als Projekt- oder Produktmanager Einfluss nehmen kannst.

#1 – Du glaubst ein Projekt ist die ultimative Lösung, für alles!

Kennst du sie auch? Diese Wasserfall-Projekte unter dem Schleier der innovativen agilen Ansätze? Nach meinen Erfahrungen glauben viele Unternehmen, dass es ausreicht „agile Methoden“ auf die Softwareentwicklung anzuwenden. Außenrum gibt es aber noch einen riesengroßen Rattenschwanz an Planungen und Entscheidungen.

„Those who worship at the altar of projects would have us believe that delivering on schedule, budget and quality will unlock the value promised by the project.“ – Allan Kelly [1]

Ich habe schon öfter erlebt, dass Projekte auf Basis von optimistischen Annahmen aus dem Boden gestampft werden. Allerdings können sie sich als falsch erweisen: Dass sich der Markt in der Zeit, in der ein Projektmanager bzw. Product Owner alles bis ins kleinste Detail durchgeplant hat, geändert haben könnte, interessiert scheinbar niemanden. Stattdessen wird das ganze Scope durchgezogen, als wäre es eine Einkaufsliste. Parallel wird eine agile Softwareentwicklung simuliert, bei der mit Sprints, User Stories & Co. gearbeitet werden soll. Gleichzeitig werden eine „Projektplanung bis Jahresende“ und „regelmäßige Statusberichte“ abgefragt. Wie passt das zusammen?

„Fortschritt ist nur möglich, wenn man intelligent gegen die Regeln verstößt.“ –  Boleslaw Barlog (*1906-1999)

#NoProjects

Schaust du dir die Definition eines Projekts an erkennst du, dass das Projektmodel immer einen Start- und einen Endpunkt besitzt und damit für temporäre Absichten vorgesehen ist. Unter diesem Aspekt hat Allan Kelly mit #NoProjects richtigerweise erkannt, dass die Entwicklung von Software kontinuierlich fortgesetzt wird: „Continuous is not temporary.“ [2]

Projektmanagement zwängt uns in ein Korsett aus Zeit, Budget und Scope, ohne Raum für situationsbedingte Neuerungen und Änderungen. Lassen wir diese Chancen in Form von high-value Features aufgrund fixer Erfolgskriterien nicht zu, reduzieren wir den Nutzen.

#2 – Du hast deine Planung aus der Glaskugel.

Wäre Gandalf ein traditionell erzogener Projektmanager, der nun plötzlich Product Owner geworden ist, dann hätte „Der Hobbit. Eine unerwartete Reise“ vermutlich wie folgt ausgesehen:

1. Montag, 19:37 Uhr: Zwergentreffen. (3 Storypoint)
2. Dienstag, 06:02 Uhr: Aufbruch. (1 Storypoints)
3. Donnerstag, 17:22 Uhr: Reise nach Bruchtal. (5 Storypoints)
4. Montag, 15:53 Uhr: Ring der Macht finden. (13 Storypoints)
5. Freitag, 20:41 Uhr: Drachen erlegen. (21 Storypoints)

Ganz eindeutig ist, dass das Erlegen eines Drachen viel aufwändiger ist (und mehr Benefit bringt), als der Aufbruch zur Reise. Wie kam Gandalf in diesem Szernario auf die detaillierte Prophezeiung? Vielleicht hatte er eine Eingebung und hat alles vorab für sich allein vorgeplant. Vielleicht hat er den Aufwand auch mit der Gruppe im Storypoker verhandelt. Man weiß es nicht. Den unerwarteten, ungeplanten Zwischenfall mit den drei Trollen, tja, der wird wohl auf das Team geschoben.

Fehlerhafte Schätzungen wirken sich letztendlich immer negativ auf das Team aus: Der Druck steigt.

#NoEstimates

Storypoker wird häufig (aus-) genutzt, um einen Aufwand mit dem Team zu bewerten. Warum überhaupt schätzen? Wäre es nicht viel effektiver, die beim Schätzen eingesparte Zeit in das Vorhaben selbst zu stecken? Diesen Ansatz verfolgt auch Vasco Duarte mit #NoEstimates.

Zähle keine Storypoints, sondern Stories. Somit kannst du auf Basis der Erfahrungswerte eine Prognose ableiten.

Vasco erkannte, dass es viel sinnvoller ist, abgeschlossene Stories zu zählen, um eine Aussage über die Kapazität des Teams zu treffen. Die Anzahl Stories zu zählen ist extrem einfach. Anhand der dadurch erhobenen Daten ist es möglich, über mehrere Iterationen hinweg eine optimistische sowie eine pessimisitische Einschätzung abzugeben. [3] Möglicherweise werden im Verlauf auch überflüssige Features erkannt und eine neue Prognose kann abgeleitet werden.

Ein guter Product Owner schätzt nicht wann etwas fertig ist, er weiß es. Aus Basis der durchschnittlich bearbeiteten Stories kann der Termin optimistisch und pessimistisch eingegrenzt werden. Ändert sich das Scope aufgrund von z.B. Scope Creep, ändert sich auch der Fertigstellungstermin.

#3 – Du bäckst zu große Brötchen.

Stell dir vor, du planst ein Fahrzeug zu entwickeln. Du startest höchst motiviert, sammelst alle Ideen und formulierst sie aus. Schnell ist ein Stapel verschiedenster Anforderungen zusammengekommen. Ein Ferrari soll es sein; mindestens 800 PS. Nicht mehr und nicht weniger!

Doch groß denken und visionär denken unterscheiden sich. Möglicherweise hast du dein eigentliches Ziel – ein Fortbewegungsmittel – aus den Augen verloren. Schnell verschwendest du deine wertvolle Zeit damit, jedes einzelne Feature bis ins kleinste Detail im Voraus zu planen.

Du kannst dir gar nicht sicher sein, wie dein Ferrari bei den Kunden ankommen wird. Du weißt nicht im Voraus, welche Features wirklich notwendig sind. Vielleicht hast du sicherheitshalber ein paar Studien und Umfragen durchgeführt. Du gehst lediglich davon aus: „Meine Kunden wollen einen Ferrari. Ich kann ihnen nicht weniger anbieten als den Ferrari. Unter 800 PS kann ich gar nicht erst ausliefern.“

Bevor du deine Softwareentwicklung so angehst, Achtung!

Kellys laws

1. “Project scope will always increase in proportion to resources.
2. Inside every large project there is a small one struggling to get out.” [4]
   

Je mehr du dir vornimmst, desto mehr Zeit und Ressourcen planst du ein. Je mehr Zeit und Ressourcen du zur Verfügung hast, desto mehr hievst du dir auf. Suche nach dem verzweifelten kleinen Projekt, das von der Masse an sinnlosen Featurewünschen erdrückt wird. Und wie stellst du es an, dieses kleine Projekt zu finden? Indem du deine Stories richtig portionierst!

User Story Slicing

Es ist einfacher, günstiger und schneller, kleine Stücke zu liefern anstelle eines Großen. Je kleiner das Häppchen, desto geringer das Risiko. [5] Muss es also wirklich ein Ferrari sein? Braucht der 0-8-15-Kunde wirklich 800 PS oder möchte er nicht einfach nur von A nach B gelangen? Und das bringt uns auch schon zur nächsten möglichen Ursache #4.

#4 – Du hast den Value aus den Augen verloren.

Du hast nun festgestellt, dass deine Anforderungsanalyse ausgeartet ist. Du weißt, du solltest lieber nach und nach kleine Stücke liefern anstelle eines Großen. Du möchtest deine Anforderungen richtig portionieren, weißt aber leider noch nicht, wie du das anstellst. Wie schaffst du es also, dich auf den reinen Mehrwert zu konzentrieren?

Elephant Carpaccio

Wie oft habe ich schon vertikal à la Wasserfall geplant? Erst einmal schön das Backend aufsetzen; Monate vergehen … immer noch keine sichtbare Funktionalität. Dabei ist es viel sinnvoller, Stories horizontal zu schneiden, um bereits zu Beginn Mehrwert zu erschaffen.

Eine mögliche Technik, um Stories horizontal und nutzerzentriert zu schneiden ist die User Story Map. Und so geht’s:

1. Überlege dir dein Ziel; welcher Benefit soll erreicht werden? → z. B. Ein Nutzer möchte seine Termine in einen Kalender eintragen zu können, um rechtzeitig über anstehende Meetings und Events informiert zu sein.
2. Plane die allgemeinen Nutzeraktivitäten von links nach rechts.
3. Orientiere dich an deinem übergeordneten Ziel und plane anschließend den Umfang je Release, um den größten Mehrwert zu schaffen.

Das Scope wurde in dieser User Story Map horizontal geschnitten, sodass mit jedem Release ein wertbringendes Feature ausgeliefert werden kann. (Tool: miro)

Natürlich ist es nützlich, einen Raum zu buchen oder Teilnehmer einzuladen. Aber dein Nutzer hatte das Ziel, seine Termine zu planen. Aus diesem Grund ist ihm mit Release 1 erst einmal geholfen. Von dort ausgehend kann im zweiten Schritt weitergeplant werden.

Takeaways

• #NoProjects: Nicht jedes Vorhaben muss ein Projekt sein. Probiere verschiedene Ansätze aus!
• #NoEstimates: Verzettel dich nicht mit Schätzungen. Zähle Stories, keine Storypoints!
• User Story Slicing: Es muss nicht gleich zu Beginn der ganze Elefant sein. Portioniere deine Häppchen!
• Value Optimierung: Build the right thing > build the thing right. Konzentriere dich auf den Value!

Hast du ähnliche Product Owner Erfahrungen gemacht? Teile deine Erlebnisse unten in den Kommentaren!

Noch nicht genug?

…von Value, Schätzungen und Slicing? Dann könnten dich auch folgende Blogbeiträge interessieren:

• Erfahre in Rolf’s spannendem Dreiteiler mehr über #ValueFirst vs. #NoEstimates.
• Informiere dich in Harald’s End2End Story Slicing Beitrag über die #NoEstimates Vorteile!

Verpasse auch nicht Part 2 und Part 3 dieses Blogposts, um die übrigen, möglichen Ursachen zu erfahren.

Quellen:

[1] Kelly, Allan: Project Myopia. Why Projects Damage Software #NoProjects, Software Strategy Ltd, 2018, S. 64.

[2] Kelly, Allan: Project Myopia. Why Projects Damage Software #NoProjects, Software Strategy Ltd, 2018, S. 3.

[3] Vgl. Duarte, Vasco: No Estimates. How to measure project progress without estimating, OikosofySeries, 2016.

[4] Kelly, Allan: Project Myopia. Why Projects Damage Software #NoProjects, Software Strategy Ltd, 2018, S. 45.

[5] Vgl. Duarte, Vasco: No Estimates. How to measure project progress without estimating, OikosofySeries, 2016, S. 57.