Date post: | 20-Mar-2017 |
Category: |
Business |
Upload: | michael-mahlberg |
View: | 26 times |
Download: | 6 times |
Slide #2017 Michael Mahlberg
The Product Owner’s Survival KitEin Überblick
1
Slide #2017 Michael Mahlberg
WILLKOMMEN…
2
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 Minuten2:00 1:00 0:00
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 Minuten2:00 1:00 0:00
Slide #2017 Michael Mahlberg
SECHS TRÜMPFENach Sharon Bowman
5
Slide #2017 Michael Mahlberg
6 TRÜ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
Slide #2017 Michael Mahlberg
ZURÜCK ZUM THEMA
7
Slide #2017 Michael Mahlberg
DINGE, DIE PRODUCT OWNER TUN SOLLTEN:
• Anforderungen aufnehmen• Verantwortlich sein• Abstimmung mit
Stakeholdern• Erreichbar sein für das Team• Priorisieren• Produktvision hüten
• Kundenkenner und Marktkenner
• Zuhörer• Kommunikator• Backlog hüten• Geschäftswert bestimmen• Feedback geben (review)
8
Antworten aus dem
Publikum!
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 Dev Teams• Stories Schätzen
9
Antworten aus dem
Publikum!
Slide #2017 Michael Mahlberg
DER PRODUCT OWNER AN SICH
DerProductOwner(Scrum-Guide2016)
DerProductOwneristfürdieWertmaximierungdesProduktssowieder
ArbeitdesEntwicklungsteamsverantwortlich.Wiediesgeschieht,kannje
nachOrganisaAon,ScrumTeamundEinzelpersonenstarkvariieren.
DerProductOwneristdieeinzigePerson,diefürdasManagementdes
ProductBacklogsverantwortlichist.DasProductBacklog-Management
umfasst:
• ProductBacklog-Einträgeklarzuformulieren;
• DieEinträgeimProductBacklogsozusorAeren,dassZieleund
MissionenopAmalerreichtwerdenkönnen;
• DenWertderArbeitzuopAmieren,diedasEntwicklungsteam
erledigt;
• DasSicherstellen,dassdasProductBacklogsichtbar,transparentund
füralleklaristsowiezeigt,worandasScrumTeamalsnächstes
arbeitenwird;und
• sicherzustellen,dassdasEntwicklungsteamdieProductBacklog-
EinträgeimerforderlichenMaßeversteht.
DerProductOwnerkanndieobengenanntenArbeitenselbsttunodersie
durchdasEntwicklungsteamerledigenlassen.DerProductOwnerbleibt
jedochimmerrechenschaPspflichAg[accountable].
DerProductOwneristeineeinzelnePerson,keinKomitee.Erkannzwar
dieWünscheeinesKomiteesimProductBacklogwiedergeben,aber
diejenigen,dieeinenEintragdesProductBacklogsinseinerPriorität
verändernmöchten,müssensichandenProductOwnerwenden.
DamitderProductOwnererfolgreichseinkann,mussdiegesamte
OrganisaAonseineEntscheidungenrespekAeren.DieEntscheidungendes
ProductOwnerssindinInhaltundReihenfolgedesProductBacklogs
sichtbar.NiemanddarfvomEntwicklungsteamverlangen,andere
Anforderungenzubearbeiten.DemEntwicklungsteamistesnichterlaubt,
nachdenAngabeneineranderenPersonalsdenendesProductOwnerszu
arbeiten.
10
Slide #2017 Michael Mahlberg
DER PRODUCT OWNER AN SICH…
DerProductOwneristdieeinzigePerson,diefürdasManagementdesProduct
Backlogsverantwortlichist.DasProductBacklog-Managementumfasst:
• ProductBacklog-Einträgeklarzuformulieren;
• DieEinträgeimProductBacklogsozusorAeren,dassZieleundMissionenopAmal
erreichtwerdenkönnen;
• DenWertderArbeitzuopAmieren,diedasEntwicklungsteamerledigt;
• DasSicherstellen,dassdasProductBacklogsichtbar,transparentundfüralleklar
istsowiezeigt,worandasScrumTeamalsnächstesarbeitenwird;und
• sicherzustellen,dassdasEntwicklungsteamdieProductBacklog-Einträgeim
erforderlichenMaßeversteht.
11
Slide #2017 Michael Mahlberg
DER PRODUCT OWNER AN SICH…
DerProductOwnerkanndieobengenanntenArbeitenselbsttunodersiedurchdas
Entwicklungsteamerledigenlassen.DerProductOwnerbleibtjedochimmer
rechenschaPspflichAg[accountable].
DerProductOwneristeineeinzelnePerson,keinKomitee.Erkannzwardie
WünscheeinesKomiteesimProductBacklogwiedergeben,aberdiejenigen,die
einenEintragdesProductBacklogsinseinerPrioritätverändernmöchten,müssen
sichandenProductOwnerwenden.
12
Slide #2017 Michael Mahlberg
DER PRODUCT OWNER AN SICH…
DamitderProductOwnererfolgreichseinkann,mussdiegesamteOrganisaAon
seineEntscheidungenrespekAeren.DieEntscheidungendesProductOwnerssindin
InhaltundReihenfolgedesProductBacklogssichtbar.Niemanddarfvom
Entwicklungsteamverlangen,andereAnforderungenzubearbeiten.Dem
Entwicklungsteamistesnichterlaubt,nachdenAngabeneineranderenPersonals
denendesProductOwnerszuarbeiten.
13
Slide #2017 Michael Mahlberg
WAS FÜR EIN PRODUCT-OWNER?Wer bin ich und wenn ja wie viele?
14
Slide #2017 Michael Mahlberg
TYPEN VON PRODUCT-OWNERN
Product Owner nach ScrumStakeholder Manager
Surrogat Product Owner Ambassador / Botschafter
Business AnalystSystemanalytikerIncident Manager
15
Prox
y-PO
Teil-P
O
Slide #2017 Michael Mahlberg
Accept Reality!
16
Slide #2017 Michael Mahlberg 17
Slide #2017 Michael Mahlberg
DELEGATION BOARDNach Jurgen Appelo
18
Slide #2017 Michael Mahlberg
MANAGE CAPACITYaka nutze Kanban-Systeme
19
Slide #2017 Michael Mahlberg
SYSTEMISCHES KONSENSIERENDank an Jo Seibert! (seibert media)
20
Slide #2017 Michael Mahlberg
NVC / GFKGewaltfreie Kommunikation
21
Slide #2017 Michael Mahlberg
Kreativitätstechniken
22
Slide #2017 Michael Mahlberg
ZWICKY BOXMorphologischer Kasten
23
Slide #2017 Michael Mahlberg 24
Slide #2017 Michael Mahlberg
WIRKUNGSMATRIXCause-effect diagrams & Simulator
25
Slide #2017 Michael Mahlberg
WIRKUNGSMATRIX
26
Slide #2017 Michael Mahlberg
WIRKUNGSMATRIX
27
Slide #2017 Michael Mahlberg
CAUSE & EFFECT DIAGRAM
28
Slide #2017 Michael Mahlberg
STORY MAPPING
29
Slide #2017 Michael Mahlberg
Backlog Management
30
Slide #2017 Michael Mahlberg
SYSTEMISCHES KONSENSIERENDank an Jo Seibert! (seibert media)
31
Slide #2017 Michael Mahlberg
BUY A FEATUREund andere Innovation Games
32
Slide #2017 Michael Mahlberg
CCCCard Conversation Confirmation
33
Slide #2017 Michael Mahlberg
CRCC{lass|omponent|…} Responsibility Collaboration
34
Slide #2017 Michael Mahlberg
SWOTNicht nur eine Matrix…
35
Slide #2017 Michael Mahlberg 36
Slide #2017 Michael Mahlberg
MOSCOW&
TRIAGE
37
Slide #2017 Michael Mahlberg
„DISCOVERY“ KANBAN
38
Slide #2017 Michael Mahlberg
EISENHOWER MATRIX
39
–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
–Peter Ferdinand Drucker
“Es ist im Wesentlichen die Verwechslung 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
Slide #2017 Michael Mahlberg
SMART & INVEST
42
SpecificMeasurableAttainableRealisticTimed
IndependentNegotiableValuableEstimable
SmallTestable
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 AUFTEILENDIE EINGANGSSTORY
VORBEREITEN
MUSTERANWENDEN
WORKFLOW SCHRITTE
OPERATIONENVARIATION DER
GESCHÄFTSREGELN
VARIATION DERSCHNITTSTELLEN
VARIATIONDER DATEN
SIMPEL / KOMPLEX
PERFORMANCENACHLAGERN
EINEN SPIKEHERAUSBRECHEN
GRÖßTER AUFWAND
DIE AUFTEILUNGÜBERPRÜFEN
Erfüllt die große Story die INVEST*-Kriterien (abgesehen von SMALL)?
Sind die neuen Storiesetwa gleich groß?
Beschreibt die Storyeinen Workflow?
Kann man die Story so aufteilen, dassWorkflowbeginn und -ende zuerst undStories aus der Mitte des Workflows als
Erweiterung umgesetzt werden?
Kann man zuerst einenMinimalworkflow herausteilen,
welcher später mit anderenStories erweitert wird?
Enthält die Story mehrereOperationen? (z.B. etwas "verwalten"
oder "konfigurieren"?)
Kannst Du die Operationen inseparate Stories aufteilen?
Enthält die Story verschiedene Ausprägungenvon Geschäftsregeln? (z.B. gibt es einen
Domänenbegriff wie "flexible Datumswerte",der mehrere Variationen nahelegt?)
Kann man die Story so aufteilen, dass ersteine Teilmenge der Regeln und spätererweiterte Regeln umgesetzt werden?
Macht die Story diegleichen Dinge mit
unterschiedlichen Daten?Kann man die Story so aufteilen,dass erst ein Teil der Daten und
später ein anderer Teil der Datenverarbeitet wird?
Kann man die Story so aufteilen,dass erst die Daten einer Schnittstelle
und später die der anderenSchnittstellen verarbeitet werden?
Bekommt die Story die selben Datenüber unterschiedliche Schnittstellen?
Sind nach der naheliegendstenAufteilung alle Stories gleich schwer
zu implementieren, unabhängigdavon, mit welcher man anfängt?Kann man erstmal nur eine Story-Ausprägung
mit dem Hauptaufwand auswählen undweitere Ausprägungen später hinzufügen?
Hat die Story einen einfachenKern, der den größten
Wert / Lernerfahrung beinhaltet?Kann man die Story so aufteilen,
dass zuerst der einfache Kern undspäter Erweiterungen umgesetzt werden?
Wird die Story dadurch komplex,dass nicht-funktionale Anforderungen
wie Performance umgesetztwerden sollen?
Kann man die Story so aufteilen,dass erst eine nur funktionierendeVersion umgesetzt wird und später
der nicht-funktionale Anteil?
Immer noch keine Idee, wie dieStory aufgeteilt werden kann?
Gibt es ein kleine Stück,das verständlich genug ist,
um damit zu beginnen?Welche 1-3 Fragen
halten Dich ammeisten zurück? Mach eine Pause
und versuches erneut.
Schreibe eine explorativeStory, welche mit minimalem Aufwand
zur Klärung dieser Fragen führt undbeginne diesen Prozess von vorne.
Schreibe diese Story zuerst,setze sie um und beginne diesen
Prozess wieder von vorne.
Hat die Story einekomplexe Schnittstelle?
Gibt es eine simple Version,die zuerst erstellt werden kann?
Probiere ein anderes Mustermit der Ursprungsstory oder den
neu entstandenen Stories.
Probiere ein anderesMuster. Wahrscheinlich istnoch etwas Überflüssiges
in jeder der Stories.
Probiere einanderes Muster.Könnten manche der Stories
prinzipiell depriorisiert oderkomplett gestrichen werden?
Gibt es eine Story mit derman offensichtlich anfangen
kann, um frühen Wert, Lernen oderRisikovermeidung usw. zu erreichen?
Kombinere sie mit einer anderen Storyoder formuliere sie um, damit es eine
gute, wenn auch große,Ausgangsstory wird.
Ist die Storygröße 1⁄10bis 1⁄6 der Velocity?
Ist jede Story in etwa 1⁄10 bis 1⁄6 der Velocity groß?
Erfüllt die Story dieINVEST-Kriterien?
Die Story mussaufgeteilt werden.
Fertig.
Probiere ein anderes Muster, um die
Story zu zerlegen.Du bist fertig oder testestnoch ein anderes Muster
auf bessere Eignung.
JA
NEIN
Beginne hier
* INVEST - Stories sollten sein:
1
2
3
Independent (Unabhängig)Negotiable (Diskutierbar)Valuable (Werterzeugend)Estimable (Schätzbar)Small (Klein)Testable (Testbar)
Letzte Möglichkeit
JANEIN
Slide #2017 Michael Mahlberg
STORY-SPLITTING
44
http://agileforall.com/wp-content/uploads/2012/08/Story-Splitting-Flowchart-DE.pdf
Slide #2017 Michael Mahlberg
Stakeholder Management
45
Slide #2017 Michael Mahlberg
KLASSISCHE MATRIX
46
Slide #2017 Michael Mahlberg
RACI MATRIX
47
ResponsibleAccountableConsultedInformed
Slide #2017 Michael Mahlberg
Abnahmen
48
Slide #2017 Michael Mahlberg
DAS ENDE DER STORY… so that?
49
Slide #2017 Michael Mahlberg 50
http://geek-and-poke.com/geekandpoke/2016/2/21/agile-families
Slide #2017 Michael Mahlberg
AKZEPTANZKRITERIENGherkin or not?
51
Slide #2017 Michael Mahlberg 52
1:Feature:Someterseyetdescriptivetextofwhatisdesired2:Textualdescriptionofthebusinessvalueofthisfeature3:Businessrulesthatgovernthescopeofthefeature4:Anyadditionalinformationthatwillmakethefeatureeasiertounderstand5:
6:Scenario:Somedeterminablebusinesssituation7:Givensomeprecondition8:Andsomeotherprecondition9:Whensomeactionbytheactor10:Andsomeotheraction11:Andyetanotheraction12:Thensometestableoutcomeisachieved13:Andsomethingelsewecancheckhappenstoo
Slide #2017 Michael Mahlberg
DIE LÖSUNGEN VON GESTERNSIND DIE PROBLEME VON HEUTE
53
Slide #2017 Michael Mahlberg
DIE LÖSUNGEN VON GESTERNSIND DIE PROBLEME VON HEUTE
54
Und das ist auch gut so
Slide #2017 Michael Mahlberg
Accept Reality!
55
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
Slide #2017 Michael Mahlberg
SICHTBARKEIT UND TRANSPARENZ
57
Delegation Board Eisenhower
Wich
tigUn
wich
tig
Dringend Nicht Dringend
Machen
Planen
Delegieren
Eliminieren
Slide #2017 Michael Mahlberg
LINKS UND REFERENZEN
58
SWOT: https://de.wikipedia.org/wiki/SWOT-AnalyseDelegation Board https://management30.com/practice/delegation-board/Sechs Trü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-PriorisierungZwicky-Box http://www.methodik.net/documents/lit%20Wyler%20kdf.pdfCause 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 Successful Teams 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
Slide #2017 Michael Mahlberg
ABSCHLIEßEND…
59
Viel Erfolg!
Slide #2013 Michael Mahlberg
KONTAKTINFORMATIONEN
60
• Bei Fragen: Einfach anmailen: [email protected]
• Bei Twitter findet man mich als MMahlberg
• I blog about every two weeks in english athttp://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