Cost of Delay (3): Verzögerungskosten durch die Wiederholung des Falschen
Oftmals sind Teams so damit beschäftigt, die gefordert Funktionalität zu implementieren, dass sie kaum Zeit dafür haben mal anzuhalten, nachzudenken und darüber zu reflektieren, was sie warum wie machen.
- Jutta Eckstein
Oftmals sind Teams so damit beschäftigt, die gefordert Funktionalität zu implementieren, dass sie kaum Zeit dafür haben mal anzuhalten, nachzudenken und darüber zu reflektieren, was sie warum wie machen.
Häufig habe ich nach dem Beenden eines Projekts die Einsicht (meist begleitet mit einem tiefen Seufzer) in der Art gehört wie "wenn wir nur über dies oder jenes früher geredet …" oder "wenn wir nur frühzeitig diese kleine Änderung gemacht …" hätten, dann "… wäre das Projekt erfolgreicher gewesen".
Aber während der Projektarbeit fällt es einerseits den Beteiligten oft nicht ein, Alternativen zu berücksichtigen und diese zu diskutieren. Und selbst wenn es ihnen einfällt, ist andererseits dann sehr oft die Antwort: "Aber wir haben nicht die Zeit, uns damit zu beschäftigen." Im Deutschen gibt es eine Redewendung, die zu dieser Haltung passt: "Wir haben keine Zeit, die Säge zu schärfen, wie müssen sägen." Ähnlich wird das in Texas ausgedrückt: "Wir haben keine Zeit einen Zaun zu bauen, wir müssen die Kühe einfangen." (engl: "We can’t build the fence, we have to chase the cattle.")
Das heißt, besonders wenn wir unter Druck stehen, machen wir einfach weiter. Aber wir nehmen uns kaum mal die Zeit, anzuhalten und über bessere Wege nachzudenken, diese Dinge zu machen. Und wir halten selten inne und nehmen uns die Zeit, um unsere Situation zu verbessern, bevor wie uns wieder an die Arbeit machen. Oft führt dieses Verhalten dazu, dass Verzögerungskosten aufgrund von technischer Schuld entstehen. Häufig hat technische Schuld den gleichen Ursprung, das heißt, wir arbeiten weiter an Funktionalitäten (weil das die Dinge sind, die geliefert werden und nach welchen die Kunden fragen), obwohl die technische Schuld der Grund ist, warum wir kaum noch in der Lage sind, wirklich Funktionalitäten zu liefern.
Zum Beispiel habe ich schon öfter Projekte gesehen, bei denen die Build-Zeiten unsäglich lange dauern oder der Build sowieso schon seit ewigen Zeiten nicht mehr durchläuft. Aber statt sich Zeit zu nehmen, die Build-Probleme zu lösen, wird weiterhin darauf gedrängt, Features zu entwickeln. Auf den ersten Blick macht das auch Sinn, da die momentane Situation sich ja so darstellt, dass keine Features geliefert werden – also müssen wir uns darauf konzentrieren, Features zu entwickeln. Dass es in der Situation aber besser wäre, keine Features zu entwickeln, sondern die ganze Konzentration auf die Build-Probleme zu richten, wird schnell mal übersehen (oder ignoriert).
Das heißt, um dafür zu sorgen, dass sich ein Projekt nicht verzögert, muss man von Zeit zu Zeit anhalten und sich darauf konzentrieren, inwiefern die Umgebung oder die Arbeitsweise verbessert beziehungsweise korrigiert werden sollte. Und sich dann nochmals Zeit nehmen, um diese Dinge tatsächlich auch umzusetzen. Erst infolgedessen kann man von schnelleren Lieferungen profitieren.
Diesen Zweck haben in der agilen Entwicklung die (regelmäßigen) Retrospektiven (insofern man sie nicht nur zum Sammeln von Plus-/Minuspunkten einsetzt). Wie oft schon habe ich mitgekriegt, wie diese im Projektstress gestrichen wurden, weil "wir keine Zeit für solche Dinge haben" – aber genau wenn man keine Zeit hat, muss man sich die Zeit dafür nehmen, "die Säge zu schärfen" (um dadurch eventuell herauszufinden, wo man die Zeit verliert beziehungsweise was einen aufhält). Das heißt, manchmal muss man langsam machen, um schneller zu werden. ()
