Bei allen Agile-Softwareprojekten gibt es festgelegte Ziele: Arbeitsergebnisse, Fristen und Budgetvorgaben. Der Umgang mit diesen Beschränkungen ist oft ein heikler Balanceakt. Hier nutzen wir das schon mehrere Jahrzehnte alte Konzept des Magischen Dreiecks für die Planung, um zu erfahren, wie Agile-Softwareteams durch das Ausbalancieren der verschiedenen Variablen ins Paradies des Agile-Projektmanagements gelangen können.
Das herkömmliche Magische Dreieck
Das Magische Dreieck ist ein Projektmanagement-Modell. Es arbeitet mit Beschränkungen, die als unflexibel gelten, weil sich Änderungen an einer Beschränkung immer auch auf die anderen auswirken. Das von Dr. Martin Barnes 1969 vorgestellte ursprüngliche Magische Dreieck folgt einem Wasserfallansatz für die Produktentwicklung: Der Umfang ist fest vorgegeben, während die Ressourcen und die verfügbare Zeit variabel sind. Für ein Softwareteam würde dies bedeuten, dass es zu Beginn des Projekts die Produktanforderungen definiert und auf dieser Grundlage den Projektumfang (eine Liste mit Aufgabenelementen) festlegt. Die Ressourcen und der Zeitplan sind variabel und werden anhand des festgelegten Umfangs eingeschätzt.
- Der Umfang ist die für ein funktionierendes Produkt zu erledigende Arbeit, ausgedrückt beispielsweise in Form von Features und Funktionen.
- Zu den Ressourcen zählen das Budget und die an der Auslieferung und Umsetzung arbeitenden Teammitglieder.
- Die Zeit gibt vor, wann das Team etwas ausliefert, zum Beispiel Releases, und wann Meilensteine erreicht werden.
Der Zweck des Magischen Drecks besteht darin, Produktteams Informationen an die Hand zu geben, auf deren Grundlage sie über Kompromisse zugunsten des Unternehmens entscheiden können. Wenn Teams beispielsweise mit einem festgelegten Umfang arbeiten und nach der Hälfte des Projekts feststellen, dass das Release-Datum nicht einzuhalten ist, können sie nur zwei Variablen beeinflussen: 1.) Zeit – sie können sich mit dem späteren Release-Datum arrangieren. 2.) Ressourcen – sie können zusätzliche Mitarbeiter zum Projekt hinzuziehen, wodurch die Kosten steigen. In den letzten zwei Jahrzehnten sind eine optimale Zusammenarbeit und schnelle Reaktionen auf Kundenfeedback bei der Softwareentwicklung unverzichtbar geworden. Aus diesen Anforderungen haben sich die Agile-Methoden entwickelt.
Anwendung des Magischen Dreiecks auf Agile
Wenn du einem Team angehörst, das nach der Wasserfallmethode entwickelt oder gerade erst auf die Agile-Entwicklung umstellt, solltest du immer im Kopf behalten, welche Elemente festgelegt sind und wo es sich nur um Schätzungen handelt. Anders als beim Wasserfallmodell sind bei Agile-Projekten der Zeitrahmen und die Ressourcen festgelegt, während der Umfang veränderlich ist. Doch auch wenn sich der Projektumfang ändern kann, verpflichten sich Agile-Entwicklerteams auf feste Iterationen – bei einem Scrum-Framework sind dies die Sprints, bei Kanban die WIP-Grenzen. Es empfiehlt sich auch, die Teamzusammensetzung während des Entwicklungsprozesses beizubehalten. Wenn immer dieselben Teammitglieder an einem Produkt oder Projekt arbeiten, entstehen mehr Vertrauen und Kontinuität, wodurch das Team effizienter wird.
Der Begriff "Umfang" ist beim Wasserfallmodell und bei der Agile-Entwicklung gleich definiert: Es geht darum, welche Software entwickelt und ausgeliefert werden soll. Bei Agile liegt der Schwerpunkt allerdings auf den übergeordneten Anforderungen – es werden nicht gleich zu Anfang ausführliche, detaillierte Anforderungen formuliert. Der Produktmanager überprüft und "pflegt" (priorisiert) den Umfang eines Projekts regelmäßig in einem Tool wie Jira. Anhand von quantitativem und qualitativem Agile-Feedback aus verschiedenen Kanälen (z. B. Marktbedingungen, Kundenfeedback, Wettbewerbsinformationen) entscheidet der Produktmanager, welche Aufgaben im nächsten Sprint bearbeitet werden sollen. Da die Ressourcen und der Zeitrahmen festgelegt sind, können die Entwicklerteams leichter auf Veränderungen am Markt reagieren und schneller einen Mehrwert für Kunden schaffen. Diese Transparenz der Beschränkungen sorgt dafür, dass die Teams in Bezug auf eine konsistente, schnelle Release-Abfolge ehrlich bleiben und somit ein wichtiges Kriterium der Agile-Entwicklung erfüllen. Wenn Teams Projekte mithilfe des Magischen Dreiecks betrachten, können sie Anpassungen vornehmen, ohne ihre Pläne zu verwerfen.
Langfristige Agile-Planung und das Magische Dreieck
Wenn der Projektumfang zunimmt, werden mehr Teams und mehr Zeit benötigt. Es ist daher nicht bei allen Agile-Projekten empfehlenswert, die Ressourcen und den Zeitrahmen fest vorzugeben, während sich der Umfang ändern kann. Für die langfristige Agile-Planung ist ein flexibleres Magisches Dreieck gefragt, mit dem Teams für die Zukunft planen können, ohne die Geschäftsziele aus den Augen zu verlieren. Beispiele wären die Lean-Startup-Bewegung und das Konzept des Minimum Viable Product (MVP). Ein MVP ist als ein kleiner Satz Features (Umfang) definiert, die einen Mehrwert für Kunden schaffen. Um dieses MVP zu erreichen, müssen die Teams möglicherweise bei einem festen Umfang (Anzahl der Features) bleiben, sodass die Zeit als einzige Variable übrig bleibt (wenn beispielsweise ein Release ohne bestimmte Features nicht möglich ist, wird das Release-Datum verschoben). Erst nach der Veröffentlichung des MVP stellen die Teams auf einen variablen Umfang um.
Ungeachtet der Unterschiede zwischen dem Wasserfallmodell und der Agile-Entwicklung gibt es beim Anwenden des Magischen Dreiecks kein Richtig oder Falsch. Das Magische Dreieck soll dir helfen, auf dem Weg zu deinen Geschäftszielen die besten Entscheidungen und Kompromisse zu finden. Mit einem Tool wie Zeitleisten kannst du die Bausteine eines Plans (Umfang, personelle Ressourcen und Zeit) visualisieren, um Teams die Planung in Echtzeit zu erleichtern. Auf der Grundlage der vorhandenen Daten deines Teams in Jira kannst du bei der Planung des nächsten Produkt-Release frei mit dem Umfang, den Teams und dem Zeitrahmen experimentieren.