Alle Artikel mit dem Schlagwort: Product-Owner

Die Dreifaltigkeit agiler Führung

Man kann von Scrum halten was man will, aber der Scrum Guide beschreibt sehr schön drei Aspekte von Führung im Kontext agiler Produktentwicklung. Da gibt es im Zentrum der Wertschöpfung das Development Team, das möglichst autonom und selbstorganisiert arbeitet. Der Product Owner sorgt als „CEO“ des Produkts für die inhaltliche Führung und gibt dadurch der Autonomie eine gemeinsame Vision und Richtung. Und schließlich gibt es den Scrum Master, der sich dienend um die Menschen kümmert und dem Product Owner, dem Development Team und dem Rest der Organisation hilft effektiv zusammenzuarbeiten. Ein klassischer Manager ist dort nicht beschrieben, denn seine verschiedenen Aufgaben sind auf diese Rollen verteilt.

Das Team, das Produkt und der ganze Rest

Rund um Agilität gibt es ein grundlegendes Missverständnis. Dieses Missverständnis beginnt im Titel des Manifests für agile Softwareentwicklung. Unter Softwareentwicklung verstanden viele über zu lange Zeit das Übersetzen von Spezifikationen in Code durch austauschbare Programmierer, die dadurch (und oft verstärkt durch Vertragsverhältnisse) komplett den Kontakt zu ihren Kunden und ihrem Produkt verloren hatten. Und viele verstehen unter Softwareentwicklung genau das heute noch. Nur in kürzeren Zyklen. Agil eben. Den Autoren des Manifests, die allesamt leidenschaftliche Softwareentwickler waren, ging es aber um etwas anderes. Ihnen ging es darum, die Softwareentwicklung wieder als Zentrum der Wertschöpfung zu begreifen und die ganze in schwergewichtige Prozesse gegossene und in Organisationsstrukturen erstarrte Verschwendung um dieses Zentrum herum zu eliminieren. Es ging ihnen darum, als langlebiges Team in gemeinsamer Verantwortung erfolgreiche Produkte zu entwickeln. Und dazu darf es keine Mittelsmänner zwischen Team und Kunden mit entsprechenden Artefakten und Übergaben geben. Stattdessen müssen Fachexperten und Entwickler täglich zusammenarbeiten, um den Markt, das Produkt und den Lösungsraum gemeinsam zu erforschen.

Das Anti-Pattern der Kunden-Lieferanten-Beziehung

Einer der vier Hauptsätze des Manifests für agile Softwareentwicklung lautet „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.“ Und in den Prinzipen hinter dem Manifest heißt es weiter „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ Dieser Begriff des Kunden führt leider bis heute oftmals du dem was Jeff Patton als Kunden-Lieferanten-Anti-Pattern bezeichnet. Gerade in großen Organisationen mit eigenen IT-Abteilungen tritt dieses Muster auf, wenn der Product-Owner seine Rolle als Vertreter der internen Kunden begreift und Anforderungen an das Development-Team zur Umsetzung gibt. Die Kunden und ihre Nöte und Bedürfnisse zu verstehen ist wichtig, ist aber nur ein Aspekt, um ein Produkt erfolgreich zu machen und genau das ist die Aufgabe des Product-Owners. Um alle Aspekte abzudecken, darf der Product-Owner nicht genialer und einsamer Entscheider sein und sich nicht einseitig dem Business zugehörig fühlen, sondern mehr Anführer eines Expertenteams, das gemeinsam die Verantwortung für die nachhaltige Entwicklung des Produkterfolgs übernimmt.

Das Produkt bin ich!

Im Scrum erfüllt der Product-Owner eine entscheidende Funktion: er maximiert den Wert seines Produkts. Ausgehend von einer kraftvollen Vision priorisiert er die Funktionen nach dem angenommenen Nutzen und überprüft diese Annahme regelmäßig anhand der Rückmeldung der Kunden. In hierarchischen Organisationen, die auf Kommando und Kontrolle basieren, ist allerdings immer wieder zu beobachten, dass der eine oder andere Product-Owner zum absolutistischen Fürsten wird: „Das Produkt bin ich!“ Gemäß diesem abgewandelten Leitspruch des Absolutismus regiert er selbstherrlich über das Team und betreibt nach Gutdünken Micromanagement.