Weniger ist mehr – der Upstream ist zu managen

Der Product Owner hat die Aufgabe zu priorisieren und das Projekt gegebenfalls abzubrechen

Projekte einfach abbrechen, wenn sie noch gar nicht fertig sind? Tja, was heißt das denn eigentlich? Die Idee, ein Projekt dann abzubrechen, wenn es bereits den Wert geliefert hat, den es liefern sollte, macht doch Sinn – oder? Warum sollte man all das liefern, was man am Anfang dachte, dass man es braucht, wenn sich herausstellt, der oder die Kundin ist bereits zufrieden?  

Tja – das geht nur, wenn man auch während des Projekts bereits in Inkrementen liefert. “Aber ich kann kein halbes Auto liefern”, oder “ein halber Tisch lässt sich auch nicht liefern.”  

Das Problem ist hier die Gleichsetzung von Produkt und Projekt. Was ist das Projekt, wenn ich auf den Mond fliegen will, oder das erste Flugzeug der Welt bauen will? Was ist das Produkt, dass ich zur Zielerreichung bauen - könnte es sein, dass ich bereits ein Teil des Produktes entwickeln und nutzen kann, obwohl ich noch nicht alles habe, von dem ich dachte ich brauche es? Die Antwort ist natürlich: “Ja”.  

Der Product Owner wird in vielen agilen Implementierungen oft noch immer als der gesehen, der für die Organisation dafür sorgen soll, dass alle Bereiche “alles” bekommen. Er soll ein Backlog aufstellen und dann einfach mit seinem Team liefern, möglichst konstant und natürlich alles.

Doch das gelingt nicht, weil es gar nicht gehen kann. Es macht auch keinen Sinn, denn nicht jede Idee, nicht jedes Feature, nicht jede Anforderung passt zur Idee des Produktes. Und – wir wollen immer Wert für den Kunden so schnell wie möglich liefern. Wenn wir alles erst Ende liefern und das Projekt sehr lange dauert, dann kann es sein, dass wir am Ende nichts liefern, was der Kunde kaufen will.

Daher ist es wesentlich zu verstehen – der Job des Product Owners ist es nicht die Umsetzung aller Features, aller Anforderungen durchzubringen, sondern der Organisation begreiflich zu machen, dass es wesentlich sinnvoller ist auch viele Dinge nicht zu tun. Die Kunst hier ist eben nicht Priorisierung, sondern “Nein!” sagen. Klar zu haben, das wird funktionieren, und deshalb machen wir es und klar zu sagen, das machen wir nicht, weil es aus Sicht der Gewinnmaximierung keinen Sinn macht.  

Ich werde nicht müde diese Tatsache in Trainings – auch in unserem Kombitraining immer wieder zu erklären - denn diese simple Tatsache ist einfach zu verstehen, aber sehr schwer umzusetzen.

Nicht nur ich sage all das, hier findet ihr noch weitere Autoren, die ähnliches erklären.  

Quellen

The Project Group: Projektabbruch – Wann und warum ein Projekt vorzeitig beendet werden sollte

  • Mountain Goat Software: Product Owner in Scrum

https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner

  • Project Management Institute (PMI): The Role of the Disciplined Agile Product Owner

https://www.pmi.org/disciplined-agile/product-owner

  • Gladwell Academy: Owning it – The Role of the Agile Product Owner

https://www.gladwellacademy.com/knowledge/blogs/owning-it-the-role-of-the-agile-product-owner

  • Scrum.org: What is a Product Owner?

https://www.scrum.org/resources/what-is-a-product-owner

  • Scrum-Master.org: Understanding Your Role and Responsibilities in the Agile Framework

https://scrum-master.org/en/product-owner-understanding-your-role-and-responsibilities-in-the-agile-framework/  

Agile Management
Agiles Management
Product Owner
Projektmanagement
Kundenfokus
BG
February 6, 2025

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die Wiederkehr der 80er – Nostalgie als politische Strategie?
BG

Die Wiederkehr der 80er – Nostalgie als politische Strategie?

Remote-First vs. Präsenztrainings – was ist besser?
BG

Remote-First vs. Präsenztrainings – was ist besser?

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung