OMG They made me Product Owner!!

Das Gesicht des Mannes im Flur drückte eine Mischung aus Euphorie und Entsetzen aus, als ich an ihm vorbeiging. Wir hatten uns zuvor an der Kaffeemaschine getroffen und darüber gesprochen, wie das Unternehmen zu einer mehr auf Scrum basierenden Art der Produktentwicklung übergegangen war.

[caption id="attachment_19875" align="aligncenter" width="470"] Zwischen Euphorie und Terror[/caption]

"Sie wissen doch, wie diese PO-Sache funktioniert, oder?", war seine erste Frage. Als ich nickte, vertraute er mir an, dass sie ihn zum Product Owner eines neuen Teams gemacht hatten, ohne vorherige Schulung. Im Allgemeinen nicht der beste Start, aber ich kann verstehen, warum die Jungs unbedingt anfangen wollten: Ihr Produkt würde ein Problem angehen, mit dem viele ihrer Kunden zu kämpfen hatten - ein vielversprechender Anfang! Bei einem Kaffee und einem Whiteboard erarbeiteten wir vier Schritte, die Sie unternehmen können, um ein Team, für das Scrum und die Rolle des Product Owner neu sind, in Schwung zu bringen.

Produkt | Welches Problem lösen Sie?

Es gibt so viel, was Sie tun sollten, aber für den Anfang: verstehen. Wenn Sie ein Produkt erben, sollten Sie sich über den Geschäftsfaktor im Klaren sein. Füllen wir eine Lücke im Portfolio? Ist es ein Sprungbrettprodukt? Welchen Einfluss haben wir auf Marke und Umsatz? Welches Problem löst unser Produkt für den Kunden und warum? Können Sie einige Zeit mit tatsächlichen Nutzern des Produkts verbringen und beobachten, wie diese das Produkt verwenden? Gehen Sie den rollenden Wellenplan durch. Verschaffen Sie sich einen Überblick über die strategischen Themen, die anstehenden Funktionen und was in den nächsten Sprints geplant ist?

Wenn Sie sich über das Problem, das Sie lösen wollen, noch nicht im Klaren sind, fangen Sie nicht an, es zu lösen. Es ist besser, den Start zu verschieben, als ohne Ziel zu beginnen. Beachten Sie, dass dies nicht gleichbedeutend damit ist, dass Sie nicht wissen, wie Sie das Problem lösen sollen. Sie können beginnen, wenn Sie wissen, was zu lösen ist und warum, ohne das Wie zu kennen. Wenn Sie Ihr Team richtig ausgewählt haben, wird es besser als Sie wissen, wie das Problem zu lösen ist.

Persönlicher Check-in mit dem Team

Wenn Sie als Team zusammenarbeiten wollen, müssen Sie sich als Team kennen. Hier ist, was Sie tun können:

• Wer ist im Team? und wer ist in Nebenrollen?
• Für Ihre Teammitglieder: Erläutern Sie Ihre starken Leistungen. Warum sollten sie froh sein, Sie im Team zu haben, was sind Ihre Stärken, Ihre Leidenschaft, wenn Sie so wollen?
• Wo kann ich Hilfe gebrauchen? Was kostet Sie Mühe und wo können Sie unterstützt werden, damit Sie mehr Zeit und Energie für Ihre Großartigkeit haben?
• Verrückte Hobbys. Teilen Sie dem Team etwas Persönliches mit, lernen Sie die Person hinter dem Coder, Tester, Designer usw. kennen. Wie ticken wir? Vielleicht haben wir mehr gemeinsam, als wir denken.
• Was für ein Mensch bin ich? Ich verwende normalerweise das DISC-Modell, um zu beschreiben, wer ich bin und warum ich mich so verhalte, wie ich mich verhalte. Es ist nicht so, dass ich nicht zwischen den Modi wechseln kann, es ist nur so, dass meine natürliche Haltung zum Beispiel gelb ist. Wenn Sie mich überzeugen wollen, können Sie so Dinge sagen, die mir gefallen und die höchstwahrscheinlich nicht funktionieren werden. Es ist unglaublich wertvoll zu wissen, welche Art von Person Sie im Team haben.
• Was macht mich glücklich?

Team | ein guter Start

Als Nächstes müssen Sie das neue Team einweihen. Wer sind wir? Was sind unsere Werte? Natürlich sollte Ihnen Ihr Scrum Master dabei helfen, aber Sie leiten das Produkt, d.h. Sie sorgen dafür, dass es erledigt wird. Sobald jeder seinen Avatar hat, der mit dem Namen des Teams übereinstimmt, arbeiten Sie an der Definition von Done und hängen Sie sie für alle sichtbar an die Wand. Dies ist ein wenig Wechselspiel zwischen dem Team und dem Product Owner, aber es ist sehr wertvoll, nicht jede einzelne Lieferung hinterfragen zu müssen. Als nächstes: Verrücken Sie Ihren Schreibtisch und setzen Sie sich zum Team. Im Ernst: Ihr Eckbüro ist mir egal, setzen Sie sich zu Ihrem Team. Die nonverbale Kommunikation des Teams wird nicht über Jira weitergegeben und Sie müssen die Seufzer des Teams hören, wenn sich etwas schwieriger als erwartet gestaltet. Oder würden Sie es lieber nach dem Sprint Review von den Stakeholdern hören?

Prozess | Richten Sie sich nach Ihrer Interpretation von Scrum

Vergewissern Sie sich, dass das, was Sie Scrum nennen und das, was man Scrum nennt, das Gleiche ist. Der Leitfaden mag klar genug sein, aber ich habe noch nie zwei Implementierungen gesehen, die identisch sind. Wie funktioniert der Freigabeprozess? Letztendlich ist er nur dann von Wert, wenn die Menschen ihn nutzen können. Veröffentlichen wir mehrmals am Tag? einmal pro Sprint? langsamer? Es ist eine gute Praxis, "schwimmende Bahnen" für Dinge wie die Bearbeitung von Vorfällen, die Unterstützung anderer Teams, Verbesserungen und funktionale User Stories einzurichten. Wie hoch sind die Investitionsquoten für diese Lanes? und was bedeuten Verbesserungen? Entwickler wollen in der Regel sofort mit dem Refactoring beginnen, sobald sie auf "Speichern" drücken. Das Problem ist, dass sie damit manchmal absolut Recht haben. Finden Sie einen ausgewogenen Weg, die Arbeit zu verteilen, damit es keine Verwirrung gibt und die Erwartungen gesteuert werden. Dies dauert in der Regel mindestens einen Tag, aber Sie werden in einer besseren Position sein, wenn Sie wissen, warum wir unser Produkt bauen, einander kennen und wissen, wie wir zusammenarbeiten. Vergessen Sie nicht, gemeinsam ein Spiel wie Boris Gloggers Ballspiel zu spielen und ein paar Drinks zu nehmen. Nächster Tag: Sprint 1, gehen Sie und seien Sie großartig!

Möchten Sie mehr über Agilität, Kampfsport und Produktmanagement erfahren? Bestellen Sie das Buch bei bol.com oder managementbook.nl, wenn Sie in den Niederlanden oder Belgien leben, oder melden Sie sich an, um die internationale Ausgabe zu erhalten.