von Zoi Natsiopoulou und Markus Kling

Wir sind Zoi und Markus. Wir sind Agile Coaches. Wir arbeiten bei verschiedenen, immer neuen Kunden und in der Regel werden wir gerufen, wenn es Probleme gibt. Natürlich hat dabei jeder Kunde für sich gesehen seine ganz besondere und einzigartige Situation. Wir beobachten jedoch auch oft Dinge, die nahezu überall gleich sind, und “pair-bloggen” darüber. In der heutigen Folge: Veränderungen in überlasteten Systemen.

Überlastetes System – Versuch einer Definition

Für unsere Zwecke interpretieren wir System als eine (Teil-)Organisation, die der Lösung eines komplexen Problems gewidmet ist, wie z.B. eine Abteilung, die eine Webanwendung entwickelt.

Auf der Suche nach einer Definition für den Begriff überlastet, sind wir zunächst im Duden fündig geworden: “[etwas] über die gegebenen Möglichkeiten hinaus beanspruchen und dadurch in seiner Funktionsfähigkeit beeinträchtigen”[1]. 

Für unseren Systembegriff verstehen wir unter “gegebenen Möglichkeiten” die vorhandene Leistungsfähigkeit oder Kapazität des Systems. Wird diese Leistungsfähigkeit überschritten, indem wir sie zu sehr beanspruchen, kommt es zu einer Überlastung, worunter die Funktionsfähigkeit des Systems leidet.

Ein einfaches Beispiel für ein System aus der wirklichen Welt ist die Autobahn. Sind zu viele Autos gleichzeitig auf der Straße, die von A nach B wollen, kommt es zum Stau. Das passiert oft an neuralgischen Stellen, wie z.B. bei Ausfahrten oder Baustellen. Wer schon einmal gehofft hatte, zu Ferienbeginn schnell durch den Gotthard-Tunnel zu kommen, hat sicher schon die ein oder andere böse Überraschung erlebt. Zu den ganzen Pendlern und LKWs, die tagtäglich durch den Tunnel wollen, kommen ganz viele Urlaubsautos dazu und sorgen für eine Überlastung. Das Ergebnis: alle brauchen länger, um an ihrem Zielort anzukommen.

Ein Beispiel aus der Projektwelt für Überlastung haben wir im Kanban Maturity Model [2] gefunden: Durch die forcierte Projektarbeit bei gleichbleibender Belastung durch das Tagesgeschäft kam es zu einer erheblichen Überbeanspruchung besonders bei fachkompetenten Mitarbeitern, was zu unvorhergesehenen Verzögerungen in den betroffenen Projekten und Services führte.

Überlastete Systeme erkennen

Wenn wir als Agile Coaches zu Kunden gerufen werden, um bei der Agilen Transformation zu unterstützen, versuchen wir zunächst, uns mit Hilfe der bisher Beteiligten ein Bild der Lage zu machen. Dabei sehen wir ziemlich schnell das erste Symptom für ein überlastetes System: 

Die Kalender sind voll, alle stecken bis zum Hals in Arbeit und es dauert Tage bis Wochen, um ein paar Termine zu bekommen. 

Schauen wir dann zweitens auf die Dinge, mit denen die Leute sich beschäftigen, sehen wir, dass es mehr Dinge gibt, die herumliegen und warten, als in Arbeit sind. Es dauert meist sehr lange, bis etwas fertig wird, selbst wenn es nur eine Kleinigkeit ist. 

Das dritte Symptom ist die Anzahl der nicht abgeschlossenen Projekte. In beinahe jeder (Teil-)Organisation sehen wir, dass zu viele Projekte am Laufen sind. Oder besser: am Bummeln oder Warten. Teils sehen wir ein Verhältnis von 1:1. In einem Bereich mit beispielsweise 100 Leuten gibt es dann um die 100 Projekte, mit denen sich die Leute beschäftigen (müssen).

Tut sich darüber hinaus die Organisation schwer damit, Lieferzusagen zu treffen bzw. einzuhalten, könnte das ein weiterer Hinweis auf Überlastung sein. Und damit meinen wir nicht die inhärente Unsicherheit durch die Varianz in der Entwicklungsdomäne, sondern eine ungleich höhere Unsicherheit, die durch die Überlast in das System kommt. 

Große Veränderungen kosten Zeit und erzeugen Widerstand

Ironischerweise ergibt sich aus diesen Schmerzpunkten sehr oft die Motivation für eine Agile Transformation. Die Kunden wünschen sich eine Verbesserung und glauben, dass Agil der richtige Ansatz ist. Genau an diesem Punkt gilt es für uns als Coaches, aufmerksam zu sein und die Kunden gut zu beraten. Denn auf der einen Seite ist der “Sense of Urgency” [3] vorhanden und somit auch die Energie, die es für eine Transformation braucht. Auf der anderen Seite müssen wir im Blick behalten, dass Agile Transformationen eine erhebliche Veränderung darstellen und mit Unsicherheit und Mehrarbeit einhergehen. Neue Rollen, Aktivitäten und Methoden müssen etabliert und gelernt werden. Auf der eh schon überfüllten Autobahn machen wir zum Ferienbeginn noch eine Baustelle auf. Und siehe da: alles braucht länger. Schlimmstenfalls bricht der Verkehr kurzzeitig zusammen. Widerstände steigen und die Akzeptanz für die Agile Transformation sinkt. Wir laufen Gefahr, in einen Teufelskreis aus zu viel Arbeit, steigender Unzufriedenheit und Widerstand zu kommen. Oft spiegelt sich das in der Aussage: “Wir haben es versucht, aber bei uns funktioniert Agil nicht. Ganz im Gegenteil, es wurde schlimmer und wir haben seitdem nichts mehr ausgeliefert.”

Ein Beispiel aus der Praxis:

Die betreffende Organisation hatte sich für ein fertiges Agiles Framework entschieden, um ähnliche Schmerzpunkte wie oben beschrieben anzugehen. Leider war das System schon vorher überlastet. Wenn wir uns den Release Burndown in Abbildung 1 anschauen, dann sehen wir die aktuelle Burndown Kurve in blau, die bis zur gestrichelten Linie “Today” verläuft. Die daraus als dünne blaue Gerade abgeleitete Prognose zeigt an, dass zum anvisierten Liefertermin noch Arbeiten offen sein würden (“Current Delta”), d.h. wir haben schon mehr Arbeit im System, als bis zum feststehenden Termin erledigt werden kann.

Dabei geht die Prognose davon aus, dass die Arbeiten weiterhin in einer vergleichbaren Geschwindigkeit ablaufen, d.h. dass mit etwa gleichbleibender Produktivität gearbeitet wird.

Leider ist es aber so, dass bei jeder Veränderung die Produktivität zunächst zurückgeht, bevor sie (hoffentlich) wieder ansteigt und sich letztendlich auf einem höheren Niveau wieder einpendelt. Das gilt für jede Veränderung – nicht nur, aber eben auch für eine Agile Transformation. Neue Rollen, Aktivitäten und Regeln werden eingeführt. Sie müssen erst mal erlernt und Altes entlernt werden. Verwirrung und Desorientierung entstehen. Dies alles drückt die Produktivität erstmal nach unten. Bekannt ist dieses Phänomen als J-Kurve, wie sie in Abbildung 2 zu sehen ist.

Da die Produktivität aber entscheidend für das Gefälle des Release Burndowns ist, wird dieses Gefälle bei sinkender Produktivität auch zurückgehen. Mitunter kann die Kurve sogar kurzzeitig ansteigen, da durch die Veränderung plötzlich neue Arbeiten im Release Backlog erscheinen oder bestehende Aufgaben größer werden. Dies sehen wir in Abbildung 1 in der grünen Kurve dargestellt. Diese nähert sich zwar nach einiger Zeit wieder an die ursprüngliche Prognose der blauen Kurve an, was auf die bis dahin angestiegene Produktivität zurückzuführen ist. Aber – abhängig von der Größe der Veränderung und dem Zeitpunkt des Release Termins – kann es passieren, dass diese Veränderung die Lage nicht verbessert, sondern verschlimmert. Es kommt dann zu dem schon bestehenden Delta noch ein größeres dazu. Genau das ist im vorliegenden Fall passiert. Genauer gesagt, es wäre passiert, wenn man nicht im letzten Moment auf Kosten der Agilität gegengesteuert hätte.

Am Ende hat es der Kunde geschafft, den Liefertermin einzuhalten. Alle waren glücklich und stolz auf Ihre Arbeit. Gleichzeitig hat es viel Energie gekostet, das Projekt zu stemmen. Der Versuch, das eigentliche Problem durch die Agile Transformation zu lösen, wurde nach hinten verschoben. Die anderen Anforderungen waren während der heißen Phase auf Eis gelegt. Sobald der Release-Termin geschafft war, poppten die Anforderungen wieder hoch, neue Projekte wurden initiiert, weil vermeintlich wieder mehr Kappa da war und es ging wieder von vorne los. Viele Anforderungen und Projekte kamen auf zu wenige Entwickler, die versprochenen Liefertermine waren nicht mit der Kapazität zu schaffen. 

Die Politik der kleinen Schritte 

Nichts zu tun ist auch keine Lösung. Aber wie können wir in überlasteten Systemen mit weniger Risiko Verbesserungen bewirken? Als David Anderson die Kanban-Methode erstmals einführte, bezeichnete er sie als Wandel in kleinen Schritten (Evolutionary Change) [2]. 

Im Zusammenhang mit Agilen Transformationen verstehen wir unter Politik der kleinen Schritte eine Vorgehensweise, die dort beginnt, wo der Kunde steht und durch viele kleine Veränderungen versucht, Verbesserungen zu erzielen. Da spielen die Problemstellung und die daraus abgeleiteten Ziele genauso eine Rolle wie kulturelle Überlegungen und die allgemeine Auslastung des Systems. Ausgehend davon ist es ratsam, den Blueprint für die Transformation selbst zu gestalten. Dazu kann man sich verschiedener Praktiken und Vorgehensweisen bedienen. 

Um auf unser Thema zurückzukommen: wir würden bei einem überlasteten System unseren Kunden nicht empfehlen, ein fertiges Framework zu implementieren, sondern eher die Politik der kleinen Schritte zu verfolgen. Am Anfang sollte eine kurze Analyse stehen, um das System zu verstehen. Dazu können Daten wie Durchlaufzeiten oder Ähnliches herangezogen werden. Aber auch Beobachtungen hinsichtlich Meetings, Zusammenarbeit, oder Artefakten. Es gilt, einen ersten Eindruck vom System zu bekommen. Gibt es die typischen Anzeichen für eine Überlastung, müssen wir die Gründe dafür suchen. Sind sie eher auf der Umsetzungs- oder auf der Koordinations-Ebene zu sehen? Oder in deren Zusammenspiel? 

Aus dem Verständnis der Problemlage entstehen Hypothesen und daraus dann passende Verbesserungsschritte. Das kann in einem Fall die Visualisierung und Verbesserung von Prozessschritten in der Wertschöpfungskette sein oder in einem anderen die Entlastung von Teams und Experten durch die Einführung von WiP Limits. Das erfordert keinen Umbau der Organisation und ist weniger aufwändig als die Zusammenstellung neuer Teams oder die Einführung neuer Rollen. Wir bewegen das System, indem wir etwas ändern, überfordern es jedoch nicht so, dass die Produktivität zu sehr darunter leidet. Zudem sind solche kleineren Veränderungen wieder schneller zurückzudrehen. Wenn wir bspw. merken, dass die WiP Limits nicht wirklich den erwünschten Effekt haben, können wir sie anpassen. Durch die kleinen Schritte entsteht auch weniger Widerstand bei den Beteiligten. 

Die Verbesserungen mit ihren anfänglichen Produktivitätsverlusten haben wir in der Abbildung 3 in der gelben Kurve visualisiert. Es gibt mehrere kleinere J-Kurven. Wir vermeiden den großen Dip und sind schneller auf der bisherigen als auch auf der angestrebten Produktivität.

Fazit

Veränderungen fügen sich keinem Plan – auch keinem Beraterplan [4]. Oft kann man im Vorfeld nicht sagen, ob eine Veränderung auch die erhofften Verbesserungen bringt. Manchmal kann es sogar zu gegenteiligen Effekten kommen. Deswegen ist man gut beraten, auf den jeweiligen Kontext zu achten und diesen bei Veränderungs-Entscheidungen einzubeziehen. Die Politik der kleinen Schritte kann eine sinnvolle Alternative zu SAFe oder Scrum sein, um bspw. eine Entlastung und dadurch den Boden für eine Reorganisation vorzubereiten. Und wenn die Organisation bewusst disruptiv vorgehen möchte, dann sollte sie sich zumindest des Risikos bewusst und bereit sein, durch das Tal der Tränen zu gehen. Das gilt für jede Veränderung, aber vor allem für Veränderungen in überlasteten Systemen. 

Referenzen:

[1] Duden, Handbuch der deutschen Rechtschreibung, Onlineversion,  https://www.duden.de/rechtschreibung/ueberlasten, abgerufen am 05.10.2022

[2] Anderson, David J. / Bozheva, Teodora, Kanban Maturity Model, Handbuch für Agilität, Resilienz und Neuausrichtung in Organisationen (2021), dpunkt.verlag GmbH

[3] Kotter, John P., Leading Change, 2011, Vahlen

[4] Eidenschink, Klaus, Metatheorie der Veränderung, Podcast, https://audioportal.metatheorie-der-veraenderung.info/das-thema-beratung-darf-keine-zielversprechen-machen/, abgerufen am 05.10.2022