Agil, Innovation, Kultur, Motivation, Scrum, Teamarbeit

Das Yin und Yang des Innovators

Die Haltung, Programmcode in hoher Qualität und ohne Verschwendung zu jedem Abschluss einer Iteration auszuliefern, nimmt in der agilen Softwareentwicklung, speziell in Scrum, viel Raum ein.

In einer möglichen Weiterentwicklung dieses Gedankens gelangen wir zu den Hyperproductive Teams, denen Jeff Sutherland eine zehnmal  höhere Produktivität zutraut, als klassischen, also nicht-agil vorgehenden Teams [Sutherland et al. 2009].

Ein hyperproduktives Team habe ich noch nicht kennengelernt. Eine Verdopplung der Produktivität zu erreichen ist jedoch realistisch und selbst noch bessere Ergebnisse kenne ich.

Das Kreisen um das Effizienzthema ist aus verschiedenen Gründen verständlich. Zum einen ist der Zustand einer ganzen Reihe von Softwareentwicklungsprojekten nicht so gut, wie er sein könnte. Damit meine ich: Der Aufwand zur Herstellung lauffähigen Codes ist sehr hoch. Hat man es dann erst einmal geschafft, die Software zu schreiben, sind vielleicht wesentliche nicht-funktionale Anforderungen, z.B. an die Performance oder an eine aufgabenangemessene Benutzungsschnittstelle, nicht erfüllt. Manche Ausnahmesituation wurde nicht bedacht, der Kunde findet das selbst heraus und gelangt rasch an die Punkte, an denen er nicht effizient oder nur über Umwege weiterarbeiten kann. Sie haben aus Ihrer eigenen Praxis sicher einige schaurig-schöne Beispiele vor Augen.

Erschwerend kommt manchmal hinzu, dass die Programmierarbeit auf einen anderen Kontinent, in eine andere Zeitzone, in einen anderen Kulturkreis und in ein anderes Sprachgebiet ausgegliedert wird. Wer vor einem solchen Schritt seine Softwareentwicklung nicht im Griff hat, hat sie danach erst recht nicht im Griff. Ist es eine gute Idee, wenn man mit drei Bällen schon nicht jonglieren kann, einfach mit sechs Bällen weiterzumachen? Welches Interesse hat beispielsweise ein indischer Programmierer, der in seinem Umfeld alle zwei Jahre den Arbeitgeber wechselt und der mit seinem Überlebenskampf und der Organisation seines Fortkommens vollauf beschäftigt ist, für eine deutsche Firma nachhaltig innovative Software zu entwickeln? Man kann vielleicht aus Kostengründen einen solchen Schritt unternehmen und dennoch mit der Entwicklungseffizienz nicht zufrieden sein.

Das Problem der effizienten Softwareentwicklung ist keinesfalls gelöst und der Druck, Software effizient zu schreiben, hat nicht nachgelassen. Damit ist klar, dass die Frage nach Entwicklungseffizienz in jedem Unternehmen, in dem Software zum Geschäft gehört, eine Rolle spielt.

Auf der anderen Seite der Medaille wollen die Agilisten ihren Stoff verkaufen. Schließlich sind Kunden zu überzeugen, Geld auszugeben und Methodiker zu bezahlen, die wissen wie der Hase läuft, die die Selbstorganisation studiert haben und die in der Lage sind, die Produktivität ganzer Organisationsbereiche mindestens zu verdoppeln. Es gibt somit eine Community, die ein vertriebliches Interesse an der Effizienzdiskussion hat. Effizienz ist ein guter Grund, sich mit Agilität auseinanderzusetzen, aber es ist nicht der einzige Grund.

Man sieht, die Eingrenzung auf den Produktivitätsaspekt in so mancher Diskussion zum Einsatz agiler Verfahren ist nachvollziehbar. In dem Zusammenhang ist zu bedenken, dass die einseitige Konzentration auf die Erhöhung der Auslieferungsgeschwindigkeit oftmals mit einer Haltung des Managements einhergeht, die davon ausgeht, dass Verhaltensänderungen bei den ausliefernden Teams gefordert, beim Management aber nicht nötig sind. Das reicht nicht.

Die Effizienz wird nur sekundär durch die Anwendung bestimmter Regeln, sondern in erster Linie durch eine echte Zusammenarbeitskultur, eine Kultur der Verständigungsbereitschaft, durch den Anspruch auf Qualität und den Willen zur Verbesserung erreicht. Das Arbeiten in Sprints oder Iterationen bringt manchmal schon etwas, hat man aber den Geist der Zusammenarbeitskultur nicht verstanden, kommt man insgesamt nicht weit. Die Erneuerung und in deren Folge die Effizienzsteigerung, muss von innen kommen. Ein Team, das ein wirkliches Team ist, kann unglaubliches und überraschendes leisten und es ist auch unter ganz persönlichen Gesichtspunkten erstrebenswert, in einem echten Team anzukommen und gemeinsam das Rad weiterzudrehen. Dabei schließe ich das Management, oder genauer, die Führungskräfte, mit ein.

Nehmen wir für die weiteren Überlegungen an, ein leistungsfähiges, echtes Team ist gewachsen und das Team hat eine Auslieferungsqualität und -geschwindigkeit, die ihresgleichen sucht. Ist jetzt das Ziel, so viel Code wie möglich in sehr geringer Zeit zu schreiben? Was bedeutet Erfolg für ein Unternehmen, das Software als Teil seines Geschäfts benötigt?

Eine andere Perspektive könnte doch auch sein, so wenig Code wie möglich zu schreiben. Wenig Code hat potentiell weniger Fehler, weniger Redundanzen, ist vermutlich einfacher zu warten und leichter zu ändern. Ist die Aufgabe vielleicht eher, Probleme zu lösen und wenn das mit wenig Code geht, am liebsten so? Wir wollen vielleicht nicht nur Software effizient ausliefern, sondern auch das richtige Problem damit lösen – also das Richtige richtig tun.

Diese Dinge gehen Hand in Hand: Erkenne das eigentliche Problem, finde die kreative Lösung und liefere dann effizient aus. Bisher orientieren wir uns sehr stark am letzten Aspekt, der effizienten Auslieferung, dem Yang, dem Gebenden.

Eine effiziente Auslieferung ist natürlich nicht wegzudenken. Wenn das nicht geht, geht alles andere sowieso nicht. Aber wie erkennen wir das eigentliche Problem, stellen die richtige Frage und wie finden wir die Lösung? Was ist also mit dem Yin, dem Empfangenden, dem Kreativen, dem Erneuernden?

Ein erster Schritt ist die Erkundung der Problemdomäne. Dazu gehört, Empathie mit den Nutzern des (zukünftigen) Produktes herzustellen. Dazu muss man den Nutzer kennenlernen, am Ort des Geschehens sein, beobachten, in Dialog treten, ein gemeinsames Verständnis herstellen, Vertrauen erwerben. Wenn man beispielsweise einen Call-Center-Agenten nachts bei seiner Arbeit begleitet hat und sieht, wie er die Dialogabläufe eines Systems handhabt, kann man als Product Owner, als Entwickler oder als UX-Designer das Arbeitsumfeld und mögliche Erfordernisse viel eher einschätzen und Lösungsideen beisteuern, die sonst keiner der Beteiligten sieht. Dieses gemeinsame Verständnis bedeutet viel mehr, als gemeinsam das selbe Dokument zu lesen. Gleiches gilt umgekehrt. Die Entwickler (ich verwende den Begriff im weitesten Sinne) sollten die Produktnutzer an ihrem Tun teilhaben lassen. Eine sehr gute Gelegenheit bietet sich schon beim Start des Projektes, wenn eine Produktvision [Schneider 2012] erstellt oder im Rahmen des Story Mapping [Patton 2008] eine Hierarchie von Produktfunktionen ausgearbeitet wird. Die in diesem Rahmen stattfindenden Diskussionen stellen Probleme und mögliche Produktfunktionen in einen Kontext, der allen Beteiligten die situative Bewertung erleichtert. Ergebnis eines solchen Prozesses ist das gemeinsame Verständnis des Problems und der möglichen Lösung. Jeff Patton, der als Erster über Story Mapping publiziert hat, formuliert dazu: Am Ende des Prozesses ist die Story Map zwar nicht unwichtig, aber wichtiger ist der Prozess, der uns bis dorthin gebracht hat [Patton 2012]. Ein Einschub scheint mir in diesem Zusammenhang noch relevant: Frederick Brooks weist darauf hin [Brooks 2010:72], dass der Architekt den Nutzer vertritt. Neben der zentralen technischen Aufgabe von IT-Architektur, nämlich die Unabhängigkeit der Komponenten zu erhalten oder zu erhöhen, scheint mir diese grundsätzliche Nutzerorientierung wesentlich und im Einklang mit dem Erfordernis, Empathie zu den Verwendern des Produktes herzustellen.

Man kann nicht mit allen Nutzern Empathie aufbauen. Es gibt Nutzer, denen Innovation nicht wichtig oder egal ist [Godin 2012a]. Um eine Innovation hervorzubringen, braucht man Nutzer, die sich engagieren, die die Zusammenarbeit wollen und die nicht nur konsumieren. Das ist die Speerspitze, die nicht im Massenmarkt sondern vor dem Massenmarkt verortet sind. Die Nutzer, die sich mit Trends auseinandersetzen, bevor sie im Massenmarkt angekommen sind. Durch Beobachtung und Analyse des Massenmarktes lässt sich zwar der Innovationsbedarf eruieren, mit den typischen Nutzern des Massenmarktes lässt sich die Innovation aber nicht erarbeiten.

Die Beschäftigung mit den Leistungsmerkmalen von Konkurrenzprodukten ist für die kreative Lösung von Nutzer- oder Kundenproblemen nicht immer hilfreich. Vielmehr stellt sich dadurch in erster Linie Empathie mit dem Konkurrenzprodukt und nicht unbedingt mit den Nutzern ein. Für die wirklich kreativen Lösungen muss man sich von der Beobachtung der Konkurrenz frei machen. Diese kreativen Lösungen geben nicht die Antworten auf bekannte Fragen, sondern liefern gute Antworten auf Fragen, die noch nicht gestellt wurden [Godin 2012b].

Kreativität braucht Raum und Zeit, oder, mit John Cleese, Kreativität braucht Grenzen des Raumes und der Zeit [Cleese 2009], also geschützte Bereiche, in denen die ungestörte Auseinandersetzung mit dem Problem und einer Lösung möglich ist. Unterbrechungen sind für kreative Prozesse hoch kontraproduktiv. Diese Grenzen in Raum und Zeit, die, obwohl Grenzen, so doch befreiend für das Neue, gelten für den Einzelnen, der Rückzugsräume benötigt, und auch für das Team, das experimentelle Freiheit braucht, um Neues schaffen zu können. Der Einzelne, das Team und die umgebende Organisation müssen diesen Rhythmus, der aus Erkundung und Auslieferung besteht, für sich entdecken und organisieren. Wir brauchen nicht das kreative Chaos, um zu erfinden. Vielmehr muss das Team Regeln (er)finden, die eine befreiende Funktion für den Arbeitsprozess haben. Eine gute Ordnung schafft Raum zur Entfaltung [Wolf 2008:71]. Ordnung ist menschlich, Unordnung ist unmenschlich [Wolf 2008:69].

Von der kreativen Idee zur Innovation ist es ein weiter Weg. Eine Innovation ist eine marktfähige Erfindung. Nur 6% der Erfindungen kommen so weit [Kriegesmann 2012]. Das bedeutet, Scheitern ist Teil des Innovationsprozesses. Die Anreizsysteme in den meisten Unternehmen belohnen Scheitern nicht. Vielmehr sind diese Anreizsysteme auf routiniertes Wohlverhalten und nicht die kreative Suche ausgelegt. Das führt zum Kopieren immer alter, immer gleicher Lösungen. Das Neue wird so nicht gefördert.

Im Unternehmen kann es hilfreich sein, für die Bewertung des Scheiterns zwischen Fehlern und Irrtümern zu unterscheiden. Ein Fehler ist etwas, von dem man vorher wissen konnte, dass es nicht funktioniert. Ein Irrtum hingegen folgt aus einer falschen Annahme, die man getroffen hat, weil man es nicht besser wissen konnte [Weißflog 2012]. Der Irrtum führt also zu Erkenntnis, der Fehler zu Verschwendung. Das Wissen, das eine Organisation durch Erkenntnisse hinzugewinnt, ist notwendige Voraussetzung zur Erarbeitung eines Innovationsvorsprungs.

Für den konstruktiven Umgang mit dem Scheitern ist der einsichtige Dialog zwischen den Beteiligten notwendig. Eine Führungskraft muss dazu die Problemdomäne sowie die Lösungsdomäne des Fachgebietes kennen. Auch die Entscheidung, in welchem Problemfeld und mit welchem Lösungsszenario man die Erkundung beginnt und welche Abbruchkriterien es für den Fall des Scheiterns gibt, ist nur mit der entsprechenden Sachkenntnis und im Dialog und in Zusammenarbeit zu treffen. Da frühe Innovationsphasen informationsarm sind, wird es keine absolute Sicherheit geben. Keine leichte Arbeit, aber sie muss getan werden.

Innovationsentscheidungen gehören zum Kern unternehmerischen Handelns. Man kann das nicht auslagern, zum Beispiel in Form einer Strategieberatung durch Consulting Firmen, die dann die Innovationsfelder der nächsten 10 Jahre benennen, was ohnehin nur dazu führt, dass die Unternehmen, die sich in dieser Form beraten lassen, alle auf denselben Feldern tätig sind. Es sind die Führungskräfte eines Unternehmens, die die Rahmenbedingungen für Innovationsprozesse schaffen.

Man muss sich selbst auf den Weg machen, um die ungelösten Probleme der Nutzer und Kunden zu entdecken. Man muss selbst die Verbindung mit den Nutzern aufnehmen (also: Sakko aus, Blaumann an). Den Einkäufer einer Ware zu kennen bedeutet nicht unbedingt, den Kunden oder Nutzer zu kennen. [Kriegesmann 2012]

Wir müssen bedenken, dass Innovation nicht minimal-invasiv zu haben ist. Innovation stellt den Status quo in Frage. Das gilt für den Markt, und, da die Organisation bzw. das Unternehmen in Verbindung mit dem Markt steht, auch für die Organisation. Innovation erzeugt Reibung.

Gerade wegen dieser Reibung erhöht man die Chancen, eine Innovation durchzusetzen, indem man Verbündete sucht. Solomon Asch hat in den 1950er Jahren ein interessantes Experiment durchgeführt, in dem es um den Einfluss von Mehrheitsmeinungen auf persönliche Entscheidungen geht [Asch 1955]. Stehen wir alleine mit unserer Meinung, tendieren wir dazu, mit Mehrheitsmeinungen konform zu gehen, selbst wenn diese Meinung gegen unsere persönliche Sichtweise steht. Schon einen weiteren Mitstreiter zu haben, verbessert die Chancen zum Festhalten am eigenen Standpunkt und zur Durchsetzung der neuen Idee.

Innovation benötigt Durchhaltewillen. Die Firma paragon, die für Ihr Gurtmikrofon belt-mic im Jahr 2011 den OWL-Innovationspreis gewonnen hat, hat an diesem Mikrofon bis zur Marktreife 10 Jahre gearbeitet. [paragon 2011].
Zum Durchhalten gehört das Konkrete. Das Tun, das richtige Tun und das bessere Tun. Nur wer konkret Dinge in Angriff nimmt, wer Mühe auf sich nimmt und trotz der Mühe bereit ist, Getanes hinter sich zu lassen darauf aufbauend und erneut und besser zu beginnen, bringt Erfindungen zur Marktreife.

Innovationsprojekte sind personifiziert, sie werden nicht durch Gremien gesteuert. Es gibt einen Product Owner, der sich mit dem Innovationsprodukt identifiziert und der sich einsetzt. Hier kann erneut der Bogen zur effizienten Auslieferung gespannt werden. Der einsichtige Product Owner ist in der Lage, durch einen einzigen Satz eine ebensolche Produktivität für das ausliefernde Team zu erzeugen, wie es das Team vielleicht nur durch jahrelange Arbeit zur Verbesserung der Codierungseffizienz leisten könnte. Wenn der Product Owner erkennt, dass eine bestimmte Funktion nicht benötigt wird, muss ein Team daran nicht arbeiten (egal, wie leistungsfähig das Team ist). Vgl. [Corinna Baldauf 2012].

Innovation ist ein Hochleistungssport und Spitzenleistung braucht Einsatz, Vertrauen und Stolz auf die eigene Arbeit. Die effiziente Auslieferung, das Yang, ist notwendige Voraussetzung für Innovation. Das einsichtige Hinterfragen, die Herstellung von Empathie, die Erkundung, die Herausforderung des Status quo, das Yin, führt jedoch erst zur Erneuerung und stellt so eine weitere Voraussetzung für die Schaffung von Innovation dar.

Das ist nicht leicht. Arbeit spielt eine zentrale Rolle, wenn es um Freiheit und Aufbruch geht. Wer das nicht leisten kann, hat im Innovationsspiel, hat bei der Gestaltung der Zukunft, nichts verloren.

Referenzen

[Asch 1955] S. Asch, Opinions and Social Pressure, 1955, siehe: http://www.panarchy.org/asch/social.pressure.1955.html

[Brooks 2010] F. P. Brooks, The Design of Design, Person Education, 2010.

[Cleese 2009] J. Cleese, Creativity, siehe: https://www.youtube.com/watch?v=zGt3-fxOvug

[Baldauf 2012] Corinna Baldauf, Hyper-productive teams? Ruthlessly pruned backlog! 2012, siehe: http://finding-marbles.com/2012/11/08/hyper-productive-teams-ruthlessly-pruned-backlog/

[Godin 2012a] S. Godin, The cycle of customers who care, 2012, siehe: http://sethgodin.typepad.com/seths_blog/2012/12/the-cycle-of-customers-who-care.html

[Godin 2012b] S. Godin, Question the question, siehe http://sethgodin.typepad.com/seths_blog/2012/12/question-the-question.html

[Kriegesmann 2012] B. Kriegesmann, 4. Ostwestfälischer Innovationskongress, 2012

[paragon 2011] paragon belt-mic, siehe: http://www.paragon.ag/startseite/produkte/akustik/gurtmikrofon-belt-mic/

[Patton 2008] J. Patton, The new Product Backlog, 2009, siehe: http://www.agileproductdesign.com/blog/the_new_backlog.html

[Patton 2012]  J. Patton, Co-making great products, 2012, siehe: http://www.infoq.com/presentations/Co-Making-Great-Products

[Schneider 2012] U. Schneider, Der erste Knopf, 2012, siehe: https://allesagil.net/2012/01/01/der-erste-knopf/

[Sutherland et al. 2009] J. Sutherland et al., Shock Therapy. A Bootstrap for Hyper-Productive Scrum, 2009, siehe: http://jeffsutherland.com/SutherlandShockTherapyAgile2009.pdf

[Weißflog 2012] S. Weissflog, 4. Ostwestfälischer Innovationskongress, 2012

[Wolf 2008] N. Wolf, Worauf warten wir? Ketzerische Gedanken zu Deutschland, rowohlt, 17. Auflage, 2008

Advertisements
Standard