Agil, fragil, Wasserfall, was denn nun?
Sprints werden geplant, die Flagge der “Agilen Entwicklung” flattert im Wind, aber trotzdem bekommt jeder in der Softwareentwicklung früher oder später mal Fragen gestellt wie “Wann ist das ungefähr fertig?” oder “Haben wir eine Deadline hierfür?”. Sie sind die natürliche Folge und absolut menschliche Reaktionen auf Planungsunsicherheit bei Auslieferungsdruck. Vor allem sind sie aber eines: Symptome.
Von außen betrachtet wird agil Software entwickelt. Zum Beispiel werden Storys mühevoll erstellt und Komplexitäten definiert. Durch die Brille des Projektmanagers sieht das super aus. Alle neuen Anpassungen der vereinbarten Guidelines aus der letzten Retrospektive werden auch befolgt.
Was sich aber hinter dem Vorhang verbergen kann, sind Entwicklungspraktiken und Arbeitsweisen, die eben nicht agil sind.
Räume schaffen
Architekturen werden vom Ort und Fundament des Hauses bis hin zum Muster der Fliesen im Gästebad vorab durchgeplant. Die Arbeitszeit wird mehr im Debugger als in der Testsuite verbracht. Es gibt Single Points of Knowledge, wo immer ein einzelner an den Code ran muss, weil es sonst zu lange dauert. Tests werden als zusätzlicher Aufwand behandelt, statt als fundamentaler Bestandteil des Bauvorhabens namens Software.
Sie aber bilden eigentlich die Basis für agile Softwareentwicklung und das darauf aufbauende Projektmanagement, nicht umgekehrt. Wenn schnelle Feedback-Schleifen mit Kunden durch die etablierte Arbeitsweise erschwert werden (etwa durch Pull Requests), verliert die ursprünglich geschätzte Komplexität an Bedeutung, weil sie etwa mit dem Bottleneck eines noch ausstehenden Reviews verschmilzt.
Dann bricht auch mal der Damm und der Wasserfall zieht einem die Beine weg. Der Keller steht dann voll mit Wasser (Hello, Technical Debt, my old friend …) und man fängt an, hektisch eimerweise zu schöpfen. Das Wasser muss raus, die Story fertig werden, egal wie, Hauptsache fertig und ohne offensichtliche Probleme. Das kostet so viel Kraft, dass gar nicht auffällt, dass der Kunde an einer ganz anderen Baustelle im Nachbarort steht, die Sonne heiß runter scheint und sich fragt, wann das versprochene Sonnensegel fertig ist.
Es folgt eine immer enger werdende Ermüdungsschleife, die zu einem sich selbst verstärkenden Verhalten führt, wenn genau dieses Phänomen parallel für mehrere Projekte so läuft. Die einzige Lösung hier ist Raum: Raum für Wachstum, Weiterbildung und Ausgestaltung der notwendigen Entwicklungspraktiken. Es fehlen möglicherweise sogar noch die Kompetenzen, die richtigen Verbesserungsinkremente durchzuführen und überhaupt zu identifizieren.
Dieser Raum muss aber geschaffen werden. Denn sonst drohen die sehr menschlichen Reaktionen wie die oben geschilderten. Das sind kritische Red Flags für Probleme der Softwareentwicklungspraktiken, die dann genau die benötigten Räume für Wachstum blockieren. Und je schlimmer es wird, desto enger werden diese Räume.
Jeder kennt das auch aus dem klassischen Teufelskreis “Stress, keine Zeit für Sport, kein Stressabbau, mehr Stress, noch weniger Sport, …” Ist analog zu “Stress – keine Zeit für Sport – kein Stressabbau – mehr Stress -…”. Aber irgendwann muss der harte Cut kommen: Man zieht die Laufschuhe an, nimmt sich 20 Minuten vor und läuft einfach los.
Das Problem der Mental Load
“Ja, das will ich ja alles, aber ich habe noch 100 andere Sachen auf dem Zettel.”.
Hier kann externe Struktur helfen. Gibt es da diesen Personal Trainer, der einem die Tage fürs Training vorgibt, einen dann noch zu Hause besuchen kommt und die verabredeten Crunches zählt, die man aus sich raus presst, nimmt das die Mental Load. Die Tätigkeit überhaupt einzuplanen und dann noch mit dem Schweinehund zu diskutieren, fällt dann weg. Der Raum des kontrollierten Vorankommens wird also strukturell für einen geschaffen.
Braucht ihr vielleicht noch einen Dogwalker für euren Schweinehund, um Raum für Wachstum eurer Entwickler zu schaffen?