Product Ownership: Der Unterschied zwischen guten und großartigen Teams

In Review-Meetings geht es häufig zu wie in der Schule: Der Product Owner prüft, ob sein Team alles richtig gemacht hat. Team und Product Owner stellen sich dann den Fragen der Besucher und hoffen, dass es möglichst glimpflich abläuft. In dieser Variante ist das Team Lieferant: Es tut das, was von ihm gefordert wird. Nicht mehr und nicht weniger.Das Review-Meeting ist eigentlich dazu da, die Verhältnisse umzukehren: Team und Product Owner stellen ihr Produkt gemeinsam vor. Sie erzählen, was sie bisher schon erreicht haben, und wohin der weitere Weg gehen soll. Im Mittelpunkt steht hier nicht mehr die Frage, ob das Team alles richtig gebaut hat (das können Product Owner und Team vorab klären). Im Mittelpunkt steht vielmehr die Frage, ob das Produkt das richtige ist.Fallbeispiel aus einem meiner neueren Projekte: Eine Firma kann sich nicht entscheiden, welches Produkt sie bauen soll. Zum einen ist da der Kundenwunsch nach einer schnellen und billigen Sonderlösung. Zum anderen gibt es die strategische Ausrichtung auf eine Zukunftstechnologie. Der Kunde ist ein sehr wichtiger, und er droht, zur Konkurrenz überzulaufen.In dieser schwierigen Konstellation wird ein Scrum-Team aufgesetzt. Zunächst ist das Team komplett orientierungslos und frustriert. Es spürt ja, dass das Management bis hin zu den obersten Etagen nicht weiß, was zu tun ist.Das Team ist allerdings hochkarätig besetzt: Die meisten Mitglieder sind schon lange mit dabei und haben tiefe Erfahrung mit der Produktfamilie.Im Laufe eines zweiwöchigen Sprints vollzieht sich ein spannender Wandel: Das Team fängt an, eine eigene Haltung aufzubauen. Es wartet nicht mehr auf Entscheidungen des Managements, sondern prescht selbst voran. Es macht ein durch und durch souveränes Review, in dem es dem Management ein durchdachtes und belastbares Bild möglicher Lösungen präsentiert, das den Entscheidungskorridor absteckt.

Team: Jeder ist Produkt-Visionär

Entscheiden muss das Management trotzdem noch. Aber durch das selbstbewusste Vorangehen des Teams wird vielen klar, wie die Lösung definitiv nicht aussehen kann (weil sie technisch nicht machbar ist, weil sie den Kostenrahmen sprengt oder weil sie mit zu vielen Abhängigkeiten behaftet ist). Und es wird auch klar, dass sich beide Alternativen (Kundenwunsch versus strategische Ausrichtung) doch irgendwie verknüpfen lassen. Erstauntes Fazit eines Managers am Ende des Reviews: Wir brauchen ein starkes Team, um Entscheidungen treffen zu können! Ein Team, das Anfragen nicht nach Vorgabe bearbeitet, sondern selber die Zügel in die Hand nimmt und das Sorgerecht für das Produkt übernimmt.Großartige Scrum-Teams zeichnen sich dadurch aus, dass das Ownership über das Produkt verteilt ist: Jeder ist Visionär des Produktes, jeder möchte es als sein eigenes präsentieren. Ein großartiges Team schreibt gemeinsam mit dem Product Owner User Stories. Teammitglieder suchen das Gespräch mit Benutzern, Kunden und Management - und können erklären, wie es weitergeht.Wird der Product Owner dadurch überflüssig? Natürlich nicht. Er ist dann koordinierende und maßgebende Instanz, die dafür sorgt, dass es am Ende des Tages ein Product Backlog gibt. Und dass die Constraints, innerhalb derer sich die Produktentwicklung bewegen soll, möglichst klar und vor allem stabil sind. Der Product Owner ist somit ein Hort der Ruhe gegenüber den oftmals hoch volatilen Wünschen von Kunde und Management.Der ganze Rest, die ganze hohe Kunst des Managements, lässt sich in zwei Worte zusammenfassen: Machen lassen (vgl. Takeuchi et Nonaka 1986: 139-140)!Takeuchi, Hirotaka und Nonaka, Ikujiro: The New New Product Development Game. Harvard Business Review, January February 1986.