Die Kon­texte 1 bis 4 im Orientierungs­modell beschreiben aus Sicht des Unter­neh­mens mög­liche Durch­drin­gungs­grade von Agi­lität. Die Aus­ein­an­der­set­zung mit den Kon­texten und deren Defi­ni­tion kann ein erster Schritt in der Struk­tu­rie­rung der Dis­kus­sion zu Agi­lität sein

1Es liegt eine tem­po­räre Organi­sation zur Errei­chung eines Zieles vor. Das Pro­jekt wird als einma­lige, tem­po­räre, mul­ti­dis­zi­pli­näre Organi­sation umge­setzt, um die verein­barten Lie­fer­ob­jekte inner­halb der gesetzten Anfor­de­rungen und Rah­men­be­din­gungen zu erfüllen. Mit einem Pro­jekt wird ein ein­ma­liges Pro­jektziel erreicht.

Die per­ma­nente Unter­neh­mung beauf­tragt Pro­jekte unter Beach­tung des magi­schen Drei­ecks. Agi­lität hat keine beson­dere Bedeu­tung. Dieser Kon­text zeichnet sich durch eine phasenorientier­te Umset­zung aus, die linear, inkre­men­tell oder auch ite­rativ sein kann.

2Es liegt eine tem­po­räre Organi­sation zur Errei­chung eines Zieles vor. Das Pro­jekt wird – wie in Kon­text 1 – als einma­lige, tem­po­räre, mul­ti­dis­zi­pli­näre Organi­sation umge­setzt. Die Pro­jektleitenden bestimmen über den Ein­satz der Werk­zeuge des Projekt­managements zur best­mög­li­chen Errei­chung des Projektziels.

Der rele­vante Unter­schied zu Kon­text 1 liegt darin, dass unter diesen Werk­zeugen ein­zelne agile Werk­zeuge sind. Dies können ein­fache Werk­zeuge sein, wie z. B. Dai­ly Standup-Mee­tings oder Kanban Boards zur Arbeitssteue­rung, oder aber auch anspruchs­vol­lere Werk­zeuge, wie z. B. bei einer Soft­ware-Ent­wick­lung, welche im Pro­jekt nach Scrum orga­ni­siert wird.

Der Kon­text 2 ist in der Praxis durch eta­blierte Grund­lagen des Pro­jekt­ma­nage­ments gekenn­zeichnet, die mit ein­zelnen agilen Werk­zeugen kom­bi­niert werden.

3Wie in den Kon­texten 1 und 2 liegt eine tem­po­räre Organi­sation zur Errei­chung eines Zieles vor. In wei­teren Merk­malen ist der Unter­schied jedoch deut­lich grösser: Das ite­ra­tive Vor­gehen wird zur Grund­lage der Projekt­abwicklung, wodurch das gesamte Pro­jekt als Backlog von Ele­menten beschrieben wird und das Pro­jekt­ziel nicht mehr von vor­ne­herein klar defi­niert ist. Daraus folgt, dass die Be­auftragung nicht mehr als „magi­sches Dreieck” erfolgt, denn damit würden Leis­tung, Zeit, und Budget fixiert und als Auf­trag formuliert.

In einem Pro­jekt im Kon­text 3 liegt das „um­gekehrte“ magi­sche Dreieck vor, wie es häufig mit „agilem Projekt­manage­ment“ in Ver­bin­dung gebracht wird. Dieses besagt, dass der Aspekt der Leis­tung erst im Pro­jekt­ver­lauf fest­ge­legt («geschärft») wird. Wei­terhin gehört zu einem agilen Pro­jekt­de­sign auch eine andere Orga­ni­sa­ti­ons­form: Die Rolle der Füh­rung wird auf oberster Ebene der Pro­jekt­lei­tung geteilt. Scrum bspw. unter­teilt die Füh­rungs­rolle in einem Ent­wick­lungs­team in die Rol­len des Pro­duct Owners (fach­liche Füh­rung) und des Scrum Mas­ters (metho­di­sche Führung).

Im Kon­text 3 wird folg­lich die Pro­jekt­lei­tung in min­des­tens eine Rolle ver­ant­wort­lich für Arbeits­weise sowie eine für Inhalt auf­ge­teilt. Dieser Kon­text ist den agilen Ska­lie­rungs­frame­works nahe (z. B. das Scaled Agile Frame­work in der „Essen­tial SAFe“ Kon­fi­gu­ra­tion). Ins­be­son­dere in der Soft­ware-Ent­wick­lung, aber auch in anderen Bran­chen, ist es oft mög­lich, ein Pro­jekt so zu gestalten, und damit meh­rere Scrum-Teams in der Form eines Pro­jektes zu syn­chro­ni­sieren und auf ein gemein­sames Ziel hinzuarbeiten.

4Im Kon­text 4 wird Agi­lität und das Prinzip des „Bring work to the peo­ple“ auf das ganze Pro­gramm oder Pro­jekt­port­folio ska­liert. Das heisst ins­be­son­dere, die Res­sourcen des ganzen Pro­gramms oder Pro­jekt­port­fo­lios sind als agile Teams in per­ma­nenten Umset­zungs­or­ga­ni­sa­tionen orga­ni­siert. Wäh­rend in Kon­text 3 Pro­jekte wei­terhin als tem­po­räre Orga­ni­sa­tionen erkennbar sind, ist das in Kon­text 4 nicht mehr der Fall. Umzu­set­zende Inhalte werden als Arbeits­pa­kete iden­ti­fi­ziert, for­mu­liert und durch die Umset­zungs­or­ga­ni­sa­tionen bear­beitet. In Summe wird die erwar­tete Leis­tung erbracht.

Als Konse­quenz des Kon­texts 4 löst sich der Pro­jekt­be­griff, wie ihn PMI, IPMA oder DIN defi­niert, auf. Die Auf­gaben der Pro­jekt­lei­tung werden auf die per­ma­nenten Umset­zungsorganisationen in ver­schie­dene Rollen auf­ge­teilt. Eben­falls erfolgt ein bedeu­tender Wechsel in der Form der Beauf­tra­gung: Es liegt kein Pro­jekt­auf­trag mehr vor, da die drei Dimen­sionen Leis­tung, Zeit und Budget nicht zum Pro­jektstart ermit­telt werden können. An die Stelle des Projekt­auftrages tritt statt­dessen ein per­ma­nenter Fluss an Arbeits­pa­keten, respek­tive ein Zusam­men­spiel von „Back­logs“ auf ver­schie­denen Ebenen, da vor allem auf den Nutzen und deren Wir­kung beim Kunden Fokus gelegt wird. Dieser Kon­text wird in letzter Kon­se­quenz durch die agi­len Ska­lie­rungs­frame­works wie SAFe (in der „Full SAFe“ oder „Port­folio SAFe“ Kon­fi­gu­ra­tion) und LeSS beschrieben.

Allen diesen Frame­works liegt das beschrie­bene Para­digma des „Bring work to the people“ zugrunde, wes­halb sie alle aus Umset­zungs­or­ga­ni­sa­tionen und einem Fluss an Arbeitspake­ten bestehen.