Die ultimativen Anti-Tipps für Product Owner

So werden Sie in kurzer Zeit zum Master Product Owner!

Endlich Product Owner! Endlich die Chance, ein Produkt so zu gestalten, dass es wirklich heraussticht. Endlich die Gelegenheit, all die tollen Ideen einzubringen, die bisher ungehört geblieben sind. Endlich nicht mehr nur Zuschauer sein, sondern das Ruder in die Hand nehmen. Und dann?

Dann stellt sich heraus, dass die Realität doch etwas anders aussieht. Statt kreativer Freiheit gibt es enge Sprintzyklen. Anstelle von visionären Entscheidungen treten Diskussionen über Backlogs, Prioritäten und technische Schulden. Und dann sind da noch die Entwicklerinnen und Entwickler, die so tief in den Details stecken, dass sie ihre eigenen Kapazitäten unterschätzen und aus Vorsicht lieber auf der Bremse stehen, anstatt beherzt zu beschleunigen.

Zum Glück gibt es Wege, all diese Herausforderungen zu meistern und die eigene Rolle als Product Owner mit maximaler Wirkung auszufüllen. Mit den folgenden Tipps werden sich das Produkt, das Team und vielleicht sogar das ganze Unternehmen schneller verändern, als der Scrum Guide „Velocity“ sagen kann. [1]

Das Zusammenspiel mit den Stakeholdern

Jeder, der schon einmal ein Produkt oder eine Dienstleistung entwickelt hat, kennt die Bedeutung von Stakeholdern. Stakeholder sind alle Personen oder Organisationen, die direkt oder indirekt von den Aktivitäten eines Unternehmens betroffen sind oder ein Interesse daran haben. Es überrascht nicht, dass der Begriff im Scrum Guide nicht weniger als 13 Mal vorkommt. Und wie beschreibt die deutsche Übersetzung des Scrum Guides das Zusammenspiel von Stakeholder und Product Owner sprachlich elegant?

„Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen“. [2]

„Kann“ die Bedürfnisse „vieler“ Stakeholder berücksichtigen? Was heißt denn „kann“ und was bedeutet „viele“ Stakeholder? „Viele“ im Sinne von „wichtig“? Sorry, das verwirrt doch nur. Machen wir es einfach: Als Product Owner sind Sie der Vertreter der Stakeholder in Ihrem Unternehmen. Und sprichwörtlich der Eigentümer des Produkts. Bumm! Tschakka! Was für eine Rolle! Was für eine herausragende Position.

Natürlich ist es wichtig, sich immer wieder daran zu erinnern, wer Ihnen zumindest indirekt diese Rolle übertragen hat und wie Sie Ihre Wertschätzung ausdrücken können: Stimmen Sie Ihren Stakeholdern zu. [3] Hören Sie eine spontane Idee, sagen Sie die schnellstmögliche Umsetzung zu. Selbst wenn die Umsetzung vermutlich schwierig wird und Wünsche miteinander konkurrieren. [4] Warum Zeit mit Diskussionen verschwenden, wenn ein schnelles „Ja“ so einfach ist?

In manchen Organisationen ist es nicht unüblich, dass der Geschäftsführer am Wochenende neue Geistesblitze hat. Selbstverständlich haben diese Blitze Vorrang. Idealerweise sparen Sie sich dabei auch den Umweg über die Personen in Ihrer Organisation, die mit Kunden im Kontakt stehen (Vertriebler, Supporterinnen), um über das Für und Wider zu diskutieren. Erstens wird niemand ohne Ahnung vom Geschäft zum Geschäftsführer, und zweitens gilt sowieso das HIPPO-Prinzip: Die Meinung der Person mit dem größten Gehaltsscheck gewinnt immer. Und sollte es Widerstand aus dem Entwicklerteam, dem Release Management, der Marketingabteilung oder Gott behüte aus dem Kreise des Entwicklerteams geben, verweisen Sie einfach auf den Scrum Guide: „Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren“. Bingo!

Unterstützen Sie Ihr Team

Wann haben Sie das letzte Mal einen Artikel gelesen, in dem die Reduzierung oder gar Abschaffung von Hierarchien in Organisationen gefordert wurde? Selbst im Scrum Guide steht explizit, dass es in Teams keine Hierarchien gibt. Was in der Theorie schön klingt, scheitert oft an der harten Realität: Hierarchien gibt es immer. [5] Und weil das so ist, können Sie als Product Owner auch die naheliegende Führungsrolle übernehmen.

• Moderieren Sie Meetings und unterstützen Sie so den Scrum Master.
• Treffen Sie Entscheidungen. Gehen Sie voran und sagen Sie nicht nur, was im nächsten Sprint erledigt werden soll, sondern auch, wie die Kolleginnen und Kollegen es am besten machen sollen. So beschleunigen Sie den Abstimmungsprozess und manifestieren gleichzeitig auf einfache Weise Ihren Status als Produktexperte.
• Vertrauen ist gut, Kontrolle ist besser. Sagen Sie jeder Entwicklerin und jedem Entwickler, dass Sie die individuelle Leistung wahrnehmen. Das gibt Sicherheit.
• Und räumen Sie mit einigen Scrum-Mythen auf: Selbstverständlich geht es im Sprint Review um Inspect & Accept und nicht um Inspect & Adapt. Und natürlich können Sie als Vertreter der Stakeholder und Eigentümer des Produkts realisierte User Storys auch einfach selbst abnehmen.

Kurzum: Helfen Sie Ihrem Team. Gehen Sie voran. Sie sind der Boss!

Effizienzsteigerung leicht gemacht

Effizienz ist das Zauberwort, das in agilen Organisationen immer wieder auftaucht. Schließlich heißt es nicht umsonst: „Scrum, The Art of Doing Twice the Work in Half the Time“. [6] Es geht also darum, in möglichst kurzer Zeit möglichst viel zu liefern – oder? [7] Je schneller ein Feature entwickelt wird, desto erfolgreicher ist das Unternehmen! Klingt bestechend logisch! Und da technische Schulden erst fällig werden, wenn sie jemand eintreiben möchte, sollten Sie diese auch nicht künstlich überbewerten.

Motivieren Sie Ihr Team, seine Velocity kontinuierlich zu steigern. Wenn ein Team im letzten Sprint 30 Story Points erreicht hat, sollte es beim nächsten Mal mehr schaffen. Noch besser: Initiieren Sie einen gesunden Wettbewerb zwischen verschiedenen Teams in Ihrer Organisation. Wer mehr liefert, gewinnt – eine einfache, klare und motivierende Botschaft. Vielleicht belohnen Sie sogar das erfolgreichste Team?

Ein kleiner Extra-Tipp: damit das in der Praxis funktioniert, sollten Sie Ihr Team an anderer Stelle entlasten: Das Backlog Refinement wird bewusst nicht als Scrum Event deklariert, verzichten Sie also auf diesen relativ zeitintensiven Austausch von Informationen mit den Entwicklerinnen und Entwicklern. Priorisieren Sie die Items nach bestem Wissen und Gewissen; einerseits vertreten Sie die Stakeholder, anderseits werden Sie so mit etwas Übung zum absoluten Produkt-Insider.

Und – aber das ist nur etwas für erfahrene Product Owner – zu guter Letzt können Sie auch Ihre Produktstrategie überdenken. Warum sich mit einem Minimum Viable Product begnügen, um möglichst früh Feedback von potenziellen Nutzerinnen und Nutzern zu erhalten, wenn Sie durch einen Perspektivwechsel auch ein Maximum Viable Product erreichen können? Die allermeisten Kundinnen und Kunden wollen nicht das Minimum, sondern das Maximum an Funktionen, die sie sich vorstellen können. Sie wollen nicht abstrahieren, ob ein zukünftiges Produkt ihren Wünschen entsprechen könnte, sie wollen das Produkt in den Händen halten, es mit einem leichten Mausklick oder Fingertipp zum Leuchten bringen. Erobern Sie Ihren Markt von Anfang an mit dem besten Produkt, das Sie sich vorstellen können und von dem Ihre Kunden noch nicht einmal geträumt haben.

Spezialtipps für fortgeschrittene Product Owner

Nachdem Sie nun gesehen haben, wie Sie Ihre Stakeholder glücklich machen, Ihr Team mit klarer Führung voranbringen und sich auf Effizienz fokussieren, gibt es zum Schluss noch ein paar Tipps, die Sie unaufhaltsam auf dem Weg zum Master Product Owner unterstützen:

Events werden gemeinhin als eine wertvolle Zutat in Scrum erachtet. Tatsächlich sind sie aber ein ziemlicher Zeitfresser. Vor lauter Events kommt man kaum noch zum Arbeiten. Sprint Planning, Daily Scrum, Sprint Retrospektive und Sprint Review. Wow. Das sind wirklich viele Möglichkeiten, sich immer wieder abzugleichen, Ziele und Aufgaben zu besprechen und Inkremente zu diskutieren. Lassen Sie doch das eine oder andere Event weg. Denken Sie daran: Die besten Ideen entstehen nicht in Meetings, sondern in stiller Einzelarbeit, fernab von Ablenkungen und langatmigen Wortmeldungen. Viele Entwicklerinnen und Entwickler sitzen zudem den ganzen Tag in einem Raum oder kommunizieren über wunderbare Plattformen online miteinander. Sparen Sie sich ein Sprint Review und nehmen Sie beim nächsten Mal einfach die realisierten Backlog Items der letzten beiden Sprints ab. Ja, das klingt auf den ersten Blick wie ein ungewöhnlicher Tipp, aber der Erfolg gibt den Mutigen recht.

Apropos Mut: In einigen Online-Beiträgen wird das Experimentieren als wertvolles Lernwerkzeug gepriesen. Das klingt natürlich gut, aber der Ausgang eines Experiments ist ungewiss, die Kosten sind oft hoch und die Effizienz gering. Außerdem weiß jedes Kind, dass die besten Unternehmen nicht diejenigen sind, die Experimente wagen, sondern diejenigen, die Bestehendes neu denken oder Wissen geschickt adaptieren (siehe z.B. Apple).

Wissen ist ein schönes Stichwort. Gerne wird auch darüber philosophiert, Wissen zu teilen. Aber warum sollten Sie es teilen und riskieren, dass andere klüger werden als Sie selbst? Wer Wissen hat, bleibt unersetzlich und hat Einfluss. Behalten Sie die Fäden in der Hand. Wissenstransfer ist schön und gut für Idealisten, als Product Owner sollten Sie Ihr Wissen hüten wie einen Schatz. Und: Testen Sie von Zeit zu Zeit Ihre Bedeutung für Ihr Umfeld, indem Sie dem einen oder anderen Meeting fernbleiben und für Rückfragen nicht zur Verfügung stehen. Machen Sie sich unsichtbar. Das hat auch den Vorteil, dass Sie so Ihrem Team Selbstorganisation beibringen können. Win-Win. Wenn Sie gewinnen, gewinnen alle.

Schön, wenn diese Tipps Ihnen und Ihrem Team weiterhelfen. Bestimmt werden Sie schon bald zum Master Product Owner aufsteigen.

Hinweise:

Dies war eine Persiflage. Bitte probieren Sie keinen dieser Tipp in der Praxis aus. Unternehmen haften für Ihre Product Owner.

[1] Im Scrum Guide fehlen eine ganze Reihe von Begriffen, die in Projekten und Entwicklungen genutzt werden. Velocity ist ein solcher Begriff. Hier finden Sie weitere fehlende Begriffe im Scrum Guide.
[2] Hier finden Sie die deutsche Übersetzung des Scrum Guides.
[3] Hier finden Sie ernsthafte Tipps im Umgang mit Stakeholdern.
[4] Welche Arten von Zielkonflikten gibt es und wie lassen sie sich üblicherweise beseitigen?
[5] „Macht die Hierarchiestufen weg, dann wird alles gut!“ Wer’s glaubt… lautet ein interessanter Impuls von Stephanie Borgert.
[6] Die Erledigung doppelter Arbeit in der halben Zeit ist für André Claaßen eine agile Geschwindigkeitslüge.
[7] Jeff Sutherland, der Autor von “Scrum, The Art of Doing Twice the Work in Half the Time” hat einen Post veröffentlicht, in dem er mitteilt, mithilfe einer KI könnte er jetzt 30 Mal schneller Software entwickeln. Zu Recht sehen Menschen vom Fach diese Aussage sehr kritisch.

Hier finden Sie einige konkrete Anti-Tipps für Product Owner als Download zum Mitnehmen.

Es gibt viele reale Gründe, warum Agilität in Unternehmen nicht funktioniert. Heiko Bartlog hat über dieses Thema eine großartige Beitragsserie geschrieben: Agilität? Haben wir probiert! Funktioniert nicht!

Und hier können Sie schauen, was ein Product Owner wirklich tut und welche Tipps in der Praxis nützlich sind.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. 

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.: