Successfully reported this slideshow.

Pecha Kucha: Innovation - Das wahre Bottleneck?!

1

Share

Loading in …3
×
1 of 22
1 of 22

Pecha Kucha: Innovation - Das wahre Bottleneck?!

1

Share

Download to read offline

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

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

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Pecha Kucha: Innovation - Das wahre Bottleneck?!

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

×