Gescheit scheitern – gescheit? (Teil 1)

Über Fehler, Kultur und Defekte

Warum die Frage schon systemisch ist

Systemisch? Die agilen Methoden sind quer über den Besprechungstisch (der SW-Entwicklung) hinaus ‘gewabert’ und verbreiten sich in anderen Bereichen der Welt. (Verkrustetes) Silo-Denken wird weg-postuliert (im Versuch zaghaft bis stringent vehement) – mal sinnvoll, mal wird die Existenz als solches geleugnet oder ich muss als Agilist genaue Fragen stellen, um eine an mich herangetragene Anforderung in meiner eigenen Landkarte im Kopf richtig zu verorten. Oft wird “gescheitert” gleich hinterher geworfen. Und dem ist so nicht so. Allem ist gemeinsam: Das genaue hin sehen hilft – nicht so wie hier in dem Bild.

Selten wird der Begriff “systemisch” ins Spiel gebracht – bis ich diesen nenne und mit Substanz versuche, anzureichern. Ich habe mich bewusst, auch mit Shu-Ha-Ri, einer Lerntechnik (weiter unten), befasst. Agile Methoden sind Modelle eines Soll-Prozesses für komplexe Systeme. Gescheit scheitern inbegriffen. Theoretisch folgen diese demnach der systemischen Weltsicht. Hier höre ich den ersten Aufschrei: “Prozess – igitt!” Und doch, es ist so wie es ist: Später dazu mehr …

Geile Software, Lösungen mit Mehrwert, aber auch Märkte und die darin befindlichen Menschen sind erst kompliziert, später komplex. Die Iteration, ein gedankliches Konstrukt, mit dem ich seit gefühlt um die 15 Jahre unterwegs bin, hat sich als probates Mittel erwiesen, um in diesen Systemen strategisch zu handeln. Mit Erfahrung und Haltung, UM und hinter dem Ausdruck “systemisch” werden Rahmen, Bedingungen und Möglichkeiten des agilen Vorgehens erst bewusst – und dann erst (also später) transparent.

Der systemische Ansatz fußt auf einer grundlegenden Überzeugung, der ich folge. Jede Person konstruiert sich ihre eigene Wirklichkeit (= Konstruktivismus). Diese(r) ist nicht mehr diskutabel, sondern lern- und hirnwissenschaftlich bewiesen. Dieser Mechanismus ist auch über die Individualebene des Einzelnen hinaus – also innerhalb von Gruppen gut zu sehen. Denken Sie an Arbeitsgruppen oder Meetings, wo nicht das beste, sondern oft das verträglichste Ergebnis (sagen wir: der kleinste, gemeinsame Teiler) präsentiert wird – na, klingelt da etwas? Falls nicht, hilft ein Blick in Richtung “Schwarmdummheit” – oder -Intelligenz.

Es wird ein gemeinschaftliches und einheitliches Verständnis ‘konstruiert’, in dem beispielsweise soziale Regeln aufgestellt werden. Diese soll(t)en dann allen Beteiligten gefallen. Es wird eine Mehrheitsmeinung gelebt und auf die gute Demokratie verwiesen. Andere, bessere oder effektivere Lösungen – verworfen? Die Spitze des Eisberges ist einerseits das Wissen darum und andererseits das konstruierte Unvermögen, es im Gesamtkontext zu plakatieren. An dieser Stelle greift die Erkenntnis, die auch schon an anderen Stellen publiziert wurde, dass die Qualität des Outputs mit einem quantitativen Anstieg der Menge aller Beteiligten – sinkt.

Aus- und Wechselwirkungen greifen

Jetzt sind wir bei systemischer Agilität. So kann je nach Kontext das gleiche Verhalten innerhalb und / oder außerhalb von Systemen sehr verschiedene Reaktionen nach sich ziehen. Zwischen-Fazit: Deswegen lohnt sich ein sehr genauer Blick auf das jeweilige System, und nicht nur das, sondern auch auf die Syteme links und rechts (oder oben und unten, je nach Sichtweise) davon. Die Ignoranz dessen kann verheerende Folgen haben und somit erhält diee Eingangsfrage “gescheit scheitern” eine weitere Bedeutung.

An mehreren Stellen geben sich agil und systemisch die Hand, genau hinsehen und hinhören ist dabei sehr sinnvoll und im Ergebnis zielführend. Jede Handlung, ganz gleich ob spontan, erprobt oder noch nie dagewesen, hat Folgen (es gilt das Ursache-Wirkung Prinzip, welches gerne in sich verwechselt wird), die man nur bedingt voraus sehen kann. Deshalb sind Planungen im agilen Kontext nur für einen gewissen Zeitraum und mit einer gewissen Heuristik möglich.

Agil ist nicht besser planen, sondern die Planungszeiträume soweit (radikal) zu verkürzen, dass in der Planung (möglichst) valide, belastbare und überschaubare Ergebnisse entstehen (Na, gemerkt?: Die Iteration) Es ist durchaus gewünscht, hierzu auch die Statistik zu befragen. Warum? Und damit sind wir wieder bei der Einleitung: Jede Statistik, insbesondere Verteilungskurven, die mit präzisen Parametern gefahren wurde, zeigt die Anteile an bereits geschehenen Ergebnissen (im Kontext), die in der Vergangenheit gescheitert sind. Wie dumm oder ignorant ist es dann, diese innerhalb des eigenen Konstruktivismus auszublenden? Harter Tobak – es nützt aber nichts (was anderes gibt es nicht …).

Kleinteilige Prognosen – helfen

Diese Prognose sind Aussichten, also Annahmen innerhalb des Systems, um dieses zu beschreiben und handlungsfähig zu bleiben. Je weiter diese Prognosen in der Zukunft legen, desto unschärfer werden diese zwangsläufig. Das ist nicht neu – Neu ist ist steigende Volatilität (Bewegungen, Unvorhersehbarkeit) aller aktuellen Entwicklungen (aha: Systeme), die wir seit einigen Jahren nicht nur sehen, sondern auch (selbst) spüren.

Bleiben wir z.B. bei Scrum: PO und Entwickler – sofern sie keinen Kundenkontakt haben (Achtung: Mit Kunde ist hier der wirkliche Endkunde, also der direkter Nutzniesser des Produktes gemeint, nicht (irgendwelche) Stakeholder!) – bilden Annahmen über die Wirklichkeitskonstruktion der Kunden, um deren Anforderungen abzubilden.

griffige Relationen herstellen

Selbst wenn es valide, realistische Daten zur Nutzung der Software oder den Bedürfnissen der Endkunden gibt, sind sie – bitte was? Weniger wahr oder mehr interpretationsbedürftig? Und bei einer Interpretation ist der Konstruktivismus schon wieder der (leise, aber mächtige) Ratgeber. Schnell konstruiert ist besser als aufwändig recherchiert, gell? Relationen, Aufbau und, schon wieder: Ursache und Wirkung(!) können nicht präzise prognostiziert werden, es können nur Annahmen getroffen und diese durch Ausprobieren, Beobachtung und Analyse überprüft werden:

Das ist jetzt wichtig: Schritt für Schritt die Folgen beobachten und (weise) darauf reagieren. Je kleiner die Schritte, desto valider das Ergebnis genau dieses kleinen Schrittes. Also nichts anderes als das „build – measure – learn“ der agilen Produktentwicklung. Ein Systemiker würde das dann „Aktions-Reaktion-Schleife“ nennen. Mir persönlich gefällt die Stelle mit ‘messen’ und ‘daraus lernen’ am besten.

---