The Product Owner's Survival Kit - ein Überblick [DE]

1. Slide #2017 Michael Mahlberg The Product Owner’s Survival Kit Ein Überblick 1

2. Slide #2017 Michael Mahlberg WILLKOMMEN… 2

3. Slide #2017 Michael Mahlberg 3 Suchen Sie sich einen Partner, den sie noch nicht kennen, stellen Sie sich einander kurz vor und ﬁnden Sie gemeinsam 5 Dinge, die ein Product Owner nicht sein oder machen sollte aber dennoch oft ist oder macht. Minuten Minuten Minuten Minuten 2:00 1:00 0:00

4. Slide #2017 Michael Mahlberg 4 Suchen Sie sich einen neuen Partner, den Sie noch nicht kennen, stellen Sie sich einander kurz vor und ﬁnden Sie gemeinsam 5 Dinge, die ein Product Owner sein oder machen sollte aber dennoch oft nicht ist oder macht. Minuten Minuten Minuten Minuten 2:00 1:00 0:00

5. Slide #2017 Michael Mahlberg SECHS TRÜMPFE Nach Sharon Bowman 5

6. Slide #2017 Michael Mahlberg 6TRÜMPFE UM WISSEN ZU ERWEITERN 6 Bewegung schlägt Sitzen Reden schlägt Zuhören Bilder schlagen Worte Unterschiedlich schlägt gleich Kürzer schlägt Länger Schreiben schlägt Lesen

7. Slide #2017 Michael Mahlberg ZURÜCK ZUM THEMA 7

8. Slide #2017 Michael Mahlberg DINGE, DIE PRODUCT OWNER TUN SOLLTEN: • Anforderungen aufnehmen • Verantwortlich sein • Abstimmung mit Stakeholdern • Erreichbar sein für dasTeam • Priorisieren • Produktvision hüten • Kundenkenner und Marktkenner • Zuhörer • Kommunikator • Backlog hüten • Geschäftswert bestimmen • Feedback geben (review) 8 Antworten aus dem Publikum!

9. Slide #2017 Michael Mahlberg DINGE, DIE PRODUCT OWNER NICHT TUN SOLLTEN: • In die Umsetzung einmischen • Architekt sein • Micromanagement • Scrummaster sein • Davon ausgehen, dass das was er sendet das ist, was empfangen wird • Reiner Requirements Engineer sein • Teil des Entwicklungsteams sein • Boss des DevTeams • Stories Schätzen 9 Antworten aus Publikum

10. Slide #2017 Michael Mahlberg DER PRODUCT OWNER AN SICH Der Product Owner (Scrum-Guide 2016) Der Product Owner ist für die Wertmaximierung des Produkts sowie der Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je nach OrganisaAon, Scrum Team und Einzelpersonen stark variieren. Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist. Das Product Backlog-Management umfasst: • Product Backlog-Einträge klar zu formulieren; • Die Einträge im Product Backlog so zu sorAeren, dass Ziele und Missionen opAmal erreicht werden können; • Den Wert der Arbeit zu opAmieren, die das Entwicklungsteam erledigt; • Das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird; und • sicherzustellen, dass das Entwicklungsteam die Product Backlog- Einträge im erforderlichen Maße versteht.   Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das Entwicklungsteam erledigen lassen. Der Product Owner bleibt jedoch immer rechenschaPspﬂichAg [accountable].   Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product Backlogs in seiner Priorität verändern möchten, müssen sich an den Product Owner wenden. Damit der Product Owner erfolgreich sein kann, muss die gesamte OrganisaAon seine Entscheidungen respekAeren. Die Entscheidungen des Product Owners sind in Inhalt und Reihenfolge des Product Backlogs sichtbar. Niemand darf vom Entwicklungsteam verlangen, andere Anforderungen zu bearbeiten. Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten. 10

11. Slide #2017 Michael Mahlberg DER PRODUCT OWNER AN SICH… Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist. Das Product Backlog-Management umfasst: • Product Backlog-Einträge klar zu formulieren; • Die Einträge im Product Backlog so zu sorAeren, dass Ziele und Missionen opAmal erreicht werden können; • Den Wert der Arbeit zu opAmieren, die das Entwicklungsteam erledigt; • Das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird; und • sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht. 11

12. Slide #2017 Michael Mahlberg DER PRODUCT OWNER AN SICH… Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das Entwicklungsteam erledigen lassen. Der Product Owner bleibt jedoch immer rechenschaPspﬂichAg [accountable].   Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product Backlogs in seiner Priorität verändern möchten, müssen sich an den Product Owner wenden. 12

13. Slide #2017 Michael Mahlberg DER PRODUCT OWNER AN SICH… Damit der Product Owner erfolgreich sein kann, muss die gesamte OrganisaAon seine Entscheidungen respekAeren. Die Entscheidungen des Product Owners sind in Inhalt und Reihenfolge des Product Backlogs sichtbar. Niemand darf vom Entwicklungsteam verlangen, andere Anforderungen zu bearbeiten. Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten. 13

14. Slide #2017 Michael Mahlberg WAS FÜR EIN PRODUCT-OWNER? Wer bin ich und wenn ja wie viele? 14

15. Slide #2017 Michael Mahlberg TYPEN VON PRODUCT-OWNERN Product Owner nach Scrum Stakeholder Manager Surrogat Product Owner Ambassador / Botschafter Business Analyst Systemanalytiker Incident Manager 15 Proxy-POTeil-PO

16. Slide #2017 Michael Mahlberg Accept Reality! 16

17. Slide #2017 Michael Mahlberg 17

18. Slide #2017 Michael Mahlberg DELEGATION BOARD Nach Jurgen Appelo 18

19. Slide #2017 Michael Mahlberg MANAGE CAPACITY aka nutze Kanban-Systeme 19

20. Slide #2017 Michael Mahlberg SYSTEMISCHES KONSENSIEREN Dank an Jo Seibert! (seibert media) 20

21. Slide #2017 Michael Mahlberg NVC / GFK Gewaltfreie Kommunikation 21

22. Slide #2017 Michael Mahlberg Kreativitätstechniken 22

23. Slide #2017 Michael Mahlberg ZWICKY BOX Morphologischer Kasten 23

25. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX Cause-effect diagrams & Simulator 25

26. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX 26

27. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX 27

28. Slide #2017 Michael Mahlberg CAUSE & EFFECT DIAGRAM 28

29. Slide #2017 Michael Mahlberg STORY MAPPING 29

30. Slide #2017 Michael Mahlberg Backlog Management 30

31. Slide #2017 Michael Mahlberg SYSTEMISCHES KONSENSIEREN Dank an Jo Seibert! (seibert media) 31

32. Slide #2017 Michael Mahlberg BUY A FEATURE und andere Innovation Games 32

33. Slide #2017 Michael Mahlberg CCC Card Conversation Conﬁrmation 33

34. Slide #2017 Michael Mahlberg CRC C{lass|omponent|…} Responsibility Collaboration 34

35. Slide #2017 Michael Mahlberg SWOT Nicht nur eine Matrix… 35

37. Slide #2017 Michael Mahlberg MOSCOW & TRIAGE 37

38. Slide #2017 Michael Mahlberg „DISCOVERY“ KANBAN 38

39. Slide #2017 Michael Mahlberg EISENHOWER MATRIX 39

40. –Peter Ferdinand Drucker “It is fundamentally the confusion between effectiveness and efﬁciency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efﬁciency what should not be done at all.” Image: Drucker-portrait-bkt - The Drucker Institute, Claremont Graduate University

41. –Peter Ferdinand Drucker “Es ist im Wesentlichen dieVerwechslung von Effektivität und Efﬁzienz die dazwischen steht die richtigen Dinge zu tun und die Dinge richtig zu tun. Es gibt sicherlich nichts, dass so nutzlos ist, wie mit großer Efﬁzienz zu tun was eigentlich überhaupt nicht getan werden sollte” Image: Drucker-portrait-bkt - The Drucker Institute, Claremont Graduate University

42. Slide #2017 Michael Mahlberg SMART & INVEST 42 Speciﬁc Measurable Attainable Realistic Timed Independent Negotiable Valuable Estimable Small Testable

43. Slide #2017 Michael Mahlberg STORY-SPLITTING 43 Zuletzt aktualisiert am 10.8.2012Copyright © 2011-2012 Agile For All. Alle Rechte vorbehalten. Unter http://www.richardlawrence.info/splitting-user-stories/ gibt es mehr Infos zu den Story Splitting Mustern. Ins Deutsche übersetzt von Kai Simons - Agilist.de www.agileforall.com USER STORIES AUFTEILEN DIE EINGANGSSTORY VORBEREITEN MUSTER ANWENDEN WORKFLOW SCHRITTE OPERATIONEN VARIATION DER GESCHÄFTSREGELN VARIATION DER SCHNITTSTELLEN VARIATION DER DATEN SIMPEL / KOMPLEX PERFORMANCE NACHLAGERN EINEN SPIKE HERAUSBRECHEN GRÖßTER AUFWAND DIE AUFTEILUNG ÜBERPRÜFEN Erfüllt die große Story die INVEST*- Kriterien (abgesehen von SMALL)? Sind die neuen Stories etwa gleich groß? Beschreibt die Story einen Workflow? Kann man die Story so aufteilen, dass Workflowbeginn und -ende zuerst und Stories aus der Mitte des Workflows als Erweiterung umgesetzt werden? Kann man zuerst einen Minimalworkflow herausteilen, welcher später mit anderen Stories erweitert wird? Enthält die Story mehrere Operationen? (z.B. etwas "verwalten" oder "konfigurieren"?) Kannst Du die Operationen in separate Stories aufteilen? Enthält die Story verschiedene Ausprägungen von Geschäftsregeln? (z.B. gibt es einen Domänenbegriff wie "flexible Datumswerte", der mehrere Variationen nahelegt?) Kann man die Story so aufteilen, dass erst eine Teilmenge der Regeln und später erweiterte Regeln umgesetzt werden? Macht die Story die gleichen Dinge mit unterschiedlichen Daten? Kann man die Story so aufteilen, dass erst ein Teil der Daten und später ein anderer Teil der Daten verarbeitet wird? Kann man die Story so aufteilen, dass erst die Daten einer Schnittstelle und später die der anderen Schnittstellen verarbeitet werden? Bekommt die Story die selben Daten über unterschiedliche Schnittstellen? Sind nach der naheliegendsten Aufteilung alle Stories gleich schwer zu implementieren, unabhängig davon, mit welcher man anfängt?Kann man erstmal nur eine Story-Ausprägung mit dem Hauptaufwand auswählen und weitere Ausprägungen später hinzufügen? Hat die Story einen einfachen Kern, der den größten Wert / Lernerfahrung beinhaltet? Kann man die Story so aufteilen, dass zuerst der einfache Kern und später Erweiterungen umgesetzt werden? Wird die Story dadurch komplex, dass nicht-funktionale Anforderungen wie Performance umgesetzt werden sollen? Kann man die Story so aufteilen, dass erst eine nur funktionierende Version umgesetzt wird und später der nicht-funktionale Anteil? Immer noch keine Idee, wie die Story aufgeteilt werden kann? Gibt es ein kleine Stück, das verständlich genug ist, um damit zu beginnen? Welche 1-3 Fragen halten Dich am meisten zurück? Mach eine Pause und versuch es erneut. Schreibe eine explorative Story, welche mit minimalem Aufwand zur Klärung dieser Fragen führt und beginne diesen Prozess von vorne. Schreibe diese Story zuerst, setze sie um und beginne diesen Prozess wieder von vorne. Hat die Story eine komplexe Schnittstelle? Gibt es eine simple Version, die zuerst erstellt werden kann? Probiere ein anderes Muster mit der Ursprungsstory oder den neu entstandenen Stories. Probiere ein anderes Muster. Wahrscheinlich ist noch etwas Überflüssiges in jeder der Stories. Probiere ein anderes Muster. Könnten manche der Stories prinzipiell depriorisiert oder komplett gestrichen werden? Gibt es eine Story mit der man offensichtlich anfangen kann, um frühen Wert, Lernen oder Risikovermeidung usw. zu erreichen? Kombinere sie mit einer anderen Story oder formuliere sie um, damit es eine gute, wenn auch große, Ausgangsstory wird. Ist die Storygröße 1⁄10 bis 1⁄6 der Velocity? Ist jede Story in etwa 1⁄10 bis 1⁄6 der Velocity groß? Erfüllt die Story die INVEST-Kriterien? Die Story muss aufgeteilt werden. Fertig. Probiere ein anderes Muster, um die Story zu zerlegen.Du bist fertig oder testest noch ein anderes Muster auf bessere Eignung. JA NEIN Beginnehier * INVEST - Stories sollten sein: 1 2 3 Independent (Unabhängig) Negotiable (Diskutierbar) Valuable (Werterzeugend) Estimable (Schätzbar) Small (Klein) Testable (Testbar) Letzte Möglichkeit JA NEIN

44. Slide #2017 Michael Mahlberg STORY-SPLITTING 44 http://agileforall.com/wp-content/uploads/2012/08/Story- Splitting-Flowchart-DE.pdf

45. Slide #2017 Michael Mahlberg Stakeholder Management 45

46. Slide #2017 Michael Mahlberg KLASSISCHE MATRIX 46

47. Slide #2017 Michael Mahlberg RACI MATRIX 47 Responsible Accountable Consulted Informed

48. Slide #2017 Michael Mahlberg Abnahmen 48

49. Slide #2017 Michael Mahlberg DAS ENDE DER STORY … so that? 49

50. Slide #2017 Michael Mahlberg 50 http://geek-and-poke.com/geekandpoke/2016/2/21/agile-families

51. Slide #2017 Michael Mahlberg AKZEPTANZKRITERIEN Gherkin or not? 51

52. Slide #2017 Michael Mahlberg 52 1: Feature: Some terse yet descriptive text of what is desired 2: Textual description of the business value of this feature 3: Business rules that govern the scope of the feature 4: Any additional information that will make the feature easier to understand 5: 6: Scenario: Some determinable business situation 7: Given some precondition 8: And some other precondition 9: When some action by the actor 10: And some other action 11: And yet another action 12: Then some testable outcome is achieved 13: And something else we can check happens too

53. Slide #2017 Michael Mahlberg DIE LÖSUNGEN VON GESTERN SIND DIE PROBLEME VON HEUTE 53

54. Slide #2017 Michael Mahlberg DIE LÖSUNGEN VON GESTERN SIND DIE PROBLEME VON HEUTE 54 Und das ist auch gut so

55. Slide #2017 Michael Mahlberg Accept Reality! 55

56. Slide #2017 Michael Mahlberg LIMIT YOUR WIP 56 Observe Orient Decide Act Nutzung (∞) (4) (3) (3) (∞) item item item item itemitem item item item item item doing doing doingdone done done 3

57. Slide #2017 Michael Mahlberg SICHTBARKEIT UND TRANSPARENZ 57 Delegation Board Eisenhower Wichtig Unwichtig Dringend Nicht Dringend Machen Planen Delegieren Eliminieren

58. Slide #2017 Michael Mahlberg LINKS UND REFERENZEN 58 SWOT: https://de.wikipedia.org/wiki/SWOT-Analyse Delegation Board https://management30.com/practice/delegation-board/ SechsTrümpfe http://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf Systemisches Konsensieren http://www.sk-prinzip.eu/das-sk-prinzip/zusammenfassung/ MoSCoW https://de.wikipedia.org/wiki/MoSCoW-Priorisierung Zwicky-Box http://www.methodik.net/documents/lit%20Wyler%20kdf.pdf Cause and Effect http://www.geraldmweinberg.com/Site/QSM_vol_1.html & https://www.chacocanyon.com/pointlookout/ 130327.shtml & http://agilecoach.typepad.com/agile-coaching/2009/10/how-to-create-a-diagram-of-effects.html Buy a feature http://www.innovationgames.com/buy-a-feature/ Story Splitting http://agileforall.com/wp-content/uploads/2012/08/Story-Splitting-Flowchart-DE.pdf Story Mapping http://jpattonassociates.com/the-new-backlog/ & http://jpattonassociates.com/user-story-mapping/ Triage https://en.wikipedia.org/wiki/Triage Discovery Kanban https://www.infoq.com/presentations/kanban-delivery-discovery Scrum Guide http://www.scrumguides.org bzw. http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide- German.pdf Akzeptanzkriterien Gojdko Adzic,,Speciﬁcation by Example: How SuccessfulTeams Deliver the Right Software, Manning, 2011 https:// www.amazon.de/Speciﬁcation-Example-Successful-Deliver-Software/dp/1617290084 Gherkin https://github.com/cucumber/cucumber/wiki/Gherkin INVEST & SMART http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ Impact Mapping https://www.impactmapping.org

59. Slide #2017 Michael Mahlberg ABSCHLIEßEND… 59 Viel Erfolg!

60. Slide #2013 Michael Mahlberg KONTAKTINFORMATIONEN 60 • Bei Fragen: Einfach anmailen: oop2017@michaelmahlberg.com • BeiTwitter ﬁndet man mich als MMahlberg • I blog about every two weeks in english at  http://agile-aspects.michaelmahlberg.com • Deutlich seltener schreibe ich in meinem deutschen Blog unter http://shu-ha-ri.michaelmahlberg.de • Ach ja: Meine Homepage ist http://www.michaelmahlberg.de