Agilität - Die häufigsten Missverständnisse, Teil 3

Falsch: Agil funktioniert nicht für komplexe Großprojekte

Niklas Schlimm

In diesem Teil der Artikelserie nehme ich es mit einem weiteren weit verbreiteten Vorurteil auf: „Agilität funktioniert nicht für komplexe Großprojekte!“ Ich möchte dazu erst einmal beschreiben, was Komplexität ist und wie komplexe Probleme gelöst werden können. Agile Teams organisieren und steuern sich im Rahmen der Problemlösung selbst. Der Mensch steht dabei als kompetenter Problemlöser im Mittelpunkt des Geschehens, denn er besitzt die Intelligenz, mit den komplexen und unbekannten Fragestellungen zurecht zu kommen. Abschließend weise ich noch auf Probleme hin, die im Rahmen selbst organisierter Teams auftreten können.

Ich habe selbst noch kein wirklich großes Projekt mit vielen Personen und verteilten Lokationen agil durchgeführt. Es waren aber schon Projekte mit bis zu 40 beteiligten Personen. Gehen wir mal davon aus, das Problem, das durch Großprojekte gelöst werden soll, sei „komplex“. Und wir nehmen an, die Bewältigung der Komplexität in einem Großprojekt trage maßgeblich zum Erfolg des Projektes bei. Das sind Annahmen, die viele, die in einem 20- oder sogar 100-Personen-Projekt gearbeitet haben, wahrscheinlich bestätigen würden. Im Folgenden möchte ich kurz besprechen, was „komplex“ eigentlich bedeutet und warum gerade agile Projekte zur Lösung komplexer Probleme gut geeignet sind.

Komplexität und Komplexitätsbewältigung

In seinem Artikel Komplexität – Was ist das? erklärt Fredmund Malik, was sich hinter dem Begriff Komplexität verbirgt. Der Artikel ist eine schöne Einführung in das Thema. Viele der folgenden Formulierungen sind direkt aus dem Artikel entnommen. Malik schlägt vor, Komplexität als reale, objektive Eigenschaft der Welt, sowohl der natürlichen wie der künstlichen Systeme, anzusehen. Komplexität kann dabei gemessen werden, und zwar mit Hilfe des Komplexitätsmaßes „Varietät“. Varietät ist die Anzahl möglicher, unterscheidbarer Zustände, die ein System haben kann.

In der Natur bestehen nach dieser Definition viele Systeme mit astronomisch hoher Komplexität. Wie löst die Natur das Problem der Steuerung dieser Systeme?

Zwei der wichtigsten kybernetischen Prinzipien der Natur sind Selbstregulierung und Selbstorganisation. Es sind universelle Architektur- und Funktionsgesetzmässigkeiten der Natur.Fredmund Malik

Diese beiden Prinzipien scheinen die Erklärung zu sein, wie die Natur mit der immensen Komplexität zurecht kommt. Weiterhin führt Malik an:

Natürliche Systeme haben keine Regler, sie regeln sich selbst; sie haben keine Organisatoren, sie organisieren sich selbst. […] Bei den Systemen der Natur sind Selbstregulierung und Selbstorganisation Fähigkeiten, die in ihrer Struktur eingebaut sind. Es gibt keine anderen natürlichen Systeme. In den von Menschen geschaffenen Systemen, seien es technische oder soziale Systeme oder Mischformen, kommen Selbstregulierung und Selbstorganisation meistens nicht von allein vor; sie müssen vielmehr gezielt „hineinorganisiert“ werden. […] Die Grundstrategie kybernetischen Managements lautet somit: Organisiere das Unternehmen so, dass es sich so weit wie möglich selbst organisieren und selbst regulieren kann.Fredmund Malik

Komplexitätsbewältigung in agilen Teams

Agile Vorgehensweisen sind der Versuch, ein Projekt so aufzusetzen, dass es sich so weit wie möglich selbst organisieren und selbst regulieren kann. Ich habe im ersten Teil dieser Serie einen Regelkreis gezeichnet, in dem die agierenden Systemelemente (die Teammitglieder) den Entwicklungsprozess (also sich selbst) regulieren. Es ist genau diese Eigenschaft, die ich aufzeigen wollte. Agile Projekt-Teams regeln und organisieren sich selbst. Es gibt kein formales Vorgehensmodell, das die Handlungen der Team-Mitglieder streng festlegt. Als Stellgröße für die Regelstrecke käme nicht nur das Sprint-Backlog in Frage, sondern auch eine neue organisatorische Absprache zwischen den Team-Mitgliedern oder zwischen dem Team und der Umwelt (z.B. mit dem Management). Zentraler Punkt ist: Das Team passt sich eigenständig an die zu lösende Aufgabe an.

Mein Zweifel an strengen Vorgehensmodellen lautet: Ein zu formal festgelegter Entwicklungs-Prozess engt das Team auf eine Weise ein, die es dem Team unmöglich macht, sich effizient an eine zu lösende komplexe und unbekannte Aufgabe anzupassen. Denn wenn man das Problem nicht kennt und das Problem komplex ist, dann reicht es nicht aus, sich auf einen festgelegten Prozess zur Lösung des Problems zu verlassen. Wie kann das Lösungsverfahren feststehen, wenn man das zu lösende Problem gar nicht genau kennt? In einem Fachkonzept sollte also beispielsweise nicht genau das stehen, was die Methode vorgibt, sondern genau das, was der Entwickler wissen muss, um die Anwendung zu entwickeln.

Wir sollten uns – wenn möglich (nicht immer!) – von dem Gedanken „Kontrolle durch Prozesse“ verabschieden, denn:

Einfache Systeme kann man mit einfachen Mitteln unter Kontrolle bringen. Komplexe Systeme benötigen komplexe Mittel. […] Um ein System unter Kontrolle zu bringen, benötigt man mindestens so viel Varietät (oder Komplexität), wie das System selbst hat. […] Der weit verbreitete Slogan „Keep it simple“ hat daher seine klare – allerdings eng begrenzte – Berechtigung. Wenn es gelingt, die Dinge einfach zu halten, können die Steuerungs- und Regulierungsmechanismen auch einfach sein.Fredmund Malik

Ich will es auch mal anders ausdrücken: Viele Leute sagen „Es liegt an den Personen, die das Projekt machen, ob es ein Erfolg wird oder nicht“. Wer das denkt, liegt voll auf der dargestellten Argumentationslinie. Ich erkläre mir diese Aussage nämlich so: Ein gut ausgebildeter, fachlich kompetenter Mensch (oder noch besser: ein ganzes Team) verfügt über eine enorme Varietät was sein Verhalten gegenüber den komplexen Problemstellungen des Projektes angeht. Er kennt immer eine adäquate Lösung, auch für vorher unbekannte Probleme. Keine Dokumentation eines formalen Vorgehens würde die Rolle der Leistungsträger im Projekt (und dessen Varietät im Verhalten) adäquat beschreiben können, oder? Und wenn es das nicht kann, sollen wir dann trotzdem strikt nur das tun, was tatsächlich im Vorgehensmodell beschrieben ist?

Geschrieben von
Niklas Schlimm
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.