Je mehr die agilen Methoden über den Tellerrand der Softwareentwicklung hinaus schwappen und sich in der Welt verbreiten, umso häufiger wird der Begriff "systemisch“ ins Spiel gebracht.
Auch bei leanovate hält der systemische Ansatz Einzug, indem wir uns mit diesem bewusster befassen.
Agile Methoden sind Vorgehensweisen für komplexe Systeme und folgen demnach der systemischen Weltsicht. Anspruchsvolle Software, aber auch Märkte und natürlich Menschen sind komplex. Iteratives Vorgehen erweist sich als bestes Vorgehen, um in diesen Systemen strategisch zu handeln. Mit Wissen um den Begriff und die Haltung hinter dem Ausdruck „systemisch“ werden Bedingungen und Auswirkungen des agilen Vorgehens bewusst.
Eine der grundlegenden Überzeugungen des systemischen Ansatzes ist, dass jede Person sich die eigene Wirklichkeit selbst konstruiert (= Konstruktivismus). Gleichzeitig greift der Mechanismus auch - über die Individualebene hinaus - innerhalb von Gruppen. Hier werden gemeinschaftlich ein einheitliches Verständnis geschaffen und beispielsweise soziale Regeln aufgestellt. So gibt es in einigen Unternehmen die Regel, morgens alle Kollegen mit Handschlag zu begrüßen. Das wird erwartet und gilt als höflich. Wir kennen hier in Berlin wiederum einige Firmen, in denen ein angebotener Handschlag komische Blicke auslösen würde. So kann je nach Kontext das gleiche Verhalten verschiedene Reaktionen nach sich ziehen. Deswegen lohnt sich ein Blick auf das jeweilige System.
Das Thema Konstruktivismus greift im agilen Kontext beispielsweise in der Review. So wird hier dem Kunden die Umsetzung der Anforderungen aus den User Storys gezeigt. Es kann durchaus vorkommen, dass die Entwickler nach bestem Wissen und Gewissen etwas realisiert haben, was sich der Kunde anders vorgestellt hat, jedoch vorab nicht genauer hat beschreiben können. Die Wirklichkeitskonstruktionen stimmen - völlig wertfrei - nicht überein. Innerhalb der Review kann mit dem Feedback des Kunden eine gemeinsame Sprache gefunden und am konkreten Feature Veränderungswünsche konkretisiert werden. Das Agile Prinzip "Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen..." geht in diese Richtung. In der Review entsteht ein Finetuning des gegenseitigen Verständnisses der Wirklichkeitskonstruktionen. Die Entwickler verstehen die Kundenwünsche allmählich besser und umgekehrt erlangen die Kunden Zugang zur Sicht der Entwickler.
An einer anderen Stelle geben sich agil und systemisch erneut die Hand. Jede Handlung, egal ob spontan oder geplant, egal ob erprobt oder noch nie dagewesen, hat Folgen, die man nur bedingt voraussehen kann. Deshalb sind Vorhersagen und Planungen nur für einen gewissen Zeitraum und mit einer gewissen Wahrscheinlichkeit möglich. Diese Vorhersagen sind Annahmen innerhalb des Systems, um dieses zu beschreiben und handlungsfähig zu bleiben. Oder anderes gesagt: PO und Entwicklungsteam - sofern sie keinen direkten Kundenkontakt haben - bilden Annahmen über die Wirklichkeitskonstruktion der Kunden, um deren Bedürfnisse zu bedienen. Selbst wenn es Daten zur Nutzung der Software oder den Bedürfnissen gibt, so sind sie interpretationsbedürftig. Aufbau und Abhängigkeiten können nicht präzise vorhergesagt werden, es können nur Annahmen getroffen und diese durch Ausprobieren und Beobachtung überprüft werden: Schritt für Schritt, die Folgen beobachten und reagieren. Also nichts anderes als das „build – measure – learn“ der agilen Produktentwicklung. Ein Systemiker würde das dann "Aktions-Reaktion-Schleife" nennen.
Methoden wie Scrum und Kanban, die bewusst auf kleinschrittiges, iteratives Vorgehen und regelmäßige Feedbackschleifen setzen, sind im Werkzeugkoffer, um der Unplanbarkeit zum Trotz strategisch zu handeln. Ganz systemisch. Und agil.