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
.svg)
