Geschichten, Modelle, Plots

Warum wir reden

So lange ich im Geschäft bin, hat im regelmäßigen drei- bis fünf-Jahresrhythmus ein neues Modell aus dem agilen Kontext zur ex ante Lösung planerischer, technischer und organisatorischer Lösungen Konjunktur. Scrum, Lean Kanban, Responsibility Process, Agile Fluency, Spotify Model, Team Topologies, Canvas aller Art - die Liste kann ich inzwischen beliebig verlängern (vermutlich ist das eine Funktion meines Alters).

Die über den Tag hinaus tragfähigen Ansätze haben eine längere Geschichte, sind in der Praxis verankert und bieten Raum zur Auseinandersetzung. Alle sind in sich irgendwo bestechend und logisch. Alle sind überaus detailliert und nach Rezept anwendbar. Und alle versprechen die finale Antwort auf die von den Autor:innen erlebten beschriebenen Herausforderungen.

Ganz klar: Jedes Konzept hat eigene Aspekte und ich möchte die Auseinandersetzung mit jedem einzelnen nicht missen. Und für uns, die wir die Mühen der Ebene in Auftraggebenden-Dienstleistendenkonstellationen durchschreiten, ist das jedes Mal ein Blick ins gelobte Land.

Vor allem für unsere jungen Kolleg:innen bleibt es dann leider meistens bei dieser Verheißung, denn die Silver Bullet findet sich in den beschriebenen Ansätzen nicht. Vielleicht liegt es daran, dass wir wenige Greenfieldprojekte machen und das reale Setting sich immer nur in Teilen mit den beschriebenen Blaupausen deckt. In jedem Fall sind für unsere Teams die Anpassungsaufwände für die Implementierung der Modelle groß und scheinen nur zu oft an uns, den Verhältnissen oder dem Gegenüber zu scheitern.

Mir scheint das etwas zu kurz gegriffen. Aus einer Diskussion mit dem Blick auf die Entstehungslogik und die damit verbundene Reichweite von Modellen, hier ein paar Gedanken in aller Kürze.

1. Geschichten: Teams lösen Aufgaben

Softwareentwicklung ist oft genug mit einer Expedition in unbekanntes Terrain vergleichbar. Die Aufgaben zu lösen verlangt Umgang mit Unsicherheit. Technische und prozessuale Innovation, ein dynamischer Markt für Lösungen und Produkte machen ein "more of the same" zur seltenen Ausnahme.

Entwickelnde Teams arbeiten deshalb mit Versuch und Irrtum, sie bewegen sich in einer Welt, in der viele Dinge gleichzeitig passieren. Jeder Erfolg (oder Misserfolg) ist nicht monokausal zu erklären oder gar im vorhinein planbar. Ein "best guess" ist das höchste Level erzielbarer Sicherheit. Das "ist so ähnlich wie ..." ist das Modell für die Begrenzung des Problem- und des Lösungsraums.

Eintretende Ereignisse sind immer irgendwie überraschend und verlangen (bei Erfolgen wie auch bei Misserfolgen) nach nachträglicher Erklärung. Man könnte einen soziologischen Lehrsatz für Individuen, für Teams paraphrasieren: "Teams verhalten sich nicht (ex ante) rational, sie rationalisieren ihr Verhalten (ex post)."

Ein Erklärungsversuch: Jedes Team entwickelt ex post Erklärungen für das Erlebte. Mir scheint es dabei nur allzu verständlich, dass die "Erfolge" lieber erzählt, erklärt und zu Recht gefeiert werden. Scheitern und Misserfolg sind ungeliebt - aller "embrace failure" Rhetorik zum Trotz. Die Fragen und Antworten werden innerhalb des Teams und in anderen sozialen Kontexten gestellt: gerade bei Erfolgen. Und immer findet sich ein:e Erzähler:in, der:die allein oder gemeinsam mit anderen sortiert, erklärt, verdichtet und das Erlebte damit teilbar macht.

So entsteht "Success als Story": Teams benennen Elemente und Prozesse, die sie erfolgreich gemacht haben, sie entwickeln eine Sprache für die Erklärung ihrer selbst und ihrer Vergangenheit. Sie beschreiben im Nachhinein, was aus ihrer Sicht geschehen ist. Damit vergemeinschaften sie, was in welcher Reihenfolge sichtbar und erinnert wurde. Und im Erzählen entsteht so die Realität. Im linearen Verlauf der Geschichte entsteht Kausalität aus der Beschreibung. Das Storytelling sorgt damit für Vergewisserung und schafft eine intersubjektive Basis, es dient der Integration neuer Mitglieder und zur Kommunikation jenseits direkter persönlicher Erfahrungen.

Und - das ist der faszinierende Effekt dieser Konstruktionsleistung - die gemeinsame Geschichte eröffnet oft genug die Entwicklung der besseren Lösung für das jeweilige Setting, denn sie kann weitererzählt werden.

Es gibt Indizien für diese lebendigen Geschichten: Sie und ihre einzelnen Elemente gehören dem produzierenden Team. Sie sind nicht kodifiziert und existieren in unterschiedlichen Schattierungen. Sie schillern. Und sie transportieren Staunen und Stolz über den Erfolg des eigenen Tuns. Die Teilnahme an der Expedition ist das einzig wirkliche Merkmal für Glaubwürdigkeit.

Geschichten transportieren Erfahrung: Die Frage beim Bootsverleih lautet: "Wo bist Du schon gesegelt ...?"

2. Modelle: Systeme suchen Rezepte

Die Zuhörer:innen sind nicht nur Individuen und andere Teams, denn Software entwickelnde Teams bewegen sich in ausdifferenzierten Organisationen und Systemen. Es ist simpel: Software entwickelt man ... FÜR oder ... UM, ...., nicht als Selbstzweck.

Soziale Systeme sind klug (oder besser: rational), sie entwickeln Mechanismen, die die Systeme verstetigen und erfolgreich halten (also mindestens das eigene Fortbestehen garantieren sollen). Auf der Ebene der Personen wird diese Aufgabe an Rollen delegiert, die nach Erfolgen versprechenden Mechaniken suchen und diese im System verfügbar machen sollen - eine wichtige Rolle des Managements.

Für diese Kommunikation ist die Chiffre nicht mehr die Geschichte, sondern das Modell. Damit soll es möglich werden, für definierte Settings das ex ante zu beschreiben, was man tun muss, um die erfolgreiche Expedition zu garantieren. Modelle werden in der Welt der angewandten Beratung mit Rezepten verquickt, die die einzelnen Implementierungsschritte enthalten. Rezepte sind generell gültig, man kann sich auf das Ergebnis verlassen und ist von der konkreten Situation unabhängig.

Der Schritt ist gravierend: Die Erzählung des Erfolgs wird in ein Modell umgeformt und mit Rezepten zur Implementierung versehen. Der Kurzschluss: Ein Team oder eine Struktur muss nur entsprechend gestaltet werden und das Eintreten des Erfolges kann erwartet und gemessen werden.

Indiz: Das Modell existiert vom Team losgelöst. Es gehört den Beratenden und wird vom Management angewendet. Es muss (und soll) von den Produzierenden nur implementiert werden. Es entwickelt ein "Eigenleben", eine eigene, erklärungsbedürftige Sprache und von der unmittelbaren Erfahrung losgelöste Zeichen und Markierungen: Zertifikate, Stufen, Scheine.

Modelle transportieren Zutrauen vs. Formalien: Die Geschichte beim Bootsverleih lautet dann "Welche Scheine haben Sie ...?"

3. neuland Plots: Diskurse mit Hilfe von Modellen

Es gibt m. E. eine Brücke zwischen Geschichte und Modell - sie scheint mir der Kern unseres agilen Tuns zu sein. Und ich erlebe sie täglich. Nennen wir diese Brücke zwischen dem unmittelbaren Erleben und der verallgemeinerten Abstraktion versuchshalber einen "Plot".

Es gibt Anknüpfungspunkte: Die ernsthaften und tragfähigen Modelle agiler Softwareentwicklung sind aus der Praxis entwickelt worden. Und jede:r aus der Praxis - Practitioner ist nicht umsonst das Ehrenzeichen in der agilen Berater:innenzunft -, weiß um die Gefahr des Verzichts auf lebendige Geschichten, wenn sich Teams und deren Zusammenarbeit selbst organisieren sollen. Die Kopie von Strukturmerkmalen, das Abhaken von Checklisten und das "working by the book" helfen nur dann, wenn es über die Anwendung des Kanons hinausführt. Wer beim "Griffe kloppen" stehen bleibt, verliert.

Stattdessen wird eine andere Figur kultiviert: "Bei 123 scheint xyz wichtig gewesen zu sein, versucht, ob xyz auch bei Euch wichtig ist ...". Das Gespräch auf dieser Ebene sucht nach einem für das Team verfolgbaren Handlungsstrang, einem Plot. Und hier kann auch ein Modell hilfreich sein, wenn und soweit es die Selbstorganisation des Teams ins Zentrum stellt.

Die neuland Plots aus dem E-Commerce sind vielfältig z. B. Vertikalisierung, Migration, Plattformwechsel, Effizienzsteigerung, neues Geschäftsmodell, Startup, First Mover. Sie lassen sich durch beliebige Bindestrichbezeichnungen erweitern.

Die neuland Plots bieten Aktions- und Rollenmodelle, sie enthalten sozusagen White Label Backlogs und produzieren Awareness für vermutlich eintretende Ereignisse. Sie strukturieren damit zukünftige Situationen thesenhaft vor und erlauben dem Team, sich auf anstehende kognitive Beanspruchungen vorzubereiten.

Das Vergewissern über den Plot lässt sich in drei Fragen zusammenfassen.

1. "Welche Teile der Kundendomäne soll die zu entwickelnde Software bedienen?
2. "Ab wann soll sie in welchem Umfang zur Verfügung stehen?"
3. "Wie lange soll die entwickelte Software im Einsatz sein?"

Um den Plot zu verabreden, müssen wir zudem wissen, wer in der Geschichte mitspielt.

1. Wir müssen die Rollen kennen und - auch das gehört dazu,
2. wir müssen die einzelnen Charaktere kennen und beschreiben - wie in einem Sequel.

Um es ganz deutlich zu sagen: Das ist keine Verschwendung von Zeit. Genau wie die scheinbar zeitfressende qualitätsgetriebene, testgetriebene Entwicklung entsteht hier Handlungsschnelligkeit letztlich durch Gespräch der vielen. Das inhaltsleere Nachvollziehen von Dogmen ist die Verschwendung von Zeit und kognitiver Kapazität, denn sie verhindert nur allzu oft die Selbstorganisation der liefernden Teams.

Wichtig ist: Der neuland Plot ist nicht die Story. Die entwickelt sich dynamisch aus dem Tun. Aus der Reaktion der Beteiligten, aus Veränderungen der Umwelt, aus den parallel laufenden Geschichten im Markt, aus dem Gelernten und neu zu Lernenden und aus der steten Kommunikation zwischen den Handelnden bei uns und unserem jeweiligen Auftraggeber.

Zentral ist Stetigkeit: Wir schreiben nicht nur einmal ein Canvas auf dem initialen Kickoff Workshop, sondern wir machen das immer wieder. Wir besprechen nicht einmal das Big Picture, sondern vergewissern uns regelmäßig und spinnen unser Garn. Wir experimentieren, um neue Lösungen zu entwickeln und sind überzeugt davon.

Und wenn nötig, können wir unseren Anteil an der Geschichte größer oder kleiner machen, wir können sogar den Plot wechseln oder Spin offs aus unserem Hauptplot abzweigen, denn die lebendige Geschichte sind wir alle - und das trägt übrigens auch über Unternehmensgrenzen hinweg.

Einfach ist das nicht, aber so geht das.