Wie übernehme ich ganz konkret als Product Owner:in? (2/2)

Wenn jemand ein neues Produkt übernimmt, scheint es genug Hinweise zu geben, wie zu starten ist. Aber wie ist das, wenn ich ein bestehendes Produkt übernehme? Was ist dann zu beachten? Hier ist ein Vorschlag.

Dieser Beitrag besteht aus zwei Teilen. Für eine gute Übernahme brauchen wir ein klares Verständnis davon, was ein Product Owner ist. Davon handelt der erste Teil.

Hier die Punkte in der Übersicht:

• Klärt vorab das Mandat für die PO-Rolle. Ein schwaches Mandat lässt sich später nicht mehr ändern.
  
• Seht Euch an, wie geliefert wird. Je schneller und je automatisierter, je besser.
• Falls Ihr nicht nur für ein Produkt verantwortlich seid, seht Euch die unterschiedlichen Kategorien der Dinge an, die geliefert werden und optimiert jede Kategorie für sich.
• Verschafft Euch einen Überblick über die nötigen Skills und fangt mit Wissenstransfer an, um die Flexibilität zu erhöhen.
• Klärt die Wissenslücken. Was ist noch nicht gut gelöst? Welche Art von Technologien brauchen wir noch, damit das Produkt den Anwendern hilft?
• Verschafft Euch einen Überblick über die Einzelteile des Produkts, um eine gemeinsame Sprachbasis zu schaffen, wenn neue Features umgesetzt werden.
• Macht Euch eine Tabelle mit den Stakeholdern, um aktiv mit den Stakeholdern zu arbeiten.

Bis auf das Verhandeln des Mandats, kann man alle anderen Punkte innerhalb von 1-2 Tagen klären. Danach könnt Ihr mit Refinement und Sprint Planning in Scrum einsteigen.

Ein PO verschafft sich einen Überblick über das Produkt, die Wissenslücken und die Stakeholder (DALL-E generiertes Bild)

Mandat vorab klären

Es kann sein, dass Führungskräfte kein klares Verständnis von der Rolle Product Owner haben. Deswegen muss man vorab klären, was die Idee dieser Rolle ist und ob die Organisation wirklich einen Product Owner haben will. Das hat nämlich Auswirkungen:

• Ein PO hat Handlungsspielraum, den er mit der Unternehmensleitung abstimmt. Was erwartet die Unternehmensleitung von dem Produkt, dem Service oder vom Team?
  
• Ein PO verantwortet die Entwicklungskosten und die künftigen Erlöse.
  
• Ein Scrum-Team ist dann am schnellsten, wenn die Mitglieder Vollzeit im Scrum-Team arbeiten. Das ist oft nicht der Fall. Der wirtschaftliche Schaden von fragmentiertem Arbeiten ist sehr hoch.
• Ein Scrum-Team braucht ebenfalls Handlungsspielräume, d. h. es darf seine Arbeitsmittel und Arbeitsweisen selbst managen.
  

Es wird sehr schwierig, diese Fragen nach Amtsantritt zu klären. Wenn Ihr neue Product Owner:innen seid, würde ich mich mit Scrum-Begriffen auch erstmal ggü. der Leitung zurückhalten. Bietet Eure Hilfe an, wenn jemand mehr über Agilität wissen will. Aber drängt Euer Wissen nicht auf. Das wirkt bedrohlich.

Lieferung klären

Wenn das Mandat klar ist, schaut Euch an, wie das Scrum-Team liefert. Wie lange dauert es, eine Veränderung zu testen? Je schneller und je automatischer, desto besser. 

In der Softwareentwicklung gibt es sog. CI-Pipelines mit automatischen Unit- und Verhaltenstests. Es kann sein, dass das Scrum-Team solche Techniken noch nicht kennt oder nutzt. Dann ist jede Woche Zeit einzuplanen, in der man diese Techniken in Betrieb nimmt. (Das ändert auch die Art, Code zu schreiben.) Es sollte das Ziel sein, die Liefergeschwindigkeit zu verdoppeln, ohne mehr Arbeit und Stress zu erzeugen.

Value Streams klären

Wir treten nochmal einen Schritt zurück. Nehmen wir an, Ihr seid nicht nur für ein Produkt, sondern für die Lieferungen eines Bereichs verantwortlich. Dann ist es hilfreich, sich mal die einzelnen Leistungen anzusehen.

Macht Euch eine Übersicht:

• Gibt es unterschiedliche Kategorien von Dienstleistungen oder Produkten, die regelmäßig geliefert werden?
• Was ist speziell für eine Kategorie, das nicht in den anderen Kategorien vorkommt? Was haben alle gemeinsam?

Nehmt die Zeiten auf: Wie wird jede einzelne Kategorie geliefert? Wie lange dauern die einzelnen Schritte? Was ist das Verhältnis zwischen reiner Bearbeitungszeit und der gesamten Durchlaufzeit - das ist die Prozesseffizienz? Welche einzelnen Schritte liefern keinen Wert aus Kundensicht? Was kann man tun, um nicht-wertschöpfende Schritte zu entfernen?

Skills klären

Welche Skills brauchen wir im Scrum-Team, um zu liefern? Besprecht das im Team. Es das Ziel, dass sich das Team alle nötigen Skill beibringt, damit es flexibler wird. 

Nehmen wir an, wir haben ein Team mit 8 Personen. Jeder macht ein bisschen, damit das Produkt fertig wird. Wenn wir es schaffen, die nötigen Skills zu verteilen, können wir 2 Teams mit vier Personen machen, die genauso schnell liefern.

Wissenslücken klären

Macht Euch eine Übersicht darüber, was Ihr über die erfolgreiche Nutzung Eures Produkts wisst und welches Wissen noch fehlt, z. B. in Form eines Mindmaps. Welche Technologien setzt Ihr ein? Was für Technologien braucht Ihr noch?

Produktüberblick erstellen

Macht Euch einen Überblick, aus welchen Teilen Euer Produkt besteht (max. eine Seite). Das kann ein Baumdiagramm, ein Mindmap, ein Domänenmodell oder ein Bild in einem anderen Format sein. Hauptsache Ihr habt eine gemeinsame Kommunikationsbasis.

Mit Stakeholdern arbeiten

Macht Euch einen Plan, welche Stakeholder - vor allem künftige Anwender - vom Produkt betroffen sind. Fragt Euch zusätzlich, wer die Lieferung besonders fördern, aber auch besonders verzögern kann. Macht Euch eine Liste dieser Gruppen oder Personen:

• Gruppe
• Informationsbedürfnisse: Was baucht diese Gruppe von uns? Was brauchen wir von denen, um erfolgreich weiter zu machen?
• Wie oft sollte man mit dieser Gruppe Kontakt aufnehmen?
• Wie nehmen wir Kontakt mit dieser Gruppe auf?

E-Mail scheidet aus meiner Sicht als Kommunikationsmedium aus. Es ist natürlich sehr elegant, wenn man die Scrum-Ereignisse mit der Stakeholderarbeit verbinden kann.

Aus meiner Sicht arbeitet ein Produktowner mit drei Listen oder Bildern, die alle maximal eine Seite lang sind:

• Produktüberblick
• Wissenlücken
• Stakeholdertabelle

Scrum funktioniert, weil wir über die Stakeholderarbeit und andere Mechanismen unsere aktuelle Lösung ständig bewerten. Fragt Euch also immer wieder:

• Nach welchen Kriterien bewerten wir, ob unsere Lösung gut oder schlecht ist? (je konkreter je besser)
• Wie bekommen wir häufig Feedback zu diesen Kriterien, um über die nächsten Schritte zu entscheiden?

In die Sprintplanung einsteigen

Für den Product Owner ist nur EINE Frage zu Beginn eine Sprints wichtig:

• Welches Feedback brauchen wir am Ende des Sprints, um guten Gewissens das Geld unserer Sponsoren weiter zu verbrennen?

Alle anderen Fragen leiten sich daraus ab:

• Welche Wissenslücken sollten wir deshalb in diesem Sprint angehen?
• Welche Backlog Items können wir dazu heranziehen? Sind diese eigentlich gut vorbereitet (ready)?
• Wie wollen wir diese Items umsetzen, damit wir gutes Feedback bekommen.

Viel Erfolg in Eurer Product-Owner-Arbeit!

Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.

Vielen Dank an Lutz B. für das Feedback zur ersten Version dieses Artikels.