Agil = doppelt so viel in halber Zeit?

Ich habe schon oft gehört, ob es stimmt, dass man mit agilen Methoden doppelt so viel in halber Zeit erreichen kann. Manchmal habe ich das von meinen Kunden als Erwartung formuliert gehört. Ein Grund für dieses Missverständnis mag das grundsätzlich grossartige Scrum-Buch „The Art of Doing Twice the Work in Half the Time„(Wortlich übersetzt: „Doppelt so viel in halber Zeit“) von Jeff Sutherland (co-creator of Scrum) sein. 

Die kurze Antwort bleibt aber: Nein, das ist (natürlich) nicht richtig und ein schlechter Grund, weshalb eine Organisation es sich zum Ziel setzen sollte agil werden zu wollen. Im Folgenden Blog gehe ich nicht auf andere Aspekte von „Agil“ ein, von Vor- oder Nachteilen, sondern beschränke mich auf die Diskussion des „Outputs“, einer agilen Vorgehensweise im Vergleich zum „alten Klassiker“ dem Wasserfall-Modell.

Agile Vorgehensweisen sind deshalb so erfolgreich und mittlerweile der neue „Standard“, weil es in der klassischen Softwareentwicklung eine Grundannahme gab die falsch war: Softwareentwicklung ist eine planbare Arbeit die man hinreichend mit einer Konstruktionstätigkeit oder Fließbandarbeit vergleichen kann. Diese Annahme hat sich als falsch erwiesen und ebnete den Agilen Methoden den Weg, die davon ausgehen, dass Softwareentwicklung eher mit einem Forschungsprojekt zu vergleichen ist.

 

Agile Methoden beruhen ihrerseits auf einer Grundannahme, nämlich, dass das Umfeld in dem sie eingesetzt werden, hinreichend komplex ist. Ein komplexes Umfeld ist dann gegeben, wenn eine Vorhersage von Ursache und Wirkung entweder nicht möglich oder aufgrund des benötigten Aufwands nicht zielführend ist.

 

Bei Softwareprojekten ergibt sich in der Regel schon das Problem von hoch volatilen Anforderungen, sodass selbst wenn Softwareentwicklung planbar wäre, man aufgrund der Zeitdauer eines Projekts am Ende etwas hätte, das man dann nicht mehr möchte. Und zudem ergibt sich im Laufe des Projekts oft ein Zeitdruck die Software schneller einsetzen zu wollen als geplant. Die Entwicklung ist dann beim klassischen Vorgehen vielleicht schon weiter. Soll man jetzt beim Testen kürzen? Eine schlechte Idee!

Besser wäre es gewesen sich gleich nur auf das Nötigste zu beschränken.

Man muss sich bewusst sein, dass „Agil“ nicht effizient bedeutet. Es ist das Gegenteil. Klar strukturierte, aufeinander aufbauende und durchgeplante Abläufe sind viel effizienter als jede agile Methode es je sein kann. Der große Unterschied liegt im Grad der Robustheit der Softwareentwicklung. Umso effizienter ein System, desto anfälliger ist es für Störungen im Ablauf. Agile Methoden haben hier den großen Vorteil, dass sie mit Störungen wesentlich besser umgehen können. Diese werden nicht nur erwartet, sondern regelrecht begrüßt, weil sie den gesamten Prozess stärken können! In einem klassischen Wasserfallprozess, der hoch effizient abläuft, kann eine verhältnismäßig kleine Störung für große Turbulenzen sorgen und erfordert oft eine komplette Neuplanung. Insofern kann man „Agil“ als Versicherung gegen Ungewissheit verstehen, als Maßnahme zur Risikominimierung.

 

Wenn ein Projekt allerdings ohne nennenswerte Probleme abläuft oder seiner Natur nach simpel ist, also eine optimale Lösung bereits in der Planungsphase determinierbar ist, dann ist es zu erwarten, dass eine andere effizientere Vorgehensweise schneller und günstiger im Einsatz ist, weil ich eben durch den Einsatz einer agilen Methode Effizienz verliere und dafür Robustheit und Wahlfreiheit für spätere Entscheidungen gewinne.

 

Zusammengefasst möchte dich die anfangs gestellte Frage so beantworten: Eine agile Vorgehensmethode kann tatsächlich doppelt so viel in halber Zeit oder gar schneller zu einem erfolgreichen Projektabschluss führen, das hängt aber vom Kontext ab in dem sie eingesetzt wird. Wenn eine agile Methode schneller und effizienter funktioniert, dann deshalb, weil der Kontext in dem die Methode eingesetzt wurde, Anpassungen verlangte, die erst im Laufe der Entwicklung bekannt wurden.

Beispielsweise, weil man Anforderungen gestrichen hat, die man doch nicht brauchte oder Anpassungen am Produkt vornehmen musste. Die Stärken agiler Vorgehensweisen sind der Fokus auf das Wesentliche, dies zuerst zu liefern und die Fähigkeit sich auf eine sich veränderte Umwelt anzupassen. Durch dieses Vorgehen schaffen wir es dann auch doppelt so viel in halber Zeit zu liefern.  In einer sich nicht verändernden Welt ist „agil“ also überflüssig. Haben Sie jetzt vielleicht eine Idee wieso „agil“ in den letzten beiden Jahrzehnten so erfolgreich wurde?

Wollen Sie agil sein? Und wenn ja, was versprechen Sie sich für Ihre Organisation davon? 

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen