Was macht ein PO in einem DevOps-Team?

Stell dir vor, du bist dir gewohnt (oder wirst darauf vorbereitet), zusammen mit einem SW-Entwicklungsteam in der Rolle des Product Owners neue Features zu entwickeln. Dabei stellt sich heraus, dass das Team ein DevOps-Team ist, welches sowohl neue Features entwickelt und sich gleichzeitig auch um den Betrieb derselben kümmert. Welche Rolle spielst du als PO dort genau? Passt Scrum zu Betriebs-Themen? Welche Verantwortung habe ich als PO dort? Wie vermeide ich es, ein Flaschenhals im Prozess zu sein und trotzdem sicherzustellen, dass zur richtigen Zeit am richtigen gearbeitet wird? Priorisiere ich nun alle Bugs, welche aus dem Betrieb (aka Produktion) kommen? ... und noch ein paar weitere Fragen haben sich mir aufgedrängt, als ich Mitte 2017 auf ein solches Team gestossen bin. Ich möchte meine Erfahrungen und konkreten Massnahmen mit euch teilen weil ich davon überzeugt bin, dass es anderen Product Ownern eher früher als später auch so gehen wird. Spätestens wenn das MVP in Produktion geht kann es heute sehr gut sein, dass sich dasselbe Team im Betrieb darum kümmert. Und das ist gut so :-)

Transcript

1. Was macht ein Product Owner in einem DevOps-Team? Daniel Nussbaum
2. Wer bin ich und mein Produkt?
3. Wer bin ich und wo komme ich her? 3 Ursprünglich KV
4. Was auf XING nicht steht (virtuelles Interview) 4  Q: «Was bedeutet für dich Agilität?»  A: «Die Rückkehr des gesunden Menschenverstandes»  Q: «Was sind die Aufgaben des POs?»  «A1: Sicherstellen, dass zur richtigen Zeit am richtigen gearbeitet wird»  «A2: Abgesehen davon mach ich (fast) alles, was meinem Produkt gut tut»  Q: «Woran misst du einen guten PO?»  A: «An der Anzahl Nein pro Tag»
5. Mein Produkt … 5  … löst das Problem der fairen Einnahmenverteilung im öffentlichen Verkehr  … hat Einfluss auf mehrere Mia CHF, welche zwischen Transportunternehmungen jährlich umverteilt wird  … wird nicht nur von der SBB benutzt  … gibt es heute schon, wird aber modernisiert und verbessert  … dient sowohl der Mittel- und Langfristplanung wie aber auch für KPIs im Geschäftsbericht der SBB
6. Produkt-Kontext & Team-Organisation.
8. Dev Ops Teamorganisation (rein virtuell & dynamisch) 10
9. Ops.
10. Was habe ich als PO «festgelegt»?  3 P’s 12 Prinzipien Priorisierungsverfahren Prozess
11. Prinzipien.
12. Prinzipien (1 / 1) Qualität ist wichtiger als Geschwindigkeit Bugs und technische Schulden werden natürlich auf- und abgebaut Wir wissen was passiert, bevor es passiert Stabiler und günstiger Betrieb ist wichtiger, als neue Features zu entwickeln Zuerst überleben wir, dann leben wir besser
13. Priorisierungsverfahren.
14. Priorisierungsverfahren (1 / 1)
15. Prozess.
17. Prozess (1 / 5) Rotierende Rolle Betriebskönig 19  Aufgaben ▪ SPOC für 2nd-Level-Support ▪ Prüft die Teammailbox + Umgebungen  läuft alles ? ▪ Kümmert sich um Releases, Deployments, Infrastruktur ▪ Priorisiert die Bugs gem. Priorisierungsverfahren  Alle anderen im Team ▪ Am DEV-Stream arbeiten ▪ Im Notfall sofort Support des Betriebskönigs ▪ Zero-Bug-Policy
18. Prozess (2 / 5) Zero-Bug-Policy: Theorie Kosten-/Nutzen-Denken Jederzeit Null Bugs
19. Prozess (3 / 5) Zero-Bug-Policy: Praxis WENN [Aufwand] > [Nutzen] DANN Bug schliessen (Won’t fix) SONST Bug fixen Vor dem Start einer neuen Story wird ein Bug gefixt
20. Prozess (4 / 5) Zero-Bug-Policy: Auswirkungen auf Bugs Offen (alle) Nur Blocker + Critical
21. Prozess (5 / 5) Zero-Bug-Policy: Auswirkungen auf Dev Fazit: Keine Auswirkung messbar
22. 24 Prinzipien Zusammenfassung Priorisierungsverfahren Prozess