Agilität gilt häufig als Allheilmittel in IT-Projekten, aber ist das wirklich so? Und wann ist ein anderes Vorgehen erfolgversprechender? Und welche Alternativen gibt es?

Eine Antwort hierauf liefert das Cynefin-Framework. Dieses erlaubt, Aufgaben und Situationen in unterschiedliche Kategorien einzuordnen. Abhängig von der jeweiligen Kategorie kann dann die passende Vorgehensweise gewählt werden. Nicht jede Vorgehensweise passt hierbei zu jedem Kontext.

Die Situationen, die Cynefin klassifiziert sind (wir bleiben bei den englischen Begriffen): Simple, Complicated, Complex und Chaotic.

Simple:

Eine planbare Aufgabe ohne Ungewissheiten: Rasenmähen, der direkte Weg zur Arbeit, eine „normale“ Steuererklärung. Grundvorgehen: die Kategorisierung, Schätzung und Planung erfolgt aus der eigenen Erfahrung: der Weg zur Arbeit dauert 20min, Steuerklärung für einen einfachen Angestellten dauert ca. 20min, …

Complicated:

Eine Aufgabe, die unbekannte Größen enthält. Diese unbekannten Größen sind aber erfassbar (‚known unknowns‘): der Weg zur Arbeit mit Varianten je nach Verkehrslage, die Steuererklärung mit Spezialfall (z.B. für das Erbrecht muss ich eine Kollegin fragen). Grundvorgehen hier ist die Analyse, um die unbekannten Größen einschätzen zu können.

Chaotic:

Die Bombe tickt, das Haus brennt, es muss jetzt gehandelt werden – für eine Abwägung aller Möglichkeiten ist keine Zeit. Die Reaktion, nicht die Aktion steht im Vordergrund: Im brennenden Haus bleiben: Überlebenschancen 1000000:1, Sprung aus dem Fenster: Überlebenschancen 1000:1, die Situation hat sich nicht wesentlich verbessert, aber für weitere Überlegungen war keine Zeit. Völlig neue Vorgehensweisen wie die Fensterscheibe mit dem Stuhl einzuschmeißen, werden erprobt.

Neben dem Katastrophenfall können auch Alltagssituationen direkt in den Chaotic-Quadranten gleiten:

Grundvorgehen: Intuition, ungewöhnliche und schnelle Strategien sind gefragt. Ziel ist es, aus der Reaktion wieder in die Aktion zu kommen.

Complex:

Eine Aufgabe, die noch nie gelöst wurde. Es gibt unbekannte Randbedingungen, aber nicht alle sind bereits bekannt (unknown Unknowns): der Arbeitsweg wird zur Höhlentaucherei, denn diese Höhle ist noch niemals erforscht worden. Wie beim Manhatten-Projekt oder den Apollo-Missionen werden jeweils die Erkenntnisse der letzten Experimente/Missionen benutzt, um die Parameter der nächsten Experimente/Missionen festzulegen.

Und in genau diesem Quadranten glänzen agile Vorgehensweisen. Da keine Erfahrungswerte vorliegen, muss man sich selbst welche schaffen (Probe, Inspect, Adapt). Die neu gewonnenen Erkenntnisse beeinflussen das aktuelle Vorgehen.

In der Tat befinden sich die meisten Software-Projekte in diesem Quadranten. Vor Google hat noch niemand die Google-Suche implementiert und die meisten IT-Projekte sind auf ihre Weise einzigartig. Technologien müssen auf ihre Wirksamkeit geprüft werden, die Erkenntnisse daraus haben Auswirkung auf das weitere Vorgehen.

Bei zu schnell wechselnden Anforderungen besteht die Gefahr, in den Chaotic-Quadranten zu driften. Ähnliches gilt bei einem Anstieg ungeplanter Arbeit (etwa durch viele Fehler in der Produktion). Hier sollte dementsprechend die Vorgehensweise angepasst werden – man braucht keine Sprintplanung, wenn die meisten Ressourcen mit dem Fixen von eingehenden Fehlern beschäftigt sind. Erst wenn man den reaktiven/chaotischen Quadranten verlässt, lohnt es sich lang- und mittelfristig zu planen.

Was hilft diese Kategorisierung?

Das Cynefin-Framework liefert eine gute Antwort, warum eigentlich bevorzugt agile Vorgehensweisen in der IT angewandt werden – warum sich einige Teams oder Teammitglieder damit aber gelegentlich schwertun. Dies zeigt sich häufig beim Schätzen der Aufgaben bzw. den sogenannten User-Storys.

Ein typischer Stolperstein bei agilen Methoden: das Schätzen

Gelegentliches Nachhören in diversen Teams bringt zu Tage, dass viele Elemente der agilen Methoden als reine Pflichtübung absolviert werden: „Die Dailys macht man halt“ oder abgelehnt werden: „Ich kann das doch gar nicht abschätzen“.

Der letzte Satz resultiert daraus, dass man zwar agile Praktiken an dem Complex-Quadranten anwendet, aber gedanklich im Simple Quadranten steckt. Um kurz bei der Schätzrunde zu bleiben: hier geht um keine genaue Schätzung wie sie im Simple-Quadranten stattfindet („Standard-Steuererklärung 20 Minuten“). Insofern ist die Anmerkung, dass eine präzise Schätzung nicht möglich ist, ist ja erstmal korrekt. Im Complex-Quadranten ist die Schätzung eher eine Einschätzung – mein Kollege Johannes Höhne nennt es sehr anschaulich „Respekt vor der Aufgabe“.

Jetzt sind aber (zum Glück) nicht alle Aufgaben eines Sprints tatsächlich komplex. Es finden sich auch immer wieder Aufgaben aus dem Bereich Simple (Spalte in eine Tabelle hinzufügen) und Complicate (Applikationserver installieren). Aufgaben aus dem Bereich Chaotic manifestieren sich meist als ungeplante Arbeit.

Die Irritationen, die beim Schätzen auftreten sind oft Folge der Inhomogenität der Aufgaben. Hier hilft der Verweis auf Cynefin und dass die komplexe Einschätzung simpler Aufgaben mit Story Points tatsächlich nicht immer ganz glücklich ist – meist bekommen diese eine kleine Punktzahl und sind auch in wenigen Stunden abgearbeitet.

Immer Agil?

Soll man vielleicht doch nicht immer agil vorgehen? Die meisten Software-Projekte befinden sich zum deutlich größten Teil im Complex-Quadranten und sind daher mit agilen Methoden gut bedient.

Es lohnt sich allerdings, immer mal wieder zu prüfen, ob man sich tatsächlich hauptsächlich im Complex-Quadranten befindet. Beispiele, bei denen das nicht so ist:

  • Für eine wohlbekannte Anwendung werden regelmäßig kleine Erweiterungen und neue Features hinzugefügt: Simple / Complicate
  • Operations Team für Deployments und Produktionssupport: Simple / Complicate / Chaotic (bei Produktionsproblemen)

Fazit zu Cynefin

Cynefin zeigt anschaulich die Berechtigung agiler Methoden. Sie helfen im Complex-Quadranten nicht planbare Aufgaben so planbar wie möglich zu machen. Schwierigkeiten bei Schätz- und Planungsrunden haben häufig ihre Ursache, dass Aufgaben nicht den passenden Quadranten zugeordnet werden, bzw. Cynefin nicht bekannt ist.

Zu guter Letzt hilft Cynefin bei der Einschätzung, ob man in einem guten Vorgehensmodell ist: auch in der Softwareentwicklung gibt es (allerdings nicht allzu häufig) Bereiche, in denen man mit einer klassischen Wochenplanung effektiver ist als mit agilen Methoden.

Tags:

Keine Kommentare vorhanden.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.