Maßnahmen für eine Umstellung des Projektvorgehens im laufenden Projekt
Das agile Projektvorgehen ist aus der Softwareentwicklung kaum noch wegzudenken. Seit der Unterzeichnung des „Agile Manifesto“ vor etwa zwei Jahrzehnten haben zahlreiche Unternehmen Erfahrungen mit agilen Arbeitsweisen gesammelt und auf diese Weise dazu beigetragen, Agilität als Alternative zum klassischen Wasserfallmodell zu etablieren. Trotz der vielen Jahre, in denen agile Methoden in zahlreichen Projekten erfolgreich eingesetzt wurden und auch weiterhin werden, kommt es jedoch immer wieder zu Konflikten – insbesondere dann, wenn agile Projekte in traditionell ausgerichteten Organisationsstrukturen angesiedelt sind. Wie lässt sich derartigen Kontroversen wirkungsvoll begegnen?
Die Ursachen für das erhebliche Konfliktpotential, das die Einführung agiler Methoden birgt, haben meine Kollegen Ulrike Fuchs und Benedikt Jost in ihrem Artikel „Die Zähmung des trojanischen Pferds: Agilität wirkungsvoll vorbereiten“ bereits sehr treffend beschrieben: Agilität erscheint auf den ersten Blick als leicht verständliches Konzept, dessen Grundzüge und Vorteile man im Handumdrehen begreifen kann. Aus diesem Grund werden die konkreten Auswirkungen auf die Prozesse und Strukturen eines Unternehmens häufig unterschätzt oder nicht in ihrer Gänze durchdrungen – insbesondere dann, wenn den Beteiligten zu Projektbeginn tatsächliche Erfahrungswerte in der agilen Arbeit fehlen.
Diese Problematik verstärkt sich noch, wenn ein agiles Projekt innerhalb eines Unternehmens mit traditioneller Organisationsstruktur verortet ist. Während das in solchen Organisationen häufig praktizierte klassische Projektmanagement von der Maxime ausgeht, Projekte detailliert planen und den Projektverlauf anhand dieser Planungen vorhersagen zu können, sind solche Herangehensweisen auf die agile Methodik nicht übertragbar. Im Gegensatz zum klassischen Projektmanagement, das für stabile Geschäftsumfelder prädestiniert ist, ist Agilität als Reaktion auf Geschäftsumfelder zu verstehen, die beispielsweise durch Digitalisierung, Globalisierung und zunehmende Vernetzung immer komplexer und dynamischer werden. In derartigen Umfeldern ist es kaum noch möglich, konkrete, langfristige Ziele zu definieren. Vielmehr müssen Projekte iterativ-inkrementell vorangetrieben werden, um ihnen die in den beschriebenen Kontexten nötige Flexibilität und Handlungsfähigkeit zu ermöglichen.
Wenn es den Stakeholdern an Verständnis für die Charakteristika komplexer Geschäftsumfelder und die daraus folgende Notwendigkeit der agilen Methodik fehlt, sind Konflikte vorprogrammiert. Sollten dem agilen Projekt zuvor nicht ausreichende Freiheitsgrade eingeräumt worden sein, kann es insbesondere an den Schnittstellen zur traditionellen Organisation schnell zu Reibungspunkten kommen – beispielsweise dann, wenn im Controlling oder Reporting langfristige Projektpläne und Analysen erwartet werden.
Agile Projekte sollten intensiv vorbereitet werden
Aufgrund dieser Problematik ist es für das Gelingen eines agilen Projekts in einer klassischen Organisation von entscheidender Bedeutung, dass nicht nur die unmittelbaren Beteiligten, sondern – insbesondere bei stark hierarchisch organisierten Unternehmen – sämtliche Stakeholder bereits vor Projektbeginn verstehen, was Agilität eigentlich ist. In einem ersten Schritt sollten daher das Geschäftsumfeld, die Eigenschaften des anvisierten Projekts sowie die bisherige Struktur und Kultur der Organisation analysiert werden. Kommt diese Analyse zu dem Schluss, dass sich das Projekt in einem komplexen und hochdynamischen Kontext bewegt, sollte allen Projektbeteiligten verdeutlicht werden, dass die agile Methodik die einzige Möglichkeit darstellt, in einem solchen Umfeld erfolgreich zu arbeiten. Ihre Einführung ist demnach nicht willkürlich, sondern eine Notwendigkeit. Ist dieser Zusammenhang verstanden und akzeptiert, sollte das Augenmerk darauf gelegt werden, welche konkreten Folgen die Einführung agiler Arbeitsweisen auf die Prozesse innerhalb des Unternehmens hat. In dieser Phase sollten sowohl die unterschiedlichen Erfahrungswerte mit agilen Methoden gesammelt als auch verschiedene Erwartungshaltungen formuliert werden. Auf dieser Basis lassen sich die genauen Rahmenbedingungen und Freiheitsgrade des agilen Projekts innerhalb des Unternehmens bestimmen und festschreiben.
Ein auf diese Weise zustande gekommenes Commitment aller Stakeholder ist ein wichtiger Schritt, um Konflikte im Projektverlauf zu verhindern. Eine Garantie, dass Schwierigkeiten vollkommen ausbleiben, ist es allerdings nicht. Aus diesem Grund sollten Anzeichen, dass wichtige Stakeholder innerhalb der traditionellen Organisation mit dem Projektverlauf unzufrieden sind und diese Unzufriedenheit mit der agilen Methodik in Verbindung bringen, nicht leichtfertig übergangen werden. Stattdessen sollte schon in dem Moment, in dem sich ein Konflikt abzeichnet, das Gespräch gesucht werden. In einem solchen Gespräch sollte zunächst noch einmal verständlich gemacht werden, dass die schwierig zu gewährleistende Transparenz hinsichtlich Projektkosten und -fortschritt, die häufig für Unmut sorgt, keine Folge der agilen Methodik an sich, sondern des komplexen Umfelds ist. In einem derartigen Projektkontext könnte somit selbst eine noch so detailliert ausgearbeitete Wasserfallplanung nur Vorhersagen schlechter Qualität liefern und wäre somit vor allem ein Akt der Selbsttäuschung.
Zudem ist es in agilen Projekten natürlich bis zu einem gewissen Grad möglich, Aussagen über den Projektfortschritt zu tätigen. Hierfür ist ein stabiles Projektumfeld jedoch eine zentrale Voraussetzung. Sofern ein Projektteam in konstanter Größe und Zusammensetzung über mehrere Sprints zusammenarbeiten kann, kann beispielsweise die Velocity des Teams Auskunft darüber geben, wie viele Funktionalitäten im Rahmen einer Iteration entwickelt werden können. Auf dieser Grundlage lassen sich – sofern zumindest eine grobe Zieldefinition der Anwendung vorliegt – Vorhersagen über den weiteren Projektfortgang tätigen.
Wenn derartige Lösungen den Stakeholdern nicht genügen und diese auf detaillierte langfristige Vorhersagen zum Projektverlauf bestehen, ist ein agiles Arbeiten hingegen kaum noch möglich, sodass ein Wechsel des Projektvorgehens von agil zu Wasserfall notwendig erscheint. Doch ist eine derartige Wende überhaupt sinnvoll? Die ehrliche Antwort auf diese Frage lautet: Nein. Dies hat mehrere Gründe. Zum einen berauben sich Unternehmen mit einer Abkehr von der agilen Methodik – wie bereits angedeutet – der einzigen wirksamen Arbeitsweise in komplexen Geschäftsumfeldern. Zum anderen ist eine Umstellung des Projektvorgehens im laufenden Projekt auch darüber hinaus mit erheblichen Risiken und Herausforderungen verbunden.
Zu empfehlen ist eine derartige Anpassung daher definitiv nicht. Geht dennoch kein Weg daran vorbei, existieren zwei Möglichkeiten, um die mit dem Wechsel verbundenen Risiken in Grenzen zu halten. Die aus Projektmanagementperspektive sicherlich bevorzugte Variante sieht einen klaren Cut vor: Die Entwicklung würde in diesem Fall vorerst gestoppt, um eine vollumfängliche Analyse der Anforderungen vorzunehmen. Anschließend könnte das Projekt als reines Wasserfallprojekt fortgesetzt werden. In der Projektrealität dürfte sich jedoch kaum ein Verantwortlicher auf ein solches Vorgehen einlassen. Schließlich geht durch einen Entwicklungsstopp in der Regel nicht nur Zeit, sondern meist auch Geld verloren. Angesichts dessen besteht häufig nur die Möglichkeit, das Projektvorgehen im laufenden Projekt anzupassen – und somit bildlich gesprochen ein bereits in vollem Lauf galoppierendes Pferd mit allen Konsequenzen zu einer Kehrtwendung zu veranlassen.
Drei Schritte, um einen Vorgehenswechsel im laufenden Projekt zu ermöglichen
Schritt 1: Risikoanalyse
Dass eine solche Kehrtwendung nicht vollkommen risikofrei ist, versteht sich eigentlich von selbst. Dennoch sollten die mit dem Projektvorgehenswechsel verbundenen Risiken in einem ersten Schritt analysiert und den Stakeholdern aufgezeigt werden, damit sie hinsichtlich des weiteren Projektfortgangs kompetente Entscheidungen treffen können.
Die mit einem Vorgehenswechsel verbundenen Risiken sind vielfältig: So sind die auf die Eigenarten komplexer Geschäftsumfelder zugeschnittenen Vorteile der agilen Softwareentwicklung wie die hohe Entwicklungsgeschwindigkeit, die durch die kurzen Entwicklungszyklen entstehende Flexibilität sowie die frühe und kontinuierliche Wertschöpfung – also genau die Gründe, weshalb sich Organisationen in der Regel für ein agiles Vorgehen entscheiden – bei einem Wechsel zu einem Wasserfallprojekt meist nicht mehr zu gewährleisten. In letzter Konsequenz müssen die Stakeholder damit rechnen, dass am Ende der Projektlaufzeit weniger Anforderungen umgesetzt sein werden als bei einer Beibehaltung des agilen Vorgehens bzw. die Laufzeit unter Umständen verlängert werden muss. Auch die Wahrscheinlichkeit, dass das Projekt komplett scheitert, erhöht sich durch die Umstellung deutlich. Darüber hinaus ist das Projektteam bei einem Vorgehenswechsel im laufenden Projekt nicht in der Lage, eine zeitlich sauber von der Entwicklung getrennte Analysephase vorzunehmen, in der die Anforderungen gesammelt sowie in der notwendigen Detailtiefe analysiert und dokumentiert werden können. Dadurch besteht die Gefahr, dass die Anforderungen und Komplexitäten der entstehenden Software nicht gänzlich durchdrungen werden und sich somit im Projektverlauf Herausforderungen und Schwierigkeiten entwickeln können, die in einem von Beginn an als Wasserfall geplantem Projekt vermeidbar gewesen wären.
So ist einerseits nicht auszuschließen, dass das Projektteam aufgrund der vergleichsweise rasch durchgeführten Analyse nicht alle Kundenwünsche korrekt verstanden hat und fälschlicherweise etwas umsetzt, das nicht hundertprozentig den Anforderungen entspricht (eine derartige Fehlentwicklung würde im agilen Vorgehen frühzeitig erkannt und angepasst werden). Anderseits kann es passieren, dass eine Anforderung in ihrem Umfang falsch eingeschätzt wird und dadurch unter Umständen das Budget nicht eingehalten werden kann.
Schritt 2: Aufwandsschätzung im laufenden Projekt
Sollten sich die Stakeholder trotz der in der Risikoanalyse aufgeworfenen Argumente weiterhin für einen Wechsel des Projektvorgehens entscheiden, erfolgt im zweiten Schritt parallel zur Entwicklung die angesprochene Analyse. Hierzu werden sämtliche Anforderungen, die nicht bereits im agilen Vorgehen umgesetzt worden sind, gesammelt und innerhalb des Projektteams in ihrer Komplexität und dem zeitlichen Aufwand ihrer Umsetzung eingeschätzt. Aufbauend auf dieser Schätzung kann anschließend der weitere Projektverlauf bis zum anvisierten Go-Live geplant werden.
Um gegenüber den Stakeholdern eine möglichst verlässliche Prognose abgeben zu können, wann die Software mit sämtlichen dokumentierten Anforderungen geliefert werden kann, sollten die Entwicklungsaufwände in der Analysephase aus zwei Gründen eher konservativ geschätzt werden. Zum einen ist – wie oben bereits beschrieben – die Gefahr, dass der Aufwand aufgrund der fehlenden intensiven Analyse unterschätzt wird, hoch.
Zum anderen kann der fehlende klare Cut zwischen agiler und Wasserfall-Projektphase dazu führen, dass man von Stakeholdern auch nach dem Wechsel des Projektvorgehens als ein im Grunde agiles Projekt angesehen wird. Aufgrund dieser Zwitterstellung kann es leicht passieren, dass Projektbeteiligte aus alter Gewohnheit weiterhin neue Anforderungen in das Projekt einbringen oder ihre Meinung zu bereits gefällten Entscheidungen ändern. Durch diese Haltung wird die eingeführte Wasserfallmethodik jedoch ihrer Stärken beraubt. Eine klare Abschätzung von Aufwand und Kosten ist schließlich nur schwer möglich, wenn sich Anforderungen auch nach der Umstellung von agil zu Wasserfall noch verändern.
Um auf solche Schwierigkeiten vorbereitet zu sein, empfiehlt sich für die Aufwandsschätzung die Arbeit mit sogenannten T-Shirt-Größen, die es dem Projektteam erlauben, für den Entwicklungsaufwand eines gewissen Features eine bestimmte Spanne statt einem konkreten Schätzwert in Personentagen oder Story Points anzulegen. So kann beispielsweise die T-Shirt-Größe M eine Spanne von 5 bis 8 Personentagen umfassen, während die T-Shirt-Größe L einen Aufwand von 13 bis 21 Personentagen umschreibt. Auf diese Weise können auch Best- und Worst-Case-Szenarien, die eventuell im weiteren Projektverlauf auftreten werden, bei der Schätzung aber noch nicht absehbar sind, bereits bei der Aufwandsschätzung berücksichtigt werden. Aus Gründen der Transparenz und Akzeptanz sollten die Stakeholder über dieses Verfahren jedoch informiert und im Idealfall auch aktiv eingebunden werden, um spätere Missverständnisse zu vermeiden.
Schritt 3: Integration des neuen Vorgehensmodells in den Projektalltag
Im dritten Schritt gilt es, das neu gewählte Vorgehensmodell in den Projektalltag zu überführen. In diesem Zusammenhang spielt das betroffene Projektteam selbstverständlich eine Schlüsselrolle. Getreu der Devise „Mache Betroffene zu Beteiligten“ sollte die Information der Mitarbeiter und die Diskussion der Hintergründe daher zunächst oberste Priorität haben. Eventuell aufkommende Kritik sollte hierbei angenommen und ehrlich und wertschätzend besprochen werden. Verantwortliche sollten demnach nicht versuchen, Kritiker von der Richtigkeit eines Schrittes zu überzeugen, von dem sie eventuell selbst nicht überzeugt sind, sondern sie dazu bewegen, den Wechsel des Projektvorgehens trotz ihrer verständlichen Bedenken mitzutragen.
Da jedes Projekt und jedes Team anders ist, existiert für diese kommunikative Arbeit kein Patentrezept, sodass Fingerspitzengefühl und individuelle Herangehensweisen nötig sind, um das Team auf dem neu eingeschlagenen Weg mitzunehmen und gemeinsam nach neuen praktikablen Prozessen zu suchen. Schließlich sind an dieser Stelle mehrere Varianten denkbar. So besteht neben der Möglichkeit, den Wechsel zum Wasserfallmodell auch im Projektteam vollständig zu vollziehen, auch die Option, die agile Methodik zu einem gewissen Grad beizubehalten. Beispielsweise könnte den Entwicklern und der QA, deren direkter Kontakt zu Stakeholdern außerhalb des Projektteams in der Regel begrenzt ist, weiterhin ein agiles Arbeiten in Sprints ermöglicht werden. Die Schnittstelle zwischen der klassischen Organisation und dem weiterhin agilen Kernteam zöge sich in diesem Fall durch das Projektmanagement und die Business Analyse, welche die klassisch ans Projekt herangetragenen Anforderungen und die agil erarbeiteten Ergebnisse für die jeweils andere Seite zu übersetzen haben. Dadurch wird auch die Rolle des Projektleiters zu einem gewissen Grad neu akzentuiert: So muss er nicht nur in der Lage sein, die unterschiedlichen Interessen an der Schnittstelle zwischen klassischer Organisation und agil arbeitendem Kernteam auszuhalten und zu moderieren, sondern sich auch verstärkt als Kommunikator und Motivator verstehen.
Fazit
Die Antwort auf die Frage, ob ein Projekt agil oder getreu der Wasserfallmethodik umgesetzt werden soll, erscheint vielen Entscheidern noch immer als Ergebnis eines willkürlichen Entscheidungsprozesses. Dementsprechend ist in vielen Organisationen der Irrglaube verbreitet, man könne sich anhand weicher Kriterien wie den persönlichen Vorlieben oder der bisherigen Unternehmenskultur für eine der beiden Varianten entscheiden und bei Nichtgefallen zur jeweils anderen wechseln. Doch so einfach ist es nicht: Nicht persönliche Neigungen oder kulturelle Erwägungen bestimmen die Auswahl des passenden Ansatzes, sondern die gegebenen Rahmenbedingungen, die auf Organisationen und Projekte einwirken.
Organisationen sollten der Analyse dieser Rahmenbedingungen daher schon vor Projektbeginn mehr Aufmerksamkeit schenken, um die für ihre Situation richtige Wahl zu treffen. Gerade in Zeiten, in denen immer mehr Geschäftsumfelder durch Digitalisierung, Globalisierung und Vernetzung komplexer und dynamischer werden, müsste diese Entscheidung immer häufiger zugunsten agiler Methoden ausfallen. Dennoch kommt es immer wieder vor, dass die Einführung agiler Arbeitsweisen – ob aufgrund persönlicher Vorlieben, Druck von Vorgesetzten oder Unverständnis – wieder zurückgenommen wird. Insbesondere im laufenden Projekt ist ein solcher Wechsel des Projektvorgehens mit erheblichen Risiken und Herausforderungen verbunden und definitiv nicht empfehlenswert. Sollte eine derartige Umstellung dennoch unumgänglich sein, können die in diesem Artikel vorgestellten Maßnahmen dabei helfen.