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.
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. 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
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 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. 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
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. 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
55. –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
56. –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
57. Slide #2017 Michael Mahlberg
SMART & INVEST
42
Specific
Measurable
Attainable
Realistic
Timed
Independent
Negotiable
Valuable
Estimable
Small
Testable
67. 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
68. Slide #2017 Michael Mahlberg
DIE LÖSUNGEN VON GESTERN
SIND DIE PROBLEME VON HEUTE
53
69. Slide #2017 Michael Mahlberg
DIE LÖSUNGEN VON GESTERN
SIND DIE PROBLEME VON HEUTE
54
Und das ist auch gut so
75. 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