Wie in "Teil 1: Nicht unter falschen Vorzeichen starten: klassisch vs. agil" dargestellt, führen insbesondere Methodendogmen sowie Fehleinsätze und Missinterpretationen von Methodologien zum Scheitern von Projekten. Projektdesaster sind jedoch vermeidbar, wenn die richtigen Methodologien ausgewählt und gleichzeitig die richtigen Rahmenbedingungen geschaffen werden. Die große Frage lautet: Was bedeutet in diesem Fall "richtig"?

RICHTIG IST, WAS FUNKTIONIERT

Bevor man die im ersten Teil beschriebene "Honeymoon-Reise" eines Projekts antritt, müssen sich Auftraggeber und Auftragnehmer kritischen Fragen stellen. Es gilt, gemeinsam den "richtigen Weg" zu wählen – sich also nicht nur auf Meilensteine zu einigen, sondern auch eine sinnvolle Methode, Teamstruktur, Vertragsart, etc. zu beschließen – und diese maßgeblichen Entscheidungen transparent für alle Seiten zu dokumentieren und im Verlauf des Projekts zu optimieren. Es sind nie die Methoden, die grundsätzlich falsch sind. Es sind vielmehr die Entscheidungen bezüglich ihres Einsatzes, die oft falsch sind.

Kann man folgende Fragen mit "Ja" beantworten, hat man gute Aussichten, das entsprechende Projekt erfolgreich abzuschließen. Jedes "Nein" birgt die Gefahr eines Scheiterns.

Ist agil der richtige Ansatz und falls ja, in welcher Ausprägung?

In der Regel liegt der Ball erst einmal beim Auftraggeber. Er fordert im Rahmen der Ausschreibung eine agile Vorgehensweise. Was nicht beantwortet und häufig in Unternehmen auch nicht hinterfragt wird: Warum überhaupt? Wird agil gewählt, weil es im Trend liegt?

Die Agilität ist ein wichtiges Werkzeug, wenn man jederzeit auf sich ändernde Rahmenbedingungen reagieren können muss, oder ein Zielzustand noch nicht eindeutig definierbar ist und man sich diesem iterativ annähern muss. Sofern man zu Beginn weiß, dass man zu einem festen Datum bestimmte Ziele erreichen muss, für die die Details (Anforderungen) bereits bekannt sind, keine großartigen Änderungsbedarfe zwischendurch erwartet werden und der Auftraggeber sich nicht intensiv am Projektgeschehen beteiligen möchte oder kann, ist man mit einem klassischen Wasserfall-Ansatz gut bedient. Noch besser eignet sich sogar ein Hybrid-Modell, bei dem man zwar einen festen Scope zu Beginn definiert, Arbeitspakte für die Umsetzung des Scopes beschreibt und diese in einen Iterationsplan überführt. Der Iterationsplan beinhaltet die Arbeitspakte, die voraussichtlich in der ersten, zweiten, n-ten Iteration umgesetzt werden. Dabei behält man sich dennoch die Möglichkeit vor, auf dem Weg zum Ziel, Iteration für Iteration, auf Änderungsbedarfe (agil) reagieren zu können. In einem hybriden Modell darf es sogar zu Beginn gewisse Unschärfen im Inhalt und Umfang (Scope) geben, abhängig vom gewählten Vertragsmodell, mal mehr und mal weniger.

Bewegt man sich in einem anderen Kontext, beispielsweise in der Forschung und Entwicklung, für die eine evolutionäre Weiterentwicklung erfolgskritisch ist, eignen sich besonders hoch-agile Ansätze wie Extreme Programming (XP). Entwickelt man bestehende Produkte weiter, kann Scrum durchaus der richtige Ansatz sein – sei es bei der Weiterentwicklung von Games oder bei der Optimierung von Websites, um die Conversion Rate zu erhöhen.

Auch hier muss wieder betont werden, dass die verschiedenen existierenden Methodologien gut funktionieren, wenn sie im für sie vorgesehenen Kontext richtig eingesetzt werden. Abweichungen davon führen höchstens zu zufälligen Erfolgen und erhöhen mit jeder Änderung die Entscheidungsbedarfe. Etwa, indem man passend zum betroffenen Kontext bestimmte Werkzeuge oder Methoden durch andere, effektivere ersetzt, oder auch bestimmte Elemente weglässt, da man die Notwendigkeit ihres Einsatzes in einem ausreichenden Grad bewerten konnte. Um nicht in die Gefahr der Pseudo-Agilität zu geraten, darf man die Grundvoraussetzungen der Methode nicht unberücksichtigt lassen. Zum Beispiel müssen beim Einsatz von Scrum die Eigenständigkeit und Entscheidungsfähigkeit des Teams oder die Variabilität des Scopes gewährleistet sein da dies in der Agilität zentrale Elemente sind, um die Wertschöpfung sicherzustellen.

Kann z.B. nicht sichergestellt werden, dass einzelne Teams eines Projekts voneinander unabhängig arbeiten können, darf vor dem Hintergrund der Agilität nicht über dieses Defizit hinweggesehen werden. Die Aussage "in Scrum agieren die Teams eigenständig", löst das Problem nicht von allein. Hier muss das entstandene Defizit mittels anderer Werkzeuge des klassischen Projektmanagements, z.B. durch ein übergeordnetes Abhängigkeits- und Risikomanagement, wieder ausgeglichen werden.

Können wir das?

Diese Frage geht typischerweise mit der ersten Frage "Ist agil der richtige Ansatz und wenn ja, in welcher Ausprägung?" einher. Beide Aspekte benötigen eine ehrliche Antwort. Selbstüberschätzung ist unbedingt zu vermeiden. Während Auftraggeber und Auftragnehmer sich damit auseinandersetzen, welches Vorgehensmodell das richtige und welcher Ausprägungsgrad der Agilität sinnvoll ist, müssen beide Parteien prüfen, ob sie auch in der Lage sind, die potenzielle Methodik erfolgreich anzuwenden. Dabei gilt es, sich kritisch zu hinterfragen. Ist das Unternehmen beispielsweise an halbjährliche Releases gebunden? Oder kann im Rahmen des Projekts jede zweite bis vierte Woche ein neues Release bereitgestellt werden? Ist die Organisation bereit, die Entscheidungshoheit an das Team zu übertragen? Wenn ja, zu welchem Grad? Kann die bestehende Organisation (Prozesse, Strukturen, Tools etc.) den Erfolg des Projekts unterstützen? Sind auf beiden Seiten die erforderlichen Fähigkeiten vorhanden?