22
Innovation - das wahre Bottleneck?! Pecha Kucha OOP 2012, München Stefan Roock [email protected] Twitter: @StefanRoock Mittwoch, 25. Januar 12
| Date post: | 29-Nov-2014 |
| Category: |
Business |
| Upload: | stefan-roock |
| View: | 1,499 times |
| Download: | 4 times |
Innovation - das wahre Bottleneck?!
Pecha KuchaOOP 2012, München
Stefan [email protected]: @StefanRoock
Mittwoch, 25. Januar 12
Copyright MrTMan. http://www.flickr.com/photos/teijo/680594567/sizes/l/in/photostream/
Auf die Geschwindigkeit kommt es an!
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.
Copyright by machanucha. http://www.flickr.com/photos/chinny_chin_chin00/4917467665/sizes/l/in/photostream/
Oder doch nicht?
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.
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.
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.
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.
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.
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.
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.
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.
Product Owner überlastet
SchlechtesProdukt
Schlechter Inputfür das Team
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.
Zeit
Wert (kumuliert)
irgendwelche Features
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.
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
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.
Zeit
Wert (kumuliert)
überlegte Features
irgendwelche Features
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.
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.
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.
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.
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.
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.
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.
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.
Danke für die Aufmerksamkeit
Mittwoch, 25. Januar 12
Weitere Fragen? Nehmen Sie gerne Kontakt auf:E-Mail: [email protected]: StefanRoockWeb: http://stefanroock.de, http://www.it-agile.de
![Logs live und in Farbe - statt nur schwarzweiß pecha kucha [pe … · 2016. 1. 11. · Logs live und in Farbe - statt nur schwarzweiß pecha kucha [pe-chahk-cha] Alexander Schwartz](https://static.unterlagen.site/doc/80x56/5fe2945d1b710f382d0c509d/logs-live-und-in-farbe-statt-nur-schwarzwei-pecha-kucha-pe-2016-1-11-logs.jpg)
