Product Owner Aufgaben: Andreas Schneider von der DEVK im Interview

Hallo Andreas. Erzähl mal: Wie bist du Product Owner geworden?

Agilität hat mich schon fasziniert, bevor ich in der Zukunftswerkstatt gearbeitet habe. Als ich dann das Angebot bekommen habe, festes Teammitglied der Zukunftswerkstatt zu werden, habe ich diese Gelegenheit sofort ergriffen. Ich wollte Teil dieses agilen Teams werden, das so spannende Themenbereiche betreut. In den letzten zwei Jahren habe ich mit der Zukunftswerkstatt viele großartige Projekte in der DEVK begleitet.

Als dann unsere Product Ownerin in Elternzeit ging, habe ich die Chance erhalten, diese Rolle einzunehmen und Verantwortung für unsere Themen zu übernehmen.

Stichwort „spannende Themen“. Das verbindet man in der Regel nicht mit einer Versicherung. Was macht die Arbeit in der Zukunftswerkstatt so spannend?

Die Zukunftswerkstatt ist das Innovation Lab der DEVK. Wir sehen uns als Förderer von Innovation im Unternehmen und geben Mitarbeitenden den Freiraum, eigene Ideen einzubringen und zu testen. Darüber hinaus unterstützen wir unsere Fachbereiche bei Innovationsthemen. Im Team arbeiten wir hierfür mit dem Scrum-Framework.

Im Kern haben wir zwei Formate: Es gibt einmal den Ideenprozess. Hier kann jeder Mitarbeitende Themen oder Ideen einbringen. Wir kuratieren den Prozess und begleiten die hausinterne Abstimmung, welche Idee in die Umsetzung geht. Gemeinsam mit dem Ideengeber entwickeln wir einen Prototyp, der dann im jeweiligen Fachbereich weiterentwickelt werden kann. Die Themen sind so bunt und unterschiedlich wie unsere Mitarbeitenden und unsere Tätigkeitsbereiche. Das können Ideen für neue Produkte oder zur Verbesserung der internen Prozesse sein. Beispiele sind etwa eine interne Suchmaschine oder ein Informationsportal rund um das Thema Immobilienerbschaft.

Wir fördern aber auch Innovation in unseren Fachbereichen, indem wir beispielsweise Design-Thinking-Workshops anbieten und die Gruppen dabei unterstützen, mit Innovationsmethoden strukturiert besondere Themen anzugehen.

Wie groß ist das Team der Zukunftswerkstatt? 

Wir sind zu neunt. Wir haben sieben Kernteammitglieder, die laut Scrum Guide wohl als „Entwickler*innen“ bezeichnet würden, einen Scrum Master und mich als Product Owner. Unser Team verteilt sich auf fünf DEVK-Standorte. Der Großteil davon sitzt in Köln, wir haben aber jeweils ein Teammitglied aus Wuppertal, Regensburg und Dresden. Ich selbst lebe und arbeite in Münster.

Eure Meetings und Scrum-Events finden also komplett remote statt? 

Ja. Alle Scrum-Events verlaufen remote. Sowohl unser Daily als auch das Sprint Planning, die Review und unsere Retrospektive halten wir über Microsoft Teams ab. Wir haben auch mit hybriden Meetingformaten experimentiert, an denen die Kölner Kolleg*innen zusammen in einem Raum teilgenommen haben. Das hat für uns aber nicht so gut funktioniert, so dass wir als Team nun fast vollständig remote arbeiten. Aber eben auch nur fast – es gibt immer wieder Termine, die einfach nicht so gut über einen Bildschirm machbar sind und wo das Zwischenmenschliche zählt. Und auch als gesamtes Team treffen wir uns in unregelmäßigen Abständen, nutzen die Zeit für besondere Themen und unternehmen dann meistens auch etwas. Denn wir merken deutlich: Solche gemeinsamen Tage schweißen das Team zusammen.

Was sind deine Aufgaben als Product Owner? 

Erst einmal ist es mir wichtig zu sagen: Als Product Owner bin ich nicht der Chef. Das wird meines Erachtens oft missverstanden. Ich bin ein normales Teammitglied, nur mit anderem Aufgabenbereich bzw. einer anderen Rolle.

Der große Unterschied zwischen mir als PO und dem Rest des Teams liegt vermutlich im Zeithorizont. Während die Kolleg*innen im Hier und Jetzt arbeiten, sich die Aufgaben vom Scrum-Board ziehen und umsetzen, schaue ich voraus und muss das „große Ganze“ im Blick haben. Ich muss dafür sorgen, dass wir die nächsten Sprints planen können, mit Stakeholder*innen sprechen, Anforderungen aufnehmen, Stories schreiben und unser Backlog im Blick halten. Dabei versuche ich, das Backlog vorausschauend genug zu planen, sodass Stories für circa die nächsten drei Monate vorbereitet und gepflegt sind. Meinen Job habe ich schlecht gemacht, wenn wir einen Termin haben, in dem wir nichts bereden können, weil ich nichts vorbereitet habe.

Gleichzeitig versuche ich dem Team den Rücken freizuhalten, damit es sich auf die Aufgaben des aktuellen Sprints fokussieren kann. Ich sitze in vielen Runden als Teamvertreter. Nicht als „Chef“, der Entscheidungen trifft, sondern um die gemeinsamen Interessen des Teams zu vertreten. Hier erkläre ich beispielsweise, warum wir bestimmte Themen oder Aufgaben höher priorisiert haben als andere und warum einige Anforderungen erst später oder auch gar nicht umgesetzt werden können. Ich treffe selten alleinige Entscheidungen. Gerade wenn es um bestimmte Themen geht, wo andere Teammitglieder tiefer im Thema sind, kann ich das auch gar nicht, sondern nutze die unterschiedlichen Fähigkeiten und Kenntnisse im Team.

Wo wir schon beim Thema sind: Wie priorisiert ihr? Machst du das allein oder gemeinsam mit dem Team? 

Auch wenn die letztendliche Verantwortung bei mir liegt, nehmen wir die Priorisierung im Dialog vor. Das Team bringt hier ziemlich viel Input ein. Sie haben die aktuellen Themen selbst sehr gut im Blick und wissen, was im nächsten Sprint gemacht werden sollte. Ich habe eher den Blick in die Zukunft. Ich kippe in unseren Priorisierungsrunden Vorschläge ein, was ich glaube, was bald umgesetzt werden sollte und versuche meine Überlegungen zu erklären. Das Team kann dann gut einschätzen, wie sinnvoll und realistisch das ist.

Habt ihr einen festen Termin, in dem ihr eure Themen priorisiert?

Nein. Das kann jederzeit passieren, wenn man eine bestimmte Notwendigkeit erkennt: Im Daily, im Backlog Refinement oder auch im Sprint Planning. Es kommt auch vor, dass zuvor höhere priorisierte Themen wieder runterpriorisiert werden und umgekehrt. Das liegt auch daran, dass wir als Innovation Lab kein klar umrissenes Softwareprodukt erstellen, sondern erheblichen externen Abhängigkeiten unterliegen.

Wann findet euer Backlog Refinement statt?

Wir machen unser Refinement als regelmäßigen Termin im laufenden Sprint. Im Refinement gehen wir durch, was wir für den nächsten Sprint planen möchten. Hier nimmt das Team für die einzelnen Stories auch eine Aufwandsschätzung vor.

Welche Methode nutzt ihr für die Aufwandschätzung? 

Planning Poker. Die Aufwandschätzung ist für mich als Product Owner manchmal schwierig zu ertragen, weil ich die Stories immer anders einschätze und mir denke: „das braucht doch niemals so lange.“ Aber ich halte mich da raus und schaue dem Team nicht in die Karten. Die Kolleg*innen sind hier die Expert*innen – und sie behalten auch meistens recht.

Wie sieht euer Board aus?

Wir pflegen unsere Tickets digital in Jira. Auf dem Board finden sich drei unterschiedliche Arten von Tickets:

1. Stories: Dies sind größere Aufgaben oder Projekte, die sich in mehrere Unteraufgaben teilen lassen. Eine Story teilt sich in drei Bereiche auf: User Story (Was ist der Mehrwert der Story für die Kund*innen/Nutzer*innen?),  Akzeptanzkriterien (Was muss passieren, damit die Story als erledigt gilt?), Was ist zu beachten? (Das können Abhängigkeiten sein, Onboarding-Zeit, wenn Teammitglieder sich etwa in neue Themen einarbeiten müssen oder auch Terminfindung o.ä.) Ein Beispiel für eine Story wäre etwa: „Design-Thinking-Workshop mit der Marketing-Abteilung durchführen“.
2. Unteraufgaben der Stories: Die Unteraufgaben zu den einzelnen Stories sind als Statement formuliert, das eindeutig mit „ja“ beantwortet werden kann. Die Unteraufgaben sind kleinteilig und eindeutig formuliert, um eventuelle Missverständnisse zu vermeiden. Fairerweise muss man sagen, dass wir an der genauen Dimensionierung dieser Unteraufgaben noch feilen. Unteraufgaben für die oben genannte Story wären z. B.: „Wir haben einen Termin gefunden, an dem der Workshop stattfindet.“ oder „Wir haben eine Präsentation erstellt.“
3. Aufgaben: Dieses Ticket kommt seltener vor. Hiermit sind Aufgaben gemeint, die auftreten, mit den eigentlichen Stories aber nichts zu tun haben. Dies sind häufig Orga-Tasks wie beispielsweise Software-Lizenzen für Teammitglieder besorgen oder das Telefonbuch aufräumen.

Wie verläuft euer Sprint Planning?

Die Stories werden ja bereits im Refinement definiert und geschätzt. Das heißt: Alle wissen, worüber wir sprechen. Ich mache am Anfang des Plannings einen Vorschlag, was meiner Meinung nach im Sprint umgesetzt werden kann und sollte.

Und dann fangen wir an zu diskutieren: Das Team schreibt die Unteraufgaben zu den einzelnen Stories. Anhand der Unteraufgaben und der Aufwandschätzung aus dem Refinement legen wir dann gemeinsam die Stories fest, die im Sprint erledigt werden. Es kommt manchmal vor, dass wir noch Aufgaben aus dem letzten Sprint zu erledigen haben. Wir bringen diese und die neuen Stories in eine priorisierte Reihenfolge.

Diese Aufstellung halten wir dann neben die Teamkapazität für den nächsten Sprint: Ist jemand im Urlaub, auf Dienstreise oder Fortbildung? Zudem planen wir einen Puffer ein für unplanbare Abwesenheiten wie z. B. Krankheiten. Wenn wir dann das Gefühl haben, dass es zu viel für den Sprint wird, „schneiden“ wir von unten ab. In der Regel kommen wir so auf circa acht Stories pro Sprint.

Das Sprint Planning ist wie alle Scrum-Events ein Regeltermin und findet immer zur gleichen Zeit statt. Wir setzen eine Dauer von drei Stunden an. Wenn die Zeit nicht ausreicht, führen wir den Termin möglichst noch am Nachmittag des gleichen Tages fort.

Wie werden die Aufgaben im Team verteilt?

Die Kolleg*innen ziehen sich die Tasks vom Board, die sie erledigen möchten. Das kann direkt im Sprint Planning passieren, kurz danach oder auch im Daily. Im Daily gleichen wir uns zudem ab, sprechen über die jeweiligen Tagespläne und Blockaden in der Arbeit.

Welche Rolle übernimmst du in der Sprint Review?

Unsere Sprint Review findet alle drei Wochen am Ende des Sprints statt. Hier präsentieren wir ein Potpourri aus den Aufgaben des letzten Sprints. Die Review ist wie alle unsere Regeltermine (außer der Retrospektive) öffentlich: Jeder aus der Organisation kann vorbeikommen bzw. sich per Teams dazuschalten. Zu Reviews laden wir also nicht nur Stakeholder*innen ein, sondern alle, die interessiert sind. Fokus: Was macht die Zukunftswerkstatt denn so?

Wir schauen uns im Vorfeld der Review an, was im Sprint gelaufen ist und was interessant ist bzw. wo uns die Meinung von den Teilnehmenden interessiert. Wir definieren die Themen, die vorgestellt werden. Die Teammitglieder schnappen sich die Themen, zu denen sie etwas sagen möchten. Manchmal stellen aber auch unser Scrum Master Timo oder ich ein Thema vor. Wir präsentieren die tatsächlichen Arbeitsergebnisse mit der Bitte um Feedback und machen keinen Frontalvortrag. Als Product Owner übernehme ich zumeist auch die Anmoderation und den Ausblick auf den nächsten Sprint.

Aber auch hier sind wir nicht hart festgelegt und versuchen, selbst besser zu werden. Wenn wir merken, dass ein Event wie beispielsweise die Review nicht mehr gut funktioniert, sind wir bereit, auch andere Formate oder Ansätze auszuprobieren.

Was ist deine Aufgabe als Product Owner in einer Retrospektive? 

Die Retrospektive ist ein teaminternes Event ohne außenstehende Teilnehmende. Ich nehme als normales Teammitglied an der Retro teil. Unser Scrum Master Timo moderiert das Meeting. Um für Abwechslung zu sorgen, wählt er jedes Mal eine neue Methode. Zumeist machen wir dann offene Retros, in der jedes Teammitglied seine eigenen Themen einbringen kann. In unregelmäßigen Abständen überlegt sich Timo vorher Themen (manchmal auch im Sparring mit mir), über die wir reden sollten. Das können organisatorische Dinge sein wie z. B. effizientere Ablagesysteme für Dateien, aber auch Sachen, die in der teaminternen Zusammenarbeit eventuell nicht rund gelaufen sind.

Wir definieren pro Retro mindestens eine konkrete Maßnahme, die wir im nächsten Sprint umsetzen wollen und nehmen das beim nächsten Mal auf Wiedervorlage: Haben wir das auch wirklich umgesetzt?  Neben der Sprint Retrospektive machen wir auch themenspezifische Retros etwa zur Verbesserung des Prototypen-Baus.