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).