7 Fähigkeiten, die Sie brauchen, um ein guter Product Owner zu sein
Veröffentlicht am
Wenn Sie sich mit Scrum vertraut machen, werden Sie feststellen, dass es sich hervorragend zur Definition von Rollen eignet. Ein Product Owner ist zum Beispiel für das Product Backlog verantwortlich, erstellt User Stories und bildet die Schnittstelle zu den Stakeholdern und dem Scrum-Team. Das ist alles richtig, aber was braucht es, um ein wirklich effektiver Product Owner zu sein?
Um dies zu ergründen, haben wir uns an Lowell Lindstrom gewandt, einen Certified Scrum Trainer® und einen der ersten Pioniere der agilen Softwareentwicklung. In den letzten 30 Jahren hat er mit vielen Product Ownern zusammengearbeitet und sie gecoacht. Er hat die Erfahrung gemacht, dass die Menschen, die für diese Rolle am besten geeignet sind, von Verantwortlichkeit, Sichtbarkeit und der Kunst des Verhandelns profitieren.
Aber es gibt Nuancen bei diesen besonderen Qualitäten. Lindstrom zufolge verfügen die Besten über sieben Fähigkeiten, die über die allgemeinen Anforderungen "Sei ein guter Kommunikator" oder "Sei verfügbar" hinausgehen, die für so gut wie jeden Job gelten könnten. Spoiler-Alarm: Wenn Sie Konflikte hassen, ist diese Rolle nichts für Sie.
Kundenbegeisterer
Als Product Owner sind Sie nicht einfach nur ein Verwalter, der alles, was die Stakeholder sagen, in das Product Backlog einträgt. Sicher, Sie müssen sich anhören, was Ihre Stakeholder wollen, aber Sie müssen mehr tun, als nur Informationen zu verarbeiten - Sie müssen die latenten Bedürfnisse entdecken, die sich Ihr Kunde oder Benutzer noch gar nicht vorgestellt hat.
Lindstrom hat zum Beispiel gerade einen neuen E-Mail-Client in Betrieb genommen und war begeistert, als er entdeckte, dass dieser eine Funktion enthielt, mit der er eine E-Mail-Nachricht ganz einfach in ein PDF-Dokument umwandeln konnte. Er musste sie nicht mehr erst in Word konvertieren oder die Zieloption in der Druckfunktion ändern. Es ist klar, dass das Team, das diese Funktion entwickelt hat, über die üblichen Anforderungen von E-Mails hinaus gedacht hat.
Geschichtenerzähler
Quelle : managedagile.com
Großartige Product Owner gehen über die Mechanik hinaus, eine User Story in das Product Backlog zu zerhacken und sie an die Entwickler zu schicken. Als Product Owner ist es Ihre Aufgabe, darüber nachzudenken, wie diese Geschichte in eine Produktfunktion umgewandelt werden kann, die - Sie haben es erraten - den Benutzer erfreut.
Nehmen wir ein anderes E-Mail-Beispiel. Nehmen wir an, ein Backlog-Element für ein Mitfahrunternehmen besteht darin, den Nutzern eine Quittung per E-Mail zukommen zu lassen. Was ist der Hintergrund? Vielleicht ist der Benutzer eine vielbeschäftigte Person auf dem Weg zum Flughafen, die auf der Grundlage dieser Quittung eine Excel-Kostenabrechnung erstellen muss. In diesem Fall können Sie sich zusätzliche Informationen ausdenken, die hilfreich sind, z.B. die Zahlungsmethode (PayPal oder Kreditkarte), Dokumentoptionen (z.B. PDF), Abhol- und Rückgabeort, zurückgelegte Entfernung usw.
Beauftragter
Seien wir mal ehrlich. Auch wenn im Rahmen von Scrum nur eine Person der Product Owner sein soll, ist es für eine einzelne Person fast unmöglich, alles allein zu bewältigen. Wenn die Dinge anfangen, durch die Maschen zu rutschen, werden Teams zusätzliche parallele Rollen schaffen. So kann ein Team beispielsweise eine Rolle als technischer Product Owner einrichten, um Product Owner zu entschädigen, die sich nicht als Teamleiter sehen.
Um zu überleben und zu gedeihen, müssen Sie delegieren und idealerweise ein informelles Team aufbauen, das Ihnen hilft. Moment, klingt das nicht wie ein Scrum-Team? Nun, ja und nein. Das Team könnte den ScrumMaster und verschiedene Mitglieder des Produktentwicklungsteams umfassen, wenn Sie das wollen. Aber es ist ein separates, informelles Product Owner Team, das Ihnen bei verschiedenen Aufgaben helfen kann, vor allem bei denen, bei denen Sie vielleicht nicht der Experte sind.
Entwickler
Quelle : agilemeridian.com
Es ist kein Fehler zu sagen, dass Sie auch ein Entwickler sind. In Scrum legen wir Wert darauf, die Rollen sorgfältig abzugrenzen. Das ist hilfreich, um Scrum zu lehren, aber nicht immer so hilfreich in der Praxis. Rollen können so überbewertet werden, dass der Schwerpunkt nicht mehr auf dem Wert liegt, der geliefert wird, sondern darauf, wer was tut. Als Product Owner denken Sie vielleicht: "Mir gehört das Product Backlog. Mir gehören die User Stories. Ich gebe sie an das Entwicklungsteam weiter, und das entwickelt sie. Das stimmt, aber wissen Sie was? Sie sind Teil eines Teams. Sie sind nicht nur ein Teamleiter.
Es ist das gesamte Team, das den Wert liefert. Wenn Sie sich selbst als Teil des Entwicklungsteams sehen, in dem Ihre Verantwortung darin besteht, zu bestimmen, was entwickelt werden soll, werden Sie eine bessere Zusammenarbeit erreichen.
Wissensvermittler
Genauso wie Sie ein Entwickler sind, sind Sie auch ein Wissensvermittler. Ja, Sie repräsentieren das Product Backlog und sind die Schnittstelle zwischen dem Entwicklungsteam und den Stakeholdern. Aber Sie sind nicht unbedingt der endgültige Experte für das Produkt. Die Entwickler, die den Code schreiben, kommen also nicht sehr weit, wenn sie sich an Sie wenden, um Details zur Benutzergeschichte zu erfahren.
Stattdessen sollten sie direkt mit den Experten, den Stakeholdern der Benutzer, sprechen. Ihre Aufgabe sollte es sein, die Zusammenarbeit zu ermöglichen und die Entwickler zu befähigen, indem Sie die richtigen Gesprächspartner für sie finden. Wenn diese Diskussionen zu Änderungen an den Anforderungen führen, sollten Sie auf jeden Fall darüber informiert werden. Wenn nicht, sollten Sie den Entwicklern das Steuer überlassen, damit sie die benötigten Informationen erhalten.
Konfliktlöser
Wenn Sie nicht mit Konflikten umgehen können, sind Sie in der falschen Branche. Gerade in der Produktentwicklung haben wir es mit einer von Natur aus konfliktreichen Situation zu tun. Das gilt vor allem dann, wenn sich die Beteiligten um Ressourcen streiten und politisieren, was sie tun werden. Je besser Sie also in der Lage sind, Konflikte zu lösen, desto weniger werden Sie eskalieren müssen (siehe unten).
Als Produktverantwortlicher müssen Sie den Mut und die Fähigkeit haben, sich einzumischen, wenn die Dinge schwierig werden. Und seien Sie sich darüber im Klaren, dass Sie in der Regel durch einen Konflikt gehen müssen, um zu einer Lösung zu gelangen. Sie müssen kooperativ sein, um das Negative zu minimieren, und Sie müssen schlichten.
Effektiver Eskalator
Quelle : agileforall.com
Ganz gleich, wie gut Sie Konflikte lösen können, es wird unvermeidlich sein, dass Sie etwas in der Befehlskette eskalieren müssen. Dabei geht es nicht um persönliche Streitigkeiten, wie kleine Kinder, die sich bei Papa beschweren: "Er hat mich geschlagen." Die Eskalation ist eine Rückmeldung an das Management, dass dieses widersprüchliche Ziele verfolgt. Nehmen wir zum Beispiel zwei Interessengruppen, die dasselbe Team mit zwei verschiedenen Zielen beauftragt haben, die nicht zusammenpassen. Das ist ein Konflikt, schlicht und einfach.
Die besten Produktverantwortlichen haben einen Konflikt-Eskalationsmechanismus parat. Natürlich werden Sie versuchen, die Dinge so gut wie möglich mit den Beteiligten zu klären, aber Sie müssen auch die Fähigkeit kultivieren, in der Managementkette nach oben und wieder nach unten zu gehen. Warten Sie nicht, bis Sie eine Krise haben, bevor Sie Ihren Eskalationspfad aufbauen und testen. Suchen Sie nach Gelegenheiten, um kleine (aber zutreffende) Dinge sehr schnell zu eskalieren, damit Sie darin gut werden. Wenn es dann um große Dinge geht und viel auf dem Spiel steht, sind Sie mit Leichtigkeit zur Eskalation bereit.
Es gibt noch viele weitere Fähigkeiten, die Sie als Product Owner kultivieren können, um Ihr Auftreten für Ihr Team zu verbessern, aber die Arbeit an diesen sieben Fähigkeiten wird Ihnen einen Vorsprung in Ihrer Rolle verschaffen. Die Schulung und Zertifizierung zum Certified Product Owner der Scrum Alliance kann Ihnen auch die Unterstützung und die Befugnisse bieten, die Sie für Ihren Erfolg benötigen.