Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

326 views

Published on

Seit die Product Owner zu den Rettern des Projektes geworden sind, verlangt „die ganze Welt“ von ihnen, dass sie ohne genaue Aufgabendefinition (längst wird der Begriff ja auch außerhalb der Scrum-Welt benutzt) aufgrund diffus beschriebener Fähigkeiten Anforderungen auf magische Art mit allen Stakeholdern friedlich abgestimmt bekommen, sie den Umsetzern wie mit dem Nürnberger Trichter verständlich machen und nebenbei noch das Releasemanagement mit erledigen. Aber wo ist der Werkzeugkasten dafür?
Ein Survival-Toolkit, das links und rechts der reinen Software-Welt Tools vom Morphologischen Kasten über Systemisches Konsensieren bis hin zur Deckungsbeitragsrechnung beleuchtet, wird in dieser Session feil geboten. Dass Kernthemen wie Story-Mapping, Backlog-Pflege, Buy-a-Feature, CCC dabei ebenfalls einsortiert werden, versteht sich von selber.

Published in: Business
  • Login to see the comments

  • Be the first to like this

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

  1. 1. Slide #2017 Michael Mahlberg The Product Owner’s Survival Kit Ein Überblick 1
  2. 2. Slide #2017 Michael Mahlberg WILLKOMMEN… 2
  3. 3. Slide #2017 Michael Mahlberg 3 Suchen Sie sich einen Partner, den sie noch nicht kennen, stellen Sie sich einander kurz vor und finden 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. 4. Slide #2017 Michael Mahlberg 4 Suchen Sie sich einen neuen Partner, den Sie noch nicht kennen, stellen Sie sich einander kurz vor und finden 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. 5. Slide #2017 Michael Mahlberg SECHS TRÜMPFE Nach Sharon Bowman 5
  6. 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. 7. Slide #2017 Michael Mahlberg ZURÜCK ZUM THEMA 7
  8. 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. 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. 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 rechenschaPspflichAg [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. 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. 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 rechenschaPspflichAg [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. 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. 14. Slide #2017 Michael Mahlberg WAS FÜR EIN PRODUCT-OWNER? Wer bin ich und wenn ja wie viele? 14
  15. 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. 16. Slide #2017 Michael Mahlberg Accept Reality! 16
  17. 17. Slide #2017 Michael Mahlberg 17
  18. 18. Slide #2017 Michael Mahlberg DELEGATION BOARD Nach Jurgen Appelo 18
  19. 19. Slide #2017 Michael Mahlberg MANAGE CAPACITY aka nutze Kanban-Systeme 19
  20. 20. Slide #2017 Michael Mahlberg SYSTEMISCHES KONSENSIEREN Dank an Jo Seibert! (seibert media) 20
  21. 21. Slide #2017 Michael Mahlberg NVC / GFK Gewaltfreie Kommunikation 21
  22. 22. Slide #2017 Michael Mahlberg Kreativitätstechniken 22
  23. 23. Slide #2017 Michael Mahlberg ZWICKY BOX Morphologischer Kasten 23
  24. 24. Slide #2017 Michael Mahlberg 24
  25. 25. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX Cause-effect diagrams & Simulator 25
  26. 26. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX 26
  27. 27. Slide #2017 Michael Mahlberg WIRKUNGSMATRIX 27
  28. 28. Slide #2017 Michael Mahlberg CAUSE & EFFECT DIAGRAM 28
  29. 29. Slide #2017 Michael Mahlberg STORY MAPPING 29
  30. 30. Slide #2017 Michael Mahlberg Backlog Management 30
  31. 31. Slide #2017 Michael Mahlberg SYSTEMISCHES KONSENSIEREN Dank an Jo Seibert! (seibert media) 31
  32. 32. Slide #2017 Michael Mahlberg BUY A FEATURE und andere Innovation Games 32
  33. 33. Slide #2017 Michael Mahlberg CCC Card Conversation Confirmation 33
  34. 34. Slide #2017 Michael Mahlberg CRC C{lass|omponent|…} Responsibility Collaboration 34
  35. 35. Slide #2017 Michael Mahlberg SWOT Nicht nur eine Matrix… 35
  36. 36. Slide #2017 Michael Mahlberg 36
  37. 37. Slide #2017 Michael Mahlberg MOSCOW & TRIAGE 37
  38. 38. Slide #2017 Michael Mahlberg „DISCOVERY“ KANBAN 38
  39. 39. Slide #2017 Michael Mahlberg EISENHOWER MATRIX 39
  40. 40. –Peter Ferdinand Drucker “It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” Image: Drucker-portrait-bkt - The Drucker Institute, Claremont Graduate University
  41. 41. –Peter Ferdinand Drucker “Es ist im Wesentlichen dieVerwechslung von Effektivität und Effizienz 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 Effizienz zu tun was eigentlich überhaupt nicht getan werden sollte” Image: Drucker-portrait-bkt - The Drucker Institute, Claremont Graduate University
  42. 42. Slide #2017 Michael Mahlberg SMART & INVEST 42 Specific Measurable Attainable Realistic Timed Independent Negotiable Valuable Estimable Small Testable
  43. 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. 44. Slide #2017 Michael Mahlberg STORY-SPLITTING 44 http://agileforall.com/wp-content/uploads/2012/08/Story- Splitting-Flowchart-DE.pdf
  45. 45. Slide #2017 Michael Mahlberg Stakeholder Management 45
  46. 46. Slide #2017 Michael Mahlberg KLASSISCHE MATRIX 46
  47. 47. Slide #2017 Michael Mahlberg RACI MATRIX 47 Responsible Accountable Consulted Informed
  48. 48. Slide #2017 Michael Mahlberg Abnahmen 48
  49. 49. Slide #2017 Michael Mahlberg DAS ENDE DER STORY … so that? 49
  50. 50. Slide #2017 Michael Mahlberg 50 http://geek-and-poke.com/geekandpoke/2016/2/21/agile-families
  51. 51. Slide #2017 Michael Mahlberg AKZEPTANZKRITERIEN Gherkin or not? 51
  52. 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. 53. Slide #2017 Michael Mahlberg DIE LÖSUNGEN VON GESTERN SIND DIE PROBLEME VON HEUTE 53
  54. 54. Slide #2017 Michael Mahlberg DIE LÖSUNGEN VON GESTERN SIND DIE PROBLEME VON HEUTE 54 Und das ist auch gut so
  55. 55. Slide #2017 Michael Mahlberg Accept Reality! 55
  56. 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. 57. Slide #2017 Michael Mahlberg SICHTBARKEIT UND TRANSPARENZ 57 Delegation Board Eisenhower Wichtig Unwichtig Dringend Nicht Dringend Machen Planen Delegieren Eliminieren
  58. 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,,Specification by Example: How SuccessfulTeams Deliver the Right Software, Manning, 2011 https:// www.amazon.de/Specification-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. 59. Slide #2017 Michael Mahlberg ABSCHLIEßEND… 59 Viel Erfolg!
  60. 60. Slide #2013 Michael Mahlberg KONTAKTINFORMATIONEN 60 • Bei Fragen: Einfach anmailen: oop2017@michaelmahlberg.com • BeiTwitter findet 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

×