Projektmanagement: agil oder sequenziell?

Aussagen wie „Wir sind nun bei uns auch agil unterwegs.“ oder „Wir haben unsere Entwicklungsprozesse nun auch auf SCRUM umgestellt.“ kommen mir regelmässig zu Ohren, wenn ich mit Vertretern aus dem Projektmanagement oder Projektverantwortlichen aus der IT und der Softwareentwicklung spreche. Mir stellt sich jeweils die Frage, ob eine solch kategorische Entscheidung zugunsten eines bestimmten Vorgehens tatsächlich zielführend sein kann. Wäre es nicht besser, sich bei jedem Projekt zunächst Gedanken zu machen, welches Vorgehen das Geeignete wäre? Also entweder klassisch phasenorientiert und sequenziell, wobei jede Projektphase klar abgeschlossen sein muss, bevor die nächste Phase begonnen werden darf. Oder im Gegensatz dazu iterativ und unter zu Hilfenahme eines agilen Vorgehensmodells, welches das Ziel verfolgt, die Entwurfsphase möglichst knapp zu halten, um rasch ein erstes verwendbares Ergebnis zu erlangen. (In der Mathematik sprechen wir dann von Iteration, wenn eine exakte Berechnung des Zielwertes nur näherungsweise möglich ist und man sich bei jeder Iteration dem exakten Ergebniswert annähert.)

Fragen zur Entscheidungsfindung

Um eine Entscheidung für ein sequenzielles oder agiles Vorgehen oder eine Mischform beider Vorgehensweisen treffen zu können, muss man sich der Vor- und Nachteile beider Prinzipien  bewusst sein und diese mit den Rahmenbedingungen im jeweiligen Projekt abgleichen.

Ein paar wenige Fragen zu den Rahmenbedingungen  können hier bereits wertvolle erste Entscheidungshinweise geben:

• Weiss der Kunde bereits genau, was er will oder hat er nur eine ungefähre Vorstellung davon, wie die Lösung aussehen soll und welchen Funktionsumfang diese aufweisen soll?
• Ist die technische Machbarkeit der Lösung bereits zu Projektbeginn sichergestellt?
• Gibt es einen bereits fest vereinbarten Preis für die Lieferung des Projektergebnisses?
• Handelt es sich um ein grosses Projekt mit mehr als 100 beteiligten Personen?
• Handelt es sich bei der durchführenden Organisation um eine hierarchisch aufgebaute Organisation mit traditionell stark ausgeprägten Führungsstrukturen?
• Haben die Akteure im Projekt ein ähnliches Projekt bereits erfolgreich durchgeführt?
• Lassen sich bei der Projektstrukturierung bereits klare und realistisch erreichbare Meilensteine definieren?
• Sind alle notwendigen Kompetenzen zur Erreichung der Projektziele bereits zu Beginn bekannt?

Wenn Sie die meisten dieser Fragen eher mit einem Ja beantworten können, spricht einiges dafür, dass ein klassisch sequenzielles Vorgehen für die Abwicklung des Projekts als Basis besser geeignet ist als ein vorgespurtes agiles Vorgehensmodell. Dabei liegen die Gründe auf der Hand: Wenn der Kunde bereits eine ganz genaue Vorstellung davon hat, welchen Leistungsumfang er vom Auftragnehmer als Ergebnis erwartet und hierfür vielleicht sogar schon einen festen Zeitplan vorliegen hat, ab wann er das Projektergebnis produktiv einsetzen möchte, bleibt dem Auftragnehmer sowohl in finanzieller wie auch terminlicher Hinsicht nur wenig Spielraum für die Entwicklung zusätzlicher Features und Optimierungen. (Dies ist unabhängig davon, ob deren Implementierung im laufenden Prozess vielleicht viel effizienter und sinnvoller wäre als zu einem späteren Zeitpunkt.) Vereinfacht an einem Beispiel ausgedrückt: Wer ein Hochhaus mit 20 Stockwerken in Auftrag gibt, die zum geplanten Fertigstellungstermin bereits vermietet sind, wird nicht sehr erfreut sein, wenn das fertige Gebäude nur 19 Stockwerke hat, die dafür ein langfristig effizienteres Energiemanagement aufweisen. Wenn Sie die meisten Fragen jedoch mit einem Nein beantworten, sollten Sie ein agiles Vorgehen zumindest in Erwägung ziehen.

Bereits 1975 stellten Basili und Turner mit SIMPL-T erste Ansätze vor, die ein iteratives und inkrementelles Vorgehen bei der Softwareentwicklung empfehlen. Im Jahre 1986 stellte Barry Boehm das Spiralmodell vor, welches diesen Ansatz weiterverfolgte und in das bis heute noch weit verbreitete Wasserfallmodell integriert wurde: Bestimmte Phasen werden so oft durchlaufen, bis das gewünschte Ergebnis vorliegt. Also ein klarer hybrider Ansatz, welcher mit seinen  stetigen Optimierungsprozessen die Vorteile eines agilen Vorgehens  mit der Planungssicherheit eines phasengeleiteten Vorgehens kombiniert.

Der Kampf gegen Vorurteile

Ein Hauptproblem der klassischen Vorgehensmodelle liegt meines Erachtens heute in dem Irrglauben, dass klassische Phasenmodelle änderungsresistent und schwerfällig zu sein scheinen. Dies trifft  in der Praxis zwar leider oft zu, liegt jedoch nicht per se am Phasenmodell, sondern an der starren und unflexiblen Handhabung des Modells: Wer Änderungen im Projektverlauf als etwas Feindliches betrachtet, wird  weder mit einem klassischen Phasenmodell noch mit einem agilen Vorgehen ein Projekt erfolgreich abschliessen können. Agile Vorgehensmodelle müssen nicht gegen solche Vorurteile ankämpfen und so werden sie vielerorts zum innovativen Heilsbringer stilisiert.

Ein weiterer Aspekt, der beim Einsatz  eines agilen Modells wie zum Beispiel SCRUM oft nicht berücksichtigt wird,  ist die Tatsache, dass Entwicklungsteams gemäss der SCRUM-Idee eher aus Generalisten bestehen sollten. Teams, die gewohnt sind,  arbeitsteilig und spezialisiert zusammenzuarbeiten sind mit solch einem Teamsetting jedoch oftmals überfordert. Im Gegenzug gibt es eine Reihe von kleineren Organisationen, in denen srumähnlich agil vorgegangen wird, ohne dass dies den Akteuren überhaupt bewusst ist. Dies, weil Sie aufgrund Ihrer zur Verfügung stehenden Ressourcen einfach dazu gezwungen sind, einer Person mehrere Rollen im Projekt zuzuweisen. Neben den Rahmenbedingungen des Projekts dürfen deshalb auch organisationale Gegebenheiten und Gewohnheiten nicht unberücksichtigt bleiben.

Was nun?

Das Abwägen von  Vor- und Nachteilen sowie die Berücksichtigung der Rahmenbedingungen führen zu den Entscheidungskriterien für das eine oder andere Vorgehen. Dabei teile ich die von Duncan und Dörrenberg vertretene Auffassung einer flexiblen  Anwendung von Vorgehensmodellen: „Agile Methoden sind bei hoher Anforderungsunsicherheit empfehlenswert. Bei hoher Kritikalität dominieren aber nach wie vor plangetriebene Methoden“ (Duncan, Dörrenberg, 2012).