Das Agil-O-Meter, oder: wieviel Agilität verträgt Ihr Projekt?

agile gauge

agile gaugeIst Ihr Projekt ein Organismus oder eine Maschine? Seit über hundert Jahren streiten Experten über die beste Vorgehensweise im Projektmanagement. Die Diskussion verläuft zuweilen recht emotionsgeladen. Ein differenzierter Blick hilft dabei, den geeigneten Ansatz zu wählen.

Auch wenn der agile Ansatz in der Softwareentwicklung in die Jahre kommt, so bleibt er weiterhin heftig umstritten. Trotzreaktion und Leichtsinn – so fassen manche Kritiker den agilen Ansatz zusammen. Generalangriff auf die verkrusteten Bürokratismen – so sehen es die Anhänger der kompromisslosen Agilität. Das agile Manifest – Anno Domini 2001 – ist entsprechend polarisierend formuliert. Durch eine prägnante Aufstellung von Gegensätzen wird der Leser gezwungen, klare Positionen zu beziehen:

  • Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
  • Funktionsfähige Software hat  Vorrang vor umfassender Dokumentation.
  • Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
  • Das Eingehen auf Änderungen hat Vorrang vor sturer Planverfolgung.

Dieser spaltende Charakter des agilen Manifests ist nicht unumstritten. Weshalb sind zum Beispiel Faktoren wie funktionierende Software und ihre Dokumentation als Gegensätze zu begreifen? Und wenn sie keine Gegensätze sind – warum muss man sich zwischen den Extremen entscheiden? Natürlich ist in einem Auto die Bremse wichtiger als das Gaspedal – muss man deshalb das Gaspedal für überflüssig erklären?

Kenner der Materie wissen, dass Softwareexperten in einer Welt voller gegensätzlicher Anforderungen leben. Ein Softwareentwickler kann nicht einfach losprogrammieren – er muss eine Vielzahl verschiedener Rahmenbedingungen beachten. Will man schnell oder hochwertig entwickeln? Kann man die Benutzerschnittstelle beliebig gestalten oder muss man sich an strenge Richtlinien halten? Sollte man viele oder wenige Kommentare in den Sourcecode schreiben? Sollte man die Schnittstellen zentral oder in der jeweils dazugehörigen Kopfdatei dokumentieren? Welche Schnittstellen sollte man überhaupt und welche ausführlich dokumentieren? Muss das Ergebnis „fehlerfrei“ sein – oder sind kleine Defects kein Riesenproblem und gar gewollt?

Die Liste der softwaretechnischen Entscheidungsnöte erscheint schier endlos. Und nun noch dies: Brauchen wir einen wohldefinierten Prozess oder wollen wir lieber agil und ungezwungen vorgehen?

Wir machen’s jetzt agil!

Wie bei den meisten Modeerscheinungen erweisen sich marketingtaugliche Begriffe in der Praxis als wenig hilfreich. Das „Silver Bullet“-Phänomen – der Glaube, dass ein singuläres Konzept für alle Probleme einzig richtig sei – greift schnell um sich, und schon bald müssen alle Projekte grundsätzlich „agil“ sein. Gerne vergisst man, dass es eine Fülle möglicher Projektarten gibt, die nach verschiedenen Kriterien eingestuft werden können und sich mehr oder weniger für die agile oder systematische Vorgehensweise eignen. Hand aufs Herz: Wer würde freiwillig in ein Flugzeug steigen, in dem alle Softwaresysteme agil erstellt wurden? Oder sich auf einen Operationstisch legen, um sich von einer agil entwickelten Steuerung eines Laser-Skalpells die Augen operieren zu lassen? Aber auch bei weniger kritischen Projekten stellt sich die Frage, wie fehlertolerant das Projektumfeld sein darf. Probleme mit einem Massenprodukt, das von tausenden enttäuschten Kunden wegen seiner schlechten Qualität in Internetforen in Grund und Boden kritisiert wird, können für seinen Hersteller schnell existenzbedrohlich werden.

Dabei hilft die traditionelle Projekttypologie nicht weiter. Ein Beispiel dafür liefert die „Goals-and-methods matrix“ von Turner und Cochrane [1]:

Turner & Cochrane’s Projekttypisierung
Abbildung 1: Turner & Cochrane’s Projekttypisierung

 

Turner und Cochrane ordnen Softwareprojekte dem Projekttyp 3 zu (wohldefinierte Methodik bei unzureichender Zielklarheit). Ein Softwaresystem wie der Airbus-Autopilot stellt jedoch eine im Vorfeld sehr detailliert spezifizierte Lösung dar, die mithilfe genau vorgegebener Arbeitsprozesse entwickelt wurde. Zugleich begnügen sich die meisten agilen Verfahren mit einer minimalistischen Vorgehensweise bei einer sehr flexibel gehandhabten Zielsetzung und entsprechen damit eher dem Projekttyp 4.

Gesucht: bessere Projektklassifizierung

Dieser Widerspruch lässt sich damit erklären, dass Software inzwischen in sämtlichen Lebensbereichen allgegenwärtig und ihre Natur daher unglaublich vielfältig ist. Moderne Softwareprojekte können je nach ihrer Art jedem der genannten vier Projekttypen zugeordnet werden. Die einfache Typisierung greift mithin nicht mehr, und spätestens seit dem agilen Hype ist daher eine andere, feinere Differenzierung der Softwareprojekte notwendig geworden. Barry Boehm, der berühmte Guru der Softwaretechnik, erkannte bereits vor knapp zehn Jahren, dass das Thema „agil vs. planmäßig“ objektiviert werden sollte. In seinem Buch „Balancing Agility and Discipline“ [2] werden verschiedene Einflussfaktoren beleuchtet, die für oder gegen agile Vorgehensweisen in Softwareprojekten sprechen. Die fünf Entscheidungskriterien für die Wahl des richtigen Vorgehens sind nach seiner Einschätzung die folgenden:

  • Projektgröße (klein vs. groß)
  • Kritikalität (fehlertolerant vs. ausfallsicher)
  • Dynamik (instabiles vs. durchorganisiertes Projektumfeld)
  • Qualifikation des Projektteams (Top-Experten in allen Bereichen vs. Arbeitsteilung)
  • Kultur (spontan vs. rollenbasiert)

Für den praktischen Einsatz sind diese Kriterien aus folgenden Gründen problematisch:

  • Es gibt zwischen den extremen Ausprägungen dieser Faktoren viele Abstufungen.
  • Konkrete Ausprägungen der Entscheidungsfaktoren sind zum Teil voneinander abhängig.
  • Nicht jede Fragestellung lässt sich eindeutig einem der o. g. Hauptkriterien zuordnen.

Wenn es sich beispielsweise um eine Erweiterung bestehender Systeme handelt, dann ist zum einen wichtig, wie groß das zu liefernde System (inklusive der Erweiterung) sein soll, zum anderen stellt sich die Frage nach der Reife der eingesetzten Technologien. Ein kleines System mit einem sehr komplexen Innenleben (z. B. finanzmathematische Rechnungskerne) sollte besser nicht agil entwickelt werden, wogegen ein umfangreiches System, das aus bewährten Standardbausteinen zusammengesetzt werden kann, als ein agiles Projekt erfolgreich sein kann. Die Abwägung lässt sich als simpler Entscheidungswürfel darstellen:

Der Entscheidungswürfel “Komplexität/Umfang”
Abbildung 2: Der Entscheidungswürfel “Komplexität/Umfang”

 

Zur Verdeutlichung betrachten wir zwei hypothetische Projekte:

A) Entwicklung eines Autopiloten für ein Passagierflugzeug

B) Entwicklung eines neuen iPhone-Konkurrenten

Die Analyse der Systemkomplexität und des Systemumfangs ergibt die folgende Positionierung:

Einordnung einer kritischen Systementwicklung A und einer Massenproduktentwicklung B
Abbildung 3: Einordnung einer kritischen Systementwicklung A und einer Massenproduktentwicklung B

 

Diese Betrachtung liefert relative Einschätzungen; absolute Zahlen und Erfahrungswerte der Industrie sind – wie so oft in der Softwaretechnik – nicht ausreichend bekannt. Letztendlich bietet diese Betrachtungsweise daher eine auf der Erfahrung des Managementteams basierende Entscheidungshilfe.

Das Agil-O-Meter

Berücksichtigt man weitere Faktoren, die in unserem Berateralltag besonders häufig vorkommen, ergibt sich eine Bewertungsmatrix – das Agil-O-Meter®:

Das Agil-O-Meter®
Abbildung 4: Das Agil-O-Meter®

 

Unsere Beispiele – Entwicklung in der Luftfahrt (A) und Entwicklung eines Massenprodukts (B) – verdeutlichen, dass bei einem Projekt nicht alle Faktoren in die gleiche Richtung zeigen müssen. Während bei (A) das Systemalter und die Technologiereife für ein agiles Projekt sprächen, zeigen alle anderen Würfelpositionierungen eine klare Empfehlung für ein systematisches Projektmanagement auf.

Der erste Schritt ist entscheidend

Eine sinnvolle Einschätzung der richtigen Balance zwischen Planmäßigkeit und Agilität stellt eine missionskritische Aufgabe dar, die am Anfang eines jeden Projekts gelöst werden muss.

Kritikalität eines Übergangs von Agilität zur Systematik und umgekehrt
Abbildung 5: Kritikalität eines Übergangs von Agilität zur Systematik und umgekehrt

 

Wenn die Organisation einmal auf eine bestimmte Vorgehensweise ausgerichtet wurde, kann sie sich nur schwer umstellen – schon gar nicht mitten im Projektverlauf. Eine Veränderung von “agil” zu “systematisch” ist riskant, der umgekehrte Weg aufwendig. Unser Agil-O-Meter erwies sich als eine einfache Möglichkeit, die wichtigsten Aspekte eines Projekts zu diskutieren und so eine bessere Entscheidung für die richtige Projektmethodik zu treffen. Ergänzend können (und sollten) die üblichen Verfahren aus der Lehre über rationales Entscheiden angewendet werden, wie gewichtete Entscheidungsmatrizen oder Entscheidungsbäume.

Vollkommen ist das Agil-O-Meter natürlich nicht: In bestimmten Projekten könnten andere Entscheidungswürfel als die von uns vorgeschlagenen erforderlich sein. Es wird dem Projektmanager nicht erspart bleiben, sich mit vielen offenen Fragen herumzuschlagen. Das Agil-O-Meter hilft, einen differenzierten Blick auf die ansonsten häufig recht kontroverse Diskussion über die geeignete Projektmethodik zu behalten.

[1] Turner, Cochrane (1993): Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them. International Journal of Project Management 11 (2, May), 93-112.

[2] Boehm, Turner (2003): Balancing Agility and Discipline: A Guide for the Perplexed. ISBN 0-321-18612-5.

Roman Mildner
Über Roman Mildner 79 Artikel
Ich bin zertifizierter Projektmanager (PMP), Managementberater und Buchautor. Seit 1992 bin ich in der IT-Branche und seit 1998 als Managementberater tätig. Zu meinen Arbeitsschwerpunkten gehören Technologiestrategie und Prozessverbesserung, insbesondere im Bereich von Automotive SPICE. Weitere Details finden Sie hier.

Hinterlasse jetzt einen Kommentar

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*


*