Das Product Owner Team - Perspektivenvielfalt gewinnt

Lesedauer ca.: 6 Minuten

Die reine Lehre vom Scrum-Ansatz lehrt uns das Highlander-Prinzip: „Es kann nur einen geben“ – den Product Owner. Über seine Aufgaben, Verantwortlichkeiten und was er/sie nicht ist, wird regelmäßig diskutiert. Und dieses Highlander-Denken wirkt schon vom Ansatz her wie ein Dogma und widerspricht jeglicher Perspektivenvielfalt.

Was passiert eigentlich, wenn ein „U-Boot-Projekt“, das in der Regel eine innovative Produktentwicklung zum Ziel hat, plötzlich in der Organisation auftaucht? Warum? Weil es feststeckt und in der eigenen Organisation auf zunehmend weniger Vertrauen trifft. Der Versuch des technischen Entwicklungsteams, etwas hoch Innovatives zu entwickeln, scheint zu scheitern. Das Produktmanagement und der Vertrieb „wissen von nichts“ und die Geschäftsführung fragt sich, wo die ganzen Entwicklungsgelder hinfließen? Was will unser Kunde wirklich? Können wir mit dem neuen Produkt jemals Geld verdienen?

Seiteninhalt

Innehalten: Kompliziert oder komplex?

Lassen Sie uns bei der Wahrnehmung anfangen. Als das oben genannte U-Boot-Projekt gestartet wurde, ging man davon aus, dass der komplizierte Produktentstehungsprozess auch in diesem Projekt erfolgreich angewendet werden könne. Jetzt jedoch liefert das Projektteam keine verlässlichen Ergebnisse, weil es zu viele Komponenten nicht selbst in der Hand hat. Das zusätzliche externe Know-how, die vielen externen Zulieferer und das unscharfe Projektziel sind schuld. Oder hätte man das vorher absehen können?

Ein wunderbares Beispiel vom Übergang von komplizierten zu komplexen Projekten. Wobei hier und im Folgenden der Einfachheit halber Komplexität mit Ungewissheit synonym benutzt werden. Wenn dieser Unterschied für ein anstehendes Projekt nicht von Anfang an wahrgenommen wird, laufen die Dinge oft aus dem Ruder. Der Überblick geht verloren, das Vertrauen in ein diffuses Projektziel und die Zufriedenheit aller Beteiligten schwindet. Aufgrund der fehlenden Wahrnehmung konnten die Beteiligten nicht auf die Ungewissheit im Sinne einer Prävention (vgl. z.B. Ungewissheitsprävention im Blogbeitrag von A. Kuhlmey) vorbereitet werden.

Um den Unterschied zwischen kompliziert und komplex noch einmal deutlich zu machen, nutze ich gerne meine Flieger-Methaper. Motorfliegen ist kompliziert und Segelfliegen komplex. Warum ist Letzteres komplex? Weil bei Segelfliegen nicht vorhersagbar ist, wo und wann genau sich ein Aufwind befindet, der zum verlässlichen Aufsteigen des Segelflugzeuges genutzt werden kann. Und weil der Streckensegelflieger den Umgang mit dieser Ungewissheit kennt und trainiert hat, kann er mehrere hundert oder gar über tausend Kilometer an einem Tag nur mit den Kräften der Natur erfliegen, ohne genau zu wissen, wo sich die Aufwinde befinden.

Starte mit dem „Wozu?“

Zurück zu unserem festgefahrenen Projekt. Eine der hilfreichsten Ansätze, um Klarheit über den Stand des Projektes zu bekommen, ist die Frage nach dem „Wozu?“. Wozu macht ihr das Projekt? Diese Frage wirkt Wunder. Simon Sinek hat das vor Jahren in seinem Vortrag „Start with why – how great leaders inspire action“ genutzt. Im Zentrum seines „Golden Circles“ steht das „Why“. Anders als bei dem deutschen Wort „Warum“ geht es hier um den Sinn. Die Frage nach dem „Wozu“ trifft es deshalb im Deutschen genauer. Sie bezieht sich auf den Sinn und ist in die Zukunft gerichtet. Nur wenn Menschen einen Sinn, ein passendes „Wozu“ haben, können sie sich intrinsisch („aus sich selbst heraus“) für ein Ziel engagieren.

Mit dem Sinn ist dabei nicht höher, schneller, weiter gemeint, sondern wird eher in der Metapher eines „Geschenkes“ dargestellt. Was ist damit gemeint? Der Kunde ist am Ende von dem neuen Produkt begeistert. Die Organisation wird durch das neue Produkt profitabler. Der Teamkollege bekommt das, was er für seinen nächsten Arbeitsschritt braucht oder das Team liefert genau das, was es versprochen hat. Wenn alles Vorgenannte so eintritt, dann erzeugt dies eine positive Energie, wie bei einem guten Geschenk, das ein Lächeln auf das Gesicht des Beschenkten zaubert. Und nicht nur das, es lässt auch die Geber lächeln.

Mit der Klärung dieser Frage kann sich auch die Haltung aller Beteiligten ändern. Ein unscharfes Projektziel, das regelmäßig mit dem „Wozu?“ iterativ und inkrementell nachgeschärft wird, bietet den Raum und die Chance für eine innovative Produktentwicklung, die ein „sinnstiftendes Geschenk“ für alle Anspruchsgruppen zum Ziel hat. So ist der Umgang mit der Ungewissheit in Bezug auf das unscharfe Projektziel eine Frage der Haltung. Die Unschärfe im Projektziel kann als Chance für Innovation umgedeutet werden (im Coaching als Reframing bekannt).

Das Geschenk als Metapher für den Gesamtnutzen

Projektauftraggeber ist stets der Kunde, der für den Mehrwert eines Produktes bereit ist zu zahlen. Er bestimmt, wie sein Wunschprodukt (Geschenk) beschaffen sein muss, damit es für ihn erstrebenswert und attraktiv wird. Zur Ermittlung der Kundenbedürfnisse gibt es eine Vielzahl von Ideation Tools, um innovative Produktideen zu entwickeln. Das können zum Beispiel Konzepte wie das Design Thinking, Customer Centricity oder auch die Walt-Disney-Methode sein.

Die Ergebnisse dieses Prozesses münden in einer „Feature-List“, also einem „Kundenwunschzettel“. Features sind dabei auf Personen und Gruppen bezogene Merkmale, Eigenschaften oder Funktionen. Diese können in „Feature Stories“ definiert werden, deren Struktur der von „User Stories“ in Scrum ähnelt. Eine typische Formulierung lautet: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erzielen“.

Aus Sicht der Organisation, die dieses Produkt entwickeln soll, besteht der Gesamtnutzen allerdings nicht nur aus dem Kundennutzen des „externen Kunden“. Wichtig sind auch die technische Realisierbarkeit, die Sinnhaftigkeit und schließlich die Profitabilität des Produktes über den Lebenszyklus. Im oben genannten Sinn entsteht am Ende nur dann ein für alle Beteiligten sinnstiftendes Geschenk, wenn der Gesamtnutzen aus einem oder mehreren kundenbezogenen, technischen und betriebswirtschaftlichen Features besteht.

Zielkonflikte im Product Owner Team lösen

Erinnern wir uns an den Ausgangspunkt, das festgefahrene U-Boot-Projekt. Das Produktmanagement möchte Features, die technisch nicht oder noch nicht realisierbar sind. Das technische Projektteam beschäftigt sich mit Features, die hipp sind, aber nur geringen Nutzen für den externen Kunden bringen. Das Projektmanagement möchte einfach nur, dass das Budget und die Timeline eingehalten werden. Alles widersprüchliche Anforderungen, die thematisiert, diskutiert und zum Einvernehmen gebracht werden müssen, damit wieder ein Gesamtnutzen entstehen kann.

In dieser Situation ist es förderlich, wenn die drei Sichten, der Kundennutzen (gemeint ist hierbei immer der externe Kunde), die technische Machbarkeit und der betriebswirtschaftliche Nutzen von Menschen mit unterschiedlichen Mandaten verantwortet werden. Mandate meinen in diesem Kontext, Verantwortung für das Projekt im Sinne einer kompetenzorientierten Führung zu übernehmen. Eine Art der Verantwortung und Führung, die temporär besteht und darauf beruht, dass derjenige, der in einem konkreten Bereich am kompetentesten ist, für einen festgelegten Zeitraum Führung übernimmt und den Prozess begleitet. Idealerweise wird dafür ein „Überblicker-Team“ gebildet, das die jeweiligen Verantwortungsbereiche im Markt und in der Organisation überblickt.

In Anlehnung an die Rolle des Product Owners in Scrum kommt in diesen Fällen ein Product Owner Team zum Einsatz, das den Projekterfolg verantwortet. Dieses Konstrukt eines Product Owner Teams (POT) ist ein zentraler Bestandteil des agilean Ansatzes (vgl. weitere Informationen). Agilean ist ein hybrider Ansatz, der agile und lean Ansätze holistisch kombiniert, um komplexe Produktentwicklung zu beschleunigen, Teams auf den Kundennutzen zu fokussieren und dabei das „Wozu?“ aller Beteiligten ins Zentrum zu stellen (vgl. Abb. Rollen im agilean Ansatz). In unserem oben genannten Projekt könnte die Kundenperspektive vom Produktmanagement, die der technischen Realisierbarkeit von einem Systemingenieur und die der betriebswirtschaftlichen Sicht vom Projektmanagement vertreten werden.

Rollen im agilean Ansatz

Verantwortung und Aufgaben des Product Owner Teams

Im Sinne der kompetenzorientierten Führung sollten die Product Owner sowohl über tiefgreifendes Expertenwissen in ihrem Verantwortungsbereich verfügen als auch so viel von den Bereichen der jeweils anderen beiden überblicken, dass sie der Argumentation kritisch folgen und ihnen begründet entsprechen oder widersprechen können. Mit ihrem Mandat verantworten die Product Owner als Team die Projektergebnisse, also das „Wozu?“ und das „Was?“ gemeinsam. Das heißt, sie formulieren die Ergebnisse, die es braucht, um das Projektziel aus ihrer Perspektive zu erreichen. Dabei können sie aus ihren Bereichen die Expertise anderer Kollegen zur Zielbestimmung einbeziehen.

Dies wiederum setzt einen oft anspruchsvollen Einigungsprozess voraus, bei dem es sich in der Praxis als günstig erwiesen hat, das POT von einem neutralen Coach begleiten zu lassen. Die Aufgabe des Coaches liegt darin, Interessenkonflikte auf eine Sachebene zurückzuführen, gegenseitiges Verständnis zu erzeugen und einen Lösungsraum zu öffnen. Dabei kann die systemische Fragetechnik oft hilfreiche Dienste zur Klarstellung der verschiedenen Perspektiven leisten (vgl. Artikel von A. Kuhlmey).

Dieser Einigungsprozess wird im agilean Ansatz als „Konklave“ bezeichnet, weil er erst dann abgeschlossen ist (auch ohne weißen Rauch), wenn sich das POT auf gemeinsam Projektergebnisse im Sinne der „Geschenke-Metapher“ geeinigt hat. Die Ergebnisse zahlen auf die oben erwähnten Features ein und werden in Form eines Ergebnisszenarios visualisiert. Dieses sogenannte „Stage-Result-Board“, im Ursprung eine Art Kanban-Board, ist der Kompass für den gesamten Projektverlauf. Es wird dynamisch an die aktuelle Situation angepasst, wobei das Ziel, die Projektfeatures zu erfüllen (das „Wozu“) immer wieder zur Orientierung dient. Eine inkrementelle und iterative Vorgehensweise ist für die Verifizierung des Kundennutzens, die technische Machbarkeit und die zu erwartende Wirtschaftlichkeit essenziell. In agilean wird auf diese Weise durch das POT über Ergebnisse lean gesteuert und agile im Umgang mit der Ungewissheit gearbeitet.

Fazit

Innovative Produktentstehungsprojekte gehören für viele Unternehmen inzwischen zum Tagesgeschäft. Oftmals wird dabei an alten Zöpfen festgehalten, also der klassische Produktentstehungsprozess herangezogen, weil agile Ansätze „bei uns nicht funktionieren“. Vielleicht liegt es in solchen Umfeldern genau daran, dass ein Einzelner nicht alles überblicken kann und deshalb das Vertrauen fehlt. Zum Beispiel im oben aufgeführten U-Boot-Projekt gilt es zunächst wieder Vertrauen in der Organisation herzustellen. Dabei hat sich der Einsatz eines Product Owner Teams bewährt, das die Mandate verschiedener Perspektiven einbringt und diese auch in der Organisation vertritt.

Dieser Beitrag erschien zuerst im t2informatik Blog.