Pecha Kucha: Innovation - Das wahre Bottleneck?!

transcript

Innovation - das wahre Bottleneck?!

Pecha KuchaOOP 2012, München

Stefan Roockstefan.roock@it-agile.deTwitter: @StefanRoock

Mittwoch, 25. Januar 12

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.

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

Oder doch nicht?

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

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.

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.

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.

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.

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

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

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

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.

Wert (kumuliert)

irgendwelche Features

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.

unbenutzt benutzt

Waste in Systemen

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

Individualentwicklung

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.

Wert (kumuliert)

überlegte Features

irgendwelche Features

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.

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.

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!

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

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

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

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

€€

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

Weitere Fragen? Nehmen Sie gerne Kontakt auf:E-Mail: stefan.roock@it-agile.deTwitter: StefanRoockWeb: http://stefanroock.de, http://www.it-agile.de