tag: scrum

Was muss ein Product Owner können?

Agile     no comments    
E„Ein neuer Product Owner wird gesucht. Wie sieht die Stellenausschreibung aus? Beim Lesen von Artikeln über modernes Produktmanagement merken wir, dass unser Produktmanagement hoffnungslos veraltet ist. Wir praktizieren kein Design Thinking, betreiben keine Innovation und der MVP ist schon wieder tot bevor wir ihn verstanden haben. Eigentlich dürfte es uns gar nicht mehr geben, so altbacken sind wir.“ Kommt das irgendwie bekannt vor?

Product Owner = Superman?

Das Lesen von Artikeln auf medium und die Teilnahme an Konferenzen wie MTP formen das Bild des Product Owners des allwissenden Supermans. Er muss einen riesigen Wissensschatz mitbringen, um das Wunderwerk zu vollbringen:

  • Stories schreiben
  • Backlog priorisieren
  • Visionen erschaffen
  • Roadmaps bauen
  • Marktforschung betreiben
  • Stakeholder verstehen und organisieren
  • Kreativ-Workshops durchführen
  • Innovation vorantreiben
  • Produkte vertreiben
  • User Experience ermöglichen
  • Business Modelle ausdenken
  • Finanzvorhersagen treffen

Dass dies relevante Aufgaben eines POs sind, ist richtig. Dass ein PO sich aber perfekt (inkl. vieler Methoden und Tools) und aus dem Stand mit allem auskennen muss, nicht. Ich will mich nun einmal auf die Kernfähigkeiten eines POs zurückbesinnen.

Was sind die Kernfähigkeiten des Product Owners?

Trennen wir uns mal von jeglicher Methodik, Vorgehensweise und von Tools. Was bleibt dann eigentlich noch übrig, mit dem sich ein PO richtig gut auskennen muss?

  • Das Wichtige vom Unwichtigen unterscheiden
  • Die wirklichen Probleme und Bedürfnisse von Kunden erkennen und adressieren
  • Komplexitäten durchdringen
  • Empathisch gegenüber Team und Stakeholdern agieren
  • Von einer klaren Linie überzeugt sein, Nein sagen können

Diese Fähigkeiten (die erlernbar sind) sind das Fundament eines jeden Product Owners. Er läuft sonst Gefahr, sich immer mehr und mehr zu verlaufen, bevor sein Fundament steht. Überspitzt dargestellt: Design-Thinking, MVP, OKR und Lean Startup helfen auf der einen Seite nicht, wenn sich der PO mit unwichtigen Features beschäftigt, am Kunden vorbei plant, das Produkt nicht versteht, sich von Team bzw. Stakeholdern gelöst hat und nur situativ reagiert. Die genannten Methoden erfordern aus meiner Sicht erst das genannte Fundament. Hier ist der PO kein besserer PO, wenn er besonders viel davon kennt, sondern wenn er verstanden hat, wofür er sie einsetzt, und wie sie ihn schneller und besser machen.

Muss ein Product Owner technische Kenntnisse haben?

Nein, aber sie helfen eigentlich immer! Treffen sich Team und PO auf der Architektur-Ebene, finden beide Seiten einen einfacheren Zugang zueinander. War der PO früher selber Entwickler, versteht er es, dass die Lösung zunächst einfacher Probleme mehrere Tage dauern können. Es fällt beiden Seiten leichter, über technische Schuld, Refactoring und Tech-Stories zu sprechen.

Kennt oder beschäftigt sich der PO nur mit der fachlichen Seite, sehe ich ein Risiko: Die Isolation vom Team / der Elfenbeinturm (ein übliches PO-Antipattern). Das muss nicht passieren, wenn beide Seiten über Empathie verfügen und die jeweils andere Seite respektieren. Doch ein PO isolierter PO kann in Discoveries, unzähligen Canvasses usw. abdriften. Er verliert dann immer die Bindung ans Team, weil ihn kaum noch jemand versteht. Einen schönen Artikel dazu gibt es hier.

Wieder auf den Boden der Tatsachen zurückfinden

Die Suche nach dem PO-Superman ist nicht sinnvoll. Man wird ihn nur schwer finden. Diese Notwendigkeit ist stark aus dem Rockstar-Image des Product Owners geboren. Methoden und Werkzeuge sind nur Mittel zum Zweck. Sie einzusetzen, um gefühlt dran zu bleiben, hilft nicht. Wenn man aber das konkrete Problem/die Komplexität verstanden hat und sie versucht zu durchdringen, ist es richtig, die passende Methode zur Lösung zu suchen.

Dann teilen wir die Rolle einfach?

Aber ich möchte wieder zur langen Liste von Aufgaben zurückkehren. Das breite Spektrum lässt sich mit den genannten Kernfähigkeiten inhatlich gut adressieren, es bleibt aber viel Arbeit. Ist das Produktteam groß, die Stakeholder-Landschaft komplex oder die Anzahl der Produkte groß, so muss sich der PO mit der Skalierung seiner eigenen Rolle beschäftigen. Dazu hat Roman Pichler drei sinnvolle Optionen beschrieben. Kurz gesagt managed der PO ein PO-Team (z.B. mit einem Business Analysten und einem UX-Experten) oder das Produkt wird zerteilt. Meiner Meinung nach sind das die richtigen Optionen. Beim PO-Team ist liegt die Verantwortung immer noch beim PO und nicht verteilt. Die Zerteilung von Produkten ist nicht einfach, schafft aber auch klare Strukturen. Ein sehr ungünstiges Modell ist die Zerteilung der PO-Rolle in ein Zwei- („PO-Technisch“ und „PO-Fachlich“), Drei- („PO-Technisch“, „PO-Fachlich“, „PO-Management“) oder gar Viergestirn („PO-Technisch“, „PO-Fachlich“, „PO-Organisatorisch“, „PO-Feelgood-Management“). Zum Einen entsteht diese Zerteilung meist am Reißbrett und hat ihren Ursprung in alten Abteilungsstrukturen (Produktmanagement, Software-Development, Projektleitung). Zum Anderen fördert eine solche Konstellation komplexe und unklare Wege in Kommunikation, Entscheidung und Verantwortung.

Schätzung – Die Spitze des Eisbergs

Agile     no comments    
DDie Schätzung eines agilen Teams können für dieses ein leidiges Thema sein. Beim Wechsel von Feinkonzeptionen und reinen Aufwandsschätzungen hin zu agiler Softwareentwicklung und Story Points beobachte ich diese Verhaltensweisen:

  • Stakeholder außerhalb des Teams denken weiterhin in Aufwandsschätzungen, Projektbudgets, Gantt-Charts und Ressourcen („1 Entwickler braucht 4 Tage, 2 brauchen 2“). Story Points und Team-Velocity werden mit hoher Komplexität auf die alten Artefakte umgerechnet.
  • Das Entwicklungsteam entscheidet sich für die Verwendung von idealen Manntagen, hat aber keinen sinnvollen Umgang mit externen Abhängigkeiten und Risiken gefunden. Ein Teil des Teams schätzt risikoreiche Stories höher als der andere Teil der nur in ideale Manntage schätzt.
  • Der Fokus des Schätzens liegt auf der Zahl an der Story. Ob nach Abarbeitung der Story die Schätzung gut oder schlecht war, ist zweitrangig. Das Team lernt nicht daran.
Ist diese Zahl wirklich so wichtig?

Die Idee des Schätzens im agilen Kontext ist, dass das Team an seinen Schätzungen lernt, ein gemeinsames Verständnis zu Anforderungen, Zielen und Machbarkeit aufbaut. Doch ist die geschätzte Zahl an einer Story wirklich so wichtig für das Entwicklungsteam? Ich meine, dass das Schätzen nur Mittel zum Zweck ist. Sobald ein Team gut darin ist, Stories zu durchdringen, zu verstehen und sie anhand von Komplexitäten zu zerteilen oder zusammenzuführen, ist die eigentliche Zahl überflüssig. Denn wenn das Team ein verlässliches Gefühl dafür entwickelt, welche Stories zusammen in einen Sprint passen, hilft die Zahl nicht mehr. In der Praxis hieße das, dass so etwas wie ein Backlog-Refinement weiterhin genutzt wird, um Stories vorzustellen, zu hinterfragen und anders zu strukturieren. Die Schätzrunde fällt aber weg.

Von der Altlast zum Lernen

Der Fokus der agilen Transition eines Teams liegt daher zunächst darauf, dass die Schätzungen eines Teams nur dem Team dienen sollen. Das bedeutet, dass das Team nicht deswegen schätzt, um externe alte Prozesse zu bedienen (die Erreichung dieses Ziels ist in vielen Organisation eine große Aufgabe). Sehr hilfreich ist auch die Einführung der Komplexität für Story Points. In idealen Manntagen geschätzte Stories lassen sich sicherlich gut in alte Strukturen hinein berichten. Übliche Risiken und externe Abhängigkeiten fließen aber gar nicht in die Schätzung mit idealen Manntagen ein, so dass diese nur bedingt hilfreich sind.

Als Nächstes lernt das Team anhand der Schätzung, Sprints optimal auszulasten und ob an der Schätzung etwas verbessert werden muss. Wenn das länger sicher funktioniert kann auf die eigentliche Schätzzahl verzichtet werden.