Das Dokument beschäftigt sich mit der Bedeutung von Geschwindigkeit in der Produktentwicklung und der Rolle des Product Owners im Scrum-Prozess. Es wird argumentiert, dass eine alleinige Beschleunigung der Umsetzungsprozesse nicht ausreicht, um erfolgreiche Produkte zu erzeugen, und dass wertvolle Features priorisiert entwickelt werden müssen, um den Kundenbedürfnissen gerecht zu werden. Es wird betont, dass eine schlechte Priorisierung von Features zu wertlosen Produkten führen kann und dass Innovation das Ziel eines effektiven Scrum-Teams sein sollte.

1. Innovation - das wahre Bottleneck?!
OOP 2012 München
Stefan Roock
stefan.roock@it-agile.de
Twitter: @StefanRoock
Mittwoch, 25. Januar 12

2. Auf die Geschwindigkeit kommt es an!
Copyright MrTMan. http://www.flickr.com/photos/teijo/680594567/sizes/l/in/photostream/
Mittwoch, 25. Januar 12
Bei der Produktentwicklung kommt es auf die Geschwindigkeit an. Wir alle wissen,
dass sich bei den Produktmanagern Anforderungen ohne Ende stauen und die Kunden
ganz ungeduldig auf neue Releases warten.

3. Auf die Geschwindigkeit kommt es nicht an!
Copyright by machanucha. http://www.flickr.com/photos/chinny_chin_chin00/4917467665/sizes/l/in/photostream/
Mittwoch, 25. Januar 12
Oder ist das vielleicht gar nicht der Fall? Ist die Geschwindigkeit vielleicht doch nicht
so wichtig? Warten die Kunden vielleicht nur deshalb so ungeduldig auf das nächste
Release, weil das aktuelle Release keine nützlichen Neuerungen aufwies.

4. Mittwoch, 25. Januar 12
Geschichte aus einer Scrum-Enterprise-Transition in einem Konzern. Mitglieder des
Transition-Teams sind beunruhigt. Eines der ersten auf Scrum umgestellten Teams
entwickelt ein Produkt weiter, dass am Markt nicht besonders erfolgreich ist. Die
Mitglieder des Transition-Teams befürchten, dass der Misserfolg des Produktes auf
Scrum zurückfällt und wünschen sich, dass sie erfolgreiche Produkte auf Scrum
umstellen.
Nachvollziehbar. Allerdings: Scrum ist nicht primär dazu da, für erfolgreiche Produkte
die Releasezyklen zu reduzieren. Scrum sollte auch dabei helfen, weniger erfolgreiche
Produkte zu erfolgreichen Produkten zu machen. Und für weniger erfolgreiche
Produkte reicht eine Beschleunigung der Umsetzung auch nicht aus. Sie kann sogar
kontraproduktiv sein, wie die folgende Betrachtung zeigt.

5. Schneller mit Scrum
Mittwoch, 25. Januar 12
Bei der Einführung von Scrum und Kanban ist tatsächlich häufig eine relevante Verbesserung von
Leadtime, Durchsatz,Velocity beobachtbar.

6. Product Owner im Sog
Mittwoch, 25. Januar 12
Das Entwicklungsteam setzt Anforderungen schließlich schneller um, als sich das
Product Owner neue Anforderungen ausdenken kann. Der Product Owner will nicht,
dass das Team herumsitzt. Das setzt den Product Owner unter Stress, das Team mit
ausreichend Anforderungen zu versorgen. Seine ganze Energie wird vom Team
aufgesogen.

7. Product Owner
überlastet
Schlechter Input
für das Team
Schlechtes
Produkt
Mittwoch, 25. Januar 12
Um das Team mit Anforderungen zu versorgen und Leerlauf zu vermeiden, steckt der
Product Owner seine ganze Energie in der Schreiben der Anforderungen. Dabei
vernachlässigt er aber seine anderen Aufgaben, insbesondere darauf, die
Kundenbedürfnisse genau zu verstehen und innovative und werthaltige Features zu
finden.
Der Product Owner liefert also schlechten Input für das Team. Das Team arbeitet
diesen nach dem GIGO-Prinzip ab: Garbage In, Garbage Out. Das Ergebnis ist ein
schlechtes Produkt mit unnützen Features.

8. Wertentwicklung des Produktes
Wert (kumuliert)
irgendwelche Features,
schlecht priorisiert
Zeit
Mittwoch, 25. Januar 12
So werden über die Zeit kontinuierlich neue Features angehäuft. Diese generieren aber
kaum Geschäftswert. Mitunter vernichten sie sogar Wert, weil sie das Produkt
verkomplizieren. Es wird also jede Menge Geld verbrannt.

9. Waste in Systemen
Individualentwicklung
unbenutzt benutzt 90% des Systemnutzens wird durch
10% der Funktionen erzeugt.
40 % unbenutzt
MS-Word selten benutzt
60 % häufig benutzt
15 %
12 %
73 %
Mittwoch, 25. Januar 12
Dieser Effekt wurde durch eine Reihe von Studien belegt, die Individualentwicklungen und
Standardprodukte untersucht haben. Ca. 2/3 der Funktionen in Softwaresystemen werden
selten oder nie benutzt. Microsoft hat mehr als 10 Jahre gebraucht gebraucht, um 85% unnützer
Funktionen in MS-Word zu entwickeln. Mit Scrum wäre das viel schneller gegangen.
In Individualentwicklung werden 60% der Funktionen nie benutzt und 30% der Funktionen
fehlen.
Es gibt Studien, die sagen, dass 90% des Systemnutzens durch 10% der Funktionen erzeugt
werden.
Das DoD (Department of Defense) hat 1993 bei einer Studie über die eigenen Projekte
herausgefunden, dass 47% der Entwicklungskosten eingespart werden könnten – dadurch dass
man letztlich sinnlose Arbeit vermeidet.
Eine Untersuchung aus dem Jahr 2000 stellt fest, dass nur 15% der Funktionen von MS-Word
häufig benutzt werden und 12% selten. 73% der Funktionen werden vom durchschnittlichen
Benutzer also gar nicht verwendet.

10. Wertentwicklung des Produktes
Wert (kumuliert)
überlegte Features,
gut priorisiert
irgendwelche Features,
schlecht priorisiert
Zeit
Mittwoch, 25. Januar 12
Stattdessen sollten die besonders werthaltigen Features entwickelt werden. Dazu muss
man sich ernsthaft mit den Kundenbedürfnissen und technologischen Möglichkeiten
auseinandersetzen. Auch wenn das bedeutet, dass weniger Features umgesetzt
werden, wäre das resultierende Produkt trotzdem wertvoller.

11. „Scrum works when the
Product Owner knows
what the customer
wants. When he
doesn't, you just
efficiently create
waste.“
David J. Bland (@davidjbland)
Mittwoch, 25. Januar 12

12. Mittwoch, 25. Januar 12
Der Product Owner ist kein Bürokrat auch auch keine Schreibkraft. Sein Job besteht darin, Geschäftswert
herzustellen und das bedeutet zu einem guten Teil, Innovationen ins Produkt zu bringen.

13. „Würdet Ihr Euer eigenes Geld in
die (Weiter-) Entwicklung des
Produktes stecken?“ (Kent Beck)
Mittwoch, 25. Januar 12

14. Check Assumptions
Jeff DeLuca
Mittwoch, 25. Januar 12
Ehrlich prüfen, ob die eigenen Annahmen zutreffen.

15. Build-Measure-Learn*
3 1
Learn Build
Measure
2
* aus Eric Ries: The Lean Startup
Mittwoch, 25. Januar 12

16. Rückwärts denken
Annahmen:
Lernen Was will ich
lernen?
Was muss ich
Messen
dafür messen?
Was muss ich
Konstruieren
dafür bauen?
Mittwoch, 25. Januar 12

17. Annahmen prüfen
Sprint-Reviews Usability Labs
Live-Observation Live-Metriken
Mittwoch, 25. Januar 12

18. Annahmen prüfen im Sprint-Review...
... beginnt im Sprint-Planning
1.Welche Annahmen möchten wir im Review prüfen?
2.Was müssen wir dafür in diesem Sprint bauen?
Mittwoch, 25. Januar 12

19. Ideen
Ideen Ideen
generieren auswählen
Annahmen: Was
Lernen
will ich lernen?
Was muss ich
Messen
dafür messen?
Was muss ich dafür
Konstruieren
bauen?
Mittwoch, 25. Januar 12

20. Die meisten Ideen sind Müll!
Ideen Ideen
generieren auswählen
Annahmen:
Lernen Was will ich
lernen?
Was muss ich
Messen
dafür messen?
Was muss ich
Konstruieren
dafür bauen?
Mittwoch, 25. Januar 12

21. Optimierung: Lernen / Zeiteinheit
Ideen Ideen
generieren auswählen
Annahmen:
Lernen Was will ich
lernen?
Was muss ich
Messen
dafür messen?
Was muss ich
Konstruieren
dafür bauen?
Mittwoch, 25. Januar 12

22. Product Owner im Team
€
€
€
Mittwoch, 25. Januar 12
Product Owner und Entwicklungsteam sind _gemeinsam_ innovativ. Es hilft, den Product Owner als Rolle im
Scrum-Team zu verstehen.

23. Innovationsinitiative? FAIL!
Schlecht für Innovation Gut für Innovation Umsetzung
einer alleine mehrere Personen Teams „in freier Wildbahn“
crossfunktionale Teams,
homogene Gruppen, Teams mit Differenzen,
unterschiedliche Charaktere,
Group-Think Uneinigkeit, Missverständnisse
Streit zulassen
maximale Auslastung, Gold-Cards, 20%-Modell
Slack-Zeit, Experimentieren
geplante Innovation (Google, 3M)
Design Thinking, Lateral
Starren auf leeres Papier Innovationstechniken
Thinking, Innovation Games, ...
Mittwoch, 25. Januar 12

24. Danke für die
Aufmerksamkeit
Mittwoch, 25. Januar 12
Weitere Fragen? Nehmen Sie gerne Kontakt auf:
E-Mail: stefan.roock@it-agile.de
Twitter: StefanRoock
Web: http://stefanroock.de, http://www.it-agile.de