Your SlideShare is downloading. ×
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Innovation - das wahre Bottleneck?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Innovation - das wahre Bottleneck?

1,660

Published on

Folien zum Vortrag "Innovation - das wahre Bottleneck?!" von der OOP 2012 in München. …

Folien zum Vortrag "Innovation - das wahre Bottleneck?!" von der OOP 2012 in München.
Inkl. der Foliennotizen.

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,660
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Innovation - das wahre Bottleneck?! OOP 2012 München Stefan Roock stefan.roock@it-agile.de Twitter: @StefanRoockMittwoch, 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 12Bei der Produktentwicklung kommt es auf die Geschwindigkeit an. Wir alle wissen,dass sich bei den Produktmanagern Anforderungen ohne Ende stauen und die Kundenganz 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 12Oder ist das vielleicht gar nicht der Fall? Ist die Geschwindigkeit vielleicht doch nichtso wichtig? Warten die Kunden vielleicht nur deshalb so ungeduldig auf das nächsteRelease, weil das aktuelle Release keine nützlichen Neuerungen aufwies.
  • 4. Mittwoch, 25. Januar 12Geschichte aus einer Scrum-Enterprise-Transition in einem Konzern. Mitglieder desTransition-Teams sind beunruhigt. Eines der ersten auf Scrum umgestellten Teamsentwickelt ein Produkt weiter, dass am Markt nicht besonders erfolgreich ist. DieMitglieder des Transition-Teams befürchten, dass der Misserfolg des Produktes aufScrum zurückfällt und wünschen sich, dass sie erfolgreiche Produkte auf Scrumumstellen.Nachvollziehbar. Allerdings: Scrum ist nicht primär dazu da, für erfolgreiche Produktedie Releasezyklen zu reduzieren. Scrum sollte auch dabei helfen, weniger erfolgreicheProdukte zu erfolgreichen Produkten zu machen. Und für weniger erfolgreicheProdukte reicht eine Beschleunigung der Umsetzung auch nicht aus. Sie kann sogarkontraproduktiv sein, wie die folgende Betrachtung zeigt.
  • 5. Schneller mit ScrumMittwoch, 25. Januar 12Bei der Einführung von Scrum und Kanban ist tatsächlich häufig eine relevante Verbesserung vonLeadtime, Durchsatz,Velocity beobachtbar.
  • 6. Product Owner im SogMittwoch, 25. Januar 12Das Entwicklungsteam setzt Anforderungen schließlich schneller um, als sich dasProduct Owner neue Anforderungen ausdenken kann. Der Product Owner will nicht,dass das Team herumsitzt. Das setzt den Product Owner unter Stress, das Team mitausreichend Anforderungen zu versorgen. Seine ganze Energie wird vom Teamaufgesogen.
  • 7. Product Owner überlastet Schlechter Input für das Team Schlechtes ProduktMittwoch, 25. Januar 12Um das Team mit Anforderungen zu versorgen und Leerlauf zu vermeiden, steckt derProduct Owner seine ganze Energie in der Schreiben der Anforderungen. Dabeivernachlässigt er aber seine anderen Aufgaben, insbesondere darauf, dieKundenbedürfnisse genau zu verstehen und innovative und werthaltige Features zufinden.Der Product Owner liefert also schlechten Input für das Team. Das Team arbeitetdiesen nach dem GIGO-Prinzip ab: Garbage In, Garbage Out. Das Ergebnis ist einschlechtes Produkt mit unnützen Features.
  • 8. Wertentwicklung des Produktes Wert (kumuliert) irgendwelche Features, schlecht priorisiert ZeitMittwoch, 25. Januar 12So werden über die Zeit kontinuierlich neue Features angehäuft. Diese generieren aberkaum Geschäftswert. Mitunter vernichten sie sogar Wert, weil sie das Produktverkomplizieren. 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 12Dieser Effekt wurde durch eine Reihe von Studien belegt, die Individualentwicklungen undStandardprodukte untersucht haben. Ca. 2/3 der Funktionen in Softwaresystemen werdenselten oder nie benutzt. Microsoft hat mehr als 10 Jahre gebraucht gebraucht, um 85% unnützerFunktionen in MS-Word zu entwickeln. Mit Scrum wäre das viel schneller gegangen.In Individualentwicklung werden 60% der Funktionen nie benutzt und 30% der Funktionenfehlen.Es gibt Studien, die sagen, dass 90% des Systemnutzens durch 10% der Funktionen erzeugtwerden.Das DoD (Department of Defense) hat 1993 bei einer Studie über die eigenen Projekteherausgefunden, dass 47% der Entwicklungskosten eingespart werden könnten – dadurch dassman letztlich sinnlose Arbeit vermeidet.Eine Untersuchung aus dem Jahr 2000 stellt fest, dass nur 15% der Funktionen von MS-Wordhäufig benutzt werden und 12% selten. 73% der Funktionen werden vom durchschnittlichenBenutzer also gar nicht verwendet.
  • 10. Wertentwicklung des Produktes Wert (kumuliert) überlegte Features, gut priorisiert irgendwelche Features, schlecht priorisiert ZeitMittwoch, 25. Januar 12Stattdessen sollten die besonders werthaltigen Features entwickelt werden. Dazu mussman sich ernsthaft mit den Kundenbedürfnissen und technologischen Möglichkeitenauseinandersetzen. Auch wenn das bedeutet, dass weniger Features umgesetztwerden, wäre das resultierende Produkt trotzdem wertvoller.
  • 11. „Scrum works when the Product Owner knows what the customer wants. When he doesnt, you just efficiently create waste.“ David J. Bland (@davidjbland)Mittwoch, 25. Januar 12
  • 12. Mittwoch, 25. Januar 12Der Product Owner ist kein Bürokrat auch auch keine Schreibkraft. Sein Job besteht darin, Geschäftswertherzustellen 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 DeLucaMittwoch, 25. Januar 12Ehrlich prüfen, ob die eigenen Annahmen zutreffen.
  • 15. Build-Measure-Learn* 3 1 Learn Build Measure 2 * aus Eric Ries: The Lean StartupMittwoch, 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-MetrikenMittwoch, 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 12Product Owner und Entwicklungsteam sind _gemeinsam_ innovativ. Es hilft, den Product Owner als Rolle imScrum-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 AufmerksamkeitMittwoch, 25. Januar 12Weitere Fragen? Nehmen Sie gerne Kontakt auf:E-Mail: stefan.roock@it-agile.deTwitter: StefanRoockWeb: http://stefanroock.de, http://www.it-agile.de

×