Eine Woche als Product Owner bei e3n

rebekka_product_owner

Was ist ein Product Owner?

Die Rolle des Product Owners stammt ursprünglich aus dem Scrum-Kontext und hat die volle Verantwortung für das Produkt. Dies bedeutet, der Product Owner hat stets den Mehrwert eines Produktes im Fokus seiner Arbeit. Dafür verantwortet er das Product Backlog, welches die Diskussionsgrundlage für den Austausch mit allen Stakeholdern (einschließlich dem kompletten Scrum-Team) darstellt.

Der Product Owner ist ein fachliches Bindeglied zwischen den einzelnen Stakeholdern und entscheidet, basierend auf deren Input, über die Reihenfolge bzw. Prioritäten der Einträge im Product Backlog und damit deren Umsetzung. Im Laufe der Zeit haben sich durch die individuelle Belebung in verschiedenen Unternehmen und Kontexten unterschiedliche Ausprägungen der Rolle des “Product Owners“ entwickelt.

Weiterführende Links:
https://www.scrum.org/resources/what-is-a-product-owner
https://www.romanpichler.com/blog/six-types-of-product-owners/

Der Wochenstart: Austausch mit dem Scrum Master und Planning

Mein Montagmorgen beginnt nicht nur mit ausreichend Kaffee sondern auch mit der Sichtung der Backlogs sowie der verschiedenen Boards, der agilen Roadmap und dem eigenen Kalender. Mit diesem Überblick werden die letzten Vorbereitungen für das Planning getroffen. Ein weiteres Ritual, welches häufig am Montagmorgen stattfindet, ist der wöchentlicher Austausch mit dem Scrum Master. Hier kann ich die vergangene Woche ganz persönlich und mit dem Abstand durch das Wochenende Revue passieren lassen. 

Mit all diesen Informationen im Gepäck kann das Planning starten. Im Planning werden zum einen die agile Roadmap in der aktualisierten Form sowie die aus meiner Sicht wichtigen Themen für die Woche vorgestellt. Gleichzeitig werden aber auch die aktuellen Tickets (welche noch nicht “Done” sind) besprochen. 

Wenn alle Beteiligten zum aktuellen Stand abgeholt sind, gehen wir die neuen Tickets durch, welche anschließend durch die Entwickler geplant werden. Während des Plannings versuche ich immer mit einem Ohr dabei zu sein, um schnell für Fragen zur Verfügung zu stehen. Anschließend stellen die Entwickler ihren Plan zur Umsetzung dem Team vor, geben eine Einschätzung der Machbarkeit ab und committen sich auf das Wochenziel.

Screenshot - Agile Roadmap PO-Week Blog

In Loop mit allen Stakeholdern - Dailies, Weeklies sowie anlassbezogene Kommunikation mit Kunden

Ein gemeinsamer, täglicher Termin bei e3N ist das Daily um 10:00 Uhr. Hier geben alle Teammitglieder einen kurzen Überblick über die eigenen Arbeiten und können potenzielle Blockaden ansprechen. Auch als Product Owner beteilige ich mich aktiv und kommuniziere wichtige Informationen in die Runde. Im Gegenzug erhalte ich Einblicke, an welchen Stellen es ggf. hakt und Unterstützung benötigt wird. Das Daily hilft auch bei der Einschätzung, wann ich mir Zeit für eine Review freihalten sollte.

Über die ganze Woche verteilt finden Austauschtermine mit den unterschiedlichen Kunden statt. Dabei kann es sich um wöchentliche Regeltermine, anlassbezogene Meetings, Telefonate oder kurze Mails- oder Slack-Nachrichten handeln, um sich jeweils abzustimmen, Fragen zu klären oder einfach um Veränderungen bei unseren Kunden frühzeitig wahrzunehmen. Im Rahmen dieser Gespräche erfahre ich mehr über die aktuellen Probleme aber auch über Ideen zu möglichen Verbesserungen aus Kundensicht. 

Ergänzend zu meiner Eigenrecherche sind diese Termine wichtige Impulsgeber für neue Backlog Items oder dienen als Grundlage für eine Revalidierung bereits vorhandener Tickets im Backlog.

Backlog Grooming, die 3 Amigos und Refinements

Die einzelnen Items (bei uns sind dies aktuell Epics, User Stories, Tasks, Bugs oder Spikes) werden initial durch unterschiedliche Teammitglieder reportet und anschließend durch mich weiter ausgearbeitet. Für die Ticket-Verfeinerung hole ich mir wiederum die notwendigen Informationen aus unterschiedlichen Quellen. Das können zum einen die entsprechenden Kundenvertreter, aber auch der passende Solution Architekt sein. Zusammen schärfen wir den Problemfall bzw. den Ausgangspunkt des jeweiligen Tickets. Vor allem bei technischen Themen können mit Hilfe von techn. Experten die einzelnen Backlog Items sinnvoll inhaltlich präzisiert und priorisiert werden.

Eine weitere Methode, welche in unregelmäßigen Abständen stattfindet ist die “3-Amigos Runde”. In dieser Runde kommen unterschiedlichen Experten zusammen und besprechen vor allem neue Spikes oder Epics, um diese sinnvoll schneiden bzw. abgrenzen zu können.

Auf diese Weise kann ich das Product Backlog pflegen und die Items für Refinements vorbereiten. Für Refinements haben wir feste Zeitslots in der Woche eingeplant, um die Ablenkung der Entwickler auf ein Minimum zu reduzieren. Es nehmen alle Entwickler teil, die an der Umsetzung des Features beteiligt sein werden. In dieser Runde werden die Tickets besprochen, die Akzeptanzkriterien nachgeschärft und für alle verständlich (um)formuliert. Mit dem Einverständnis aller im Team können so Tickets bewertet, kommentiert und geschätzt werden.

poker

Die so entstandenen bzw. priorisierten Backlog Items sind wiederum die Gesprächsgrundlage für unsere Beratung des Kunden,um das Produkt sinnvoll weiterzuentwickeln zu können und bestenfalls die notwendigen Freigaben zu erhalten.

“Im Gegensatz zum Scrum Guide, nach dem generell nur Tickets vorgestellt werden sollen, die den Status “done” erreicht haben, stellen wir auch Zwischenstände angefangener Tickets vor, wenn es sinnvoll erscheint.”

Der Wochenabschluss: Approvals und Testing, Reviews und Retrospektiven

Tickets, die erfolgreich die interne Qualitätssicherung (u.a. Erfüllen der Akzeptanzkriterien & Code Review) durch das Entwicklerteam erfüllt haben, landen letztlich für die fachliche Abnahme wieder bei mir. Auf den jeweiligen Stage-Systemen prüfe ich die Änderungen, dass mit der Lösung der Kundenbedarf sinnvoll gedeckt wird. Mit meinem Approval übergebe ich die Tickets an die Kunden zum weiteren Testing.

Ich organisiere die Reviewtermine mit den Kunden, um gemeinsam mit den Entwicklern die abgeschlossenen Tickets vorzustellen. Dabei geht es uns nicht um die reine Vorstellung der Features, sondern darum, dem Kunden einen Einblick in die Umsetzung zu geben und die positiven Auswirkungen der jeweiligen Umsetzung auf das gesamte Produkt aufzuzeigen.

Im Gegensatz zum Scrum Guide, nach dem generell nur Tickets vorgestellt werden sollen, die den Status “done” erreicht haben, stellen wir auch Zwischenstände angefangener Tickets vor, wenn es uns sinnvoll erscheint. Wir haben die Erfahrung gemacht, dass dies durchaus zu wertvollen Diskussionen führen kann und die Kundenpartizipation erhöht wird.

Abseits von den sehr kunden- bzw. produktzentrierten Aufgaben ist der kollegiale Austausch im Unternehmen und auch bilateral mit einzelnen Teammitgliedern wichtig für die kontinuierliche Weiterbildung und Verbesserung im Umgang miteinander.

Im 2-Wochenrhythmus führen wir eine Retrospektive durch und evaluieren gemeinsam im gesamten Team unsere Zusammenarbeit unabhängig von Kundenprojekten oder fachlichen Spezifika. Ebenfalls im 2-Wochenrhythmus haben wir eine unternehmensweite Lerngruppe, in der ich mich mit anderen Product Ownern und interessierten Kollegen zu relevanten Themen, Tools und Methoden austauschen und kontrovers diskutieren kann.

Neben all diesen Terminen ist es aber auch wichtig, sich persönlich mit den anderen Team-Mitgliedern im geschützten Rahmen auszutauschen und so potenzielle kleinere Konflikte oder Probleme frühzeitig zu erkennen und aus dem Weg zu räumen oder sich einfach mal direkt ein Lob auszusprechen. Dafür haben wir kurze, regelmäßige Feedbackrunden (max. 15 Min.) etabliert, welche auf rein freiwilliger Basis initiiert werden können.

Mit all dem Input, der während der Woche entstanden ist, bereite ich am Freitag das Planning für die nächste Woche grob vor und kommuniziere relevante Zwischenstände an die Kunden (falls keine Review stattgefunden hat). 
Damit verabschiede ich mich dann ins Wochenende und am Montag beginnt eine neue spannende Woche …  

TL;DR:

  • Der Product Owner ist in unserem Kontext ein strategischer Berater zwischen den einzelnen Stakeholdern.
  • Eigenrecherche und Kundentermine sind wichtige Impulsgeber für neue Backlog Items und Grundlage für eine Revalidierung bereits vorhandener Tickets.
  • In den Reviewterminen mit den Kunden geht es uns darum, dem Kunden die positiven Auswirkungen der jeweiligen Umsetzung auf das gesamte Produkt aufzuzeigen.
  • Es ist zudem wichtig, sich persönlich mit den Teamkollegen im geschützten Rahmen auszutauschen, um Lob auszusprechen und potenzielle kleinere Konflikte aus dem Weg zu räumen