Schneller fertig werden, nicht schneller arbeiten

Bild: Pexels / Burst - Lizenz

Es gibt einen Satz, der ist gleichzeitig eine der grössten Verheissungen, einer der bekanntesten Werbeslogans und eines der am weitesten verbreiteten Missverständnisse im Bereich der Agilität. Um ihn zu finden muss man nicht lange suchen, er steht gross auf dem Titel eines Buches, das von Scrum-Begründer Jeff Sutherland verfasst wurde. Er lautet Doing Twice the Work in Half the Time. Wenn er im Rahmen einer agilen Transition fällt sollte man dringend über ihn reden.

Wenn klassische Manager hören, dass man in der Hälfte der Zeit die doppelte Arbeit erledigen könne kommt bei vielen sofort der Fehlschluss zu Stande, dass das durch schnellere Arbeit passieren würde. Aus ihrer Sicht nachvollziehbar: in vielen Unternehmen herrscht noch immer die Ansicht vor, dass sich Arbeit an komplexen Aufgaben detailliert bis weit in die Zukunft planen liesse. Der Umkehrschluss - wenn das so ist, dann lässt sich mehr Geschwindigkeit nur durch schnellere Arbeit erreichen.

Dass das ein gefährlicher Trugschluss ist habe ich bereits beschrieben. Im besten Fall gelingt es und man gerät in die Build Trap, baut also in hoher Frequenz an den sich ändernden Marktbedürfnissen vorbei, in den schlechteren Konstellationen entsteht die (scheinbare) Geschwindigkeitssteigerung dadurch, dass dort Arbeit eingespart wird wo das Management es nicht sehen und nicht überprüfen kann, bei Organisation, Tests, Architektur, etc. In beiden Fällen treten die Auswirkungen verspätet aber unvermeidbar ein und aus der anfänglichen Beschleunigung wird ihr Gegenteil.

Unabhängig davon ist es aber tatsächlich so, dass agile Vorgehensweisen die Produktion erstaunlich schneller machen können. Die Ursachen dafür sind bekannt und lassen sich benennen.

Ein Grund ist, dass durch das ständige Inspect & Adapt und das permanente Kundenfeedback verhindert (oder zumindest eingedämmt) werden kann, dass am Markt vorbei entwickelt wird. Da in kleinen Arbeitspaketen sofort benutzbare Funktionen geliefert werden kann die Entwicklung jederzeit beendet und an einer anderen Stelle fortgesetzt werden. Anders als in Ansätzen mit langen Planungszyklen lässt sich dadurch Arbeit in grossem Ausmass vermeiden, und das nicht nur dadurch, dass man sie unterlässt - auch Folgearbeiten wie z.B. Ausbau oder Wartung der unnötig erstellten Features entfallen.

Ein weiterer Aspekt ist die Verkürzung von Wartezeiten. In den meisten nicht agilen Teams die ich kenne besteht die Fertigstellungszeit eines Produkts zu mehr als der Hälfte daraus, dass auf die Zulieferung eines anderen Teams gewartet wird. In einer agilen Umgebung ist das anders: Scrum Teams sind per Definition crossfunktional und haben wenige Abhängigkeiten, Kanban Teams arbeiten permanent an der Beseitigung von Flaschenhälsen und der Verbesserung von Übergabeprozessen. In beiden Fällen ist eine deutliche Verkürzung der Wartezeiten die Folge, und damit eine beschleunigte Fertigstellung.¹

Zuletzt tritt noch ein Effekt auf, der gewissermassen die Umkehrung des weiter oben genannten "Sparen wo es das Management nicht sieht" ist. Wenn Teams nach dem Pull-Prinzip arbeiten (einem der zentralen Bausteine aller agilen Vorgehen), dann nehmen sie neue Arbeit erst an wenn sie mit der alten wirklich fertig sind. Und zu diesem "wirklich fertig" gehört, dass getestet wurde, dass kein toter oder unverständlicher Code zurückgelassen wurde, dass alle durch Seitenauswirkungen erzeugten Bugs gefixt wurden, etc. Das macht die Arbeit zwar im Einzelfall etwas langsamer, langfristig sorgt es aber für deutlich mehr Geschwindigkeit.

Zusammengefasst: eine deutliche Geschwindigkeitssteigerung der Produktion ist durch Agilität möglich. Das bedeutet aber nicht schnelleres Arbeiten sondern intelligenteres Arbeiten. Diesen Unterschied sollten alle Beteiligten verstanden haben.


¹Ein häufiger Einwand an dieser Stelle ist, dass "in unserem Fall" Crossfunktionalität und Arbeit am Prozess nicht möglich sind. Das ist in den meisten Fällen eine Ausrede, aber selbst dort wo es stimmt ist es kein Argument. Solche Teams können strukturell kaum agil arbeiten, also sollte man sie nicht agil nennen und dort auch nicht die Vorteile von Agilität erwarten.