Agile Projektmethoden sind auf dem Vormarsch, doch nicht für jedes Projekt ist ein rein agiler Projektansatz geeignet. Daher gilt es im Vorfeld zu prüfen, wieviel Agilität bei einem Projekt angemessen ist. Insbesondere vor dem Start eines Projekts – oder währenddessen – kann die Durchführung eines Assessments mittels des Adaptiven Projekt Navigators© (APN), mit seinem systematischen und ganzheitlichen 360 Grad-Ansatz, bei der Überprüfung der Projektmethodik helfen.
„Würdest Du mir bitte sagen, welchen Weg ich von hier einschlagen soll?“, fragt Alice die Grinsekatze. „Das hängt vor allem davon ab, wohin Du gehen willst“, spricht die Katze. „Das ist mir eigentlich egal“, sagt Alice „Dann kommt es auch nicht darauf an, welchen Weg Du nimmst“, erwidert die Katze.
Dieser kurze Dialog aus dem Roman „Alice im Wunderland“ beschreibt, warum Rahmenbedingungen und Ziele eine äußerst wichtige Rolle spielen. Viel zu oft zerbrechen wir uns den Kopf über eine Lösung, ohne richtig verstanden zu haben, welches Problem konkret zu lösen ist. Wir setzen Projekte an, ohne uns zu verdeutlichen, was dieses Projekt erreichen soll. Wir gehen von klar definierten Anforderungen aus und wundern uns, dass sich diese während des Projekts ständig ändern oder wir wählen eine Projektmethodik aus, ohne sicher zu sein, ob dafür überhaupt die notwendigen Rahmenbedingungen gegeben sind.
Nicht selten hört man, dass vor allem große Projekte scheitern. Die Gründe dafür sind vielfältig: Eine unrealistische Projektplanung, eine fehlende Zieldefinition oder ein Projektteam, das nicht in die Lage versetzt wird, wichtige Entscheidungen zu treffen. Und Hand aufs Herz: Jeder von uns hat bereits selbst ein Projekt erlebt, das im Verzug war oder sogar gescheitert ist.
Agile Methoden als Allheilmittel für komplexe Projekte?
Das agile Projektmanagement, welches sich in den letzten Jahren bereits für Softwareentwicklungen etabliert hat und in nahezu allen Organisationen ein geflügeltes Wort ist, könnte auf den ersten Blick die Lösung für das oben skizzierte Problem darstellen.
Das wird auch durch die Ergebnisse der Agile Pulse Studie 2019 von BearingPoint bestätigt, in welcher nahezu die Hälfte der Befragten angaben, bereits über mehr als drei Jahre Erfahrung mit agilen Methoden zu verfügen.
Agile Frameworks wie Scrum und Kanban oder Skalierungsframeworks wie LeSS und SAFe beruhen grundsätzlich auf der Prämisse, dass viele Projekte zu komplex sind, um sie im Vorfeld bereits vollständig planen zu können. Als Antwort darauf wird iterativ und inkrementell in kleinen Entwicklungsteams in Form von Iterationen gearbeitet, deren Pläne empirisch angepasst werden und dessen Teammitglieder ihre Aktivitäten selbst organisieren. Der übergreifende Plan, das so genannte Product Backlog, wird durch die Arbeitsergebnisse in den einzelnen Phasen immer weiter detailliert und neu priorisiert. Ziel des agilen Vorgehens ist eine schnelle, transparente und kosteneffiziente Realisierung komplexer Produkte. Die zunehmende Bedeutung agiler Methoden manifestiert sich mittlerweile unbestritten und selbst veränderungsresistente Organisationen versuchen ihre Projekte zu “agilisieren”.
Ist daher ein agiles Vorgehen die Lösung aller eingangs genannter Hindernisse und wenn ja, warum können auch agile Projekte ins Stocken geraten?
Die Erfahrung zeigt, dass viele Organisationen Probleme haben, agile Arbeitsweisen richtig umzusetzen. Analysiert man die so genannten „agilen Projekte“ im Detail, deutet der Projektverlauf eher auf ein verstecktes Wasserfallmodell und umetikettierte traditionelle Verhaltensweisen hin. Mal liegt es an der Organisationskultur, mal an mangelnder Erfahrung und Konsequenz oder daran, dass die selektierte Methode schlicht und ergreifend nicht zu dem Projekt passt.
Laut dem dreizehnten „State of Agile Report“ von VersionOne aus dem Jahre 2019 stellen die fehlende Unterstützung agiler Arbeitsweisen durch das Management sowie der allgemeine Widerstand der Organisation gegen Veränderungen eine große Hürde bei der Umsetzung agiler Methoden dar. Eine noch größere Hürde jedoch bildet der Mangel an Erfahrung im agilen Arbeiten und die Unvereinbarkeit der Organisationskultur mit agilen Prinzipien. Folglich erscheint eine differenziertere Betrachtung sinnvoll.
Der 360 Grad-Ansatz unseres Adaptiven Projekt Navigators© (APN)
Insbesondere vor dem Start eines Projekts – aber auch währenddessen – kann ein Assessment, durch einen systematischen und ganzheitlichen 360 Grad-Ansatz, bei der Überprüfung der Projektmethodik helfen. Eine von uns entwickelte Software-Lösung, der Adaptive Projekt Navigator© (APN), hat sich genau diesen ganzheitlichen Ansatz als Ziel gesetzt. So kann durch die Abfrage von substanziellen Fragen in den vier Dimensionen „People“, „Scope“, „IT-Architecture“ und „Client Specifics“ festgestellt werden, ob beispielsweise eine reine agile Vorgehensweise für dieses Projekt geeignet ist. Die Ergebnisse werden anschließend durch eine Empfehlung zu den passenden Rollen, Events und Artefakten abgerundet.
Die Dimension „People“
Unsere Erfahrung zeigt, dass erfolgreiche Projekte nicht nur zielorientierte, geschulte und kompetente Mitarbeiter brauchen, sondern auch Führungskräfte, die ihre Mitarbeiter unterstützen, entwickeln und diesen vor allem vertrauen.
Dass motivierte Mitarbeiter einen wesentlichen Beitrag zum Erfolg oder Misserfolg eines Projekts leisten können, sollte mittlerweile kein Geheimnis mehr sein. Dennoch wurde dies lange Zeit von vielen Organisationen vergessen bzw. nicht berücksichtigt und so scheitern Projekte häufig an fehlender Kommunikation oder dem nicht vorhandenen Teamgeist.
Agile Frameworks unterstützen dabei, das Potential der beteiligten Menschen besser zu nutzen. Sie garantieren jedoch keinen Kulturwandel. Auch wenn agile Vorgehensweisen oft einfach erscheinen, gestaltet sich ihre Einführung schwierig. Neue Methodiken bringen Veränderungen für alle Projektbeteiligten mit sich. So wollen die Mitglieder eines agilen Teams die Eigenverantwortlichkeit nicht nur auf dem Papier lesen, sondern auch im Projektalltag leben, was mit den oft noch vorhandenen traditionellen Hierarchiestrukturen nicht kompatibel ist. Die neue Rollenverteilung kann nicht gelebt werden und man fällt in alte Strukturen zurück.
Umso wichtiger ist es also, dass vor der Einführung der Methode mit gezielten Fragen untersucht wird, ob beispielsweise das Team befugt ist, eigenständig Entscheidungen zu treffen, es bereichsübergreifend aufgestellt ist, oder über eine gemeinsame Projektfläche verfügt, die die Kommunikation fördert.
Die Dimension „Scope“
Es ist gewiss keine Neuigkeit, dass der Umfang des Projekts zu den drei grundlegenden Faktoren gehört, auf denen die Projektsteuerung aufgebaut ist. Nicht selten wird auch das Bild des „magischen“ Dreiecks genutzt, in dem die drei Größen, Zeit, Kosten und Umfang zum Vergleich Klassisch vs. Agil gegenübergestellt werden.
Während klassische Projekte den Umfang des Projekts als fest definieren und unverrückbar begreifen, um anschließend eine Zeit- und Kostenplanung vornehmen zu können, wird er bei agilen Projekten als variabler Parameter betrachtet. Hierbei bildet Feedback einen wesentlichen, festen Bestandteil des iterativen Planungsprozesses, der während der Umsetzungsphase andauert.
In der Zusammenarbeit mit unseren Kunden ist es immer wieder zu beobachten, dass viele Organisationen verstärkt über den Einsatz agiler Methoden nachdenken, um flexibler auf Anforderungen der Stakeholder und Marktveränderungen reagieren zu können.
In der Tat wäre eine Produktentwicklung mit vielen Unklarheiten auf Auftraggeberseite prädestiniert für ein agiles Vorgehen. Aber auch klassische Methoden haben weiterhin ihre Daseinsberechtigung und ermöglichen effiziente Projekte.
Der Adaptive Projekt Navigator© (APN) hilft dabei diese Dimension genauer unter die Lupe zu nehmen. Auch wenn auf den ersten Blick der Umfang eines Projekts als fix und gegeben erscheint, wie beispielsweise bei Projekten mit hohen gesetzlichen oder regulatorischen Vorgaben, kann eine gezielte Analyse des Umfangs genau das gegenteilige Ergebnis liefern.
Das muss also nicht zwangsläufig ein „entweder … oder …“ bedeuten. Denn denkbar ist, dass nach einer genauen Betrachtung des Faktors „Umfang“ auch eine Kombination der beiden Methoden zu einem Hybrid am effizientesten zum Ziel führt.
Die Dimension „IT-Architecture“
Wir vertreten die Meinung, dass die Gesamtbetrachtung der IT-Architektur eine wichtige Voraussetzung für die Auswahl der Projektmethodik ist. Empirisch betrachtet steigt der Anteil von Projekten mit IT-Bezug signifikant und wir erwarten eine noch höhere Relevanz in den kommenden Jahren.
Bei einer antiquierten und heterogenen IT-Landschaft mit komplizierten und umfangreichen Schnittstellen dürfte sich beispielsweise die Einhaltung der agilen Prinzipien „frühe und regelmäßige Lieferung“ und „inspizieren und anpassen“ als schwierig gestalten. Das gleiche gilt auch für ein klassisches Releasemanagement, schließlich sind in einem agilen Projekt häufig neue Versionen freizugeben. Dies bedeutet eine Erhöhung der Frequenz für neue Features. Während bei einem klassischen Projekt neue Versionen oder Features beispielsweise quartalsweise released werden, dauern Sprints nur noch ein bis vier Wochen. Daher benötigt man in agilen Projekten eine bessere Übersetzung und Integration von System- und Produktversionen als bei klassischen Projekten.
Ein frühzeitiges Verständnis über die Applikationen, Schnittstellen, die technische Infrastruktur und andere Rahmenbedingungen, wie zum Beispiel das Releasemanagement, hilft also zu bewerten, wie mit diesen Gegebenheiten umgegangen wird und welches Framework am hilfreichsten ist.
Die Dimension „Client Specifics“
Auch organisationsindividuelle Faktoren spielen beim Einsatz agiler Arbeitsweisen eine Rolle und werden in unserem 360 Grad-Ansatz berücksichtigt. Beispielsweise kann innerhalb dieser Kategorie die Transformationsfähigkeit und -bereitschaft einer Firma betrachtet werden. Ein Vorteil dieser Kategorie liegt in dem Antizipieren von Herausforderungen innerhalb der Organisation, welche durch die anderen drei Dimensionen nicht abgedeckt werden. Während die anderen drei Dimensionen standardisierte Fragestellungen behandeln, betrachten die Fragen in dieser Dimension vielmehr die individuellen Gegebenheiten der Organisation.
Fazit
Ein Projekt selbst oder auch dessen Umfeld sind möglichweise (noch) nicht dafür geeignet, ausschließlich nach agilen Rahmenbedingungen durchgeführt zu werden. Jedes Projekt verdient seine passende Methodik. Um einzuschätzen, ob ein klassisches, hybrides oder agiles Vorgehen für ein Projekt am besten geeignet ist, erscheint es sinnvoll, die wesentlichen Einflussfaktoren mit den Dimensionen People, Scope, IT-Architecture und Client Specifics ex ante zu betrachten. Wir würdigen diese Aspekte im Rahmen des 360 Grad-Ansatzes unseres Adaptiven Projekt Navigators (APN©).
Adaptive Project Navigator - The GPS of project management
