Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Weitere Informationen

Unser Tipp - Nichts verpassen!

 
 

Projektabwicklung - Wann agil, wann klassisch?

Oftmals werden wir gefragt wann welche Methode, agil oder klassisch, für die Projektabwicklung sinnvoll und zielführend ist.

Betrachtet man sich die Umfeldbedingungen und Herausforderungen, denen wir uns in den Märkten, technologischen Entwicklungen, Trends und Produktzyklen sowie der Schnelligkeit und Komplexität des Business ganz allgemein heute und verstärkt in der Zukunft gegenüberstehen, so trifft ein Begriff besonders gut auf diese Situation zu – VUCA (Volatility, Uncertainty, Complexity, Ambiguity).

VUCA steht übersetzt für Volatilität, Unsicherheit, Komplexität und Mehrdeutigkeit. Und nicht nur vor dem Hintergrund der Digitalisierung und digitalen Transformation haben diese Begriffe ihre Gültigkeit.

Volatilität meint in diesem Zusammenhang Herausforderungen, die unerwartet und unstabil sein können. Unsicherheit ist assoziiert mit Überraschungen und Herausforderungen, die kaum vorhersehbar oder prognostizierbar sind.

Komplexität führt zu Situationen für die es keine einfachen oder standardisierten Lösungsansätze gibt. Viele Einflussfaktoren und Schnittstellen, schwierige Abgrenzungen und geringe Möglichkeiten der Vereinfachung spielen hier eine Rolle.

Mehrdeutigkeit erschwert die Sicht auf Ursachen und Wirkungsbeziehungen. Welche Maßnahmen haben zu welchen Effekten geführt, lassen sich nur schwer analysieren und beantworten.

Nicht alle Herausforderungen, die mit Hilfe von Projektarbeit gelöst werden sollen stehen im Kontext von VUCA. Dennoch stellt sich die Frage, wann welcher Projektansatz, klassisch oder agil, optimal und empfehlenswert ist.

Projektansätze - Klassisch vs. agil

Der klassische Projektansatz (Project Life Cycle) basiert auf einem phasenweisen Vorgehen und geht davon aus, dass das Ergebnis des Projects in gewissem Umfang durchgängig und stabil planbar ist. Je nach dem angestrebten Ergebnis des Projekts (z.B. Software, Prozessoptimierung, Pharmaprodukt, Dienstleistung, Brückenbau etc) finden unterschiedliche Product Life Cycle-Modelle ihre Anwendung. Das bekannteste Product Life Cycle Modell ist das Wasserfall-Modell, das häufig in der Softwareentwicklung genutzt wird.

Die klassichen Project Life Cycle-Modelle sind häufig stark plan- und prozessgetrieben und haben viele Regeln und Elemente.

Project Life Cycle am Beispiel des PMBOK®-Guide 5th. Edition

Das Wasserfall-Modell geht davon aus, dass Anforderungen einmal erhoben und vollständig dokumentiert werden. Darauf aufbauend finden in den nächsten Schritten, ähnlich eines Wasserfalls, die weiteren Verarbeitungsschritte statt. Der vollständige Nutzen- oder Geschäftswert entsteht erst am Ende.

Änderungen, die in einer späten Phase, z.B. gegen Mitte/Ende der Implementierung, erforderlich werden sind mit häufig mit Terminverzug, Risiken, hohen Kosten und Aufwand verbunden, da der Wasserfall wieder neu zu laufen beginnt.

Klassischer Product Life Cycle nach dem Wasserfallmodell

Agile Ansätze – Scrum – das agile Framework

Agile Vorgehensweisen haben sich aus der Erkenntnis entwickelt, das manche Produktentwicklungen aufgrund der Komplexität, der hohen Dynamik von Veränderungen der Anforderungen, Technologien, Marktbedingungen und des Umfeldes, nicht mehr durchgängig planbar sind.

Scrum setzt auf eine inkrementelle, iterative Produktentwicklung in festgelegten Zeitfenstern (Timeboxes, 2-4 Wochen Zeitabschnitte), Sprint genannt. Nach jedem Sprint ist ein Stück Produkt entstanden mit einem bestimmten Nutzen- und Geschäftswert. Ein Backlog enthält alle Anforderungen, die jedoch im Zeitverlauf veränderlich sein können. Das ermöglicht eine adaptive Anpassung der Produktentwicklung an neue Erkenntnisse und Rahmenbedingungen (Markt, Ziele, Anforderungen, etc).

Im Rahmen der Entwicklung ist eine permanente, interaktive und enge Zusammenarbeit mit den Stakeholdern erforderlich. Weit über dem Maß, welche bei der Projektabwicklung nach klassischem Modell üblich ist.

Das Entwicklerteam ist selbstorganisierend und verwaltet sich selbst. Dadurch entsteht i.d.R. eine hohe Teammotivation mit hoher Teamperformance.

Das Regelwerk von Scrum ist einfach. Die Umsetzung in der Praxis ist jedoch anspruchsvoll aber lohnend, wie die Erfahrungen und der Verbreitungsgrad von Scrum zeigen.

Der agile Ansatz Scrum

Nachstehend eine zusammenfassende Gegenüberstellung eines ausgewählten agile und eines klassichen Ansatzes

Gegenüberstellung von Scrum (agil) und des PMBOK®-Guide (klassisch)

Stacey Komplexitäts-Matrix zur Einordnung agiler und klassischer Ansätze

Um die Anwendungsbereiche für Scrum und die klassische Projektabwicklung einzuordnen, kann das Stacey Landscape Diagramm herangezogen werden. Es wurde entwickelt von Ralph Stacey, Professor für Management.

Um zu einer ersten Einschätzung eines Projekts zu kommen und entscheiden zu können welches Vorgehen wahrscheinlich das zielführendste ist, kann die Stacey Matrix eine gute Orientierung bieten.

 

Quelle: In Anlehnung an Stacey Landscape Diagram

Die Achsen:

X- Achse: Sicherheit der Technologie meint in diesem Zusammenhang den Bekanntheitsgrad und die Beherrschung der Technologie. So werden i.d.R. sichere Technologien gut verstanden und sicher beherrscht. Bei Technologien mit hoher Unsicherheit, liegen wenig oder gar keine Erfahrungen vor oder deren Verhalten sind schwierig zu prognostizieren.

Y-Achse: Klare Anforderungen sind stabil, im Detail dokumentierbar und bei Lieferung wird genau das erhalten was auch gebraucht wird. Unklare Anforderungen sind dynamisch, nur sehr gering oder gar nicht dokumentierbar und am Ende wird ggf. festgestellt, dass eigentlich etwas anderes gebraucht wird.

Die Bedeutung der Bereiche im Diagramm:

Bereich Simpel: Hier liegt der Bereich für einfache Projekte. Ergebnisse und Entwicklungen lassen sich leicht vorhersagen und rückwirkend betrachtet ergeben sich keine neuen Erkenntnisse. Wenden Sie hier einfach Best Practices an.

Bereich Kompliziert
: Werden Anforderungen unklarer oder die Technologie unsicherer, gelangen wir in der Bereich kompliziert. Hier müssen Anforderungen detailliert erhoben, analysiert und weitere Schritte detailliert geplant werden. Ggf. müssen Prototypen gebaut, Technologiealternativen abgewogen, spezielles Know-how aufgebaut oder Experten  hinzugezogen werden. Das Verhalten sowie Ursache und Wirkungszusammenhänge sind prognostizierbar.

Hier ist eher der Anwendungsbereich für die klassische Projektabwicklung mit klassischem Project Life Cycle, beispielsweise nach PMBOK®-Guide (PMI), PRINCE2 (Axelos) oder icb (GPM/IPMA) mit sequentiellen Phasenmodellen und Wasserfall-Produktlebenszyklen.

Bereich Komplex: Je unklarer die Anforderungen und unsicherer die Technologien werden desto mehr gelangt man in den komplexen Bereich. Ursache-Wirkungsbeziehungen lassen sich nicht prognostizieren und sind erst hinterher einer Analyse wirklich zugänglich. Die Veränderungsdynamik ist hoch. Klassische Project- und Product-Life Cycle mit ihren langfristigen Planungszyklen sind nicht mehr geeignet, da sie auf eine gewisse Stabilität in der Planung sowie Vorhersagbarkeit von Ursache und Wirkung basieren.

Hier bieten sich agile Vorgehensweisen, z.B. Scrum an, die iterativ, inkrementell, adaptiv die Planung und Umsetzung angehen. Nach jedem Sprint wird überlegt, ob sich die Rahmenbedingungen geändert haben und ggf. erfolgen dann umgehend und adaptiv die Anpassungen.

Bereich Chaotisch:  In diesem Bereich laufen die Dinge eher zufällig. Ursache und Wirkungsbeziehungen sind weder vorher zu prognostizieren noch nachher zu erkennen. Glückspiele fallen z.B. in diese Kategorie. Durch geeignete Maßnahmen (Lean Startup, Hypothesenbildung, Experimentieren, Lernen) können jedoch Projekte durch Anwendung bekannterer Technologien und Schaffung von mehr Klarheit in den Anforderungen aus diesem Bereich verschoben werden.

Fazit

Agile oder klassische Vorgehensmodelle habe beide ihre Berechtigung, Vorteile und Anwendungsgebiete.

In dynamischen Umfeldern mit häufigen Änderungen der Anforderungen, Nutzung von innovativen Technologien, rasche Veränderungszyklen in den Märkten und kurzen Planungszyklen sind agile Vorgehensweisen mit inkrementellen, iterativen und adaptiven Ansätzen klar im Vorteil.

Literaturhinweise und Links

Literaturhinweise

  • Scrum verstehen und erfolgreich einsetzen, Stefan Roock, Henning Wolf, dpunkt-Verlag, 1. Auflage, 2016
  • Strategic management and organisational dynamics: the challenge of complexity, Prentice Hall, 2. Auflage, 1996

Links

Wer jetzt weiteres Interesse an Scrum - Das agile Framework oder am PMBOK®-Guide bekommen hat und sich auch ggf. zum ScrumMaster oder sich zum Project Management Professional PMP® zeritifizieren lassen möchte, dem bieten wir diese Möglichkeiten:

Scrum - Präsenzseminar, 2 Tage und Vorbereitungsseminar zu PMP-Zertifizierung, 5 Tage

https://www.gotscharek-company.com/academy/termine

eLearning Kurs : Scrum - Das agile Framework, jederzeit einsteigen und lernen wann, wo und womit Sie wollen

https://elearn.gotscharek-company.com/enrol/index.php?id=3