Übermensch oder Überentwickler? Nietzsche und der Wille nach ständiger Verbesserung

Was bedeutet es, ein cross-funktionales Team zu sein? Was bedeutet der Fokus auf 'Lernen' in einem Scrum Team; wo jede nicht ausgefüllte Rolle erlernt werden kann (und muss)? Steht und fällt Scrum mit einem Team, das nicht aus „Überentwicklern“ besteht? 

Nietzsche hatte viel zu sagen, und noch mehr, über das er sich beschwerte. Viele Zitate Nietzsches sind heute noch weit bekannt: „Gott ist tot und wir haben ihn getötet“, „Was mich nicht umbringt, macht mich stärker“, oder „Man muss noch Chaos in sich haben, um einen tanzenden Stern zu gebären“. Ich glaube, dass wir Nietzsche auch heute noch im Alltag wiederfinden; auch in der Agilität.

Hobby-Astrologe Nietzsche hatte eine Leidenschaft für tanzende Sterne

 Friedrich Nietzsche (1844–1900) war nicht nur Philosoph, er war ein intellektueller Störfaktor. Als ausgebildeter Philologe begann er mit der Analyse antiker Texte, endete aber damit, die Grundannahmen seiner eigenen Gegenwart systematisch zu zerlegen. Moral, Religion, Wahrheit--nichts war für ihn unantastbar.

In einer Welt, die begonnen hatte sich vom Glauben zu lösen, konfrontierte er seine Zeitgenossen mit einer radikalen Konsequenz: Wenn es keinen durch Gott vorgegebenen Sinn mehr gibt, dann liegt es an uns, einen zu schaffen. Doch genau hier liegt das Problem: echte Freiheit bedeutet auch, Verantwortung zu übernehmen. Und anstatt diese Verantwortung anzunehmen, neigen wir selbst heute noch dazu, neue Systeme, Regeln und Rituale zu erschaffen, die uns diese Entscheidungen wieder abnehmen sollen.

Der „Wille zur Macht“, falsche Götter und das Konzept des Übermenschen sind verschiedene Fäden in Nietzsches Teppich der Theorien. Nietzsche verstand, was es bedeutet, Mensch zu sein, nämlich Geist und Körper; halb Apollo und halb Dionysus; hermeneutisch und triebgesteuert. Er verstand auch, dass der Mensch seiner Zeit in der Erleuchtung nicht dazu bereit war, ihr Schicksal in die eigene Hand zu nehmen. Nachdem Gott, der omnipotente, allmächtige Sinnstifter des Lebens, von uns ermordert wurde, standen die Menschen vor den Jahrhunderte alten Trümmern eines Weltbilds. Gott ist tot--was nun?

Neben den „falschen Götzen“ (aka moderne Ersatzreligionen, die das Glaubensvakuum füllen) die Nietzsche kritisierte, war der „Fortschrittsglaube“ ein weiterer Dorn in seinem Auge. Er kritisiert den bedingungslosen Glauben an Fortschritt als eine Art Ersatzreligion, oder etwa als oberflächliche Verschleierung, die das Wesen des Lebens verkennt. 

Denn 'Fortschritt' heißt nicht gleich Verbesserung des Menschen, und Nietzsche stand dem modernen Begriff des Fortschritts allgemein skeptisch gegenüber. Er lehnte lineare Verbesserungen ab, und forderte statt einer quantitativen oder gesellschaftlichen Verbesserung eine qualitative ‚Steigerung‘ des Lebens und eine Umwertung aller Werte: „Nicht fort, sondern hinauf!“

Verbesserung selbst darf keine performante, dem 'Herdentrieb' folgende Tätigkeit sein, die ohne Ziel zum Selbstzweck wird. Wahre Verbesserung ist der Wille, stärker zu werden, Herausforderungen anzunehmen und das Leben zu bejahen. Nietzsche lehnte herkömmliche, moralisch geprägte Konzepte von 'Verbesserung' (insbesondere durch Religion) als Schwächung des Lebens ab. Er propagierte stattdessen Selbstüberwindung und -steigerung im Sinne des „Willens zur Macht“. Verbesserung bedeutet für ihn die Schaffung eigener Werte, das Kultivieren des „Chaos“ im Inneren und das Streben nach persönlicher Exzellenz. 

Was also können wir davon für die Agilität mitnehmen? Nietzsche hätte wahrscheinlich ein Problem mit dem „Ritual“ der Retrospektive gehabt. Als Säule von Scrum ist Reflektion und kontinuierliche Verbesserung einer der Grundpfeiler des agilen Denkens. Als Entwickler jedoch kann es einem durchaus so vorkommen, als wünsche man sich ein Art Überentwickler--übermenschliche Anstrengungen, alles zu können, alles zu lernen, motiviert durch Herausforderungen und kurzfristige Planänderungen zu gehen. In der Praxis ist das nicht häufig zu finden. Ein Frontendler kann nicht innerhalb von ein-zwei Sprints DevOps lernen, um eine Wissenslücke im Team zu füllen. Es braucht Zeit, bis ein Backendler Testfälle schreiben kann. Und die Tester verstehen den Code vielleicht genug, um ihn zu prüfen; könnten aber keine Frontend-Aufgaben übernehmen, um das Sprintziel zu schaffen.

Die Gefahr besteht, den Entwickler als „nicht motiviert genug“ abzustempeln. Man arbeitet schließlich in einem Framework, das das Lernen befürwortet; man ist ‚agil‘ und braucht daher Flexibilität von den Entwicklern. Was es aber wirklich heißt, ist ein enormer Druck, alles können zu müssen; und es stellt sich die Frage: 

Gibt es diese Teams voll Überentwickler wirklich? Können wir überhaupt dahin kommen, und ist das Streben nach kontinuierlicher Verbesserung der beste Weg dahin?

Es ist nicht genug zu sagen „wir arbeiten agil“, und zu erwarten, dass sich die Leute selbstorganisiert aufstellen und alle Hürden mit Motivation zu meistern. Die Retrospektive ist eins der agilen Werkzeuge, die uns an die Hand gegeben werden und für einen Stimmungscheck im Team durchaus sehr hilfreich sind. Doch die Plattform alleine reicht dazu nicht aus: Die Teammitglieder müssen bereit dazu sein, sich zu reflektieren. Es braucht  Mut und Ehrlichkeit sich selbst gegenüber zu sagen, wenn etwas schiefläuft. Es braucht  Durchhaltevermögen, die erkorenen Maßnahmen umzusetzen und schlechte Muster zu brechen. Es kann sein, dass Entwickler auf eigene, sich eingeschlichene Bequemlichkeiten verzichten müssen, weil das Projekt (und der Kunde) im Vorrang steht. Diese psychologischen Grundlagen müssen gelegt werden, um das Format erfolgreich durchzuführen. Das Team braucht hier vor allem Sicherheit, eine gute Fehlerkultur und den Willen, sich aus sich selbst heraus zu verbessern. 

Es steht und fällt mit dem Willen zur Selbstentwicklung

Auf der anderen Seite haben wir vielleicht ein gut funktionierendes, eingespieltes Team, und fragen trotzdem: „Was können wir anders machen, damit wir noch besser werden?“ Eine Retro muss schließlich Maßnahmen erzeugen, oder?

Nietzsche würde fragen, „wann ist gut 'genug'?“ Wenn wir nach kontinuierlicher Verbesserung streben, gibt es überhaupt ein Ende? 

Irgendwann wird die Luft auf dem Weg nach oben dünn. Retros setzen schnell das Signal: Wir müssen uns immer verbessern. Wir müssen uns immer optimieren. Wir müssen immer schneller werden. Der permanente Verbesserungszwang läuft in die Gefahr, ein weiterer Druck zu werden, von dem man sich weg-verbessern möchte.

Kontinuierliche Verbesserung darf nicht zum Selbstzweck werden. Retros durchzuführen bedeutet nicht automatisch eine Leistungssteigerung. Der Herdentrieb, den Nietzsche stark kritisierte, kommt auch hier ins Spiel wenn die Plattform zur Reflektion ein „Ritual“ wird, was runtergebetet wird und welches man absitzen muss, weil alle anderen es auch tun. 

Warum produzieren viele Retros eine Menge Maßnahmen, aber keine echte Veränderung? Wir optimieren die Prozesse, aber was wirklich fehlt, ist die Sinnhaftigkeit und der Wille, besser zu werden. Es droht, eine performante Verbesserung zu werden--kein Ziel mehr, sondern Gewohnheit. Und Gewohnheiten sind selten revolutionär. Performanz erreicht keinen echten Change.

Es gibt einen Unterschied zwischen Stillstand und bewusster Stabilität. Ein Team darf sagen, „es läuft gerade gut. Wir sind stabil und müssen nichts verändern“. Jedes System braucht Ruhephasen, um sich zu setzen. Eine gute Zusammenarbeit braucht Zeit, um sich zu entwicklen. Nicht jede Iteration muss Veränderung bringen. Das ist der Gegenpol zum blinden Fortschritts- und Optimierungsdrang, den Nietzsche kritisierte. Wenn Verbesserung kein klares Ziel hat, ist es ritualisierter Druck, und ein ritualisiertes Verhalten bringt nichts, wenn es einfach abgesessen wird.

Denn viele Teams reflektieren zwar formal, aber eben nicht wirksam. Man spricht über Symptome, aber nicht über die eigentlichen Ursachen. Man formuliert Maßnahmen, die aber nichts verändern. 

Wenn ich eine Axt im Kopf habe, bringt Aspirin mich eben nur so weit. Das Problem ist nicht, dass sich ein Team nicht ständig verbessert. Das Problem ist, wenn es so tut, als ob--ohne echte Wirkung. Das Streben nach kontinuierlich erzwungener Verbesserung ist das Problem.

Beispiele von unwirksamer Reflektion, die wahrscheinlich jeder aus der Praxis kennt, sind: „Wir sollten besser/ mehr/ schneller kommunizieren“, „Im Refinement ist aber noch viel unklar geblieben“, „wir hatten wirklich viele Merge-Konflikte“--und in der nächsten Retro sind es wieder genau dieselben Themen. Und wieder. Und wieder. Und wieder. Wir erstellen Maßnahmen und vollenden das Ritual, aber Verbesserung ist das nicht. Nimmt man dagegen das Team, das bereits gut eingespielt ist und sagt, „Unsere Zusammenarbeit funktioniert gut wie es ist“, bringt das zwar auch keine Veränderung, ist aber sehr viel wirksamer als eine Scharade der Verbesserung.

Manche wünschen sich, Scrum als Blaupause für funktionierende Teams zu nutzen, eine Art one-size-fits-all. Das Framework verspricht viel, und inspect&adapt verspricht Optimierung. Hier stößt die Theorie aber schnell auf die Praxis, und was für ein Team funktioniert, hilft dem nächsten nicht. Man kann den menschlichen Faktor, aka die Entwickler, nicht wegrationalisieren und hinter KPIs und Burndown Charts verstecken. 

Wir müssen den Menschen zum Fokus machen und dort anfangen, wo wahre Veränderung entsteht: Beim eigenen Willen zur Selbststeigerung. 

Mehr Druck erzeugt langfristig keine bessere Leistung. Die Erwartungshaltung, dass jeden Sprint die Velocity steigt, wenn nur noch eine Maßnahme mehr ergriffen wird, ist nicht realistisch. Wenn wir Überentwickler wollen, dann kommen wir am ehesten so dahin, wie der Mensch zu Nietzsches Übermensch wird: Mit echter Leidenschaft für die Sache, gelebter Kreativität, der Freiheit, sich entfalten zu dürfen, und etwas Chaos, das in richtige Bahnen gelenkt wird.

Nietzsches Übermensch kann schnell missverstanden werden

 

Wir kommen dabei dem ursprünglichen Ziel von Agilität, Entwicklern mehr Freiraum zum eigenständigen handeln zu geben, wieder näher. Ritualisiertes Verhalten und Muster, die nicht mehr hinterfragt werden oder den Sinn verloren haben, sind keine Anleitung zur Leistungssteigerung. Alle Menschen sind intrinsisch hermeneutisch, und Sinnhaftigkeit darf auch in der agilen Welt nicht zu kurz kommen. Man möchte dem Chaos vorbeugen indem man aus Gesprächen Rituale macht, aber auch da erinnert uns Nietzsche: Ohne Chaos kann kein tanzender Stern geboren werden--und wahrscheinlich auch keine Software.