Meine Arbeit – wie sieht sie aus, wie fühlt es sich an?
Meine Arbeit ist kommunikativ, sehr sogar. Sie ist kreativ, wertschöpfend und somit selbstredend auch verantwortungsvoll. Ich arbeite an einer Schnittstelle, die viele Menschen zusammenführt und verbindet. Das klingt einfach, ist es aber nicht immer. Meine erste “Product Owner-Pflicht” ist, so oft Fragen zu stellen, bis ich an den Kern der Anforderung herangekommen bin. Dann erkenne ich “Must-Haves” und “Nice-to-Haves”. Das klingt einfacher als es ist. Es ist sehr herausfordernd, denn damit schaffe ich Raum für Freude und auch für Enttäuschungen – ein modernes Wort hierfür: Erwartungsmanagement!
Hallo, ich bin Heiko – Product Owner!
Als Product Owner bin ich für die Weiterentwicklung und Wertschöpfung von bestimmten Produkten, Modulen und Services der finfire Plattform verantwortlich. Wie in jedem modernen Umfeld gilt auch bei uns: Stillstand ist Rückschritt – wir wollen Fortschritt!
Visionen und Ziele, wo sind sie?
Ich bin Informatiker, habe langjährige Berufserfahrung in der Luftfahrt aber keine Ausbildung im Finanzwesen. Sind das gute Voraussetzungen? Ja, denn es ist eine gemeinschaftliche Aufgabe gute Visionen zu schaffen und treffsichere Ziele in dieser Branche festzulegen. Ich stehe mit folgenden Gruppen im Austausch:
- Management der Netfonds (Stakeholder).
- Entwicklungsteams.
- Endanwendern.
Ein kontinuierlicher Austausch ist wichtig. In diesem schaue und höre ich genau hin. Ich notiere, sortiere und priorisiere. Aus Gedanken entstehen die Ziele und Visionen, die ich in mein Backlog übernehme. Das Backlog ist meine Themensammlung. Klingt banal: Das Backlog ist mein Heiligtum. Es liegt vollständig in meiner Verantwortung und ist mein zentrales Instrument, mit dem ich Weiterentwicklung und Wertschöpfung steuere. Aus dem Backlog versorge ich mein Entwicklungsteam mit Aufgaben.
Aus Zielen werden Arbeitspakete
Bevor Visionen, Ideen oder Ziele in die Entwicklung gegeben werden, müssen diese reifen. Ich muss an den Themen redaktionell arbeiten, bevor diese in einem Scrum-Prozess in die Entwicklung gegeben werden. Was passiert da genau?
Anforderungen klein schneiden (MVP): Es ist wichtig, möglichst kleine Produktinkremente (Features) zu finden und aufzuschreiben. Dieser MVP (Minimum Viable Product) ermöglicht eine schnelle und agile Steuerung des Wertschöpfungsprozesses und ist ein zentrales Element der Risikosteuerung. Fehlgeleitete Anforderungen oder Entwicklungen können dadurch schnell auffallen und zügig ein neuer Kurs gesetzt werden (Fail Fast).
Epics: Der MVP findet sich als “Epic” in meinem Backlog wieder. Neben einem aussagekräftigen Titel ist eine genaue Beschreibung des Epics und dessen Leistungsumfangs (Akzeptanzkriterien) notwendig. Ein Epic sollte in einem Release-Train (RT) abgearbeitet werden können. Ein RT besteht in der finfire Entwicklung aus 4 Sprints.
Stories: Ein Epic besteht aus mehreren Stories, die ich in dem Epic identifiziere und aufschreibe. Jede Story ist eine in sich geschlossene Tätigkeit, die einen Mehrwert erzeugt. Stories sind genau wie die Epics klar über Titel, Beschreibung und Akzeptanzkriterien beschrieben und dadurch auch Stories von anderen Stories des Epics abgrenzbar. Die Richtgröße für den maximalen Umfang einer Story lautet: Die Abarbeitung sollte innerhalb eines Sprints möglich sein.
Vorbedingungen & Prüfungen: Für alle Stories wird überprüft, ob Vorarbeiten notwendig werden wie z.B. Überprüfung der technischen Machbarkeit, Erstellung eines UI/UX Design, mögliche Abhängigkeiten zu Modulen & Services anderer Teams, Testszenarien entwickeln, Testdaten bereitstellen oder anfordern, usw.
Die Arbeitspakete in der täglichen Routine
Zugunsten vollständiger Transparenz und Klarheit stelle ich die fertigen Epics und Stories den Stakeholdern vor. Ich erläutere wie die Ziele erreicht werden, wie der MVP aussieht, was mit dem MVP erreicht wird und was der MVP nicht leisten wird. Alignment is key!
Anschließend priorisiere ich mein Backlog klar nach der Maßgabe der Wertschöpfung. Hierbei haben Epics, die sich sich in der Entwicklung befinden “Vorfahrt”, um diese Wertschöpfung zu Ende bringen. Neue Epics und Stories ordnen sich also in einer sortierten Priorität dahinter ein. Ich bewerte und priorisiere nicht nur die neuen Epics und Stories sondern das komplette Backlog. Eine Priorität ist eine Momentaufnahme und nicht für alle Ewigkeiten in Stein gemeißelt.
Vor dem Start eines RT gehe ich mit dem Team die zur Entwicklung anstehenden Epics durch. Ich lege Wert darauf, dass mein Team einen genauen Überblick über die gewünschte Fachlichkeit bekommt. So kann die im Team vorhandene Kreativität stimuliert und ich in gute Bahnen gelenkt werden, was schlussendlich auf das Ziel einzahlt, Team-Identifikation mit der Aufgabe und Produkt zu fördern.
Bevor neue Epics in die Entwicklung gehen, warte ich auf den nächsten Schätzworkshop. In diesem werden die Stories entlang der von mir festgelegten Priorität geschätzt. Danach ist sichergestellt, dass die Entwicklung der ersten Stories eines neuen Epics beginnen kann.
Nun startet eine neue, gemeinsame Reise von idealerweise 4 Sprints, an deren Ende ein Epic fertiggestellt sein soll. Jeder einzelne Sprint folgt einem identischen Ablauf. In den Daily’s stelle ich gemeinsam mit dem Team den Fortschritt fest und überprüfe, ob wir auf Kurs sind. Werden Stories fertiggestellt, nehme ich diese auf Basis der zuvor definierten Testfälle und Testdaten fachlich ab. Am Ende des Sprints findet der Review statt. Dazu sind die relevanten Stakeholder eingeladen und erhalten eine Präsentation über den fachlichen Fortschritt. Die Präsentation wird gerne von den Mitgliedern des Entwicklungsteams übernommen, weil es diesen Kollegen den Raum für Aufmerksamkeit und Sichtbarkeit öffnet. Das kann die Basis für Anerkennung und Identifikation sein. Im Sprint Review werden auch Fragen und Ideen ausgetauscht. Es wird gemeinsam festgestellt, ob man auf Kurs ist oder ob der Kurs angepasst werden muss.
Zusätzlich gibt es einen regelmäßigen Austausch mit den weiteren finfire Product Ownern. Wir halten uns gegenseitig auf dem Laufenden, um einen Gesamtüberblick über den allgemeinen Fortschritt der finfire Plattform zu haben.
Mein Fazit
So ist er also, mein Job als Product Owner. Der Scrum-Prozess unterstützt mich mit einer feste Struktur. Das ist eine wichtige und notwendige Unterstützung. Gespräche mit Stakeholdern und dem Team starten nicht immer mit einer einheitlichen Erwartung. Das kann zu Kontroversen führen, vor denen ich mich nicht scheuen darf. Jeder früh gefundene Konsens ist eine zwingende Voraussetzung, damit am Ende einer Reise ein für alle Seiten gutes Ergebnis entsteht. Das ist nicht immer leicht, aber die Suche nach dem gemeinsamen Konsens ist aus meiner Sicht der entscheidende Reiz und die Kunst, warum der Job Spaß macht. Am Ende trennt er Menschen nicht – nein, er verbindet Menschen. Das bringt mir viel Spaß, denn er fordert mich in Kommunikation, Logik, Antizipation und Empathie – Wenn das alles gut funktioniert, wird es mit guten Ergebnissen und Vertrauen belohnt.
Bild: Canva
Super Beitrag! Bringt Nicht-IT’lern die IT-Welt ein Stückchen näher.
Diese Rolle füllst Du klasse aus. Du hörst zu, verstehst und gibst dem Fachbereich ein konstruktives Bild. Weiter so!