Agiles Projektmanagement – eine Übersicht

Wo man auch immer man sich zum Thema Entwicklung trifft und austauscht, fällt das Wort „agil“. Manchmal hinter vorgehaltener Hand als DER Tipp – manchmal in Bezug auf eine Methode.

Wer bei Wikipedia nachsieht, wird die Bedeutungen „beweglich“ und „flexibel“ finden. Das klingt ja schon mal ganz brauchbar. Im allgemeinen Sprachumgang wird „agil“ eher in Verbindung mit rüstigen Menschen verwendet.

So lange wollen wir nun nicht warten. Beweglichkeit und Flexibilität können wir auch schon in jüngeren Jahren – in früheren Entwicklungsstufen – gut einsetzen.

Ist „agil“ sein jetzt nur eine Modewelle? Wenn ja, wieso brauchen wir beim Projektmanagement eine solche? Haben wir nicht schon genug theoretische Lösungskonzepte mit zu wenig praktischer Umsetzung? Wie soll uns diese Agilität weiter bringen?

Um Antworten auf diese Fragen zu finden und den Mystizismus auf reale Beine zu stellen, blenden wir zuerst 11 Jahre zurück. Die Wirtschaft war damals geprägt durch:

• Erzeugte Features und Produkte, die nie zum Einsatz kamen (Studien haben ~60% nicht verwendete Funktionalität aufgezeigt!)
• Erzeugte Features und Produkte, die nicht den geplanten Nutzen brachten
• Fehlerhafte Produkte
• Sich ständig ändernde Situationen und Rahmenbedingungen
• Zu lange Lieferzeiten und ständige Lieferverzögerungen
• Kostenexplosionen

17 Vertreter der „leicht gewichteten Ansätze“ trafen sich 2001 und plauderten über Lösungsszenarien zu diesen wenig zufriedenstellenden Ergebnissen. Die Überzeugung über sinnvolle Alternativen mündete in der agilen Allianz mit folgenden Grundsätzen:

Die Aussagen sind dann wie beabsichtigt angekommen, wenn beide Teile der Aussagen je Zeile als wichtig erachtet werden, aber die Ziele der linken Spalte über diejenigen der rechten gestellt werden.

Mit diesen Erkenntnissen wurde nahezu mit allen bekannten Wirtschaftsmustern gebrochen, denn mit den herkömmlichen Vorgehensweisen und Methoden war eine Verbesserung nicht mehr machbar.

Manchen sprechen bereits von Agilität, wenn lediglich Flexibilität in der Konfiguration angeboten wird und/oder Module wahlweise eingesetzt werden können. Diese Einreihung zeugt von einer Fehlinterpretation der kennzeichnenden Begrifflichkeiten Sichtbarkeit und Flexibilität.

Dabei handelt es sich bei Letzterem vielmehr um den Zugang zur Wahrnehmung und mentale bzw. abwicklungstechnische Einstellung zu Prioritäten des Unternehmens.

Um dies zu erreichen und auch der menschlichen Natur Rechnung zu tragen, werden andere Systematiken im Umgang mit Unschärfe und/oder Änderungen der Anforderungen eingesetzt. Diese führen letztendlich zu der Haltung, Detailentscheidungen erst so spät als möglich einzuholen. Weil erst im Laufe der Entwicklung ausreichend brauchbare Erkenntnisse über die gewünschten Produktcharakteristika entstehen. Die hier dargestellte Vorgehensweise führt sogar zum Ansatz, Änderungen zu „umarmen“. Eine äußerst intensive Art eines Zeichens des Willkommens. Wer genauer hinsieht, wird den dahinter liegenden Grund nachvollziehen können. Denn diese Informationen machen sehr oft den wesentlichen Unterschied in deren Anwendung und damit am Markt aus.

Um die gegenseitigen Ideen von Kunde und Entwickler „be-greif-barer“ zu gestalten, ist deswegen die ständige Einbindung der Kundenseite und deren Mitarbeit während der gesamten Erstellung absolut erforderlich.

Die Wahrscheinlichkeit, Manifestationen gleich welcher Art herzustellen, welche nicht im gedachten Umfang genutzt werden oder gar gänzlich in der Schublade verschwinden, ist dadurch stark reduziert. Alle beteiligten Teammitglieder identifizieren sich viel mehr mit den umgesetzten Lösungen.

Wobei frühe, verlässliche Liefermöglichkeiten fertiger einsatzfähiger Teilprodukte samt tatsächlichem Einsatz mit erwarteter Nutzenentfaltung angestrebt werden.

Die Kombination aus dieser Sichtbarkeit – Mitarbeit – frühem Einsatz ermöglicht durch die Auseinandersetzung samt breiter Akzeptanz der selektierten Lösungsvarianten oft Realisierungen höherer Ordnung und damit erweitertem Nutzen. Wobei bei der Beschaffenheit statt Perfektion der „fit-for-purpose“-Ansatz im Vordergrund steht. Damit ist nichts anderes gemeint, als genau das zu erstellen, was tatsächlich für den geplanten Einsatz gewünscht und benötigt ist. Weder zu wenig noch zu viel (das sogenannte „Gold-plating“).

Erst die erfolgte Umsetzung dieser Haltung bringt uns dem beabsichtigen Denken der Agilität nahe.

Aus diesem Generalansatz entstanden diverse unterschiedliche Ausprägungen. Die einen konzentrierten sich auf agile Produktentwicklung, andere auf spezielle Entwicklungsmethoden für Software oder auf agiles Projektmanagement.

Zu diesem Bündel gesellten sich noch weitere komplementäre Vorgangsweisen aus der Welt des hochproduktiven Arbeitens in Asien – der Lean-Welt.

Unsere weiteren Detailbetrachtungen führen wir anhand des Vorreitermodells für agiles Projektmanagement – AgilePM™ – durch. Weil sich AgilePM™ bei einem Klassifizierungsansatz über eine Basisrubrik „Agile Delivery and Engineering Practices“ und den darauf folgenden Bereichen „Agile Team Management Practice“ sowie „Agile Project Management Practices and Project Lifecycle“ bis hin zu „Corporate and other Practices“ erstreckt.

Extreme Programming als Vertreter der Basisrubrik findet insbesondere im Software-Engineering seinen Fokus und ist damit sehr spezifisch. Scrum als bekannteste Methode wird in der Produktentwicklung eingesetzt und wird dem Segment der „Agile Team Management Practices“ zugeordnet. AgilePM™ passt für alle Aufgaben agiler Anwendungen und besonders denjenigen mit hoher Skalierbarkeit.

Die Bandbreite des agilen Vorgehens reicht von der IT über die Organisations-entwicklung, Forschung & Entwicklung & Innovation bis hin zum Bauwesen. Das Mitwirken des Kunden während des Entstehens und damit das schnelle Feedback sind in jedem dieser Fälle von enormen Vorteil. Gerade bei Aufgabenstellungen mit dem Hauptaugenmerk Kreativität unterstützt ein systematischer Lösungsprozess die Effektivität der vorhandenen Mittel.

Bei AgilePM™ gliedert sich dieser in die Phasen „Pre-Project“ (adressierte Aufgabe im Unternehmen), „Feasibility“ (Lösungsansatz und Nutzen), „Foundations“ (fundierte Ausgangsbasis für die Umsetzung), „Evolutionary Development“ (iteratives und inkrementelles Entwickeln der Lösung), „Deployment“ (Ausrollen und Integration in die Geschäftsabläufe) sowie „Post-Project“ (Reflektieren und Messen der Ergebnisse). Wobei die Teile „Evolutionary Development“ sowie „Deployment“ mehrfach sequentiell als auch parallel platziert werden können.

Quelle: Agile Project Management Handbook 2.0, DSDM Consortium

Diese multiplen Architekturvarianten geben der zu realisierende Idee viel Raum und die erforderlichen Leitplanken.

Begleitende Rollen sind:

1. „Business Sponsor“ (Eigentümer des Business Case – strategische Ausrichtung – finanzielle Mittel – Eskalation)
2. „Business Visionary“ (Kommunikator, Promotor, Entscheider über Muss-Anforderungen)
3. „Technical Co-Ordinator“ (technische Richtlinien)
4. „Project Manager“ (Koordination der übergeordneten technischen und kaufmännischen Aspekte)
5. „Team Leader “ (Detailaspekte je Team)
6. „Business Ambassador“ (Kundenvertreter im Lösungsteam)
7. „Business Analyst“ (verbindet Unternehmen mit Umsetzung)
8. „Lösungsentwickler“ (Entwickler der Lösung)
9. „Lösungstester“ (Prüfer)
10. „Business Advisor“ (fallweise eingesetzte Fachspezialisten aus dem Unternehmen)
11. „Workshop Facilitator“ (führt fachlich unabhängig den Workshop-Prozess)
12. „DSDM-Coach“ (Spezialist für die Methode)

Die Rollen von 1 – 4 werden der Gruppe „Project“ zugewiesen. Die Gruppe des „Solution Development“ besteht aus den Rollen 5 – 10. Die letzten beiden sind Sonderrollen.

Die Besetzung erfolgt nicht nur aus einem passungsgetriebenen Mapping von Anforderung mit existenten Ressourcen, sondern bei 5, 6 und 10 durchaus auch „nur“ temporär für den erforderlichen Umfang.

In diesem Modell dürfen nicht nur mehrere Rollen von ein und derselben Person übernommen werden, sondern auch – außer 1 – geteilt werden. Das bringt zusammen mit dem oben dargestellten Vorgehen totale Skalierungsmöglichkeiten.

Spannend ist der selten auftauchende Widerstand gegen die Rolle des „Project Managers“ und der Gruppe „Project“ im Gesamten. Obwohl genau die darin inkludierten Aufgaben in der Integration ins Unternehmen oder bei größeren Vorhaben fehlen würden. Dabei wird völlig übersehen, wie durch die Skalierungsvarianten die optimale Ausrichtung für jede Art gegeben ist.

Eine Studie der FH Koblenz aus dem Jahre 2012 ergab eine um mindestens ~20% höhere Erfolgswahrscheinlichkeit durch den Einsatz agiler Ansätze. Intensivere Auseinandersetzung mit dieser ausgereiften Methode macht daher also durchaus Sinn.

Über den Autor:

Dieter Strasser, MSc, CMC ist als akkreditierter Trainer, Berater, Coach und Facilitator zum Schwerpunkt Projektmanagement im gesamten deutschsprachigen Raum tätig.
33 Jahre Praxiserfahrung fließen in die Lehre in der Privatwirtschaft und an Hochschulen ein.
Seine Spezialität ist die Vernetzung der einzelnen Bereiche untereinander sowie deren Integration in Unternehmen.

Weitere Informationen über die Viable Projects GmbH