AGILE INNOVATION

Agil oder streng nach dem großen Plan?

Wie können wir die Hürden und Hindernisse für Innovationen überwinden? Versucht das denn keiner? Ich will im Folgenden darstellen, wie wir weiterkommen können.

Dieser letzte Abschnitt ist nun kein vollständiges Lehrbuch über die ganze Breite aller Problematiken der Innovation. Ich will ja in diesem Buch hauptsächlich die Barrieren für die Innovation sichtbar machen. Ich beschränke mich daher im »konstruktiven Teil« auf Ratschläge und Handlungsempfehlungen, die nicht in jedem Ratgeber stehen.

Es ist sehr schwierig, wenn nicht unmöglich, allgemeine Ratschläge zu geben. Jede Innovation für sich ist etwas Besonderes. Es geht ja darum, etwas, was es noch nicht gibt, zum ersten Mal der Menschheit zugänglich zu machen. Bei diesem ersten Mal wird noch lange probiert, zugehört und experimentiert werden.

Ich beschreibe nun Erfordernisse für Innovationen. Sie werden sehen, dass diese in praktischen, realen Fällen meist nicht erfüllt werden, ja nicht einmal Gegenstand der Betrachtung sind. Wenn Sie also meine Betrachtungen lesen und meine Auffassung der beschriebenen Notwendigkeiten mehr oder weniger teilen können, dann folgt daraus, dass es nicht nur Feinde und Verhinderer von Innovationen gibt, sondern dass die allgemeine Unprofessionalität oder die konsistent falsche Methodenwahl vielleicht ein noch größeres Hindernis für Innovationen darstellt.

Dies sehen Sie schon gleich in der folgenden Diskussion des »agilen Handelns«. Es ist bekannt, wie das geht, aber die meisten lehnen solch ein Vorgehen ab, und die meisten, die es in der »richtigen« Weise versuchen, können es dann leider nicht gut. Das »richtige Vorgehen« ist eben schwieriger – und führt derzeit noch wegen Unprofessionalität genauso häufig zum Desaster wie das übliche falsche Vorgehen. Das diskreditiert das richtige Vorgehen leider sehr.

Mein Einstiegsbeispiel sind die Aktivitäten und neuen Denkweisen aus dem Software-Erstellungsbereich. Software-Erstellung ist ja sehr oft gleichzeitig auch Innovation. Man schreibt ja nicht einfach ein Programm, sondern erfindet meist auch eine neue Nutzung für neue Kunden.

Seit vielen Jahren ächzen die kreativen Software-Entwickler unter den viel zu detaillierten Projekt-, Zeit- und Finanzplänen, die eine Software-Entwicklung aus ihrer Sicht viel zu stark bürokratisieren. »Hilfe!«, rufen sie, »es handelt sich doch jedes Mal um eine Innovation, die Flexibilität und viele Veränderungen im Prozess erfordert!«

Und im Kontext dieses Buches merken Sie, dass schon wieder die Welten im Denkbabylon aufeinander prallen. »Behindernde Struktur« oder »kreatives Durcheinander«?

In der Software-Entwicklung werden seit vielleicht 20 Jahren neue Ansätze unter dem Banner der »Agilität« diskutiert, konzipiert und auch schon in einem guten Ausmaß umgesetzt. Es liegt nahe, aus der Idee der »agilen Software-Entwicklung« eine der »agilen Innovation« zu formen. Das will ich im Folgenden unternehmen. Bedenken Sie, dass Software-Entwicklung eine eigene Industrie geworden ist und natürlich nach den besten Konzepten suchen muss, während Innovation in den Unternehmen immer noch irgendwie ein isoliertes Einzelnes ist. Es ist deshalb klar, dass die Umsetzung neuer Konzepte in der Software-Entwicklung mit mehr Energie verfolgt wird als in dem allgemeinen Gemenge der Innovation. Es ist also richtig, sich bei der Software-Erstellung umzusehen, wenn man auf dem Innovationsfeld dazulernen möchte.

Das Wort »agil« kommt aus dem Lateinischen und bedeutet »beweglich« oder »behände«. Man sagt: »Für dein Alter bist du noch erstaunlich agil« oder »Die Leute in der (sonst so bürokratischen) Stadtverwaltung sind unerwartet agil! Die tun was!« Alte, Beamte, Finanzprüfer, Controller, Büroleiter sind irgendwie nicht agil, oder? Jedenfalls sagt das unser gängiges Vorurteil. Das muss ich hier unbedingt »bringen«, weil es genau in den Kontext passt.

Das Wort »agil« ist durch seine spezifische Bedeutung bei der Entwicklung von Software in den Sprachschatz der IT gekommen. Die klassischen Software-Entwicklungsprozesse, die man seit den 70er Jahren verwendete, wurden mit der Größe der Projekte immer starrer, der bürokratische Aufwand stieg bis ins Ärgerliche an. Zunächst legt dabei der Software-Kunde seine Anforderungen möglichst genau in einem Lastenheft nieder. Auf dieser Basis erarbeitet das Software-Entwicklungsunternehmen ein detailliertes Pflichtenheft, das die zu erstellende Software beschreibt. Wenn der Kunde das Pflichtenheft akzeptiert, wird alles nach Plan in verschiedenen Schritten ausgeführt.

Jeder Schritt endet mit einem festen Ergebnis, erst danach tritt das Projekt in die nächste Phase ein. Nachdem der Kunde also das Pflichtenheft angenommen hat, läuft ein großes Projekt ab, das vorher generalstabsmäßig geplant ist. Genaue Ablaufpläne steuern viele Software-Entwickler, die am besten alle gleichzeitig jede der Phasen beenden, damit in die nächste Phase übergegangen werden kann. Die einzelnen Phasen ersehen Sie aus der Grafik, die immer so stufig nach unten in Lehrbüchern erscheint. Dieses Vorgehen wird nämlich mit dem Terminus »Wasserfallmodell« bezeichnet.

Der Kunde bekommt am Ende, was er unterschrieben hat. Leider ist dann ein Teil der Software schon veraltet oder überholt, oder sie trifft nicht die Erwartungen des Kunden, der sie jetzt doch lieber anders gehabt hätte. Hätte man ihn zwischendurch nicht einmal reinschauen lassen können? Nein, das würde den komplizierten Plan völlig durcheinander bringen und sofort Vertragsfragen aufkommen lassen: Kostet es nun mehr?

Kent Beck erwies sich als Vorreiter einer neuen Entwicklung, als er seit 1999 etwa mit Martin Fowler und Erich Gamma unter dem Schlagwort Extreme Programming flexiblere Vorgehensweisen zu beschreiben versuchte, die damals wie eine Revolution wirkten. Bei einem heute schon als historisch betrachteten Treffen von Software-Entwicklern im Jahre 2001 in Utah prägte man den Begriff »agil«. Bei dieser Gelegenheit wurde ein Manifest von Prinzipien und Werten ausformuliert, das Agile Manifest oder Agile Manifesto oder original das Manifesto for Agile Software Development. Die Einzelheiten sind gut in Wikipedia zu finden. Ich möchte hier nur exemplarisch die hauptsächlichen Werte herausheben, die man damals als Fundament betrachtete (sie finden Sie auf der Frontseite von http://agilemanifesto.org/):

[Bild vergrößern]

Wasserfallmodell

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Sie können dort weiterklicken und zwölf Prinzipien finden, die sich als Handlungsleitlinien aus diesen Werten herleiten. Ich zitiere aus der deutschen Wikipedia die deutsche Übersetzung des obigen englischen Textes (die ich etwas »verbessere«, dort ist das englische »over« durch »mehr« übersetzt, ich setze stattdessen »wichtiger als« ein):

1. Individuen und Interaktionen sind uns wichtiger als Prozesse und Werkzeuge. – Zwar sind wohldefinierte Entwicklungsprozesse und Entwicklungswerkzeuge wichtig, wesentlicher sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
2. Funktionierende Software ist uns wichtiger als umfassende Dokumentation. – Gut geschriebene und ausführliche Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software.
3. Zusammenarbeit mit dem Kunden ist uns wichtiger als Vertragsverhandlung. – Statt sich an ursprünglich formulierten und mittlerweile veralteten Leistungsbeschreibungen in Verträgen festzuhalten, steht vielmehr die fortwährende konstruktive und vertrauensvolle Abstimmung mit dem Kunden im Mittelpunkt.
4. Reagieren auf Veränderung ist uns wichtiger als das Befolgen eines Plans. – Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.

Agile Entwicklung verzichtet auf die methodische Strenge der klassischen Phasenabläufe und strebt einen iterativen Teamdialog mit dem Kunden an, der mithilft, das Projekt zu seiner Zufriedenheit zu beeinflussen. Immer wieder werden Änderungen diskutiert, immer wieder wird mit ihm diskutiert, welche Funktionalität er von der Software erwartet. Wir sind es ja gewöhnt, heute Software zu bedienen, die für alle erdenklichen Fälle programmiert ist und die wir lieber einfacher hätten. Alles ist berücksichtigt, nur das nicht, was wir gerne hätten: Unkompliziertheit!

Die Gedanken rund um das Agile Manifesto gleichen denen zur Innovation auf schlagende Weise. Die Werte, die im Manifest niedergelegt sind, drücken dies aus:

• Agilität ist mehr »hysterisch als zwanghaft«.
• Agilität ist die Abkehr vom linkshirndominierten Denken des »richtigen« Menschen, es will nicht mehr so viel Wert auf Prozesse, Dokumentationen, Pläne, Lastenhefte und Pflichtenhefte legen.
• Agilität geht offen mit Veränderungen und Ungewissheiten um.
• Agilität steht für ein Denkkonstrukt, wie es eher einem »natürlichen« Menschen entspricht, der aber eine Affinität zum »wahren« Menschen hat – das zeigt die Ausdrucksweise des Manifestes, das keine Regeln vorschreibt, sondern Prinzipien und Maximen als Leitlinien des Handelns sieht.

Oder kurz:

Die Denkbewegung der agilen Entwicklung und des Extreme Programming ist im omnisophischen Dreieck zwischen dem Pionier und dem Entrepreneur angesiedelt.

Diese neuen Ansätze stellen eine Abkehr von den klassischen Großprojektansätzen dar, die zunehmend als zu schwerfällig, monolithisch kolossal und vor allem zu bürokratisch empfunden werden.

Viele Projekte werden heute nach dem agilen Konzept angelegt und durchgeführt. Was kommt heraus? Ist nun der Stein des Weisen gefunden, wie die Unterzeichner des Manifestes glauben machen könnten?

Ach nein, denn die agilen Methoden verlangen natürlich »leider« agile Entwickler und ebenso agile Kunden. Was, wenn das Kundenunternehmen, das eine Software entwickeln lässt, ein bürokratischer Koloss ist? Dann wird es als abnehmender Kunde auf den klassischen Phasenmodellen mit Dokumentationen und Plänen bestehen. Ihm ist es wichtiger, dass die Zeit- und Budgetpläne eingehalten werden, auch wenn die Software dann nicht so gut ist (»Die Mitarbeiter müssen sich eben dran gewöhnen, wenn sie nicht perfekt ist – besser ging es eben nicht«). Agilität erfordert ein hohes Maß an professionellen Kommunikationsfähigkeiten, und zwar fast durchweg von allen Entwicklern. Diese sind aber oft sehr introvertiert, etliche haben Symptome des Asperger-Syndroms, einer milden Form des Autismus. Sie sind im omnisophische Dreieck zu weit von der »natürlichen Ecke« entfernt. Sie arbeiten im Planmodus gut, auch wenn sie über das viele Kontrollieren und Dokumentieren jammern. Im agilen Modus können sie mangels Kommunikationsfreude und -fertigkeit an die Grenze des Versagens geraten!

Aus diesen Erfahrungen heraus könnte man folgern (das tue ich hier einmal): Agile Entwicklung ist dann besser als solche nach bürokratischen Prozessen, wenn alle Beteiligten Pioniere und Entrepreneure sind, also auch als Personen agil sind. Ein agiles Projekt mit traditionellen Mitarbeitern (»Gamma-Tieren«), die für alles Anordnungen und Arbeitszuweisungen erwarten, wird tendenziell scheitern.

Diese Entwicklung der agilen Software-Entwicklung im letzten Jahrzehnt wirft uns ein helles Licht auf die Innovation:

Innovationen sollten besser gelingen, wenn sie nach agilen Prinzipien von agilen Menschen betrieben werden, die sich während der Dauer des Innovationsprojekts draußen beim Kunden darum bemühen, dass die Neuheit reißenden Absatz und frohen Zuspruch genießt. Bei Innovationen muss man erwarten und verlangen können, dass alle am Projekt Arbeitenden agile Persönlichkeiten sind.

Natürlich gibt es gar nicht so viele »agile Menschen«, bestimmt nicht annähernd so viele, dass alle Software-Entwicklung damit geschafft werden könnte. Wie sollte das denn gehen?, ein ganze Industrie nur mit solchen Ausnahmemenschen zu betreiben? Ein solcher »agiler Ansatz« wird also für die Software-Entwicklung als Ganzes nicht wirklich umsetzbar sein. Die bürokratischen Prozesse dagegen lassen sich ja mit normalen Menschen durchführen!

Innovationen aber sollten in einem Unternehmen mit Ausnahmebegabungen betrieben werden können, oder? So viele »Sondertalente« solle es doch geben? Das ist der Hoffnungsschimmer, und deshalb versuche ich jetzt, das Agile im Kontext der Innovation zu predigen.

Zum Business-Case gehört auch die Meisterschaft

Abstrakt gesehen gibt es zwei verschiedene Konzepte, ein Ziel zu erreichen:

• Man erarbeitet einen Plan, mit dem das Ziel erreicht wird, und setzt ihn um – ähnlich wie es das Wasserfallmodell der Software-Entwicklung in Phasen vorsieht.
• Man vertraut besonders agilen Menschen, die auf große Erfahrung im Erreichen von Zielen zurückblicken können, die Aufgabe an und »lässt sie machen«.

Ich will jetzt keinesfalls schwarz-weiß werden und Ihnen jetzt vortragen, dass Pläne grundsätzlich schlecht oder schlechter sind. Wahrscheinlich geht es ohne Plan gar nicht wirklich. Auch die tollsten Professionals haben einen Plan, aber sie wissen, wie sie im Ungewissen damit umgehen müssen.

Aber das zwanghafte Erarbeiten von Businessplänen oder Business-Cases treibt zu große Blüten.

Seit etlichen Jahren verlangt das strukturierte Management, dass absolut jeder Innovator einen Business-Case einreichen muss, in dem er die zukünftige Entwicklung seiner Idee zum Geschäft möglichst detailliert darlegt. Die Business-Cases sehen alle sehr ähnlich aus, sie folgen einer weithin vorgeschriebenen Liturgie. Sie müssen unbedingt folgendermaßen aussehen:

1. Executive Summary (eine Seite, vielleicht zwei, damit man alles sofort versteht)
2. Beschreibung der Innovation – worum es sich handelt
3. Wie groß ist der Markt dafür? Welche Wettbewerber gibt es?
4. Wie wird das Neue vertrieben, wie wird Marketing gemacht?
5. Beschreibung des Geschäftsmodells – wodurch und wie wird Geld verdient?
6. Wie soll das neue Unternehmen organisiert sein?
7. Wie wird alles realisiert?
8. Wo lauern dabei Risiken?
9. Langer detaillierter Abschnitt über die Finanzierung und den zu erwartenden Gewinn, insbesondere wird eine Aufstellung der Kosten und der geplanten Umsätze der nächsten fünf Jahre erwartet. Es muss ersichtlich sein, dass ein Investor mit seinem Geld einen erheblichen Gewinn erzielen kann. Das ist natürlich die Voraussetzung für das ganze Projekt.
10. Schlussempfehlung für das Projekt – ganz positiv.

Die Antworten auf die Fragen ergeben eine Art Rezept oder Plan, wie demnächst mit der innovativen Idee Geld verdient wird. So einen Plan sollte man wirklich haben, ganz ohne Vorgehensvorstellungen ist Innovation unsinnig. Es ist klar, dass man sich über Finanzen und Wettbewerber Gedanken machen muss. Dann aber – das ist der wichtige Punkt dabei – dann aber muss man Meister genug sein, das Rezept wirklich zuzubereiten. Selbst erprobte Rezepte aus Kochbüchern brauchen Erfahrung, und ein ganz neues Gericht gelingt auch dem Erfahrenen nicht immer! Oder meistens beim ersten Mal nicht so gut!

Wenn das beim Kochen schon so ist – wie sieht es dann erst bei Innovationen aus? Man braucht ganz gehörige Meisterschaft dazu, damit etwas gleich beim ersten Mal klappt. Innovatoren müssen in der Lage sein, in einem absolut unsicheren und ungewissen Terrain mit allen Unwägbarkeiten umzugehen. Innovation findet eben mitten in Zufällen, zwischen Pech und Glück, zwischen Gelingen und immer wieder drohenden Schieflagen statt. Innovatoren müssen trotzdem alles stemmen können und am besten alle Zufälle als Chancen ummünzen und zu ihrem Glück mitnehmen.

Fragt aber jemand beim Business-Case, ob den ein echter Meister durchführt? Nie! Oder wenigstens: nicht wirklich. Fragt jemand bei Forschungsförderprojekten, ob nicht nur das Thema vielversprechend ist, sondern auch der Doktorand, der es durchführt? Nie! Immer steht das Rezept im Vordergrund. Man nimmt an, dass ein gutes Rezept oder ein guter Projektplan ein gutes Projekt garantiert. An die Durchführung denkt niemand, die hält jeder für selbstverständlich. Wieder sehen wir totale Ignoranz an der Stelle (»lack on execution«), wo alles scheitert.

In diesem Sinne sehe ich mich bei Innovationen von ungeheuer vielen Rezeptschreibern umgeben, die an Businessplänen feilen, die genehmigungsreif werden sollen. Diese Leute lesen Bücher und Erfolgstipps, wann Business-Cases von Banken oder Unternehmen abgenickt werden. Für diese schriftstellerischen Bemühungen, ein ausgefeiltes Grafikdesign für die geplanten Umsatzkurven und das neue Firmenlogo nehmen sie sich unglaublich viel Zeit. Viele Erfinder kommen dann mit Luxusbusinessplänen und stellen sie mir vor. »Businesslyrik.«

Und dann stelle ich ein paar Fragen, ob »sie kochen können« beziehungsweise eine Vorstellung von der Umsetzung haben.

»Wer sind die möglichen Wettbewerber?« – »Meine Idee ist vollkommen neu.« – »Woher wissen Sie das?« – »Ich habe eine Stunde gegoogelt – nichts, Gott sei Dank.« – »Hey, Gott sei Dank, nach nur einer einzigen Stunde! Wenn Sie auch nur einen Wettbewerber übersehen haben, sind Sie vielleicht ganz schnell hinüber!« – »Ja, schon, aber dann bekomme ich doch kein Startkapital!« – »Was hilft Ihnen das?« – »Irgendwie packe ich das, das spüre ich.«

Oder: »Wie vermarkten Sie denn das? Haben Sie die nötigen Kontakte dafür? Kennen Sie Multiplikatoren? Können Sie irgendwo publizieren? Haben Sie Follower bei Twitter?« – »Ich schalte Anzeigen.« – »Wie viel kostet das?« – »Ich nehme einfach das Geld dafür, was im Businessplan vorgesehen ist.« – »Wie weit kommen Sie damit? Wie viel Mehrumsatz ergibt das? Wenn eine Werbekampagne nicht einschlägt, ist das Geld unwiederbringlich verbrannt. Dann sind Sie fast schon pleite.« – »Tja, irgendwie wird es schon nicht so schlimm kommen.«

Ich frage, wie denn normale Menschen auf ihre neue Superidee reagieren, kommt die bei OpenMinds an? »Meine Bekannten sagen, ich bin verrückt, aber eigentlich halte ich meine Idee geheim, damit sie nicht geklaut wird.« – »Wie wollen Sie ohne jedes Feedback später dafür Marketing machen?« – »Dafür habe ich dann einen Mitarbeiter.« – »Wissen Sie, wie viel der kostet? Wird jemand bei Ihnen arbeiten wollen, wenn die Gehälter am Anfang nicht sicher sind? Haben Sie schon Leute auf der Warteliste?« – »Nein, ich warte auf die Investitionszusage.«

Ich schüttle meist sorgenvoll den Kopf. Sie alle schreiben einen Plan wie ein Kochrezept, haben aber keine Vorstellung vom Kochen. Dabei haben sie meist etliche Monate mit dem Erstellen des Businessplans verbracht. Ihre Gedanken kreisten Monat um Monat um das Rezept, sie haben sich aber nicht um das Kochen danach gekümmert.

Deshalb sind die Pläne dann oft so schrecklich unausgegoren. Viele sind nicht durchführbar, meist werden die Zeitaufwände am Anfang gnadenlos unterschätzt. »Wir haben nicht gedacht, dass wir uns erst einige Zeit als Menschen kennenlernen müssen. Es war schwer, Leute zu bekommen, die wollten gleich ein hohes Gehalt! Uns war nicht klar, dass es Verzögerungen bei Einstellungen geben könnte und dass wir uns dann doch noch nicht so genau vorstellen konnten, wie wir es ganz konkret umsetzen müssen. Da sind unsere ersten Monatsgehälter fast verpufft, und wir hatten schon eine finanzielle Schieflage, bevor es begann. Wir haben erkannt, wie wenig eigentlich im Plan drinstand, tja, jetzt haben wir ein Problem.« Dabei haben diese Amateure kein Problem, sie sind das Problem.

Den meisten Erstinnovatoren fehlen die Grundvoraussetzungen für den Erfolg. Sie haben sich meist zu sehr auf die Idee fokussiert und die Umsetzung nicht bedacht. Für die Umsetzung muss man etwas können! Vorher … Das bespreche ich jetzt.