Mein Tag als… Product Owner in St. Gallen.

Discover more about the service Agile Teams and Processes our digital agency has to offer for you.

Ich bin Viviane, Product Owner am Standort St. Gallen und möchte euch am Beispiel meines Arbeitstages das daily business eines Product Owners und mein Arbeitsumfeld vorstellen.

Als Digitalagentur gehören agile Projekte bei Liip zum Alltag. Das spezielle ist, dass jedes Projekt neu und anders ist als das Letzte. Liip arbeitet an massgeschneiderten Lösungen für die Kund*innen, daher gibt es nichts von der Stange. Zudem hat jeder Standort und jedes Team andere Tätigkeitsschwerpunkte. Am Standort St. Gallen werden vor allem Projekte im Bereich custom development umgesetzt. Ganz unabhängig davon spielt in den Teams der Product Owner eine Schlüsselrolle für die Zusammenarbeit mit Kund*innen. Wir sind nicht nur erste Ansprechperson bei Projektideen, sondern sehen uns vor allem als Partner*in in der Produktentwicklung. Ganz nach SCRUM ist es unser Ziel, gemeinsam mit den Kund*innen ein innovatives, sinnvolles und wertschöpfendes Produkt zu entwickeln. Es ist daher gar nicht ungewöhnlich, mit einem Problem zu starten, welches gelöst werden muss. Und dann legen wir als Product Owner los.

Der Start in die Woche

08:30 Uhr, Montag morgen.
Der erste Schluck heisser Kaffee während der Rechner startet.
Das wichtigste Zuerst: die virtuelle Morgen- Begrüssung im Team. Geht es allen gut? Sind alle da? Gerade jetzt, wo der Grossteil der Kolleg*innen inklusive mir selbst von zuhause aus arbeitet sind kleine CheckIns und (virtuelle) ComeTogether besonders wichtig.

Nächster Schritt: E-Mails checken. War das Deployment des aktuellen Releases heute morgen auf der Testumgebung erfolgreich? Ah, der Kollege hat die Kundin bereits informiert, alles hat geklappt, das Feature ist erfolgreich ausgerollt. Das Nachtesten wandert auf meine Agenda für später.

Dann stehen für die beiden Produkte, welche ich in der Rolle des Product Owners verantworte, die Dailies an. Wo stehen wir in Bezug auf das Sprint-Ziel? Schaffen wir, was wir uns für diesen Sprint vorgenommen haben? Wichtig ist an dieser Stelle wirklich das Sprint-Ziel, nicht alle Stories im Sprint.
Solange das Sprint-Ziel nicht gefährdet ist, kann gegebenenfalls beim Scope nachjustiert werden, heute ist das aber nicht nötig.

Im Daily selbst sind neben dem SCRUM-Team, welches auch die Kolleg*innen aus dem Design beinhaltet, nach Bedarf auch jeweils Vertreter*innen des Kunden anwesend. So wird, insbesondere auch bei Abhängigkeiten zu anderen Projekten, ein schneller Austausch und Transparenz über den Projektfortschritt gewährleistet.

Der Verantwortungsbereich des POs bei Liip

Die Rolle des Product Owners bei Liip kann je nach Projekt neben den “klassischen” Verantwortungsbereichen nach SCRUM auch Projektmanagement-Tätigkeiten umfassen. Für mich bedeutet das auch, jeweils Montag Vormittags auch das Projektcontrolling und -Reporting auf der To-Do-List zu haben.

Wie genau ich mich aber bei der Ausführung meiner Verantwortlichkeiten organisiere, ist vollständig mir überlassen. Ich bin eigenverantwortlich dafür, den Anforderungen meiner Rolle(n) bei Liip gerecht zu werden.

Diese Freiheit, aber auch Verantwortung, speist sich einerseits aus dem agilen Mindset und dass ich als Product Owner Teil eines selbstorganisierten Teams bin, aber auch daraus, dass Liip holakratisch organisiert ist.

Wo Holacracy endet und Agilität beginnt

Holakratie und Agilität gehen dabei Hand in Hand; der Wirkungskreis von Holakratie endet dort, wo Agilität beginnt. Im Detail adressiert Holakratie als Rahmenwerk Fragestellungen zur Organisation von Liip, insbesondere zur Struktur und Entscheidungsfindung im Unternehmen. Die agile Arbeitsweise und als Teil dessen agile Frameworks wie SCRUM sind darin eingebettet und unterstützen die Prozesse und Abläufe der Produktentwicklung.

Für mich bedeutet das vor allem Selbstbestimmung im Arbeitsalltag.

Produktentwicklung Hand in Hand

Nach dem Mittagessen liegt der Fokus vor allem auf der Produktweiterentwicklung.
Die Kollegin aus dem Design ist aus dem Urlaub zurück: das Design für die Error pages fehlt noch. Wir stimmen die Anforderung und das Timing dazu im Detail ab. Ausserdem fehlen noch die Animationen. Wie sieht es mit der Kapazität aus? Werden die Animationen rechtzeitig fertig um im übernächsten Sprint für die Implementierung im Frontend zur Verfügung zu stehen?

Gemeinsam ans Ziel

Kund*innentermin. Die neue Anforderung ist noch etwas unkonkret, wir erarbeiten den spezifischen Use Case gemeinsam. Mich treibt dabei vor allem die Fragestellung an, welches Problem für welche Zielgruppe durch die neue Anforderung gelöst werden soll. Wir analysieren, welchen Mehrwert die neuen Features für Nutzer*innen bietet und definieren das Ziel der Anforderung. Im Anschluss erweitere ich die Spezifikation und passe die Priorisierung der Themen im Backlog an.

Zum Abschluss des Tages noch das Testing des Release auf der Testumgebung, alles ok.

Checkout mit den Kollegen, gemeinsamer Aperó zum erfolgreichen Deployment. Feierabend.