innovation - das wahre bottleneck?

Innovation - das wahre Bottleneck?!

OOP 2012 MünchenStefan Roock

[email protected]: @StefanRoock

Mittwoch, 25. Januar 12

mailto:[email protected]

mailto:[email protected]

Copyright MrTMan. http://www.flickr.com/photos/teijo/680594567/sizes/l/in/photostream/

Auf die Geschwindigkeit kommt es an!


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.

http://www.flickr.com/photos/teijo/680594567/sizes/l/in/photostream/

http://www.flickr.com/photos/teijo/680594567/sizes/l/in/photostream/

Copyright by machanucha. http://www.flickr.com/photos/chinny_chin_chin00/4917467665/sizes/l/in/photostream/

Auf die Geschwindigkeit kommt es nicht an!


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.

http://www.flickr.com/photos/chinny_chin_chin00/4917467665/sizes/l/in/photostream/

http://www.flickr.com/photos/chinny_chin_chin00/4917467665/sizes/l/in/photostream/


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.

Schneller mit Scrum


Bei der Einführung von Scrum und Kanban ist tatsächlich häufig eine relevante Verbesserung von Leadtime, Durchsatz, Velocity beobachtbar.

Product Owner im Sog


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.

Product Owner überlastet

SchlechtesProdukt

Schlechter Inputfür das Team


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.

Wertentwicklung des Produktes

Zeit

Wert (kumuliert)

irgendwelche Features,schlecht priorisiert


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.

40 %

60 %

unbenutzt benutzt

Waste in Systemen

90% des Systemnutzens wird durch 10% der Funktionen erzeugt.

Individualentwicklung

15 %

12 %

73 %

unbenutztselten benutzthäufig benutzt

MS-Word


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.

Wertentwicklung des Produktes

Zeit

Wert (kumuliert)

überlegte Features,gut priorisiert

irgendwelche Features,schlecht priorisiert


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.

„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 12Der 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.

„Würdet Ihr Euer eigenes Geld in die (Weiter-) Entwicklung des

Produktes stecken?“ (Kent Beck)


Check AssumptionsJeff DeLuca

Mittwoch, 25. Januar 12Ehrlich prüfen, ob die eigenen Annahmen zutreffen.

Build-Measure-Learn*

Build

Measure

Learn 1

2

3

* aus Eric Ries: The Lean StartupMittwoch, 25. Januar 12

Rückwärts denken

Konstruieren

Messen

LernenAnnahmen: Was will ich

lernen?

Was muss ich dafür messen?

Was muss ich dafür bauen?


Live-Metriken

Usability Labs

Live-Observation

Sprint-Reviews

Annahmen prüfen


... beginnt im Sprint-Planning1.Welche Annahmen möchten wir im Review prüfen?2.Was müssen wir dafür in diesem Sprint bauen?

Annahmen prüfen im Sprint-Review...


Ideen

Konstruieren

Messen

LernenAnnahmen: Was will ich lernen?



Ideen generieren

Ideen auswählen


Die meisten Ideen sind Müll!

Konstruieren

Messen


lernen?



Ideen generieren

Ideen auswählen


Optimierung: Lernen / Zeiteinheit

Konstruieren

Messen


lernen?



Ideen generieren

Ideen auswählen


Product Owner im Team

€€

€

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

Innovationsinitiative? FAIL!Schlecht für Innovation Gut für Innovation Umsetzung

einer alleine mehrere Personen Teams „in freier Wildbahn“

homogene Gruppen, Group-Think

Teams mit Differenzen,Uneinigkeit, Missverständnisse

crossfunktionale Teams, unterschiedliche Charaktere,

Streit zulassen

maximale Auslastung,geplante Innovation

Slack-Zeit, Experimentieren Gold-Cards, 20%-Modell (Google, 3M)

Starren auf leeres Papier Innovationstechniken Design Thinking, Lateral Thinking, Innovation Games, ...


Danke für die Aufmerksamkeit

Mittwoch, 25. Januar 12Weitere Fragen? Nehmen Sie gerne Kontakt auf:E-Mail: [email protected]: StefanRoockWeb: http://stefanroock.de, http://www.it-agile.de

innovation - das wahre bottleneck?

Business