Product Owner Skills & Voraussetzungen

Kein Projekt kommt ohne ihn aus: Der Product Owner ist DIE entscheidende Schlüsselperson, die für Erfolg oder Misserfolg stehen kann. Als Schnittstelle zwischen Business und Entwicklungsteam dürfen allerdings nicht nur kommunikative Skills mitgebracht werden.

Er trägt die Produkt-Vision im Herzen. Er weiß, wie sich ein Produkt kurz-, mittel- und langfristig entwickeln soll. Er kennt die Personas seiner Stakeholder, weiß Kundenfeedback zu interpretieren und daraus seine Strategie zu entwickeln.

Aber was für Skills muss ein Product Owner mitbringen, damit nachhaltige Werte geschaffen werden? Hier meine persönliche Top 5.

Neugier

Product Owner sind wissenshungrig. Sie sind nicht nur Beobachter, sondern auch Zuhörer, Reisende, Innovatoren und Fragesteller. Ihre wichtigsten Schnittstellen? Stakeholder, Kunden und Entwickler.

Prozesse müssen präzise verstanden und abgebildet werden, bevor sie durch IT unterstützt, optimiert oder automatisiert werden können. Der PO ist im Idealfall sowohl in den Prozessen als auch in der Technologie zuhause.

Ich habe einige Fälle erlebt, in denen sich Prozess-Verantwortliche als Product Owner gesehen haben, da ausschließlich sie die „notwendige Fachkompetenz“ für ein Projekt mitbringen würden. Diese weit verbreitete Fehleinschätzung kann ein massives Scheitern von Projekten zu Folge haben, da Interessen in der Regel einseitig vertreten werden. Fehlendes technologisches Fachwissen und utopische Vorstellungen bei der Umsetzung kosten Zeit und Geld.

Warum ich den idealen PO auch als Reisenden sehe? Um einen Blick über den eigenen Tellerrand zu erhalten, ist ein brancheninterner und -übergreifender Austausch auf Konferenzen, Open Space Formaten oder in klassischen „Arbeitsgemeinschaften“ erforderlich. Schlüsselkunden haben ihren Sitz nicht immer im Haus nebenan und ein persönliches Gespräch ist oft besser als ein Telefonat.

Auch sollte der Product Owner einplanen, sich regelmäßig mit dem Service-Desk oder Kundenservice auszutauschen. Als Geheimtipp empfehle ich einmal pro Woche eine Stunde lang Kundenanfragen zu lesen, um Probleme und Wünsche
frühzeitig zu erkennen und langfristig bestmöglichen Value zu schaffen.

Vision

Die klare Definition der Vision ist das, worauf der Product Owner sein Handeln aufbauen kann. Die Vision hilft nicht nur ihm, richtige Entscheidungen zu treffen, sondern schafft auch Transparenz in Richtung Business (Stakeholder) und Technologie (Entwickler). Eine offene Kommunikation der Vision ist entscheidend, um zu verstehen, welches übergeordnete Ziel mit einem Produkt erreicht werden soll.

Gerade für Entwickler, die an „eher unscheinbaren“ Backlog-Items arbeiten, ist ein Verständnis der Vision wichtig, um den Sinn hinter den großen Ganzen zu erkennen und sich als Bestandteil des Gesamterfolgs zu betrachten.

Ein Bekannter von mir hat einen aus meiner Sicht ziemlich stumpfen Alltag im Access Management. Er ist tagtäglich damit beschäftigt, Firewall-Regeln einzurichten, zu bearbeiten und zu prüfen. Seine nahezu einzige Schnittstelle zur Außenwelt ist das Service Desk, über das er Aufträge erhält. Und das seit Jahren. Da er sich allerdings als Schlüsselposition in der IT-Security betrachtet und damit einen maßgeblichen Beitrag zur Unternehmenssicherheit beiträgt, ist er glücklich. Und zufriedene Teamplayer sind heutzutage essentiell wichtig, um produktiven Output zu liefern.

Kommunikation

Verbindliche und transparente Kommunikation gegenüber Team-Mitgliedern und Stakeholdern sind essentiell für erfolgreiche Projekte. Gerade dann, wenn mehrere oder viele Teams ein gemeinsames Ziel verfolgen, muss jeder seine Rolle verstehen und darf nicht auf Basis von Halbwissen, Annahmen oder Mutmaßungen handeln. Auch müssen die richtigen Tools zur Verfügung gestellt werden, um sicherzustellen, dass Informationen stets verfügbar sind und Fragen schnell und effizient geklärt werden können.

Der Product Owner muss nicht nur gute Kommunikations-Skills mitbringen sondern sich auch in unterschiedliche Team- und Persönlichkeitstypen hineinversetzen können. Er muss die Strategie und Vision des Business verstehen und diese in den Entwicklungsteams Wirklichkeit werden lassen. Wenn die Kommunikation nicht klar und transparent ist, gerät ein Projekt schnell in Schieflage.

Hingabe

Getreu dem Motto „Home is where your heart is“ muss ein Product Owner sich mit dem Vorhaben identifizieren und voll und ganz hinter ihm stehen. Der ideale PO versucht, bei jedem Meeting dabei zu sein und mit allen Team-Mitgliedern zusammenzuarbeiten. Er hat stets ein offenes Ohr für Fragen und ist bereit, seine Vision und sein Wissen zu teilen.

Filtern, Bewerten und auch mal Nein-Sagen

Natürlich darf der Product Owner kein chronischer Verweigerer sein und sich als Blockade zwischen Business und Development aufbauen. Trotzdem ist es wichtig, dass er nicht jede einzelne Idee umsetzen lässt. Er braucht auch den Mut „nein“ sagen zu können und Wünsche sehr weit unten im Backlog zu platzieren.

Der Versuch, jeden Wunsch erfüllen zu wollen, endet häufig darin, dass das
Team das Projektziel aus den Augen verliert, der Entwicklungsprozess zu langsam voranschreitet und Ergebnisse ausbleiben.

Wichtig ist, und das sollte selbstverständlich sein, das „Nein“ nett zu verpacken und beispielsweise auf ein späteres Release zu verweisen. Es passiert schnell, dass Ideengeber auf Feedback verzichten, weil sie davon ausgehen, dass Vorschläge „sowieso nicht“ berücksichtigt werden. Und das leitet einen langsamen, qualvollen Tod der Innovationskultur ein.

Agile Frameworks

Als das Agile Manifest im Jahr 2001 erstmalig veröffentlicht wurde, folgten mit Scrum, DSDM und Extreme Programming die ersten Frameworks auf Basis der agilen Werte.

Agiles Manifest


Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Der Fokus dieser Frameworks ermöglicht es auch heute noch, dass kleine Teams auf effizientem Weg mit geringem bürokratischen Aufwand hochwertige Ergebnisse liefern.

Agile Methoden haben inzwischen auch im Mittelstand, bei Konzernen und öffentlichen Körperschaften an Wichtigkeit gewonnen, so dass jüngere Frameworks gewachsen sind, die large-scale Implementationen mit sehr großen Teams ermöglichen.

Grundsätzlich muss man sich vor der Einführung eines Frameworks folgende Fragen stellen:

  • Wie groß ist die Entwicklungsorganisation?
  • Wie komplex ist das Produkt?
  • Wie groß ist die Gesamtorganisation?

Was bleibt von Scrum & Co. übrig?

Projekte werden soweit herunter gebrochen, dass Teams nach wie vor an kleinen, überschaubaren Projekten arbeiten. In der nächsten organisatorischen Stufe werden diese Projekte zu Programs zusammengefasst. Alle Teams arbeiten miteinander an einem Program. Die Herausforderung ist, dass die Teams so locker organisiert werden, dass sie genug Freiheit für eine kreative Entfaltung und die Schaffung von Innovation haben, aber trotzdem so strukturiert arbeiten, dass sie übergreifende Erwartungen und Anforderungen erfüllen.

Komplex ist außerdem die Koordination, wann ein Projekt startet und abgeschlossen sein wird: Die Definition von Aufgaben, das Management des „Work in Progress“ und die Planung der nächsten Schritte erfordert viel Steuerung und Kommunikation.

Large-Scale Frameworks

SAFe („Scaled Agile Framework“)

Das Scaled Agile Framework gehört aufgrund seiner hohen Verbreitung zu den populärsten Methoden, große agile Teams zu steuern. Eines der größten Unternehmen in Deutschland, das SAFe einsetzt, ist die Volkswagen AG.

SAFe wurde in 2007 erstmalig von Dean Leffingwell in Buchform veröffentlicht und seitdem regelmäßig verbessert und aktualisiert. Die aktuelle Version 4.6 ist im Oktober 2018 erschienen. SAFe versteht sich als Sammlung von Strukturen, Methoden und optimierten Workflows. Zudem ist der Zertifizierungsprozess klar definiert und sehr ausgereift.

Ähnlich wie Scrum schreibt das Framework genau vor, wie SAFe einzusetzen ist. Dies beinhaltet:

  • Aufbauorganisation (Strukturen, Rollen, Abhängigkeiten)
  • Prozess mit definierten Zeitpunkten für die Artefakt-Generierung
  • Methoden
  • Praktiken

Aufgrund der Komplexität ist SAFe nur in großen Strukturen einsetzbar und bietet zudem die Möglichkeit, die Entwicklungs-Organisation an bestehende Konzernstrukturen anzubinden. Die einzelnen Projekt-Teams arbeiten auf Basis einer erweiterten, modifizierten Form von Scrum.

LeSS („Large Scale Scrum“)

LeSS ist, einfach ausgedrückt, eine erweiterte Form von Scrum, bei der eine zusätzliche Ebene die Entwicklungsteams miteinander vernetzt. Diese übergeordneten Teams bestehen aus bis zu zwei Mitgliedern der Entwicklungsteams, die an regelmäßigen, übergreifenden Meetings teilnehmen und die Schnittstelle zu anderen Teams darstellen.

Die zusätzlichen Abstimmungen beinhalten ein übergreifendes Sprint Planning und Daily Standup. Weiterhin gibt es eine „overall retrospective“, die in der Woche nach dem Sprint Review stattfindet und an der bedarfsabhängig Mitglieder der Entwicklungsteams teilnehmen.

Für alle Teams gilt eine Definition of Done. Sprint-Dauer, -Beginn und -Ende sind ebenfalls synchron. Teams haben allerdings die Möglichkeit, die Definition of Done intern strenger auszulegen und durch eigene Anforderungen zu erweitern. Ziel ist, dass nach jedem Sprint ein Produkt besteht, das potentiell bereitgestellt werden kann („shippable product“).

Trotz der Größe der entwickelnden Organisation gibt es nur einen Product Owner und ein Product Backlog. Der Product Owner wird allerdings durch die Teams, die direkt mit Kunden und anderen Stakeholdern zusammenarbeiten, bei der Pflege des Backlogs unterstützt.

Weiterhin ist vorgesehen, dass ein Scrum-Master fulltime für bis zu drei Teams tätig ist. Organisatorische/disziplinarische Manager sind optional. Ihr Fokus liegt aber weniger auf der Organisation des Tagesgeschäfts, sondern darauf, Werte innerhalb des Entwicklungszyklus zu definieren und zu schaffen.

Der Einsatz von LeSS bietet sich an, wenn zwei bis acht Teams gemeinsam an einem Produkt arbeiten. Für großere Implementierungen gibt es „LeSS Huge“, bei dem bis zu 1000 Entwickler koordiniert werden können.

DaD („Disciplined Agile Delivery“)

Während Scrum üblicherweise davon ausgeht, dass bereits eine vorhandene Entwicklungsorganisation besteht, beschäftigt sich das DaD Framework mit der Initiierung eines Entwicklungsprozesses, quasi einem „Sprint Zero“, den es in Scrum formal nicht gibt.

„Disciplined Agile Delivery“ fungiert als Orientierungs- und Entscheidungshilfe für die Einführung agiler Methoden:

  • Modellierung
  • Dokumentation
  • Governance

Hierbei besteht die Möglichkeit, die Organisationsstruktur nahezu individuell zu definieren. DaD bezeichnet sich als „Hybrid Agile“. Das bedeutet: Es werden verschiedene Modelle und Methoden aus unterschiedlichen Frameworks (SAFe, Scrum, Kanban, Lean) miteinander vereint.

Dabei gliedert sich das Vorgehen in drei Phasen:

Inception Phase
Vision des Projekts entwickeln, Risiken identifizieren, Arbeitsumfeld schaffen

Contruction Phase
Erstellung eines potentiell bereitstellbaren Produkts, Qualitätssicherung

Transition Phase
Bereitstellung der Lösung

Maßnahmen in allen Phasen
Sicherstellung der Projektvision, Risiken adressieren, Optimierung der Teamprozesss und Arbeitsumgebung/Infrastruktur

Der Lifecycle der Produktentwicklung basiert hauptsächlich auf Scrum, wird aber um die straffe Verfolgung einer definierten Strategie (Vision/Mission) erweitert. Für den Erfolg der Umsetzung sind nicht nur das Entwicklungsteam, sondern alle Personen innerhalb der Organisation verantwortlich.

Agile Scaling Cycle

Der „Agile Scaling Cycle“ ist weniger ein Framework sondern mehr ein Vorgehen zur Entwicklung einer agilen Organisation. Durch ihn soll sichergestellt werden, dass die Flexibilität, Produktivität und die Innovationskraft, die auf Team-Ebene besteht, auch bei einer wachsenden agilen Organisation und größeren Projekten sichergestellt werden kann.

Das zyklische Vorgehen in drei Schritten ermöglicht es, neue und bestehende Organisationsstrukturen zu entwickeln und nachhaltig zu verbessern:

Step 1: Abhängigkeiten reduzieren
Projekte werden soweit herunter gebrochen, dass möglichst wenig Abhängigkeiten bestehen. Wohl bemerkt: Wenig bedeutet nicht „keine“.

Step 2: Teams koordinieren
Die verbleibenden Abhängigkeiten (fachlich und technisch) werden im zweiten Schritt des Cycles bestmöglich koordiniert und gesteuert.

Step 3: Unternehmen entwickeln
Auf Basis der gewonnenen Erfahrungen wird die Organisation weiterentwickelt und verbessert.

Mit diesem iterativen Verfahren wird langfristig sichergestellt, dass eine optimale Organisation größtmöglichen Value liefern kann.

Spotify Culture

Der Vollständigkeit halber möchte ich abschließend noch die „Spotify Culture“ nennen. Der schwedische Musikdienst hat inzwischen weltbekannte agile Strukturen und Vorgehen entwickelt. Aufgrund des hohen Innovationswertes werde ich in einem gesonderten Artikel darauf eingehen.

Fazit

Die Wahl des individuell „richtigen“ Frameworks ist stark abhängig vom Vorhaben, vorhandenen Organisationsstrukturen und der derzeitigen Arbeitsweise von Teams. Auch Hybridmodelle sind denkbar. Wichtig ist, dass eine initiale Zündung zum agilen Wandel (egal ob bottom-up oder top-down) stattfinden muss.

Agilität ist der Grundstein einer zukunftssicheren Organisation, in der nachhaltig Werte geschaffen werden und die langfristig auf zufriedene, eigenverantwortlich-tätige Mitarbeiter mit dem richtigen Mindset bauen kann.

Was Kinder in welchem Alter können sollten

Was sollte ein Kind wann können? Diese Frage haben wir uns letzte Woche gestellt, nachdem wir mit dem kleinen Prinzen (9) eine Diskussion darüber geführt haben, bei welchen Dingen Kinder im Haushalt helfen sollten. Wie ich herausgefunden habe, geht es vielen Eltern genauso wie uns, so dass wir nach ein paar Tagen Recherche und Gesprächen mit Freunden und Bekannten folgende Sammlung zusammengestellt haben. Ich freue mich auf Eure Anmerkungen in den Kommentaren, so dass ich die Liste nach und nach erweitern, korrigieren und vervollständigen kann.

weiterlesenWas Kinder in welchem Alter können sollten

Meine Erfahrung mit der Check24 Mietwagenbuchung

Ich möchte mir an dieser Stelle einmal Luft machen und über meine Check24 Mietwagenbuchung berichten.

Über die Website habe ich im Laufe der letzten Jahre immer wieder Fahrzeuge geordert. Die Online-Buchung verlief jede mal schnell, einfach und auch von der Kommunikation per E-Mail und SMS sehr serviceorientiert und effektiv. Doch dieses Jahr habe ich das erste Mal mit dem Check24 Kundenservice Kontakt gehabt. Hätte ich vorher gewusst, auf was ich mich einlasse, hätte ich mit Sicherheit bei einem anderen Dienstleister gebucht…

weiterlesenMeine Erfahrung mit der Check24 Mietwagenbuchung