Nach objektiven Kriterien entscheiden Agil oder klassisch – für jedes Projekt das passende Vorgehen finden

Agile Vorgehen haben sich mittlerweile etabliert und mancherorts klassische Vorgehensmodelle auch vollständig verdrängt. In einigen Unternehmen ist es sogar möglich, ein Projekt je nach Rahmenbedingungen agil oder klassisch durchzuführen. Doch wie können die Verantwortlichen das richtige Vorgehen ermitteln? Carsten Held verwendet hierfür ein einfaches, praxiserprobtes Tool.

 

Nach objektiven Kriterien entscheiden Agil oder klassisch – für jedes Projekt das passende Vorgehen finden

Agile Vorgehen haben sich mittlerweile etabliert und mancherorts klassische Vorgehensmodelle auch vollständig verdrängt. In einigen Unternehmen ist es sogar möglich, ein Projekt je nach Rahmenbedingungen agil oder klassisch durchzuführen. Doch wie können die Verantwortlichen das richtige Vorgehen ermitteln? Carsten Held verwendet hierfür ein einfaches, praxiserprobtes Tool.

 

Agil oder klassisch? Diese Frage treibt seit einiger Zeit zahlreiche Projektverantwortliche um. Beide Ansätze besitzen ihre (un-)bestrittenen Vorteile und haben zweifelsohne ihre Daseinsberechtigung! Praktiker und Theoretiker betonen immer wieder, dass es im selben Unternehmen, sogar im selben Projekt, durchaus Platz für beides gibt: Agile und klassische Vorgehensmodelle können koexistieren und teilweise werden sogar hybride Vorgehen propagiert!

Zudem sind viele Unternehmen und Projektleiter nicht mehr nur in einer der beiden Welten – agil oder klassisch – sondern agil UND klassisch unterwegs: Theoretisches Wissen und praktische Erfahrung ermöglichen es heutzutage, bedarfs- und fallorientiert zwischen diesen beiden grundlegenden PM-Methoden zu unterscheiden und die für das Vorhaben sinnvollste PM-Methode zu nutzen. Es ist nicht mehr nötig – und war ohnehin zu keinem Zeitpunkt der Sache dienlich –, sich im Paradigmen-Streit einem der beiden Lager "blind und stur" anzuschließen oder verpflichtet zu fühlen. Denn es gilt für beide Lager:

  • Erfolgreiche Projekte bleiben termin- sowie budgettreu und liefern die vereinbarte Funktionalität in einwandfreier Qualität.
  • Es ist niemals alles bereits im Vorfeld klar; wichtige Punkte und Fragestellungen im Sinne der Evaluation "agil oder klassisch" können zu Beginn des Projektvorhabens nur oberflächlich betrachtet bzw. beantwortet werden. Nichtsdestotrotz ist eben diese Evaluation möglich und hilfreich und mit dem hier vorgestellten Entscheidungsbaum keineswegs "Zeitverschwendung" – denn der Projektleiter bzw. die Entscheidungsträger benötigen ohnehin die für die Entscheidungsfindung notwendigen Informationen.

Der vorliegende Beitrag stellt ein praxiserprobtes Vorgehen vor, das sich bei der Entscheidungsfindung im Hinblick auf die Gretchenfrage "agil oder klassisch" verwenden lässt. Bei gegebenen Rahmenbedingungen erhält der Anwender anhand eines Entscheidungsbaums und der dazugehörigen Matrix eine Empfehlung für das geeignetere Vorgehen.

Die Sache muss entscheiden

Das geflügelte Wort: "Wer als Werkzeug nur den Hammer kennt, sieht in jedem Problem einen Nagel" darf die zwei Lager nicht mehr länger trennen. Es wird Zeit, dass hier die Sache entscheidet und nicht die Vorliebe des Projektleiters, die diktierte Marschrichtung des Unternehmens oder eines Bereichsleiters in Sachen PM-Methodologie! Es muss also die bereits in Ausgabe 10/2011 (Fachbeitrag "Agile Methoden im traditionellen Projektmanagement-Umfeld einsetzen") am Beispiel von IBM festgestellte Maxime gelten: "Pragmatismus vor methodischer Dogmatik!"

Ist die von der Organisation festgelegte PM-Methode suboptimal, können daraus eine erhöhte Fehleranfälligkeit sowie Ineffizienzen bei der Durchführung entstehen; denn ein allzu stures (und somit kopfloses/unreflektiertes) Handeln birgt Gefahren. Wer allerdings völlig frei selbst entscheiden kann, dürfte persönliche Vorlieben ins Feld führen und aufgrund mangelnder Objektivität ebenfalls nicht an der Sache und den Fakten selbst ausgerichtet entscheiden.

Ein Beispiel aus der Praxis

Aufgrund zeitlicher Restriktionen (dies ist für den erfahrenen Projektleiter absolut nichts Neues oder Ungewöhnliches) und dem Irrglauben, dass ein agiles Vorgehen schneller ans Ziel führt, wurde für die Aufgabe "Anbindung einer Kauf-Software an den zentralen internen Datenbestand/-lieferant" die Vorgehensweise Scrum gewählt – obwohl niemand im Team (inkl. Projekt- und/oder Teilprojektleiter) oder gar in der Organisation selbst Scrum-Erfahrung nachweisen konnte!

Nüchtern betrachtet, musste bei diesem Vorhaben lediglich eine Eingangs- und eine Ausgangsschnittstelle eingerichtet sowie die nötigen Datenfelder identifiziert und geliefert werden. Somit lag weder eine hochkomplexe Aufgabe vor dem Team, noch waren die Anforderungen zu Projektbeginn zu unscharf bzw. zu ungewiss und/oder einer zu hohen Änderungsanfälligkeit unterworfen! Auch wenn die Anzahl/Ausprägungen der Datenfelder – zugegebenermaßen – zu Beginn nur zu ca. 80% klar war, rechtfertigt dies wohl kaum die Vorgabe, unbedingt nach Scrum vorgehen zu müssen.

Dabei bleibt festzuhalten, und dies bestätigen Praktiker und Theoretiker gleichermaßen: Eine Zeitersparnis im eigentlichen Sinne liefern agile Methoden nicht. Sie gehen "lediglich" anders mit den Anforderungen um! (Wodurch allerdings häufig bei gleichen zeitlichen Eckpunkten und gleichem Ressourceneinsatz bedarfsgerechter geliefert werden kann.)

Der Entscheidungsbaum als objektive Entscheidungshilfe

Als Entscheidungskriterien für den Entscheidungsbaum dienen praxis-bestätigte und empirisch belegte

  • organisationale Merkmale (im Sinne der übergeordneten Unternehmensstruktur),
  • organisatorische Merkmale (im Sinne der Projektorganisation) sowie
  • bekannte Unterscheidungen, die sich unter dem Begriff der "Komplexität des Projektvorhabens" zusammenfassen lassen.

Die daraus resultierende Matrix dient im Sinne eines Entscheidungsbaums dazu, die grundlegende Wahl zwischen "agil oder klassisch" nachvollziehbar zu machen und nach bestimmten Kriterien zu treffen (und nicht rein gefühlsmäßig geleitet oder aufgrund persönlicher Vorlieben).

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 10
Kommentare 2

Alle Kommentare (2)

Michael
Plachy

Grundsätzlich finde ich den Artikel spannend. Jedoch sehe ich wesentliche Entscheidungskriterien nicht dargestellt. Eine wesentliche Voraussetzung für agiles Vorgehen ist aus meienr Erfahreung, dass der Anforder/Fachliche Auftraggeber im erhebblichen Ausmaß während der gesamten Projektlaufzeit zur Verfügung steht. Da ist sehr häufig nicht der Fall. Weiters sidn die vertraglichen Aspekte relevant. (Inhouse-Projekt vs. Vertragliche Abwicklung, Fixpreis vs. Aufwandsverrechnung. Ein weiteres Kriterium wäre aus meiner Sicht: Weiterentwicklung einer bestehenden System-Architektur Vs. Neuentwicklung eines Systems.

 

Dieter
Bertsch

Die Herleitung der Entscheidung klassisch / agile über das CYNEFIN-Modell (oder alternativ über das Diagram „Strategic Management and Organizational Dynamics“ von Ralph Stacey in Agile Software Development with Scrum von Ken Schwaber & Mike Beedle) halte ich für einen hilfreichen Ansatz.
Die Umsetzung in Ihrem Entscheidungsbaum teile ich jedoch nicht.
Zu 5: Hier fehlt mir eine Schleife, die Teams so zu strukturieren, dass sie der optimalen Größe von 7 +/- 2 Personen (also kleiner 10 Personen) entsprechen. Das sollte bei Scrum-Erfahrung bzw. bei dem Wunsch, Scrum einzusetzen, kein Hindernis für agiles Vorgehen sein (wobei m.E. die „Multifunktionalität“ der Teambesetzung wichtiger wäre wie die Größe des Teams).
Zu 6: Auch die Anzahl von mehr als 50 Personen in Projekt scheint mir willkürliche und kein echtes Entscheidungskriterium für oder gegen ein Vorgehen. Alle Projekte mit vielen Beteiligten tun sich schwer. (Für die Erstimplementierung von Scrum würde ich es nicht empfehlen; es ist aber kein Hindernis. So gibt es verschiedene Ansätze, Scrum zu skalieren, die dem Umfeld/der Kultur des Unternehmens entsprechen.)
Zu 7 (in Verbindung mit 8): Zu 'komplizierten Projekten' führen Sie bezüglich CYNEFIN aus, dass es sich um ein „geordnetes System“ handelt. Wie können Sie das beurteilen, wenn – wie unter 7. beschrieben – Anforderungen und Ziele noch unklar sind und noch signifikanten Änderungen unterliegen? Genau das sind m.E. Kriterien, die für – wie Sie es nennen – „Unordnung“ spricht. Nur durch iterativ inkrementelles Vorgehen kann ich mich hier der gewünschten Lösung nähern. Ihre Grafik (vollständige Quadrate / Anforderungen vs. Vielecke / unvollständige bzw. unbekannte Anforderungen) verdeutlicht genau dieses.
Dementsprechend kann ich in Ihrem Modell nach Schritt 7 von der „agilen Schiene“ nicht mehr zu „klassischem“ Vorgehen kommen, was m.E. Schritt 8 überflüssig macht.