Störe meine Kreise nicht!

Was hat Archimedes, der Mathematiker und Naturwissenschaftler der griechischen Antike, mit Softwareentwicklung zu tun? Er wollte sich im Jahr 212 v. Chr. nur ungestört seinen geometrischen Analysen widmen, als er von römischen Soldaten festgenommen werden sollte. Der Legende nach wurden diese über seine Reaktion – „Störe meine Kreise nicht!“ – so wütend, dass sie ihn gleich an Ort und Stelle erschlugen.Der negative Effekt von Störungen bei unserer Arbeit ist wohl jedem bekannt, auch wenn wir heutzutage etwas kultivierter miteinander umgehen. Mir geht es hier jedoch um den Nutzen von Regelkreisen bei der Bewältigung komplexer Aufgaben. Auch diese Kreise sollten keinesfalls gestört werden.

Im dunklen Wald

Unsere Arbeit in der Softwareentwicklung ist fast immer kompliziert und meist komplex. Damit ist sie kaum vorab planbar [1]. Was das bedeutet, möchte ich über eine Metapher erläutern.Stellen wir uns vor, wir befinden uns mitten im Wald, es ist Nacht und es regnet. Wir wissen, dass ein schützendes Haus etwa einen Kilometer vor uns liegt. Leider gibt es keinen Pfad, dem wir folgen können. Wir müssen den Weg selbst finden und gehen in die Richtung, in der wir das Haus vermuten.Bei jedem Schritt meldet uns unser Körper, was sich um uns herum gerade befindet. Wurzeln und Äste liegen uns im Weg, die wir im Dunkeln kaum rechtzeitig erkennen können. Meist spüren wir sie erst, wenn wir auf sie treten oder gegen sie laufen. Auch tief hängende Äste bereiten uns Probleme, und wir tasten uns langsam Schritt für Schritt voran.Zwischendurch bleiben wir immer wieder kurz stehen und blicken um uns herum in die Dunkelheit. Von Zeit zu Zeit nehmen wir ein leichtes Funkeln zwischen den Bäumen war – das muss das gesuchte Haus sein. Die Lichter brennen hell im Haus und wir richten unseren Weg bei jedem Halt wieder neu aus. Doch die Hindernisse auf unserem Weg bringen uns immer wieder vom Ziel ab, sodass wir uns regelmäßig neu orientieren und auf unser Ziel ausrichten.Unser Algorithmus aus vorsichtigem Vorantasten und Umgehen von Hindernissen gepaart mit der regelmäßigen Überprüfung unseres Weges auf das Ziel hin führt uns letztendlich nach 20 Minuten zum Ziel. Endlich sind wir im Trockenen und Warmen angekommen.Wenn wir jetzt noch ein Haus hätten, das sich hin und her bewegt, während wir darauf zuwandern, hätten wir eine schöne Metapher für die meisten Softwareprojekte. Doch unser Algorithmus aus zwei Regelkreisen bewährt sich im dunklen Wald genauso wie vor dem Rechner.

Regelkreise

Regelkreise sind das zentrale Element in der Steuerung von Systemen. Ein technischer Regelkreis steuert ein System, das durch eine äußere Störgröße Veränderungen ausgesetzt ist, über die Beobachtung von Abweichungen gegenüber einem Sollwert. Regelkreise gibt es nicht nur in technischen, sondern­ auch in biologischen, psychischen und sozialen Systemen. Allgemein ausgedrückt besteht ein Regelkreis aus drei Schritten, die immer wieder zyklisch durchlaufen werden (Bild 1):

• Handlung: eine Interaktion am zu regelnden System
• Reaktion: das zu regelnde System beobachten
• Analysieren: aus dem Verhalten des zu regelnden Systems lernen

Neben dem zu steuernden System beinhaltet ein Regelkreis implizit auch stets ein steuerndes System. Bei einer Heizungssteuerung ist das offensichtlich. Das Steuerungssystem ist über Sensoren und Antriebselemente (Aktoren) sowohl mit der Heizungsanlage selbst wie auch mit dem zu beheizenden System als auch mit dessen Umweltsystem gekoppelt. Im Arbeitsumfeld verwischt diese klare Sicht jedoch schnell. Daher betrachten wir im Folgenden das Beobachten in einem sozialen System etwas genauer.

Beobachten

Nach Niklas Luhmann gibt es grundsätzlich zwei Möglichkeiten, etwas zu beobachten. Er bezeichnet das als Beobachten erster und zweiter Ordnung [2]. Beim Beobachten erster Ordnung beobachten wir im Rahmen von direkten Regelkreisen ein System. Ein Beispiel ist ein Softwareentwickler, der im Rahmen eines agilen Entwicklungsprozesses mehrmals pro Tag die Ergebnisse automatisierter Tests als Rückmeldung zu seiner Entwicklungsarbeit erhält.Beim Beobachten zweiter Ordnung beobachten wir im Rahmen von indirekten Regelkreisen das Beobachten erster Ordnung. Im obigen Beispiel hätten wir hier eine Beobachtung zweiter Ordnung durch einen Coach, der ein agiles Team bei seiner Entwicklung begleitet und den Entwicklungsprozess hinterfragt, um ihn regelmäßig gemeinsam mit dem Team weiterzuentwickeln.Nach diesem Muster lässt sich auch ein Beobachten dritter oder weiterer höherer Ordnungen definieren. Im obigen Beispiel erfolgt eine Beobachtung dritter Ordnung durch einen weiteren, besonders erfahrenen Coach, der im Rahmen einer Supervision die Arbeit des Coaches aus der Beobachtung zweiter Ordnung betrachtet.Werfen wir einen genaueren Blick auf das Beobachten selbst. Im konstruktivistischen Ansatz, der auf Ernst von Glasersfeld und Heinz von Foerster zurückgeht und den zum Beispiel Gregory Bateson, Paul Watzlawick und Niklas Luhmann verfolgen, können wir unsere Umwelt nicht direkt beobachten, sondern nur als „Referenz“ in uns selbst. Dazu konstruieren wir ein geistiges Bild unserer Umwelt im Kopf. Beobachten bedeutet daher, zu vergleichen oder zu unterscheiden.­ Wir vergleichen unser Bild von uns selbst, unsere „Selbstreferenz“, mit dem Bild unserer Umwelt, der „Fremdreferenz“.Beobachten bedeutet also, Unterscheidungen zu treffen. Diese entstehen im Beobachter und kommen nicht aus der beobachteten Realität. So wie wir ein Abbild der Realität in unserem Kopf konstruieren, fügen wir auch unsere Unterscheidungen hinzu. Unsere Erkenntnisse sind also konstruiert. Damit ist der Beobachter auch Teil des beobachteten Systems und kann ebenso wenig alles neutral beobachten [2].Dieser theoretische Exkurs führt uns zu wichtigen Konsequenzen für unsere Arbeit. Wir können nur beobachten, worauf wir unseren Fokus gesetzt haben. Im Gegenzug haben wir bei einer Beobachtung stets einen blinden Fleck beziehungsweise eine Latenz. Latenzen können wir nur durch Beobachtungen zweiter Ordnung erkennen.An einem kurzen Beispiel sehen wir schnell, was es mit Fokus und blindem Fleck auf sich hat. In diesem Artikel geht es um die Konsequenzen von Komplexität in unserem Arbeitsumfeld und wie wir angemessen damit umgehen können. Es findet keine Kritik an den gesellschaftlichen Aspekten und Konsequenzen in diesem Zusammenhang statt. Wir setzen sie als Rahmenbedingung, bewerten sie aber nicht weiter. Dieser Fokus erfolgte bewusst, obwohl oder vielleicht gerade weil Komplexität für viele auch ein emotionales Thema ist.An diesem Beispiel wird deutlich: Wir beobachten stets einen bestimmten Aspekt und setzen den Fokus darauf. Alles andere blenden wir aus. Diese Unterscheidung ist eine Grundeigenschaft des Beobachtens.

Sofortige Rückkopplung und regelmäßige Kalibrierung

Wenn wir die beiden Themen „Regelkreise“ und „Beobachten“ im Zusammenhang betrachten, kommen wir zu zwei ­Arten von Regelkreisen. Nach Gregory Bateson unterscheiden wir Rückkopplung und Kalibrierung [3]. Bei einer Rückkopplung beobachten wir über direkte Regelkreise innerhalb des betrachteten Systems. Mit einer Kalibrierung beobachten wir über indirekte Regelkreise von außerhalb des betrachteten SystemsEine Rückkopplung erfolgt zeitnah und direkt. Norbert Wiener hat in seinem Grundlagenwerk „Kybernetik“ bereits 1948 anhand von Krankheitsbildern gezeigt, welche Bedeutung Rückkopplung und Kalibrierung im menschlichen Körper haben und was passiert, wenn sie gestört sind [4]. Im beruflichen Kontext erhalten wir direkte Rückmeldung über den Fortschritt unserer Arbeit. In der Softwareentwicklung haben die Entwickler zum Beispiel regelmäßig mehrmals am Tag eine direkte Rückmeldung über ihre Arbeit durch selbst gestartete oder im Hintergrund laufende automatisierte Tests.Über Kalibrierungen betrachten wir einen Prozess, der über Rückkopplungen gesteuert wird. Wir versuchen, Veränderungen im Prozess auszuprobieren und nach bestimmter Zeit zu bewerten, um so den Prozess zu verbessern. Regelmäßige Retrospektiven sind ein Beispiel dafür.Fassen wir für die Betrachtung von Regelkreisen zusammen: Rückkopplungen sind Beobachtungen erster Ordnung, die innerhalb einer Softwareentwicklung ablaufen. Wir beobachten dabei die Ergebnisse unserer Arbeit in kurzen Zyklen, idealerweise mehrfach am Tag. Über regelmäßige Kalibrierungen beobachten wir den Prozess und versuchen diesen schrittweise auf ein Ziel hin zu verbessern.Es handelt sich daher um eine Beobachtung zweifacher Ordnung. Beide Arten von Rückkopplungen sind elementar bei der Steuerung komplexer Systeme beziehungsweise Projekte, da wir das Verhalten komplexer Systeme nicht vorhersagen können.

Retrospektive Kohärenz: Komplexe Systeme steuern

Wenn wir das Verhalten eines komplexen Systems nicht vorhersagen können, lässt es sich auch nicht mit traditionellen Konzepten steuern. Sich hinzusetzen, einen Plan zu schmieden und den dann strikt einzuhalten, verspricht kaum Erfolg. „Kein Plan überlebt die erste Feindberührung!“, wusste bereits Feldmarschall Graf von Moltke. Oder weniger martialisch: „Wenn du Gott zum Lachen bringen willst, mache einen Plan!“ – ein Ausspruch, der dem französischen Philosophen Blaise Pascal zugeschrieben wird.Wir können bei einem komplexen System nur im Nachhinein erkennen, was wie funktioniert hat oder eben nicht. Solche Erkenntnisse können nur rückblickend gewonnen werden. Das Verhalten eines komplexen Systems wird erst im Rückblick kohärent, also in sich zusammenhängend klar. Diesen Weg des Erkenntnisgewinns bezeichnet man daher als retrospektive Kohärenz [5].Für die Optimierung von Abläufen oder andere Veränderungen in komplexen Systemen, wie zum Beispiel die Durchführung eines Softwareentwicklungsprojekts, ist der rückblickende Erkenntnisgewinn die einzige Möglichkeit, Erklärungen und Zusammenhänge zu erkennen. Das hat Konsequenzen für die Strukturierung des Projekts. Daraus lassen sich drei Dinge ableiten:1. Wir benötigen in sehr kurzen Abständen Regelkreise in Form von Rückkopplungen, um unsere tägliche Arbeit steuern zu können. In der Softwareentwicklung liefern Tests diese Rückmeldung. Ein testgetriebenes Vorgehen mit automatisierten Tests ist daher unabdingbar bei der Umsetzung komplexer Aufgaben.2. Wir benötigen Kalibrierungen, um ein komplexes Projekt zu steuern. In regelmäßigen Retrospektiven alle zwei bis vier Wochen betrachten wir unsere Arbeitsweise und Prozesse beziehungsweise Workflows und versuchen, über kleine Anpassungen und Veränderungen die Entwicklung effektiver zu machen.3. Wir können bei der Bearbeitung komplexer Aufgaben kaum Fehler machen. Es sei denn, dass wir entgegen besseren möglichen Wissens gehandelt hätten.Der letzte Punkt klingt spannend: Da wir in komplexen Projekten keine klaren Vorhersagen treffen können, greift der traditionelle Fehlerbegriff hier kaum. Konstruktiver ist es, von notwendigen Lernschleifen im Sinne der retrospektiven Kohärenz zu sprechen. Ein Fehler ist es aus dieser Sichtweise eher, einer entsprechenden Aufgabe ihre Komplexität abzusprechen oder diese grob zu unterschätzen.

Test Driven Development

Wie sieht das konkret aus? Das testgetriebene Entwickeln nach Kent Beck (TDD – Test Driven Development) ist ein Paradebeispiel für kurze, wirkungsvolle Rückkopplungen [6]. Die Vorgehensweise ist bereits mehr als 15 Jahre alt und in ihrer Wirkung vielfach bewiesen, aber leider immer noch nicht weit genug verbreitet, wie Probleme beim Refactoring oder bei der Erweiterung bestehender Software regelmäßig beweisen. Der Ablauf ist in Bild 2 dargestellt. Könner benötigen für einen Durchlauf nur 15 bis 20 Minuten. Zwei bis vier Durchläufe am Tag sind das absolute Minimum für Einsteiger.

Was tun wir, wenn es Probleme gibt, so vorzugehen? Wie wir gesehen haben, ist der Wert der Rückkopplungen essenziell. Daher verändern wir unser Umfeld schrittweise so, dass ein solches Arbeiten möglich ist. Häufig ist die Zerlegung der Arbeit in entsprechend kleine Schritte zu Beginn schwierig. Auch kann das Entwicklungsumfeld zu langsam für ein häufiges Feedback sein oder eine Test Stage für gemeinsame, integrierte Systemtests für die Teamarbeit fehlen.Diese Probleme sind in der Retrospektive zu identifizieren und möglichst schnell zu lösen. Auf keinen Fall dienen diese Probleme als Ausrede dafür, auf aussagekräftige Rückkopplung durch testgetriebenes Vorgehen zu verzichten. Ein agiler Coach oder der Scrum Master ist für diesen Lösungsprozess verantwortlich. Daran erkennen wir, wie Rückkopplung und Kalibrierung miteinander verwoben sind.

Iteratives Vorgehen mit Retrospektiven

Die Kalibrierungen beziehungsweise Retrospektiven finden regelmäßig statt. Am einfachsten ist das im Rahmen eines iterativen Vorgehens. Eine Iteration ist ein festes Prüfraster, an dem wir die Entwicklung kurz stoppen und darauf schauen, wie wir arbeiten. Anhand der Projektziele können wir Probleme und Lösungsideen bewerten und priorisieren. Am Ende jeder Iteration findet also eine Kalibrierung unserer Vorgehensweise in Bezug auf die Ziele des Projekts in Form einer Retrospektive statt (Bild 3).

Dieses Bild beschreibt ganz gut das Vorgehen in der Wald-Metapher am Anfang. Diese Vorgehensweise ist die aus der Systemtheorie bekannte Form des Vorgehens bei komplexen Vorhaben. Daher genießen die Rückkopplung und die Kalibrierung so eine hohe Priorität in agilen Vorgehensweisen wie zum Beispiel Scrum.Was unternehmen wir, wenn die Retrospektive zum Ritual verkommen ist und als Zeitverschwendung wahrgenommen wird? Der einfache Weg, die Retrospektiven zu reduzieren und sie zum Beispiel nur noch jede zweite oder dritte Iteration durchzuführen oder sie gar ganz abzuschaffen, stellt keine Lösung dar, da uns so die Kalibrierung abhandenkommt. Also gilt es, die Retrospektive wieder wertvoller für die Beteiligten zu gestalten: Wir beobachten in der dritten Ordnung, eventuell mit einem Coach als Supervisor, um zu erkennen, was wir verändern möchten, und probieren es aus.

Indikatoren

Wie erkennen wir, ob sich durch eine Veränderung eine Verbesserung eingestellt hat? Dafür benötigen wir Indikatoren. In agilen Projekten kann hierfür zum Beispiel die Velocity herangezogen werden (Bild 4). Die Velocity, also die Anzahl der fertig umgesetzten Tasks oder Story Points pro Iteration, sollte dabei zuerst ausreichend konstant gehalten werden. Das ist ein Hinweis darauf, dass die Prozesse stabil laufen. Erst dann probieren wir Veränderungen aus.

Dabei kann es zu Beginn zu einer Verringerung der Velocity kommen, die in der Umstellung und dem damit verbundenen Lernen begründet ist. Wir warten daher bis zu drei Iterationen ab, damit sich das Team an die Veränderung gewöhnen kann. Erst danach erfolgt die Bewertung der Veränderung. In den Retrospektiven kann dies genau analysiert werden. So bleiben die Retrospektiven wirksam und wir lernen bewusster, wie sich die komplexen Zusammenhänge verhalten.

Fazit

Bei der Entwicklung komplexer Softwareprojekte hilft uns die Systemtheorie, eine geeignete Vorgehensweise zu finden. Die Implementierung von Regelkreisen ist der Kern des Lösungsansatzes, da sich komplexe Vorhaben (anders als „nur“ komplizierte) nicht vorab ausreichend planen lassen. Dabei sind zwei Arten von Regelkreisen essenziell.Die Rückkopplung gibt uns sofort Rückmeldung über unsere Arbeit und die Arbeitsergebnisse. So können wir aktuell anstehende Probleme sofort erkennen und beseitigen.Während die Rückkopplung innerhalb unserer Entwicklungsarbeit abläuft, betrachten wir über die Retrospektive, wie wir arbeiten. Dieser Regelkreis implementiert eine regelmäßige Kalibrierung unserer Arbeitsweise und Workflows in Bezug auf das Projektziel auf Basis von Indikatoren.

Fussnoten

1. Uwe Vigenschow, APM – Agiles Projektmanagement, dpunkt.verlag, 2015,
2. Margot Berghaus, Luhmann leicht gemacht, Böhlau, 3. Auflage, 2011,
3. Gregory Bateson, Geist und Natur – eine notwendige Einheit, Suhrkamp Taschenbuch Wissenschaft, 1987,
4. Norbert Wiener, Kybernetik – Regelung und Nachrichtenübertragung im Lebewesen und in der Maschine, Econ, 2. Auflage, 1963,
5. Uwe Vigenschow, Björn Schneider, Ines Meyrose, Soft Skills für IT-Führungskräfte und Projektleiter – ­Softwareentwickler führen und coachen, Hochleistungsteams aufbauen, dpunkt.verlag, 3. Auflage, 2016,
6. Kent Beck, Test Driven Development by Example, ­Addison-Wesley, 2002,