Wann agil und wann klassisch?

Wann man eher eine agile und wann eher eine klassische Vorgehensweise in Software-Entwicklungsvorhaben wählen sollte.

In unseren Projekten stehen wir immer wieder vor der Fragestellung, wann man denn nun eigentlich welche Methode einsetzen soll, also wann eher agil / Scrum und wann eher klassisch / Wasserfall zum Einsatz kommt. Wir möchten uns an dieser Stelle bewusst nicht an der leider meist ideologisch geführten Debatte um das vermeintlich bessere Vorgehensmodell beteiligen. Wie an anderer Stelle bereits festgestellt, braucht es manchmal »einen Hammer und manchmal einen Schraubendreher«. Und genauso, wie man sich für ein Werkzeug anhand gewisser Eigenschaften der Problemstellung (»Schraube oder Nagel in die Wand«) entscheidet, sollte man auch die Entscheidung für die einzusetzende Methode anhand der Eigenschaften des Umsetzungsvorhabens treffen.

Klingt logisch, aber so ein Entwicklungsprojekt weist ja nun eine Menge Eigenschaften auf. Es hat einen Anfang und ein Ende, es gibt vielleicht schon eine Zielarchitektur oder zumindest eine Vorstellung davon, evtl. stehen die Mitarbeiter oder der Entwicklungspartner schon fest und aufgrund dessen häufig auch schon die Technologie, etc. An welcher Eigenschaft entscheidet sich nun die Methode?

Unserer Erfahrung nach ist die Art des Problems, für dessen Lösung die Software erstellt werden soll, das definierende Kriterium für die entsprechende Entwicklungsmethodik: handelt es sich um ein kompliziertes Problem, so empfiehlt sich eher ein klassisches Vorgehen, bei komplexen Problemstellungen hingegen die agile Herangehensweise.

Sagt sich leicht, aber wir haben zugegebenermaßen einige Zeit und Diskussionen gebraucht, um zu einer entsprechenden Semantik der beiden häufig, aber vermutlich seltener trennscharf verwendeten Wörter »komplex« und »kompliziert« zu kommen.

Komplex ist ein Problem, wenn es viele und insb. unbekannte Größen aufweist. Je näher man an den Kunden kommt, desto komplexer wird es in der Regel. Wir finden dann häufig nicht oder nur schwer berechenbare Situationen vor: wer weiß schon, wie der Kunde sich Morgen verhält? Die Aufgabe einer Stewardess an Bord eines Airbus ist bspw. eine komplexe Aufgabe, da sich nicht vorhersagen lässt, wie sich welcher Passagier in der Luft an Bord verhalten wird und was er dann bspw. trinken möchte. Das »Problem« wird in diesem Fall durch hingehen, fragen und verstehen gelöst, also grundsätzlich eher explorativ.

Eine komplizierte Problemstellung weist viele Variablen auf, die aber (weitestgehend) bekannt bzw. zu ermitteln und somit berechenbar sind. Hier befinden wir uns häufig in Situationen mit vielen Abhängigkeiten, Systemen und Schnittstellen. Hierbei sollte dann aber auch eher analytisch an die Aufgabenstellung gegangen und sich die Berechenbarkeit zunutze gemacht werden: ein Airbus wird dann doch (glücklicherweise!?) eher mit klassischen Vorgehensweisen gebaut.

Weitere interessante Ansätze zur Definition von komplex und kompliziert finden sich bspw. im KULTURMANAGEMENT BLOG.

Zurück zur Softwareentwicklung, am Beispiel E-Commerce: Je näher wir mit unserem Vorhaben also »an« den Kunden, bspw. in Richtung Frontend kommen, desto mehr spricht in der Regel für eine agile Entwicklungsmethode, da wir hier oft auch eine unklare Anforderungssituation vorfinden. Bewegen wir uns mit der zu lösenden Problemstellung eher in Richtung Backend und haben es mit vielen (bekannten) Schnittstellen und Systemen zu tun, dann kann eine klassische Vorgehensweise angebrachter sein.