Eine Woche als Product Owner bei e3n

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/

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.

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.

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.

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.

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 …