Folien zum Pecha-Kucha "Innovation - das wahre Bottleneck?!" auf der OOP 2012 in München. Inkl. Foliennotizen. Video des Vortrags: http://youtu.be/zxEk2zjpBkk

1. Innovation - das wahre
Bottleneck?!
Pecha Kucha
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. Oder doch nicht?
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. Schneller mit Scrum
Mittwoch, 25. Januar 12
Vor einiger Zeit belauschte ich ein Gespräch von internen Scrum-Coaches bei einem meiner Kunden. Der Kunde
hatte begonnen, seine Teams schrittweise auf Scrum umzustellen. Die internen Coaches waren für die Begleitung
der Teams zuständig. Scrum funktionierte in den Teams gut und die Release-Zyklen verkürzten sich drastisch von
12-24 auf 1 bis 3 Monate.

5. Mittwoch, 25. Januar 12
Trotzdem waren die internen Coaches unzufrieden. Sie hatten Teams zur Umstellung auf Scrum bekommen, die an
relativ erfolglosen Produkten arbeiteten. Sie fürchteten, dass diese Produkte eingestellt würden und der Misserfolg
des Produktes auf Scrum zurückfallen könnte.

6. Mittwoch, 25. Januar 12
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.

7. Mittwoch, 25. Januar 12
Am Anfang sieht die Welt häufig so aus, dass das Entwicklungsteam viel zu langsam ist oder zumindest erscheint.
Das Business hat eine lange Liste von Dingen, auf deren Umsetzung sie ganz dringend warten. Der
vielbeschworene Anforderungsstau wird immer länger.

8. Mittwoch, 25. Januar 12
Mit Hilfe von Scrum beschleunigt das Team ungemein. Das Team (der Drache) verlangt immer schneller neuen
Input. Irgendwann ist der Anforderungsstau beseitigt und ein Anforderungssog entsteht, der den Product Owner
unter Druck setzt.

9. Product Owner im Sog
Mittwoch, 25. Januar 12
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.

10. Product Owner
überlastet
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.

11. Product Owner
überlastet
Schlechter Input
für das Team
Schlechtes
Produkt
Mittwoch, 25. Januar 12
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.

12. Wert (kumuliert)
irgendwelche
Features
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.

13. 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.

14. Wert (kumuliert)
überlegte
Features
irgendwelche
Features
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.

15. Mittwoch, 25. Januar 12
Um es ganz klar zu sagen: Der Product Owner ist kein Bürokrat und auch keine Schreibkraft. Sein Job besteht
darin, Geschäftswert herzustellen und das bedeutet zu einem guten Teil, Kundenbedürfnisse zu verstehen und
Innovationen ins Produkt zu bringen.

16. Mittwoch, 25. Januar 12
In der Praxis sehe ich häufig eine starke Abgrenzung des Product Owners vom Entwicklungsteam. Dies behindert
den Product Owner dabei, werthaltige und innovative Features zu finden. Er ist vollauf damit beschäftigt, das
Team mit _irgendwelchen_ Anforderungen zu versorgen.

17. Ask the Team!
Mittwoch, 25. Januar 12
Dabei lässt sich das ganze Dilemma ganz einfach zu lösen. Das Product Owner sollte das Team um Unterstützung
bitten. „Ask the Team“ ist das Motto. Und das Team sollte dieser Bitte entsprechen. Dadurch entstehen eine ganze
Menge von Vorteilen.

18. Weniger Hunger
Mittwoch, 25. Januar 12
Erstens: Durch die Unterstützung des Product Owners hat das Team weniger Zeit für die Umsetzung der
Anforderungen und dadurch weniger Hunger auf Anforderungen. Die Belastung des Product-Owners sinkt.

19. Mehr Manpower
Mittwoch, 25. Januar 12
Zweitens: Es gibt zusätzliche Arbeitskraft beim Erstellen der User Storys. Es hat sich bewährt, das Product Owner
und Entwicklungsteam in regelmäßigen Anforderungsworkshops gemeinsam an User Storys arbeiten. Sie treffen
sich z.B. wöchentlich für 2 Stunden zu so einem Workshop.

20. Mehr Unterschiedlichkeit
Mittwoch, 25. Januar 12
Drittens: Für Innovation ist die Arbeit in interdisziplinären Gruppen besonders gut. Ich kenne wenige
Kreativtechniken, die nur eine Person benötigen. Gerade die Unterschiedlichkeit von Personen erzeugt die
notwendige kreative Energie.

21. Product Owner im Team
€
€
€
Mittwoch, 25. Januar 12
Für mich ist der Product Owner eine Rolle _im_ Team. Product Owner und Entwicklungsteam sind _gemeinsam_
innovativ und letztlich _gemeinsam_ verantwortlich für den Produkterfolg.

22. 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