Wie setzt man das Cynefin Framework für Agilität ein?

So finden Sie heraus, welche Projekte sich agil umsetzen lassen
Der Übergang von einer traditionellen hierarchischen zu einer modernen nicht-hierarchischen Struktur ist in Unternehmen oft nicht einfach zu bewerkstelligen. Wann ist der ideale Zeitpunkt dafür, zusätzlich zum hierarchischen Organigramm ein zweites, agiles Organigramm aufzubauen? Und welche Projekte können überhaupt agil umgesetzt werden?

Entscheidungsgrundlage: das Cynefin-Framework
Als eine wichtige Grundlage, um zu entscheiden, welches Vorhaben oder Projekt sich für ein agiles Vorgehen eignet, hat sich das Cynefin-Framework bewährt. Es ist eigentlich ein Wissensmanagement-Modell, das Dave Snowden 1999 entwickelt hat und das seit Anfang der 2000er-Jahre auch als allgemeines Strategiemodell dient. Das Framework hilft unter anderem, Kontext-Typologien zu definieren und Richtlinien in komplexen Umfeldern zu finden.

Das Framework ist in vier Quadranten unterteilt, die den ansteigenden Komplexitätsgrad abbilden:

Vorhaben und Projekte können anhand dieser Quadranten unterschiedlichen Komplexitätsstufen zugeordnet werden:

• Wenn zu Beginn eines Projekts oder Vorhabens das zu erreichende Ergebnis ebenso bekannt ist wie der Weg dorthin (wie im produzierenden Gewerbe, z. B. in der Automobilindustrie), dann handelt es sich um ein einfaches Projekt im Sinne des Cynefin-Frameworks.
• Bieten die Rahmenbedingungen eines Projekts oder Vorhabens mehr bekannte als unbekannte Faktoren, dann ist es als kompliziert einzustufen.
• Wenn das Projekt mehr unbekannte als bekannte Rahmenbedingungen aufweist, dann ist es komplex.
• Sind die Rahmenbedingungen eines Projekts komplett unbekannt, dann ist es im Sinne des Cynefin-Frameworks als chaotisch einzustufen.

 

Nicht alle Projekte können agil umgesetzt werden

Grundsätzlich gilt: Alle Projekte, die im ersten, zweiten oder dritten Quadranten des Cynefin-Frameworks angesiedelt sind, lassen sich iterativ bzw. agil umsetzen. Das heißt jedoch nicht automatisch, dass eine agile Umsetzung in all den Fällen auch Sinn macht. Scrum bspw. bringt einen recht großen Overhead an Regelbesprechungen, Terminvereinbaren etc. mit sich. Gerade für Projekte im ersten und zweiten Quadranten wäre der Verwaltungsaufwand deutlich zu hoch, denn die einzelnen Umsetzungsschritte, die gegangen werden müssen, liegen meist recht klar auf der Hand. Die Faustregel dazu lautet: Wenn es Best- oder Good-Practices gibt, ist eine agile Umsetzung i.d.R. nicht von Vorteil.

Sobald ein Projekt im dritten Quadranten und damit als komplex eingeordnet wurde, ist klar: Weil noch mehr Faktoren unbekannt sind als bei den lediglich komplizierten Projekten braucht es nicht nur ein iteratives Vorgehen, das relativ lose ist und mit dem man einen Schritt nach dem anderen tun kann (wie Kanban), sondern es wird auch ein Regelwerk für Teams benötigt. Denn diese Projekte sind in der Regel größer und binden mehr Menschen mit ein. Die Herausforderung in diesen Projekten ist es immer, die Arbeitsweise zu strukturieren, denn dies frisst Produktivitätsfaktoren. Deshalb geht es ab hier nur noch mit Scrum – es bietet genau dieses Regelwerk, das Abläufe und Besprechungen klar vorgibt. Der Product Owner kann sich dann gezielt darauf fokussieren, das Unbekannte bekannt zu machen. Mit dem Scrum Master hat er jemanden an seiner Seite, der ihn unterstützt: Das, was der Product Owner als Priorität festlegt, setzt das Entwicklungsteam um und der Scrum Master hält dem Team dabei den Rücken frei, fokussiert sich auf Produktivitätsverbesserungen und entwickelt das Team, die Rollen und jedes Individuum in sich im agilen Reifegrad. Je nach größe des Projektes, kommen für solche Projekte sogar skalierte Scrum Framework wie Spotify, Less, Scrum @ scale oder Nexus infrage. Anfangen sollten sie aber mit einem Scrum Team.

Wenn sich ein Projekt im vierten Quadranten befindet, ist das Ziel es schnellstmöglich in Quadrant drei überzuführen. Dazu muss zumindest ein wenig was bekannt gemacht werden. Dafür gibt es Methodiken wie „Design Thinking“ oder „Brainstorming“.

 

Der perfekte Moment, in die agile Welt zu gehen

Innerhalb eines hierarchisch strukturierten Organigramms wird zu Beginn eines Projekts häufig ein Vorprojekt oder eine Prestudy gestartet. Deren Ziel ist es, die Zahl der vorhandenen unbekannten Faktoren zu reduzieren. So kann das eigentliche Projekt dann beispielsweise aus dem dritten Quadranten des Cynefin-Frameworks („komplex“) in den ersten Quadranten („einfach“) verschoben werden. Anschließend ließe sich das Projekt nach der Wasserfall-Methode managen.

Der Haken daran: Das funktioniert so nicht! Ich kenne kein Projekt, in dem das funktioniert hätte! Denn in den Prestudys sind sich die Beteiligten oft sehr schnell einig: „Das hier ist out of scope, das Betrachten wir gar nicht! Lass uns lieber die Betrachtungsweise auf ein Minimum reduzieren!“ Aber ganz ehrlich: Wenn man das tut, kann man sich gleich die gesamte Prestudy schenken.

Dieser Moment – wenn das Betriebssystem 1 ein Projekt vorhat, das unabhängig von anderen, bereits umgesetzten Projekten läuft, und die beteiligten Personen überlegen, eine Prestudy zu machen – ist vielmehr der perfekte Zeitpunkt, das agile Organigramm aufzubauen und die ersten Schritte in der agilen Welt zu machen.

Es gilt also zuerst zu definieren, ob das anstehende Projekt ein isoliertes, freies Projekt ist oder ob sich dieses Projekt in zu großer Abhängigkeit von anderen Bereichen bzw. Schnittstellen im Betriebssystem 1 befindet – wie es bei einem Projekt der Fall ist, das seine erste Phase schon durchlaufen hat und nun in die zweite Projektphase eintritt. Ist das Projekt dagegen unabhängig und frei, dann kann es ganz ohne Prestudy agil umgesetzt werden.