Agile PM - just another (agile) Framework?

Von DSDM zu AgilePM

Wodurch unterscheidet sich die DSDM von traditionelleren Ansätzen?

Nun, bei der DSDM unterstützt der iterative Ansatz die Tatsache, dass im Laufe der Zeit immer mehr Details bekannt werden. Daraus ergibt sich, dass das aktuelle Inkrement immer nur in jener Detailtiefe abgeschlossen werden muss, um im nächsten Entwicklungsdurchlauf das nächste Projektinkrement ohne Defizite beim detaillierten Verständnis einleiten zu können.

Dies ermöglicht es, auf die sehr wahrscheinlichen Veränderungen der Unternehmensanforderungen mit der Zeit und deren Detailtiefe zu reagieren und die bisherigen Anstrengungen einer zu detaillierten Vorarbeit werden umgangen.

Das bedeutet, die entwickelte Lösung richtet sich auf die aktuellen und sich abzeichnenden Bedürfnisse des Unternehmens und nicht, wie es beim traditionellen Ansatz der Fall ist, auf die Behebung aller wahrgenommen Eventualitäten.

Im Buch „AgilePM® Agile Project Management Handbook v2“ findet sich – beinahe gebetsmühlenartig - an mehreren Stellen Philosophie des DSDM:

„Der größtmögliche Geschäftsnutzen entsteht, wenn Projekte auf klare Geschäftsziele ausgerichtet sind, regelmäßig Ergebnisse ausliefern und die Zusammenarbeit motivierter und befugter Mitarbeiter beinhaltet.“

Diese Philosophie sagt im Grunde bereits alles über DSDM aus.

Gestützt wird sie durch acht Prinzipien.

1. Konzentrieren Sie sich auf das Geschäftsbedürfnis
2. Liefern Sie pünktlich
3. Arbeiten Sie zusammen
4. Dulden Sie keine Abstriche in Sachen Qualität
5. Bauen Sie schrittweise auf soliden Grundlagen auf
6. Entwickeln Sie iterativ
7. Kommunizieren Sie kontinuierlich und deutlich
8. Demonstrieren Sie Steuerung

Aber wodurch unterscheidet sich DSDM jetzt von Scrum und Co?

Da SEQIS schon jahrelang praktische Erfahrung mit agilen Frameworks und agilen Projekten hat, wurde diese Frage durch die Trainingsteilnehmer besonders intensiv diskutiert und Parallelen bzw. Unterschiede zu anderen agilen Ansätzen wurden gesucht.

Vieles ist – teilweise unter einer anderen Bezeichnung – bekannt.

Was jedoch ein auffallender Unterschied ist, sind die vielen verschiedenen klar definierten Rollen und deren definierte Verantwortlichkeiten.

13 an der Zahl. Das mag jetzt auf den ersten Blick nach sehr vielen Rollen aussehen – vergleicht man es zB mit Scrum wo es nur drei zentrale Rollen (Product Owner, Scrum Master und Entwicklungsteam) gibt – und man könnte meinen, dass das Projektteam demzufolge aus sehr vielen Personen bestehen muss.

Jedoch mit dem Wissen, dass a) mehrere Rollen durch ein und dieselbe physische Person abgedeckt werden kann und b) in auch in zB Scrum diese Rollen bzw. deren Tätigkeiten indirekt abgedeckt werden müssen, relativiert sich diese Zahl wieder.

Der große Vorteil hierbei liegt darin, dass jede Rolle genau weiß, was sie zu tun hat und wo deren Verantwortungsbereiche liegen und es somit zu keinen Unklarheiten kommt.

Es muss jedoch sichergestellt werden, dass jedes Projektteammitglied genau weiß, welche Rolle(n) es im Projekt hat.

Diese Rollen lassen sich in Interessensgebiete clustern, welche die Geschäftsinteressen, lösungsspezifischen/technischen Interessen, Managementinteressen und Prozessinteressen widerspiegeln.

Einen weiteren Unterschied stellt der Prozess selbst dar.

Der Prozess besteht im Wesentlichen aus den Phasen:

• Pre-Project
• Feasibility
• Foundations
• Evolutionary Development
• Deployment Phase
• Post-ProjectPhase

Während Pre-Project, Feasibility und Evolutionary Developement usw. ähnlich wie bei anderen Frameworks ist, stellt die Foundations ein Unterscheidungsmerkmal dar.

In dieser soll ausgehend von der Feasibility-Phase ein grundlegendes (jedoch nicht detailliertes) Verständnis über den Geschäftszweck des Projekts, die potenzielle Lösung, sowie das Management von Entwicklung und Umsetzung der Lösung geschaffen werden.

Also das Fundament für alle folgenden Phasen. Hier können bereits Design- und Umsetzungsrichtlinien definiert werden.

Es werden die Anforderungen auf einem sehr hohen Level definiert und ein möglicher Delivery Plan wird erstellt um bereits eine Aussage darüber treffen zu können, wann man mit welchen Projektinkrementen rechnen kann.

Ziel ist es, einen Überblick über den Umfang der Aufgaben und, im weitesten Sinne, über deren Durchführung von wem, wann und wo zu liefern.

"Produkte" - was ist das im DSDM?

Noch ein Merkmal von DSDM sind die (möglichen) Produkte.

Was ist damit gemeint?

Das Framework beinhaltet eine Reihe von Produkten, die im Zuge der Projektentwicklung zu berücksichtigen sind.

Nicht alle Produkte sind für jedes Projekt erforderlich und der Grad an Formalismus variiert je nach Projekt und Organisation.

Das ist jetzt unter Produkt zu verstehen?

In jeder Phase des Prozesses wird bzw, werden ein oder mehrere Artefakte (folgend unterstrichen) erstellt, aktualisiert und/oder detailliert.

In der Feasibility zum Beispiel wird der Business Case in einer ersten Version erstellt. Die Prioritised Requirements List, die Solution Architecture Definition u. dgl. werden begonnen.

Ein weiteres Produkt der Feasibility ist das Feasibility Assessment. Dies liefert einen kurzen Überblick über die zuvor erstellen, sich entwickelnden Produkte am Ende der Feasibility Phase und soll bei der Entscheidung, ob das Projekt weitergeführt wird oder nicht, unterstützen.

Neben den erwähnten gibt es noch einige Produkte mehr. Es handelt sich lediglich um Richtlinien, die zur Anregung einer guten Kommunikation innerhalb eines Projekts benötigt werden.

Im Training intensiv behandelt wurde u.a. auch die DSDM-Praktik MoSCoW-Priorisierung und wie diese auf welchem Detaillierungsgrad in welcher Phase angewandt wird.

Ein zentrales Element in DSDM ist das Timeboxing – in den zwei unterschiedlichen Ausprägungen.

Und, und, und.

Es gäbe noch so viel zu berichten.

Jedoch kann man das nicht in einem Artikel unterbringen und vor allem soll ja noch Spannung und Neugier erhalten bleiben.