Agiles Innovationsmanagement

Scrum ist aus der Softwareentwicklung nicht mehr wegzudenken. Insbesondere im Bereich E-Business, wo die Märkte besonders dynamisch sind, ist agile Entwicklung mit Scrum, XP oder Kanban längst Stand der Kunst. Allerdings ist mit der heute üblichen Verwendung agiler Ansätze ihr Potenzial noch lange nicht ausgereizt. Dieser Artikel beleuchtet den Zusammenhang agiler Entwicklung mit Innovationsmanagement. Es wird verdeutlicht, welche zentrale Rolle cross-funktionale, autonome Teams sowohl für Scrum wie auch für Innovationen haben und welchen Einfluss unterschiedlicher Innovationsbedarf auf die Ausgestaltung agiler Entwicklung hat.
Scrum-Test
Im Jahr 1986 veröffentlichten Hirotaka Takeuchi und Ikujiro Nonaka im Harvard Business Review einen Artikel mit dem Titel „The New New Product Development Game“ (siehe [TakeuchiNonaka86]). In diesem Artikel beschreiben die Autoren verschiedene Fallbeispiele von Produktentwicklungen, die besonders schnell und innovativ waren: ein neuer PKW bei Honda, eine Spiegelreflexkamera bei Canon, ein Büro-Kopierer bei Fuji-Xerox, ein Heim-Kopierer bei Canon und ein Personalcomputer bei NEC. Als wichtiger Erfolgsfaktor wurde die Arbeit in sogenannten Scrum-Teams genannt (meines Wissens nach taucht hier der Begriff des Scrum-Teams das erste Mal in der Literatur in Zusammenhang mit Produktentwicklung auf). Es verwundert daher nicht, warum vielen dieser Artikel als die Geburtsstunde von Scrum gilt. Jeff Sutherland (Mit-Erfinder von Scrum) bezieht sich immer wieder auf die Arbeiten von Nonaka und Takeuchi, wenn er über Scrum für die Software-Entwicklung spricht.
Der besagte Artikel im Harvard Business Review stellt wesentliche Unterschiede zwischen klassischer Entwicklung und der Entwicklung in Scrum-Teams dar (siehe Abbildung 1). Klassisch folgen verschiedene Phasen wie Marktforschung, Design, Produktspezifikation, Entwicklung und Qualitätssicherung sequenziell aufeinander. In jeder Phase arbeiten die jeweiligen Spezialisten. Erst wenn eine Phase abgeschlossen ist, wird mit der nächsten begonnen. In den untersuchten Produktentwicklungen wurde von diesem strikt sequenziellen Verfahren abgewichen; es gab mindestens teilüberlappende Phasen. Die nächste Phase beginnt, bevor die aktuelle Phase vollständig abgeschlossen ist. Bereits diese Überlappung bringt gravierende Änderungen mit sich:
- Die Projektbeteiligten müssen miteinander kooperieren, um die Phasenübergänge gestalten zu können.
- Probleme mit dem Ergebnis einer Phase können während der Kooperation entdeckt und sofort gemeinsam beseitigt werden.
- Die Time-to-Market sinkt (je nach Breite der Überlappung marginal bis erheblich).
Treibt man diese Phasenüberlappung ins Extrem finden alle Phasen gleichzeitig statt (unterer Teil in Abbildung 1). Die Folgen sind auch extrem:
- Alle Projektbeteiligten müssen sich kontinuierlich abstimmen, damit kein Chaos ausbricht. Kooperation wird maximiert.
- Durch die enge Zusammenarbeit der Projektbeteiligten werden zu jedem Zeitpunkt verschiedenste Perspektiven eingebracht. Das wirkt Group-Think entgegen und erhöht die Chance auf Innovation.
- Die Time-to-Market sinkt erheblich.

Nonaka und Takeuchi vergleichen die sequenzielle Arbeitsweise mit einem Staffellauf. Jeder Läufer hat seine Strecke zu absolvieren, übergibt den Staffelstab an den nächsten Läufer und hat dann mit dem Geschehen nichts weiter zu tun.
Die dritte Variante nennen sie in Anlehnung an das Rugby-Spiel Scrum¹, weil ein Rugby-Team sich gemeinsam über das Spielfeld bewegen muss, um erfolgreich zu sein. Ein Scrum-Team nach Nonaka und Takeuchi ist cross-funktional (interdisziplinär) besetzt, führt alle Phasen der Produktentwicklung gleichzeitig aus, kooperiert eng, arbeitet autonom und organisiert sich selbst (siehe Abbildung 2).
¹ Scrum ist beim Rugby eine Methode, um das Spiel nach einer Unterbrechung neu zu starten.
Zusammengefasst kann man sagen:
Scrum-Teams sind autonome, business-fokussierte Teams, die ihren Prozess in Besitz und Verantwortung nehmen.
Interessant ist der Vergleich der Scrum-Teams nach Nonaka und Takeuchi mit dem, was in der heutigen Praxis der Softwareentwicklung üblich ist. In der Softwareentwicklung finden wir häufig minimal-cross-funktionale Teams, die Programmierer und Tester enthalten. Schon bei der Integration von Designern geraten viele Unternehmen ins Straucheln. Das ist im Vergleich zu den Teams bei Canon, Honda, Fuji-Xerox und NEC der reinste Ponyhof. Bei Honda waren z. B. Vertrieb, Entwicklung, Qualitätssicherung und Produktion mit im Team.
Wenn wir in der Softwareentwicklung auf Innovation abzielen, sollten wir die Diversität im Team erhöhen und z. B. Marketing, Vertrieb, Customer Service, Design ins Team integrieren (siehe dazu auch [RoockRoock13]).
Geschäfts- und Innovationssystem
Scrum eignet sich für die Softwareentwicklung, wenn nennenswerte Probleme zu lösen sind. Für repetitive Tätigkeiten (z. B. Produktion oder Erbringen eines standardisierten Services) ist Scrum nur bedingt verwendbar und häufig ineffizient. Das verwundert auch nicht weiter, wenn man sich vergegenwärtigt, dass für das operative Erbringen einer Leistung andere Dinge wichtig sind als für die Entwicklung von Produkten oder Dienstleistungen. Nonaka und Takeuchi unterscheiden dazu zwischen dem Geschäfts- und dem Innovationssystem im Unternehmen (siehe [NonakaTakeuchi95]). Wie in Abbildung 3 dargestellt benötigt das Geschäftssystem Stabilität. Die Kunden möchten Verlässlichkeit. Das Unternehmen wird hier Effizienz optimieren, um die Leistung gegenüber dem Kunden schneller oder billiger anbieten zu können oder um einfach nur die eigenen Gewinne zu optimieren. Im Innovationssystem ist Stabilität und Effizienzoptimierung allerdings schädlich; Don Reinertsen spricht von toxischen Ideen. Innovation findet nur dann statt, wenn Instabilität zugelassen und gefördert wird. Das Ziel ist, Lernen zu maximieren.
Nonaka und Takeuchi raten dazu, Geschäfts- und Innovationssystem durch Mitarbeiterrotation miteinander zu verkoppeln. Das für die Softwareentwicklung durch zu deklinieren, ist allerdings eine längere Geschichte, die den Rahmen dieses Artikels sprengen würde.
Festzuhalten bleibt, dass Geschäfts- und Innovationssysteme unterschiedliche Strukturen benötigen und dass Scrum-Teams eine gute Wahl für das Innovationssystem sind.
Drei Horizonte der Innovation
[Baghai et al 00] unterscheiden unterschiedliche Horizonte, in denen Innovation stattfinden muss (siehe Abbildung 4), um langfristiges Wachstum zu gewährleisten. Im Horizont 1 findet das aktuelle Geschäft statt; dort wird aktuell das Geld verdient. Wenn ein Startup erfolgreich wird, wächst es schnell bezüglich der Umsätze. Irgendwann tritt allerdings eine Sättigung in dem Geschäftsfeld ein (die Wachstumskurve in Abbildung 4 verläuft logarithmisch). Das Unternehmen kann Jahrzehnte profitabel bleiben, aber weiteres Wachstum ist nicht mehr möglich. Die Ursache ist, dass der Markt insgesamt gesättigt ist und der Markt zwischen den Wettbewerbern aufgeteilt ist. Diese Aufteilung kann sich natürlich prinzipiell verschieben. Das passiert meist aber nur langsam.
In Horizont 1 wird allerdings nicht nur das Geschäft abgewickelt. Es finden auch Innovationen statt und zwar immer mit dem Ziel, die existierenden Kundenbedürfnisse mit den existierenden Produkten / Services besser zu erfüllen. Die meisten Innovationen im Horizont 1 haben mit Effizienzoptimierung und Qualitätssteigerung im Service zu tun.
Wenn das Unternehmen weiter wachsen will, müssen darüber hinaus gehende Innovationen her. In Horizont 2 werden die Produkte oder Geschäftsbereiche entwickelt, die später den existierenden Horizont 1 deutlich erweitern oder gar ersetzen sollen. In der Softwareentwicklung erstreckt sich dieser Horizont meist 12-24 Monate in die Zukunft. (Die von Nonaka und Takeuchi untersuchten Produktentwicklungen fanden übrigens alle in Horizont 2 statt.)
Die Entwicklungen in Horizont 2 finden nicht auf gut Glück statt. Sie basieren auf validierten Geschäftsmodellen und vorher gesicherten Optionen. Und genau das findet im Horizont 3 statt (meist 18-36 Monate in der Zukunft). Hier werden viele Ideen mit jeweils wenig Aufwand parallel bearbeitet. Es geht darum, mit wenig Aufwand und Kosten viele Optionen für die Zukunft zu sichern.
Ein Ölförderer sichert sich z. B. Bohrrechte in einer bestimmten Region und entscheidet später, ob er das Feld überhaupt erschließt. Mitunter staunen wir über Firmenkäufe weil wir den Bezug zum Geschäft des Käufers nicht erkennen. Beispiele dafür sind der Kauf von Skype durch eBay oder der Kauf von Boston Dynamics (Militärroboter) durch Google sowie der Verkauf von Skype durch eBay später an Microsoft. Im Horizont 3 ergeben solche Firmenkäufe aber durchaus Sinn. Man sichert sich Optionen für zukünftiges Geschäft, das eben nicht in Horizont 1 liegt. Später entscheidet man, ob man die Option in den Horizont 2 zieht und das Geschäft wirklich entwickelt. Und mitunter entscheidet man sich, die Option gar nicht mehr auszuschöpfen und verkauft das Unternehmen wieder. Dass dieser Verkauf mitunter mit Verlust erfolgt, ist hier tatsächlich nachrangig.
Die angegebenen Zeitspannen für die Horizonte 2 und 3 mögen sehr lang erscheinen. Schließlich arbeiten wir doch längst agil und können viel schneller reagieren. Das wäre plausibel. In der Praxis sind die meisten E-Business-Unternehmen aber keineswegs in der Lage, die angegebenen Zeiten deutlich zu unterschreiten. Schließlich müssen die Entscheidungen durch viele Bereiche und Hierarchieebenen wandern, bis man tatsächlich beschließt, ein neues Produkt in Horizont 2 zu entwickeln. Agilität ist in den meisten Unternehmen leider nach wie vor auf die Entwicklung beschränkt, während der Rest des Unternehmens langsam und starr geblieben ist. Ein Grund dafür ist unter anderem, dass das Innovationssystem nicht effektiv gestaltet ist und immer wieder durch die Strukturen des Geschäftssystems behindert wird.
Organisation für das 3-Horizonte-Modell
Damit das 3-Horizonte-Modell gut funktioniert, müssen bestimmte organisatorische Voraussetzungen erfüllt sein. Zunächst muss ausreichend Freiraum vorhanden sein, so dass die vielen kleinen Ideen im Horizont 3 entstehen und als Optionen gesichert werden können. Im E-Business geht es hier vor allem darum, neue Kundenbedürfnisse zu entdecken und zu validieren und neue technologische Möglichkeiten im Auge zu behalten. Die Firma 3M ist bekannt dafür, dass sie viele neue Produktideen entwickelt hat. Dort hat jeder Ingenieur 15% seiner Arbeitszeit zur freien Verfügung (sogenannte Slack-Zeit), um an eigenen Projekten zu arbeiten, die nicht weiter genehmigt werden müssen. Google hatte ein ähnliches Modell, das anscheinend gar nicht mehr oder zumindest nicht mehr flächendeckend eingesetzt wird. Über die Ursachen lässt sich nur spekulieren. Es wäre plausibel, wenn eine interne Auswertung ergeben hätte, dass durch die Investitionen kein ausreichender Mehrwert geschaffen wurde.
Eine Ursache könnte die starke technologische Fokussierung sein. Bei einem unserer Kunden wurde ein ähnliches Modell eingeführt. Die Entwickler haben sich in ihrer Slack-Zeit vor allem mit neuen Technologien beschäftigt. Dabei wurden die Kundenbedürfnisse vernachlässigt. Man sollte sich daher klar darüber sein, welche Art von Innovation man anstrebt (siehe Abbildung 5). Sucht man nach neuen technologischen Möglichkeiten, bekannte Kundenbedürfnisse mit etablierten Businessmodellen zu befriedigen, ist der beschriebene technologische Fokus valide.
Wenn man allerdings glaubt, dass man neue Kundenbedürfnisse entdecken und mit alten oder neuen Technologien befriedigen sollte, sieht die Situation anders aus. Dann müssen Rahmenbedingungen definiert werden, die dazu führen, dass Slack-Zeit auch kundenorientiert verwendet wird. Man könnte dazu z. B. die Regel etablieren, dass Slack-Zeit nicht im eigenen Büro, sondern nur beim Kunden verbracht werden darf.
Zusammenfassung
In existierenden Geschäftsfeldern werden Innovationen benötigt, um diese optimal auszureizen und gegen Wettbewerber zu sichern. Langfristig müssen Optionen auf die Entwicklung neuer Geschäftsfelder gesichert werden; das geschieht z. B. durch die leichtgewichtige Validierung neuer Produktideen. Und nicht zuletzt müssen ausgewählte Optionen dann tatsächlich in die Entwicklung gehen.
Innovation ist dabei nicht gleich Innovation. Man kann innovative Technologien einsetzen, neue Geschäftsmodelle erfinden oder neue Kundenbedürfnisse entdecken – und natürlich jegliche Kombination aus den drei genannten Aspekten.
Innovationen brauchen eine andere Umgebung als die Abwicklung von Geschäftsprozessen. Cross-funktionale autonome Teams mit einer hohen Diversität erhöhen die Wahrscheinlichkeit von Innovationen. Dazu müssen Diversität und Verantwortung der Scrum-Teams deutlich über das hinausgehen, was heute üblich ist.
Referenzen
- [NonakaTakeuchi95] Ikujiro Nonaka und Hirotaka Takeuchi: „The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“, Oxford University Press, 1995
- [RoockRoock13] Arne Roock, Stefan Roock: „Wie cross-funktional soll mein Team sein?“, PDF, stefanroock.files.wordpress.com/2013/08/crossfunktionaleteams_roocks.pdf
- [TakeuchiNonaka86] Hirotaka Takeuchi, Ikujiro Nonaka: „The New New Product Development Game“, Harvard Business Review, 1986
- [Baghai et al 00] Mehrdad Baghai, Stephen Coley, David White: „The Alchemy of Growth“, Basic Books, 2000
Autor

Stefan Roock ist einer der Gründer der it-agile GmbH und arbeitet dort als agiler Coach und Geschäftsführer.
Stefan arbeitet im Coaching auf eine Arbeitswelt hin, in der wir bewusst und verantwortlich handeln, in der wir gemeinsam etwas bewegen, in der wir Differenzen für Kreativität nutzen und in die wir uns ganz (mit all unseren Stärken, Schwächen und Emotionen) einbringen. Er glaubt, dass damit eine Arbeitswelt entsteht, in der Menschen erfüllt arbeiten und Unternehmen erfolgreich ihren Zweck erfüllen können.
Stefan begleitet seit 15 Jahren agile Transitionen; zu seinen Kunden gehören mobile.de, MyHammer, Telekom Products & Innovations und viele andere.
Stefan hat mehrere Bücher über agile Themen geschrieben und ist regelmäßig Konferenzsprecher zu agilen Themen.
www.stefanroock.de
stefan.roock(at)it-agile.de
www.twitter.de/StefanRoock