Direkt zum Hauptbereich

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!

 

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

 

Kommentare

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Psychologische Sicherheit: Das Geheimrezept hoch performanter Teams

  Psychologische Sicherheit ist ein Konzept, das hoch performante Teams auszeichnet.    In Zeiten zunehmender Ausfälle aufgrund psychischer Belastungen am Arbeitsplatz findet das Thema immer mehr Beachtung in der Gesellschaft und Wirtschaft. Psychologische Sicherheit beschreibt einen Zustand, in dem Teammitglieder in einem als persönlich sicher empfundenen Umfeld, produktive Ergebnisse erzielen. Verantwortung, Vertrauen und Verletzlichkeit bilden das Fundament gemeinsamer Zusammenarbeit.   Indikatoren für eine geringe psychologische Sicherheit im Team: ·         der Status quo wird nicht offen hinterfragt ·         Ideen oder Fehler werden nicht offen kommuniziert ·         Teammitglieder scheinen mehr Energie darauf zu verwenden, "das Gesicht zu wahren" ·         Meetings ufern regelmäßig aus - Diskussionen statt Ergebnisse und Entscheidungen ·         nach einem Meeting fragen sich Kollegen regelmäßig, wieso sie überhaupt an dem Termin teilgenommen haben ·  

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Wie liest man sich in Scrum und Agilität ein?

Nehmen wir an, Sie hätten keine Ahnung von Scrum und Agilität. Aber Sie spüren bei Ihren (Beratungs-) Kunden immer wieder, dass sie diese Themen bewegen. Wer sind die Player, welche Bücher sind wichtig? In diesem Artikel versuche ich einen Überblick zu geben.

Teambarometer und mehr mit Microsoft Updates/Microsoft Aktualisierungen

In der Zusammenarbeit ist ja immer besonders wichtig zu wissen, wie es im Team so läuft. Wenn das Team virtuell arbeitet, ist das eine besondere Herausforderung. Microsoft bietet hierzu neuerdings mit der  App "Updates" ( deutsch: Aktualisierungen)  eine besonders komfortable Hilfe an, die automatisiert  turnusmäßige Abfragen ermöglicht.