Innovation Tokens – Gegen Informatikerromantik und Technologieüberflutung

Alexander Heusingfeld

Das Dilemma: Innovation vs. Chaos

Eine neue Technologie ins Unternehmen oder Projekt einzubringen, verursacht Kosten. Aber sind wir uns wirklich im Klaren darüber, über welche Kosten wir hier sprechen? Wenn wir ein Team von erfahrenen Java-Entwicklern haben, wird der Vorschlag, neue Anforderungen an unsere Anwendung mit Python umzusetzen, vermutlich Stirnrunzeln hervorrufen. Denn uns wird relativ schnell bewusst, dass die Anwendung dadurch komplexer werden würde. Wir würden uns fragen, ob das Team dies handhaben kann und ob unser Betrieb dem gewachsen ist.

Lautet der Vorschlag aber beispielsweise, die Daten unserer Anwendung in verschiedene NoSQL-Datenbanken aufzuteilen, die auf die jeweiligen Datenstrukturen und ihre Anwendungsfälle optimiert sind, bekommen wir stattdessen oft ganz andere Aussagen zu hören. Nämlich: Gute Idee, wir nutzen das beste Tool für den jeweiligen Job. Zu leicht vergessen wir, uns vorab schon die vielleicht unangenehme Frage zu stellen: Kann mein Team, ja, unsere Organisation, ein System mit diesen Technologien überhaupt betreiben?

Heutzutage sind Unternehmen ständig gefordert einen Spagat auszubalancieren. Auf der einen Seite bringt zu viel Innovation in Form von neuen Technologien und Prozess- oder Organisationsveränderungen Unruhe und Unsicherheit ins Unternehmen. Auf der anderen Seite müssen Unternehmen innovativ sein, um am Markt gegen den Mitbewerber zu bestehen und gleichzeitig gute Mitarbeiter anzulocken. Aber es wäre natürlich auch unvernünftig, Innovation in Form von neuer Technologie generell auszuschließen. Bei einigen großen oder mittelständischen Firmen durften wir derartige Bemühungen beobachten, die teilweise einen großen Anteil daran hatten, dass diese Unternehmen von ihren Mitbewerbern überholt wurden. Die Frage ist also: Wie viel Innovation und Neuerungen sollen wir zulassen? Was ist das richtige Maß? Um diese Frage zu beantworten, soll uns die Idee der Innovation Tokens helfen.

Die Idee hinter Innovation Tokens

Die Idee von Innovation Tokens besteht darin, dass ein Team für die Umsetzung einer bestimmten Anforderung nur eine begrenzte Anzahl an Tokens zur Verfügung hat. Die genaue Anzahl hängt von den Fähigkeiten und der Einsatzbereitschaft des Teams und der Organisation ab. Die Anzahl der Tokens hängt aber nicht vom Umfang der Anforderung ab. Wenn die Anforderung groß ist, war es in unseren Projekten bisher nie effektiv, diese mit noch mehr Technologie zu erschlagen. Dies führte eher zum gegenteiligen Effekt. Des Weiteren haben wir auch noch kein Team erlebt, das mehr als fünf Tokens in einer Phase eingesetzt hat. In der Regel sollten Teams mit drei Innovation Tokens pro Projekt auskommen.

An dieser Stelle kommt oft die Frage auf: Verspiele ich nicht eine Chance, wenn ich Innovation so stark begrenze? Nein, denn wir wollen die Anzahl der gleichzeitig eingeführten Neuerungen auf diejenigen begrenzen, von denen wir uns den größten Mehrwert für unsere Produkte oder unseren Business Value-Versprechen. Wir können drei wesentliche Punkte festhalten, die die Notwendigkeit unterstreichen, die Anzahl gleichzeitig neu eingeführter Technologien zu begrenzen:

• Die unbekannten Unbekannten reduzieren
• Den kognitiven Ballast reduzieren
• Unsere Zeit auf die Wertschöpfung verwenden, anstatt auf „Nebenkriegsschauplätze“

„The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.“ –Dan McKinley

An die unbekannten Unbekannten denken

Wenn wir neue Software schreiben, gibt es immer Dinge, die wir im Vorfeld noch nicht wissen. Wir wissen aber, dass wir uns um diese Dinge kümmern sollten. Wir sollten z. B. wissen, wie sich die Datenbank verhält, wenn ihre Systemressourcen ausgelastet sind und ob unsere Anwendung in dem Fall auf bestimmte Fehlerszenarien reagieren können muss. Bei neuen Technologien gibt es aber leider auch einige Dinge, von denen wir gar nichts wissen. Da wir nicht wissen, dass diese existieren, wissen wir auch nicht, ob und wann sie für uns überhaupt relevant werden oder ob wir uns darum kümmern müssen. Ein Beispiel hierfür wäre, dass in unserem Messaging-System in bestimmten Situationen Nachrichten verloren gehen. Die Anzahl dieser unbekannten Unbekannten (Unknown Unknowns) wollen wir dringend auf ein Minimum reduzieren, denn sie können im schlimmsten Fall zu Datenverlust, Produktionsausfall oder Scheitern des Projekts führen.

Kognitiven Ballast vermeiden

Auch kognitiven Ballast sollten wir vermeiden. Als kognitiven Ballast bezeichnen wir Aufgaben, die wir bei der Einführung neuer Technologien implizit mit aufgebürdet bekommen. Es gibt schon Unit-Tests für die Anwendung, aber wie schreiben wir Unit-Tests für diese neue Technologie? Wir haben Monitoring für unser System, aber wie muss es angepasst werden, wenn wir die neue Technologie einführen? Was muss ein Entwickler wissen, um überhaupt anfangen zu können die neue Technologie zu nutzen? Wie verändern sich dadurch die Folgeprozesse?

All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt zum Erreichen des Ziels beiträgt. Jede Firma, jedes Team kann nur eine bestimmte Menge kognitiven Ballast tragen, bevor vielleicht wichtige Punkte runterfallen und vergessen werden. Wie groß diese Menge in einem Team gerade ist, lässt sich schwer messen. Was aber klar ist: Dass ein Thema runtergefallen ist, bemerken wir meist erst dadurch, dass es uns schmerzhaft auf die Füße fällt.

Fokus auf die Wertschöpfung legen

Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem genutzt wird. Dementsprechend sollte es unser Anliegen sein, die Projektziele an dieser Wertschöpfung und den fachlichen Zielen zu orientieren, damit das Projektteam diese in technische Detailentscheidungen immer einbezieht – wie der Einführung neuer Technologien. Wenn bei der Definition der Projektziele die fachlichen Ziele nicht transparent sind und nicht klar ist, wie der Mehrwert am Ende gemessen wird, kann dies dazu führen, dass unbewusst Entscheidungen getroffen werden, die gegen unsere fachlichen Ziele laufen.

Der Endkunde zahlt nicht mehr Geld für unsere Produkte, nur weil unsere Protokollevents per TCP in eine zentrale ElasticSearch-Datenbank geschrieben werden, anstatt in eine Datei auf der Festplatte. Wie hilft das dem Kunden? Wo trägt diese Änderung zur Wertschöpfung bei? Wird das System dadurch stabiler? Sinken die Wartungskosten? Können potenzielle Fehlerszenarien früher entdeckt und behoben werden, bevor der Kunde davon betroffen ist? Die Aufgabe des Entwicklungsteams ist es, mit ihrer Arbeit zur Wertschöpfung ihres Unternehmens beizutragen. Und unter diesem Gesichtspunkt sollten wir auch unsere Innovation Tokens einsetzen.

Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die Mehrheit unserer Zeit verbringen, nicht im so genannten Parity-Sektor, in dem für uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten sehr gut abschätzen lassen.

So werden die Tokens eingesetzt

Nehmen wir an, wir sind in einem Team mit JavaScript-Entwicklern und sollen eine neue Webanwendung schreiben. Das Team hat bisher gute Ergebnisse mit dem JavaScript-Web-Framework Express.js erzielt, das im Node.js-Ökosystem weit verbreitet ist. Nun möchten die Kollegen aber auf das Framework hapi wechseln, weil es einige Expertenfeatures mitbringt. Hierfür müsste das Team ein Innovation Token ausgeben, da es sich um einen invasiven Austausch handelt, durch den die Vorgehensweise bei der Entwicklung verändert wird und weite Teile der Anwendung umgebaut werden müssen. In Konzeption, Test und Betrieb sollten die Veränderungen nicht oder nur marginal zu spüren sein.

Wichtig ist hierbei, dass die Einführung dieser neuen Technologie eine Mehrheitsentscheidung des Teams ist und dass diese Entwurfsentscheidung sowie die Gründe und Alternativen dieser Entscheidung schriftlich festgehalten werden (arc42 Kapitel 9). Auf diese Weise ist nicht nur für Außenstehende, beispielsweise andere Teams oder Auditoren, sondern auch für das Team selbst nach ein paar Monaten noch klar ersichtlich, warum die Entscheidung so getroffen wurde. So kann das Team zu einem späteren Zeitpunkt die Kriterien ansehen und gegebenenfalls feststellen, dass sich die Rahmenbedingungen geändert haben und die Entscheidung zu Gunsten einer Alternative revidiert werden sollte.

In dem Moment, in dem eine Entwurfsentscheidung über die Teamgrenzen hinaus geht, also beispielsweise auch Auswirkungen auf den Betrieb der Anwendung hat, muss das Team hierfür zwei Innovation Tokens ausgeben. Dies wäre bei der Einführung einer neuen Datenbanktechnologie der Fall, die noch nicht im Unternehmen vorhanden ist. Der Grund hierfür ist, dass dies nicht nur Aufwände und Risiken in unserem Team erzeugt, sondern eben auch in mindestens einem anderen Team. Unser Operationsteam muss sich bei der Einführung beispielsweise von Cassandra mit Themen wie Clusterbetrieb, Datensicherung und -wiederherstellung, dem Monitoring und dem Verhalten der Datenbank bei Network Partitions beschäftigen, damit das Entwicklungsteam die Datenbank überhaupt benutzen kann.

Ein konkretes Beispielprojekt

Letztlich steht und fällt die Idee der Innovation Tokens mit der Akzeptanz bei den Teammitgliedern. Was, wenn die Teams die Gründe für diese Einschränkung nicht verstehen? Oder schlimmer noch, sie vermuten als Ursache die vermeintliche Inkompetenz eines anderen Teams mit den neuen Technologien umzugehen und beschuldigen das andere Team, sie auszubremsen, anstatt dieses Team bei der Aufgabe zu unterstützen. Da ich allerdings ein großer Freund von kleinen Experimenten bin und davon, Dinge auszuprobieren, anstatt sie tot zu diskutieren, haben wir das Konzept in einem kleinen Projekt angewendet.

Der Auftrag des Projekts war es, eine Webanwendung als Microservice zu erstellen. Im Entwicklungsteam herrschten von Anfang an sehr unterschiedliche Vorstellungen davon, welche Technologien benötigt würden. Nahezu jedes Teammitglied schlug andere Technologien vor und die meisten beharrten darauf, dass diese unbedingt notwendig seien. Wir merkten schnell, dass wir so nicht weiterkamen. Wir mussten ein gemeinsames Verständnis dafür erarbeiten, welche Technologie uns an welcher Stelle wie stark helfen konnte, wie viel Aufwand die Einführung bedeutete und welche Alternativen es gab. Deshalb sollte zunächst jeder seine eigenen Vorschläge dem Team schriftlich vorstellen und dabei folgende Fragen beantworten:

• Welches unserer Probleme wird diese Technologie lösen?
• Welche Veränderungen erfordert diese Technologie gegenüber dem Status quo?
• Wie könnten wir diese Probleme lösen, wenn wir die Technologie nicht einsetzen können?

Interessant war insbesondere bei den Antworten zu Frage 1, dass hier Probleme genannt wurden, die vorher nie diskutiert worden waren. Dies war ein Gewinn für das Projekt, denn es führte zu Schritt 0: Probleme und Herausforderungen explizit machen. Dieses Ergebnis half den anderen Teammitgliedern, die Beweggründe des Vorschlagenden zu verstehen und einschätzen zu können. Anschließend konnten wir im Team Technologievorschläge zusammenfassen und über die beste Alternative abstimmen. Allerdings konnten wir die Liste immer noch nicht auf die gewünschte Anzahl von nur drei Technologien verkürzen.

Um dieses Ziel letztlich doch zu erreichen, schlug unser Projektleiter eine geheime Abstimmung vor. Jeder von uns wählte die aus seiner Sicht wichtigsten drei Technologien aus und schickte seine Auswahl an unseren Projektleiter. Dieser addierte die Stimmen und stellte uns das Ergebnis in einem Folgetermin vor. So reduzierten wir eine Liste von 28 Technologien auf sechs, wobei zwei Technologien ganz vorne lagen. Da wir uns hier nicht auf eine dritte Technologie einigen konnten, beschlossen wir, zunächst mit den zwei neuen sowie den vorhandenen Technologien zu starten. Die Entscheidung für die dritte Technologie wollten wir erst später treffen, wenn wir an einen Punkt kommen sollten, an dem wir unsere Herausforderungen nicht mehr lösen könnten. Dieser Fall trat in diesem Projekt jedoch nie ein.

Rückblickend können wir sagen, dass wir die Probleme vermutlich auch über Umwege ganz ohne neue Technologien hätten lösen können. Hier wären dann aber die nicht zu unterschätzenden Faktoren Motivation, Teamgefühl und vor allem die Weiterbildung zu kurz gekommen. Dies kann sich unserer Erfahrung nach mittelfristig negativ auf die Produktivität auswirken, wodurch dann wirklich Wettbewerbsnachteile entstehen können.

Fazit

Innovation Tokens sind ein einfach verständlicher Ansatz, um das richtige Maß an neuen Technologien in Softwareentwicklungsprojekten zu finden. Projektverantwortliche und Teams bekommen hierbei ein Hilfsmittel an die Hand, das eine Selbstkontrolle und Fokussierung auf das Notwendige ermöglicht, anstatt einem Team überladene Genehmigungsprozesse oder lähmende Regularien aufzubürden. Kurz: Bei richtiger Anwendung fördern sie den gesunden Menschenverstand und die Besinnung auf die Wertschöpfungsziele.