E-Book, Deutsch, 444 Seiten
Reihe: Rheinwerk Computing
Dellnitz / Demarmels / Gentsch Fokus!
1. Auflage 2023
ISBN: 978-3-8362-9271-9
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection
Das Handbuch für Product Owner
E-Book, Deutsch, 444 Seiten
Reihe: Rheinwerk Computing
ISBN: 978-3-8362-9271-9
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection
Du bist Product Owner. Die Aufgabe könnte kaum komplexer sein: Die Qualität eures Produkts hängt von deiner Arbeit ebenso ab wie ein wertschätzendes Miteinander. Auch Infrastruktur, Stakeholder und Terminpläne brauchen deine Aufmerksamkeit. Ihr liefert häufig und du musst stets wissen, wie es um den Fortschritt bestellt ist.
Dieses Handbuch hilft dir, die Rolle in allen Facetten gut auszufüllen. Es bietet einen Überblick über Prinzipien, Aufgaben und Artefakte in Scrum, lehrt Grundlagen gelungener Kommunikation und eine Fülle ganz konkreter Vorgehensweisen.
Du profitierst von der vielseitigen Erfahrung der Autor*innen im Coaching und in der Produktentwicklung. Lerne pfiffige Abläufe und robuste Methoden für verschiedene Projektsituationen kennen. Für den Einstieg und als Begleiter in der Praxis.
Aus dem Inhalt:
- Weshalb Unternehmen agil arbeiten
- Aufgaben in der Product-Owner-Rolle
- Meetings und Retrospektiven gestalten
- Produktstrategie und Ziele
- Story Mapping und Releaseplanung
- Kommunikation: POs als Vermittler
- Gekonnt priorisieren
- Design Thinking: Nutzer*innen beobachten und verstehen
- Datengetriebene Produktentwicklung
- Risiken erkennen
- Agilität für ganze Unternehmen
Julia Dellnitz ist Geschäftsführerin der Unternehmensberatung smidig in Hamburg. Sie liebt es, Menschen bei der Entwicklung digitaler Produkte und Prozesse zum Erfolg zu führen. In den letzten zwanzig Jahren hat sie große Change- und Digitalisierungsinitiativen begleitet und mit Tausenden Menschen an spannenden Projekten gearbeitet. Sie ist bekannt für ihre spielerischen Vorträge und setzt sich für mehr Vielfalt in Tech-Berufen ein.
Autoren/Hrsg.
Weitere Infos & Material
Vorwort ... 17 1. Gesucht: Product Owner (m/w/d) ... 19 1.1 ... Scrum - eine agile Allzweckmethode? ... 20 1.2 ... Product Owner*in - was ist das eigentlich? ... 25 1.3 ... Fünf Dinge, um die du dich wirklich kümmern musst ... 31 1.4 ... Was ist NICHT dein Job?! ... 40 2. Alles im Blick: die Produktübersicht ... 43 2.1 ... Viele verschiedene Perspektiven einbeziehen ... 44 2.2 ... Alles auf einem Blatt ... 45 2.3 ... Deine Vision zählt ... 48 2.4 ... Die Bedürfnisse der Kundschaft kennenlernen ... 50 2.5 ... Die Produktstruktur entwickeln ... 52 2.6 ... Der Return muss stimmen: Nutzen und wirtschaftliche Anreize ... 58 2.7 ... Unwägbarkeiten und Risiken konstruktiv wenden ... 60 2.8 ... Rechtliche Rahmenbedingungen einbeziehen ... 65 2.9 ... Die Abhängigkeiten ermitteln ... 66 2.10 ... Die Kommunikation mit den Stakeholder*innen aufbauen ... 70 2.11 ... Experimentiere dich an den Auftrag ran ... 73 2.12 ... Deine persönliche Überblicksroutine ... 75 3. Das Fundament: Projektmanagement ... 77 3.1 ... Meilensteine, Iterationen und das Produkt-Ziel ... 78 3.2 ... Deine Vorgehensstrategie entwickeln ... 83 3.3 ... Wie sag ich es den anderen? ... 88 3.4 ... Vom ersten Meilenstein zum Product Backlog ... 90 3.5 ... Produktarten und ihre Herausforderungen ... 93 4. Zeit für Feedback ... 99 4.1 ... Die Wissensspirale ... 100 4.2 ... Feedback: ehrliche Rückmeldungen für die Weiterentwicklung nutzen ... 102 4.3 ... Voraussetzungen für gute Feedback-Gespräche ... 104 4.4 ... Feedback-Regeln ... 107 4.5 ... Der Feedback-Canvas ... 108 4.6 ... Vom Umgang mit Feedback und Fehlern ... 110 4.7 ... Lernmomente gestalten ... 111 4.8 ... Impulse im Entwicklungsalltag aufgreifen ... 111 5. Product Discovery: Raten oder Daten? ... 123 5.1 ... Was ist Product Discovery? ... 124 5.2 ... Immer ist ein guter Zeitpunkt ... 126 5.3 ... Die Haltung entscheidet ... 126 5.4 ... Methoden zur Product Discovery ... 128 5.5 ... Design Thinking ... 139 5.6 ... Serendipität ... 141 5.7 ... Vorsicht vor Denkfehlern! ... 142 5.8 ... Hypothesen bilden und testen ... 143 5.9 ... Wie weiter? ... 144 6. Zuhören, verstehen, ansprechen: dein Kommunikationsjob ... 147 6.1 ... Verständlichkeit und Verständigung herstellen ... 149 6.2 ... Zusammenarbeit durch angemessene Kommunikation initiieren ... 154 6.3 ... Agil kommunizieren ... 159 6.4 ... Gesprächsführung übernehmen in alltäglichen und herausfordernden Situationen ... 161 6.5 ... Kreative Prozesse moderieren ... 171 6.6 ... Schneller entscheiden, statt immer zu warten ... 175 7. Frisch sortiert ist halb gewonnen: das Refinement ... 187 7.1 ... Hol dein Team zusammen ... 188 7.2 ... Stories und Backlog-Einträge schreiben ... 188 7.3 ... Geschickt schneiden ... 195 7.4 ... Akzeptanzkriterien finden ... 200 7.5 ... Definition of Done ... 204 7.6 ... Gut geschätzt: Story Points & Co. ... 207 7.7 ... Sortieren und priorisieren (und mal Nein sagen können) ... 214 7.8 ... Das Refinement ritualisieren: Wie machen wir das regelmäßig? ... 217 8. Interview: Auf einen Kaffee mit Product Ownerin Jil ... 221 8.1 ... Die Product-Owner-Rolle in der Praxis ... 222 8.2 ... Mit Daten arbeiten ... 223 8.3 ... Kommunikation ist das A und O ... 223 8.4 ... Fragen sind »The Only Way«! ... 225 8.5 ... Dein allerbester Freund aus dem Tech-Team ... 226 8.6 ... Geh mit dem Problem ins Team, nicht mit der Lösung ... 226 8.7 ... Tools helfen, den Überblick zu behalten ... 227 8.8 ... Der Blick ins Product Backlog ... 228 8.9 ... Scrum? Kanban? Scrumban! ... 230 8.10 ... Ein gutes Reporting-Tool ist Pflicht ... 231 9. Was liegt an? Planning und Daily ... 233 9.1 ... Das Sprint Planning vorbereiten ... 235 9.2 ... Das Sprint-Ziel formulieren ... 239 9.3 ... Aushandeln: Was kommt in den Sprint? ... 243 9.4 ... Daily zur Information nutzen ... 246 9.5 ... Dem Team Orientierung geben ... 248 9.6 ... Sind wir done done? Die Definition of Done nutzen ... 249 9.7 ... Wertvoll und nützlich? Features abnehmen ... 249 9.8 ... Refinement: Anforderungen erkennen ... 250 9.9 ... Sprint-Wechsel vorbereiten ... 252 9.10 ... Den Sprint abbrechen ... 252 9.11 ... Dann machen wir eben was anderes: der Pivot ... 256
10. Gemeinsam führen ... 259 10.1 ... Wer macht was? ... 260 10.2 ... Die Grundlagen im Agilen Manifest ... 261 10.3 ... Führen und Managen ... 262 10.4 ... Cynefin Framework ... 265 10.5 ... Dich selbst führen ... 268 10.6 ... Mit anderen führen ... 273
11. Tech für Anfänger*innen ... 281 11.1 ... Zuverlässig und mit hoher Qualität entwickeln und liefern ... 282 11.2 ... Anwendungen professionell betreiben ... 294 11.3 ... Rechtliche und Sicherheitsanforderungen sicherstellen ... 298 11.4 ... Aus- und Weiterbildung ... 303
12. Kurs anpassen: das Review ... 305 12.1 ... Das Sprint Review ... 306 12.2 ... Das Review Meeting vorbereiten ... 307 12.3 ... Zum Start ... 314 12.4 ... Der Stand der Dinge ... 317 12.5 ... Die Entwicklungen im Umfeld ... 322 12.6 ... Wie weiter? ... 325 12.7 ... Was nicht ins Review gehört ... 327
13. Auf eine gute Zusammenarbeit! Die Retrospektive ... 329 13.1 ... Wie wird's gemacht? ... 330 13.2 ... Die richtigen Rahmenbedingungen ... 331 13.3 ... Psychologische Sicherheit ... 331 13.4 ... Lass uns über Gefühle sprechen ... 333 13.5 ... Die Retrospektive für kritisches Feedback nutzen ... 334 13.6 ... Ein typischer Ablauf ... 335 13.7 ... Nach der Retro ist vor der Retro ... 337
14. Guter Rat von Lennart ... 339 14.1 ... Was macht ein Agile Coach? ... 339 14.2 ... Der Unterschied zur Scrum-Master-Rolle ... 340 14.3 ... Wie ein agiler Coach unterstützt ... 340 14.4 ... Tipps für das Stakeholder-Management ... 341 14.5 ... Es gibt keine schlechten Nachrichten ... 342 14.6 ... Wenn Führung fordert ... 343 14.7 ... Der Weg zum Agile Coach ... 344
15. Heiße Konflikte willkommen! ... 347 15.1 ... Konflikte für Innovationen nutzen ... 348 15.2 ... Die Basis für Austausch schaffen ... 353 15.3 ... Höflich miteinander umgehen ... 363 15.4 ... Das Kritische ansprechen: der Elefant im Raum ... 365 15.5 ... Nein sagen (können/dürfen/müssen) ... 370 15.6 ... Grenzen der Kommunikation anerkennen und für sich selbst sorgen ... 372
16. Liefern mit Stil ... 377 16.1 ... Wie oft liefern? ... 379 16.2 ... Was ist alles zu tun? ... 381 16.3 ... Liefern ist kein Endpunkt ... 390
17. Umfeld und Unterstützung: die Sicht aufs Unternehmen ... 391 17.1 ... Warum Organisationsentwicklung? ... 392 17.2 ... Vom ersten Scrum Team zum agilen Unternehmen ... 399 17.3 ... Hypothesengeleitete Entwicklung ... 415
18. Gut gemacht! ... 421 18.1 ... Probiere es einfach aus! ... 421 18.2 ... Danke ... 422 Anhang ... 423 A ... Elefanten-Carpaccio (Beispiellösung) ... 423 B ... Literaturverzeichnis ... 427 Das Team, das dieses Buch geschrieben hat ... 437 Index ... 439
1 Gesucht: Product Owner (m/w/d)
Ende 2022 listet Google ca. 1,4 Milliarden Einträge zu dem Suchbegriff »Product Owner«. In diesem Kapitel erfährst du deutlich kompakter, was die Rolle ausmacht und wie du deine Arbeit als Product Owner*in von Anfang an erfolgreich gestalten kannst.
Karla und Benno stehen nebeneinander am Fenster. Hamburg im Nebel, nur ein paar Gebäude lassen sich schemenhaft erahnen. Speicherstadt, moderne Wohn- und Bürohäuser, eine Brücke. »Wen suchen wir eigentlich genau? Für mich hört sich das wie eine Eier legende Wollmilchsau an. Die Person muss das Produkt gut kennen, viel Erfahrung im Projektmanagement haben und sich mit Digitalisierung bis ins technische Detail auskennen«, sagt Benno mehr zu sich selbst als zu Karla. »Sie sollte vor allem gut kommunizieren können, empathisch sein, den Markt kennen. Entscheidungsfreudig sein. Und sich durchsetzen können«, ergänzt Karla. »Ich bin nur froh, dass wir hier niemanden allein lassen. Das Produkt ist anspruchsvoll, aber wir haben ein erfahrenes Entwicklungsteam am Start, und Rami wird die Scrum-Master-Rolle exzellent ausfüllen.«
Karla und Benno suchen: jemanden wie dich. Die beiden sind Führungskräfte in einem mittelgroßen Unternehmen, das sich mitten in der digitalen Transformation befindet. Sie stehen vor einer schwierigen Personalentscheidung: In Bennos Bereich soll eine Product-Owner-Position besetzt werden, zum ersten Mal. Für Benno sind Scrum und agiles Arbeiten noch recht neu. Gleichwohl hat er schon verstanden, dass die Product-Owner-Rolle recht umfassende fachliche Kompetenzen erfordert. Er weiß nur noch nicht, wer sie mitbringen soll, zumal von der Entwicklung des neuen Produkts die Zukunft des Unternehmens maßgeblich abhängt. Karla hat als IT-Leitung schon viel Erfahrung mit agilem Vorgehen und deswegen auch einen guten Blick für die persönlichen Kompetenzen, die ein*e Product Owner*in braucht. Sie ist zuversichtlicher, auch weil sie auf Rami vertraut, der das Team als erfahrener Scrum Master in Vollzeit begleiten wird.
Die Product-Owner-Rolle ist ein Konzept aus Scrum. Und Scrum ist eine – vielleicht die bekannteste – Möglichkeit, einen funktionierenden Arbeitsprozess im Sinne des Agilen Manifests und der zwölf agilen Prinzipien umzusetzen. Und sie hat ein vielschichtiges Kompetenzprofil: Da wird eine analytische und visionäre Person gesucht, die fachlich-technisch Ahnung von ihrer Domäne hat, stark in der Kommunikation nach innen und außen ist, agiles und klassisches Projektmanagement aus dem Effeff beherrscht und auch noch unternehmerisch handelt.
Zum Einstieg in dieses Buch laden wir dich deswegen ein, die Rolle intensiv kennenzulernen und dir deine eigenen Stärken bewusst zu machen. Du richtest den Blick zunächst auf das große Ganze – Scrum beziehungsweise das agile Vorgehen im Allgemeinen und deine Rolle als Product Owner*in im Besonderen. Dabei lernst du die Herausforderungen der Rolle an einem praktischen Beispiel kennen und kannst gleichzeitig auch deine eigenen Kompetenzen reflektieren.
Im Anschluss raten wir dir zu fünf Dingen, um die du dich als Product Owner*in unbedingt kümmern solltest – insbesondere wenn du neu mit einem Team startest. Sie sind ein Ausblick auf die vielfältigen Möglichkeiten, die du in diesem Buch findest, um deine Rolle bewusst zu gestalten und dich weiterzuentwickeln.
1.1 Scrum – eine agile Allzweckmethode?
Unternehmen nutzen Scrum, weil sie flexibler werden wollen. Sie möchten schneller auf Veränderungen reagieren, Chancen nutzen und sich besser auf die Anforderungen ihrer Kundschaft einstellen. Vor dem Hintergrund des Fachkräftemangels spielt Scrum auch oft eine Rolle, um als Unternehmen attraktive Arbeitsbedingungen bieten zu können. Kaum ein*e Wissensarbeiter*in möchte heutzutage noch streng hierarchisch oder fremdbestimmt arbeiten. Gefragt sind Selbstorganisation und lebenslanges Lernen, mobile Arbeit entlang individueller Wertvorstellungen und Führung nur da, wo sie auch wirklich dienlich ist.
Scrum ist in diesem Zusammenhang schon fast zum Synonym für agile Vorgehensmodelle geworden. Scrum wurde in den frühen 1990er-Jahren von den Softwareentwicklern Jeff Sutherland und Ken Schwaber entworfen und überzeugt heute viele durch seine vermeintlich einfache Struktur (siehe Abbildung 1.1), die sich mit den Jahren nicht nur in der Softwareentwicklung, sondern auch in vielen anderen Feldern bewährt hat. Wer Scrum implementieren will, braucht kein aufwändiges Prozess- oder Rollenmodell. Es reichen:
-
3 Rollen: Product Owner*in, Scrum Master*in und Entwickler*in
-
5 Events: Sprint, Daily, Planning, Review und Retrospektive
-
3 Artefakte: Product Backlog, Sprint Backlog und Produkt-Inkrement
Abbildung 1.1 Der Scrum-Prozess steht für eine iterativ-inkrementelle Auslieferung mit fest etablierten Planungs- und Lernmomenten.
Eingerahmt wird das Ganze durch die fünf Werte Commitment, Mut, Fokus, Offenheit und Respekt. Wer dann noch seine Vorstellungen in Produkt-Ziel und Sprint-Ziel zu übersetzen weiß und die gemeinsamen Qualitätsvorstellungen in einer Definition of Done festhält, ist auf dem besten Weg, nach Scrum zu arbeiten.
Commitment
Der englische Begriff Commitment lässt sich leider nicht eindeutig ins Deutsche übertragen. Viele übersetzen ihn mit Engagement, Einsatzbereitschaft oder auch Entschlossenheit. Gemeint ist in Scrum, dass ein Team sich eigenverantwortlich und motiviert in die Pflicht nimmt, die vereinbarten Ziele zu erreichen und nicht darauf zu bauen, dass jemand von außen für Motivation sorgt, etwa indem Druck aufgebaut wird oder Belohnungen in Aussicht gestellt werden. Um dieser Definition gerecht zu werden, verwenden wir den englischen Begriff in diesem Buch.
Der Begriff agil ist in der Geschäftswelt nicht trennscharf definiert. Manche sprechen von Business Agility und meinen damit, dass sich in einem dynamischen Markt doch schneller Geld verdienen lassen müsse. Andere sind stolz auf die Agilität in der eigenen Logistikkette, und dritte setzen das agile Vorgehensmodell Scrum gleich mit agilem Vorgehen, ohne jemals vom Agilen Manifest (siehe Abbildung 1.2) und seinen zwölf agilen Prinzipien gehört zu haben. Sie alle geben dem Modewort agil eine unterschiedliche Bedeutung und sprechen über völlig verschiedene Dinge.
In diesem Buch meinen wir mit Agilität ein Vorgehen, das sich an den Werten des Agilen Manifests orientiert und nach dessen zwölf agilen Prinzipien organisiert ist. Wir betrachten Scrum dabei als eine besonders geeignete Möglichkeit, die Arbeit in einem Produktteam auf diese Art zu bewältigen, und nutzen die Definitionen der Meetings, Rollen und Artefakte als Referenzpunkte. Viele Produktteams kombinieren Scrum mit Kanban. Sie organisieren dann beispielsweise die Arbeit während des Sprints mit einem Kanban-Board oder verzichten ganz auf die Sprint-Logik, etablieren über Kanban eine kontinuierliche Auslieferung und passen die Meetings, Rollen und Artefakte aus Scrum entsprechend an. Dieses Vorgehen wird häufig auch als Scrumban bezeichnet.
Die Herangehensweisen in diesem Buch eignen sich für agiles Vorgehen im Allgemeinen, orientieren sich aber an Scrum als Blaupause.
Abbildung 1.2 Das Agile Manifest im Original dient seit den späten 1990ern vielen agilen Teams als Grundlage ihrer Arbeit.
Der Scrum Guide oder auch die agilen Prinzipien fassen kurz zusammen, worum es geht. In der Praxis ist es nicht so einfach. Nicht umsonst hieß es lange im Scrum Guide – also den knapp zwölf Seiten, die Scrum in der englischen Version offiziell beschreiben –, Scrum sei zwar leicht zu verstehen, aber schwierig anzuwenden. In der aktuellen Version des Scrum Guide kommt der Satz etwas aufmunternder daher: »Scrum ist einfach. Probiere es aus.«
Und darin steckt das Wesentliche. Scrum ist ein einfaches Rahmenwerk für komplexe Fragestellungen. Es ermöglicht einem Team oder einer Organisation während einer Produktentwicklung, kontinuierlich und früh zu liefern, kontinuierlich und früh Feedback zu den Ausbaustufen des Produkts zu bekommen und damit kontinuierlich zu lernen und das eigene Vorgehen frühzeitig anzupassen. In einem dynamischen Umfeld ist das eine strategische Kompetenz. Sie stellt einen Wettbewerbsvorteil dar gegenüber Unternehmen mit starren Strukturen oder langsamen, bürokratischen Prozessen. Die WirtschaftsWoche schreibt dazu im Juli 2017 sogar: »Je agiler ein Unternehmen im Ganzen, desto größer ist sein wirtschaftlicher Erfolg.« und belegt diese Aussage mit Daten aus dem Agile Performer Index (Dämon, 2017).
Scrum ist dabei eine Möglichkeit, das Agile Manifest praktisch umzusetzen, das heißt insbesondere im Projektmanagement und in der Produktentwicklung ein agiles Vorgehensmodell zu etablieren. Das lässt sich leicht nachvollziehen, wenn die Rollen, Meetings und Artefakte aus Scrum...
