In der Diskussion um agile versus klassische Projektsteuerung wird gerne das Iron Triangle als Argument verwendet. Doch wie viel Wahrheit steckt in der Idee, dass in klassischen Projekten der Scope fix ist und in agilen Projekten die Zeit? Und was bedeutet das für das Schätzen von Aufwand, Ressourcen und Geschwindigkeit?
Das Iron Triangle – auch bekannt als magisches Dreieck des Projektmanagements – beschreibt das Spannungsfeld von Scope, Zeit und Ressourcen. In der klassischen Theorie gilt: Ist eine dieser Dimensionen fixiert, müssen sich die anderen beiden daran anpassen. Und wer kennt nicht die Projekte bei denen die Anforderungen mit einem lapidaren "So wie bisher" erklärt werden. Ähnlich klingt es, wenn beispielsweise die Systemplattform eines Produktes ersetzt wird. Höchst selten kommt tatsächlich jemand auf die Idee, in so einem Szenario sauberes Requirements Engineering zu tätigen und zu prüfen, was nötig, sinnvoll, wichtig und allenfalls nicht notwendig ist. Entsprechend wird meist davon ausgegangen, dass der Scope fix ist – Zeit und Ressourcen werden dementsprechend geschätzt und geplant.
In agilen Ansätzen hingegen gilt: Zeit und Teamgrösse (also Ressourcen) sind fix – der Scope wird flexibel gehalten. Nicht flexibel, weil egal, sondern weil wir eben aus den klassischen Projekten gelernt haben, dass der Scope fast nie fix ist. So weit, so didaktisch. Doch die Realität ist oft komplizierter.
In klassischen Projekten ist die Fixierung des Scopes wie erwähnt mehr Wunsch als Wirklichkeit. Es gibt grob zwei Phänomene. Das sind die Projekte, bei denen zu Beginn versucht wird, Anforderungen möglichst vollständig zu definieren und dann gibt es jene die mit eher absurden Begründungen postulieren, dass "alles so wie bisher" sein soll. Doch im Projektverlauf ändern sich die Rahmenbedingungen immer und oft auch ständig. Um diesen Wandel zu handhaben, gibt es Prozesse wie Change Requests oder ein Rebaselining des Projektplans. In der Praxis geschieht aber oft auch etwas anderes: Man hält am ursprünglichen Scope fest – und gleicht die Abweichungen mit mehr Zeit, mehr Budget oder schlicht mehr Leuten aus.
Besonders auffällig: Wenn ein Projekt lange strauchelt, werden oft sogenannte Taskforces eingesetzt. Diese bestehen selten aus mehr als 5 bis 7 Personen – meist hochqualifiziert, mit klarem Mandat und minimaler Prozesslast. Und erstaunlicherweise schaffen sie es oft, das Projekt – oder zumindest einen funktionierenden Teil davon – doch noch ins Ziel zu bringen. Das wirft die Frage auf: War der ursprüngliche Plan überhaupt realistisch? Oder war die Steuerung durch Scope-Fixierung von Anfang an trügerisch?
Agile Teams drehen das Dreieck um: Sprintdauer (Zeit) und Team (Ressourcen) sind stabil, was bedeutet, dass der Scope innerhalb dieser Grenzen verhandelbar ist. Das heisst aber nicht, dass "alles offen" ist. Im Gegenteil: Das Management des Scopes ist die zentrale Disziplin in der agilen Produktentwicklung.
Hier kommen Praktiken wie Backlog Management, Backlog Refinement oder Agile Requirements Engineering ins Spiel. Sie sorgen dafür, dass der Scope laufend priorisiert, aufgeschnitten und angepasst wird. Nicht der Umfang einer ursprünglich festgelegten Anforderung ist entscheidend, sondern welcher Teil davon im nächsten Sprint den höchsten Wert liefert.
Die vermeintliche Unsicherheit – also dass man in Agilität den Scope verfehlen kann – ist in Wahrheit ein Ausdruck von bewusster, werteorientierter Steuerung. Statt alles umzusetzen, wird das umgesetzt, was den grössten Kundennutzen bringt.
In der klassischen Projektlogik heisst es oft: Wenn der Scope zu gross ist, braucht es mehr Leute oder mehr Zeit. Doch in einem agilen Setup ist die erste Frage eine andere: Was ist wirklich wichtig? Erst wenn ein stabil arbeitendes, cross-funktionales Team mit klaren Prioritäten und guter technischer Basis nachhaltig überlastet ist, macht es Sinn, über zusätzliche Ressourcen nachzudenken.
Ein hoher Work-in-Progress, viele nicht abgeschlossene Stories oder eine anhaltende Überlastung bei einzelnen Rollen (z. B. Testing, Architektur) können Hinweise darauf sein, dass das Team strukturell nicht genügt. Aber der reflexhafte Ruf nach "mehr Leuten" ist selten die beste Antwort. Besser ist es, zuerst den Flow zu stabilisieren, technische Schulden zu reduzieren und Prioritäten zu klären.
Ein gutes Beispiel haben wir bei unserem Kunden erlebt, bei dem wir als eine der ersten Massnahmen das Projektteam von ursprünglich über 20 Personen in einem ersten Schritt in Stakeholder und Projektmitarbeitende aufgeteilt haben. Dadurch entstand ein Kernteam von 5 Personen und die restlichen 15 Personen konnten sich fortan auf ihre Rolle als Stakeholder fokussieren. Erst nach drei Jahren hat das Team in diesem Jahr nun begonnen, das stabil arbeitende, cross-funktionale Team schrittweise zu erweitern.
Velocity und Burndown-Charts gehören zu den bekanntesten Messgrössen in der agilen Welt. Gerade in Organisationen, die den Wechsel hin zur Agilität absolvieren, beobachten wir oft, dass diese Charts gerne genutzt werden, um den Outcome von Teams zu messen. Doch was sagen sie wirklich aus? Velocity zeigt, wie viel relative Arbeit ein Team pro Sprint erledigt – also wie konstant und stabil der Flow ist. Burndown zeigt, wie der Sprint- oder Release-Scope über die Zeit abgebaut wird. Beide sind Werkzeuge zur Selbstbeobachtung.
Wichtig ist: Diese Charts messen Output, nicht Outcome. Sie sagen nichts über den Wert der gelieferten Arbeit für den Kunden. Deshalb sollten sie auch nicht zur Leistungsmessung oder zum Teamvergleich verwendet werden. Ihr sinnvoller Einsatz liegt in der gemeinsamen Reflexion: Wird zu viel begonnen und nicht fertiggestellt? Wird kontinuierlich geliefert? Entwickelt sich ein gesundes Arbeitstempo?
In vielen Projekten wird gemessen, wie viel umgesetzt wurde: Anzahl Stories, Features oder Deployments. Das ist der Output – also das, was produziert wurde. Doch in der agilen Welt zählt etwas anderes: Was hat die Arbeit bewirkt? Hat sie den Kundennutzen erhöht, ein Problem gelöst, einen Mehrwert geschaffen? Das ist der Outcome. Während Output sichtbar macht, wie viel erledigt wurde, zeigt Outcome, ob es sich gelohnt hat. Erst wenn wir vom Output-Denken ins Outcome-Verständnis wechseln, gestalten wir wirklich wirksame Organisationen.
Das Iron Triangle ist ein nützliches Denkmodell – wenn man es nicht dogmatisch versteht. In klassischen Projekten wird der Scope selten wirklich eingehalten, sondern mit immer neuen Ressourcen aufgeweicht. In agilen Teams hingegen ist der Scope explizit gestaltbar – was viel Disziplin und Klarheit im Umgang mit Anforderungen erfordert.
Die grösste Herausforderung ist nicht das Modell selbst, sondern wie wir damit arbeiten. Wer Agilität ernst nimmt, betreibt kein Wunschkonzert, sondern eine andere Form der Steuerung: eine, die Priorisierung, Feedback und kontinuierliche Lernprozesse ins Zentrum stellt. Und das ist alles andere als ungenau – es ist einfach nur ehrlich.