Klassisch versus agil oder doch beides?

Die Wahl der Projektmanagement-Methode entscheidet oft schon vor Projektbeginn zwischen Jubel oder Klagen!
Klassisch? Oder doch agil? Oder ein bisschen von beidem?

Die Herausforderungen bei klassischen Modellen (V-Modell, Wasserfall-Modell) sind bekannt:

• Die vorgelagerte Anforderungsanlayse ist anfällig dafür, dass nicht wirklich benötigte Funktionalitäten formuliert werden.
• Das frühe Abschließen der Planungs- und Spezifikationsphase führt zu einem Verlust von Flexibilität bezüglich nachfolgender Änderungen.
• Repräsentative Ergebnisse liegen erst zum Projektende vor – hohe Erwartungen werden oftmals nicht erfüllt.

Diese Problemstellungen führten zu den Prinzipien neuerer agiler Methoden:

• Ein Produkt wird inkrementell und in kurzen Iterationen erstellt.
• Die Zufriedenstellung des Kunden durch frühe und kontinuierliche Lieferung brauchbarer Produktteile hat höchste Priorität.
• Anforderungsänderungen sind in jedem Stadium möglich.

So weit, so gut! Oft führt dies aber zu neuen Fragestellungen:

• Wie kann ich sicherstellen, dass der gesamte Leistungsumfang auch wirklich mit dem zur Verfügung stehenden Budget abgedeckt wird?
• Wie erfülle ich die Erwartungen des Top-Managements / der Budgetgeber bzgl. langfristiger Meilensteine, des Leistungsreportings?
• Wie verfahre ich bei Ausschreibungen, wo ich sicherstellen muss, dass wirklich alle benötigten Anforderungen geliefert werden?

Analysen von Projekten zeigen genau diese Themen (Kontrollverlust, Widerstand im Management, Mängel an Dokumentation, …) als die Schwächen bei der Durchführung von Projekten nach agilen Methoden. Berechtigte Punkte, auf die man beim geplanten Aufsetzen eines agilen Projektes eingehen muss! Im Einzelfall kann dies auch zu Modell-Mischformen führen, d. h. zum Einführen eines klassischen Projektüberbaus mit Projektlenkungsausschuss, Projektauftraggeber und einem operativen Projektmanager für die im Scrum-Framework definierten Rollen, wie Product Owner, Scrum Master und die anderen Team-Mitglieder.

Baue ich mein Haus auf Sand?!

Eine besondere, da nicht wirklich sichtbare, zusätzliche Herausforderung in agilen Projekten wird als „Technische Schuld“ (technical dept) bezeichnet. Während die Anwender (Product Owner) die positiven und negativen Aspekte einer Software in Form von Funktionen (Features) und Fehlern (Bugs) klar identifizieren können, liegen andere Aspekte (technische Stabilität) im Verborgenen.
Im positiven Sinn liegt der Software eine durchdachte, gut dokumentierte Architektur zugrunde, die in puncto Wartbarkeit und Weiterentwicklungspotentialen keine Wünsche offenlässt. Im negativen Sinne ist hier das Gegenteil der Fall und es tut sich eine technische Schuld auf. Da bei agilen Projekten die Funktionen Zug um Zug und nicht nach einer ausführlichen vorgelagerten Planungsphase entstehen, sind diese dafür besonders anfällig. Derartigen Entwicklungen muss durch laufend eingeplante Dokumentations- und Refactoring-Tasks entgegengewirkt werden, um sicherzustellen, dass die Software neben den sichtbaren Funktionalitäten auch ein solides Fundament bekommt, wartbar bleibt und zukünftige Weiterentwicklungen nicht verunmöglicht werden. Eine geeignete Infrastruktur mit Versionierung, Buildmanagement sowie automatisierten Tests sind dabei zusätzlich unterstützend.

Zusammenfassend bieten agile Methoden vielversprechende Werkzeuge, um Projekte erfolgreich abzuwickeln. Sie lösen Probleme der klassischen Methoden, bringen aber andere Herausforderungen mit sich, die es zu kennen und denen es entgegenzuwirken gilt.

Was sind Ihre Erfahrungen? Über Ihr Feedback würden wir uns sehr freuen!