Langsamer ist manchmal schneller: Auch im agilen Zeitalter lohnt es sich, Ideen reifen zu lassen

Agilität wird vielfach verstanden als ein Weg, schneller zum Ziel zu kommen, indem man alles weglässt, was einem unnötig erscheint oder wozu man schlicht keine Lust hat. Viele Projekte haben alles aus dem Alltag verbannt, was auch nur nach Wasserfall riecht. Längerfristige Projektplanung (also mehr als ein, zwei Sprints), ausführliche Analyse, Architekturarbeit, Nachdenken über den Tag hinaus – das und vieles mehr wird dem Wunsch nach höherer Geschwindigkeit geopfert. Alles, was zählt, ist, schnell Business Value zu erzielen.

Keine Frage: In vor-agilen Zeiten haben wir so manche unnötige Schleife gedreht, Funktionen so gebaut, dass sie Generationen halten (und nach wenigen Monaten wieder entsorgt wurden), riesige Datenmodelle entworfen, die zwar alles konnten, aber deren Vorteile, nun ja, sagen wir mal ziemlich begrenzt waren, und vieles mehr. Und heute? Heute schütten wir allzu oft das Kind mit dem Bade aus.

Viele Unternehmen haben ihre Geschäftsprozesse so stark vereinfacht, dass sie nicht mehr in der Lage sind, ihr Tagesgeschäft fehlerfrei zu machen. Alles, was irgendwie überflüssig erschien, wurde wegoptimiert. Im Zweifelsfall wird halt improvisiert. Das genügt schon.

Und im Projekt? Da geht es kaum anders zu. Dokumentation? Verrufen. Kostet viel Geld, veraltet schnell, und keiner liest sie. Ausführliche Analyse? Wir besorgen uns schnell die API des anderen Systems, und dann bauen wir schwuppdiwupp einen Anschluss und fertig. Design? Alle an einen Tisch, mit dem (mangels Zeit halbgaren) Wissen schnell eine Lösung skizziert, und dann geht's auf zum Coden.

Solange Sie ein Projekt machen, dass nur aus Ihrem Team besteht, das nach wenigen Sprints beendet ist und eine Wegwerf- oder Insellösung produziert, mag das angehen. Was aber, wenn das, was Sie produzieren, mit anderen Systemen zusammenspielen soll, wenn es von anderen Teams genutzt werden soll? Was kostet es zum Beispiel, wenn eine API zwar vorhanden, aber völlig undokumentiert ist? Wenn hinterher alle raten und ausprobieren müssen, wie sie funktioniert? Wenn die Anwendung immer wieder crasht, weil deren  API nicht hinreichend gegen Fehlbenutzung abgesichert wurde?

Die Befürworter der reinen agilen Lehre sagen „You ain't gonna need it“ – Du wirst es nicht brauchen. Doch die Wenigsten räumen mit der nächsten Anforderung auf. Stattdessen wird um die Defizite herumgewerkelt, ein Rucksack angehängt oder schlimmstenfalls gleich alles weggeworfen und nochmal gemacht.

Und so wird das System komplexer und komplexer und komplexer. Und die nächste Iteration teurer und teurer und teurer. Software-Entropie nennt man das. Die mit viel Engagement erarbeitete Software ist schon nach kurzer Zeit reif für die Ablösung.

Kommt Ihnen das bekannt vor? Ja, das gab es auch schon zu Wasserfallzeiten. Aber seltsamerweise gab es auch schon damals Projekte, die haben trotz aller Bürokratie Systeme gebaut, die gut fortzuschreiben waren, die man zu angemessenen Kosten mit akzeptablem Aufwand erweitern könnte. Was haben die anders gemacht?

Sie haben sich Zeit gelassen.

Zeit ist teuer. Aber die schnelle Lösung, unter hohem Druck erzeugt, ist so gut wie immer teurer. Warum das so ist? Menschen unter Druck arbeiten nicht schneller, sondern schlampiger. Sie prüfen nicht, ob Annahmen realistisch und vollständig sind, spielen Lösungsansätze nicht durch, verproben Konzepte nicht ganzheitlich und vieles andere mehr. Das alles spart vordergründig Zeit und damit Geld. Die Entwickler können schneller loslegen, das System wird schneller fertig – so meint man.

Oft genug sieht die Realität anders aus. Weil nur wenige Standardfälle bedacht werden. Weil Fehlerfälle nicht mitgedacht werden. Weil die neu hinzugenommene Technik zwar schick ist, aber die alten Designfehler beibehält. Oder (noch schlimmer) neue hinzufügt.

Vieles davon wäre locker zu verhindern gewesen, wenn man sich mehr Zeit zum Nachdenken genommen hätte.

Als ich vor gut 30 Jahren Informatik studiert habe, habe ich gelernt, dass ein Fehler in der Stufe, in der er gefunden wird, ungefähr zehnmal so teuer zu beheben ist, wie in der Stufe davor. Und immer noch glauben Teams, das wird sie nicht treffen. Wie naiv.

Nehmen wir uns die Zeit. Machen wir unsere Arbeit gelassen und hinreichend gründlich. Ich glaube nicht, das wir jeden Zipfel eines Problems mit der gleichen Intensität ausleuchten müssen. Aber wenn wir etwas weglassen, sollten wir das zumindest bewusst tun und nicht nur, weil wir glauben, dafür keine Zeit zu haben. Wir sollten wissen, welche Risiken wir uns mit einer Entscheidung einhandeln, und was es kostet, wenn die Risiken eintreffen.

Langsamer ist manchmal schneller – und obendrein günstiger. Auch Ihr Projekt wird besser ins Ziel kommen, wenn Sie in Codierung und Test weniger Fehler und Sackgassen durchleben müssen, weil Analyse und Design ihren Job hinreichend gut machen durften.