Was ist AgilePM/DSDM?

Agiles Projektmanagement hat viele Namen. Scrum kennen die meisten. AgilePM und DSDM bleiben blass. Dieser Artikel erklärt AgilePM und DSDM von Grund auf. Phasen, Rollen, Priorisierung, Zeitboxen. In rund zwölf Minuten kennst du das ganze Gerüst.

AgilePM und DSDM: zwei Namen, ein Kern

AgilePM ist die Methoden- und Zertifizierungsmarke von APMG International. Sie basiert vollständig auf DSDM. DSDM steht für Dynamic Systems Development Method und stammt vom Agile Business Consortium. DSDM entstand in den 1990er-Jahren, lange vor dem Agilen Manifest. Es ist damit eine der ältesten agilen Methoden überhaupt.

Der Unterschied ist schnell erklärt. DSDM ist das Rahmenwerk mit Prinzipien, Phasen und Rollen. AgilePM ist die zertifizierbare Trainings- und Prüfungslinie darauf. Wer „AgilePM Foundation" oder „AgilePM Practitioner" liest, lernt im Kern DSDM. Beide Begriffe meinen praktisch dasselbe Vorgehen.

Was AgilePM von leichteren Methoden trennt: Es liefert Projekt-Governance mit. Business Case, Phasen-Freigaben, klare Rollen, dokumentierte Entscheidungen. Genau das, was Auftraggeber in regulierten Branchen verlangen. AgilePM verbindet agile Iteration mit der Kontrolle eines klassischen Projektrahmens.

Die 8 DSDM-Prinzipien

DSDM ruht auf acht Prinzipien. Sie sind nicht dekorativ. Verletzt ein Projekt eines davon, steigt das Risiko spürbar. Hier die acht im Überblick.

1. Fokus auf den Geschäftsbedarf. Jede Entscheidung dient einem klaren Geschäftsziel. Kein Feature ohne Begründung.
2. Pünktlich liefern. Der Termin steht fest. Das Team liefert zum Datum, notfalls mit reduziertem Umfang.
3. Kollaborieren. Fachseite und Technik arbeiten Schulter an Schulter. Stakeholder sind eingebunden, nicht nur informiert.
4. Niemals Qualität kompromittieren. Qualität wird vorab definiert und ist nicht verhandelbar. Gekürzt wird der Umfang, nie die Güte.
5. Inkrementell auf solider Basis bauen. Erst ein tragfähiges Fundament, dann Schritt für Schritt erweitern.
6. Iterativ entwickeln. Das Team baut, zeigt, lernt, verbessert. Feedback fliesst früh und oft zurück.
7. Kontinuierlich und klar kommunizieren. Workshops, tägliche Abstimmung, sichtbare Artefakte. Missverständnisse werden früh gekappt.
8. Kontrolle demonstrieren. Fortschritt ist jederzeit belegbar. Plan, Stand und Prognose liegen offen.

Diese Prinzipien tragen jede Methodenentscheidung. Mehr zu jedem Einzelnen findest du im Glossar zu den DSDM-Prinzipien.

Der DSDM-Lebenszyklus: die Phasen

DSDM strukturiert ein Projekt in einen klaren Lebenszyklus. Sechs Phasen führen vom ersten Impuls bis zum Nutzen im Betrieb. Jede Phase hat einen Zweck und ein definiertes Ergebnis. Im Krelora-Kontext laufen diese Phasen als Kurzform „Phase A–G".

Die Reihenfolge ist bewusst gewählt. Feasibility und Foundations investieren früh in Klarheit. Danach läuft die Evolutionary Development in Schleifen. Deployment kann mehrfach erfolgen, inkrementell. Post-Project misst, ob sich der Aufwand gelohnt hat.

Wichtig: DSDM friert nicht alles in Foundations ein. Es legt genug fest, um zu starten, und hält genug offen, um zu lernen. „Just enough design up front" nennt das die Methode. Tiefer steigt der Cluster zu den DSDM-Phasen ein.

Die DSDM-Rollen

DSDM definiert rund dreizehn Rollen. Sie ordnen sich drei Bereichen zu: Projektebene, Lösungsentwicklung und unterstützende Rollen. Diese klare Zuordnung verhindert Verantwortungslücken. Jede Rolle hat eine Stimme, kein Thema bleibt herrenlos.

Auffällig ist der Anteil der Fachrollen. Business Sponsor, Visionary, Ambassador, Advisor. DSDM holt die Fachseite tief ins Projekt. Sie entscheidet mit, sie testet mit, sie priorisiert mit. Das ist kein Zufall, sondern Prinzip eins in der Praxis. Die Rollen im Detail erklärt der Cluster zu den DSDM-Rollen.

MoSCoW: Priorisierung, die Termine hält

MoSCoW ist das Priorisierungsmodell von DSDM. Vier Stufen sortieren jede Anforderung. Die Buchstaben stehen für die Dringlichkeit, das o ist Füllung.

Der Trick steckt in der Verteilung. DSDM empfiehlt, dass „Must"-Anforderungen höchstens rund 60 Prozent des Aufwands binden. Der Rest verteilt sich auf Should und Could. Dieser Puffer ist die Versicherung gegen Verzug. Läuft die Zeit knapp, opfert das Team zuerst Could, dann Should. Die Musts bleiben. Der Termin hält.

So wird MoSCoW zum Partner des Timeboxing. Feste Zeit, flexibler Umfang. Wer MoSCoW sauber nutzt, liefert pünktlich, ohne Qualität zu verlieren. Mehr Beispiele im MoSCoW-Cluster.

Timeboxing: feste Zeit statt fester Scope

Timeboxing dreht die klassische Logik um. Im Wasserfall ist der Umfang fix und die Zeit dehnt sich. In DSDM ist die Zeit fix und der Umfang atmet. Eine Timebox ist eine feste Zeitspanne, meist zwei bis vier Wochen. Sie endet zum geplanten Datum, egal was passiert.

Innerhalb der Timebox arbeitet das Team in einem klaren Rhythmus. Häufig in drei Schritten: Untersuchen, Verfeinern, Konsolidieren. Am Anfang wird der Umfang der Box vereinbart. Am Ende steht ein demonstrierbares Ergebnis. Verschiebt sich nichts beim Termin, verschiebt sich der Inhalt.

Genau hier greift MoSCoW. Gerät eine Timebox unter Druck, fallen Could-Punkte zuerst. Das Team schützt die Musts und liefert zum Datum. Diese Disziplin macht DSDM für Festtermin-Projekte stark. Die Box ist heilig, der Inhalt verhandelbar.

Pflicht-Produkte: die Artefakte

DSDM kennt definierte Produkte, also Artefakte, die ein Projekt erzeugt. Sie sind keine Bürokratie um ihrer selbst willen. Jedes Produkt trägt eine Entscheidung oder einen Nachweis. Hier die wichtigsten.

• Business Case — begründet, warum das Projekt läuft. Wird über die Phasen verfeinert.
• Prioritised Requirements List — die priorisierte Anforderungsliste, durchgängig nach MoSCoW sortiert.
• Solution Architecture Definition — der technische und fachliche Rahmen der Lösung.
• Development Approach Definition — wie das Team baut, testet und Qualität sichert.
• Delivery Plan — der grobe Fahrplan über die Timeboxen.
• Timebox Plan — der Detailplan einer einzelnen Zeitbox.
• Management Foundations — Governance, Organisation und Berichtswege.

Die meisten Produkte entstehen früh, in Feasibility und Foundations. Danach werden sie gepflegt, nicht neu erfunden. DSDM hält den Aufwand bewusst schlank: so viel Dokumentation wie nötig, so wenig wie möglich. Den vollständigen Überblick gibt der Cluster zu den DSDM-Produkten.

Phase-Gates: kontrollierte Übergänge

Ein Phase-Gate ist ein formaler Übergang zwischen zwei Phasen. Bevor ein Projekt von Foundations in die Entwicklung wechselt, prüft das Gate. Liegen die nötigen Produkte vor? Trägt der Business Case noch? Sind die Risiken im Griff? Erst nach Freigabe geht es weiter.

Gates geben dem Sponsor echte Kontrolle. An jedem Gate kann er weitermachen, anpassen oder stoppen. Das ist „demonstrieren von Kontrolle" als Mechanismus. Ein Projekt läuft nicht blind durch, sondern an klaren Haltepunkten mit bewusster Entscheidung.

Genau dieser Approval-Schritt unterscheidet AgilePM von leichtgewichtigen Methoden. Die Iteration bleibt agil. Die Übergänge bleiben kontrolliert. Wie Gates in der Praxis aussehen, zeigt der Phase-Gate-Cluster.

PAQ: Change-Requests bewerten (Krelora-Begriff)

Ein Hinweis zur Einordnung: PAQ steht im Krelora-Kontext für Projekt-Akzeptanz-Qualität. Es ist ein Bewertungs-Workflow für Change-Requests durch benannte Assessor:innen. Das ist Krelora-Terminologie, kein Standardbegriff aus dem DSDM-Handbuch.

Der Gedanke dahinter passt aber direkt zu DSDM. Änderungen kommen in jedem Projekt. PAQ sorgt dafür, dass jede Änderung erst durch einen Triage- und Bewertungsschritt läuft, bevor sie das Projekt beeinflusst. Wer das Konzept im Krelora-Sinn nachlesen will, findet es im PAQ-Eintrag.

DSDM vs. Scrum vs. PRINCE2

Drei Namen, drei Schwerpunkte. Eine kurze, sachliche Abgrenzung hilft bei der Einordnung.

Scrum konzentriert sich auf das Team und das Produkt. Es lässt Projekt-Governance bewusst offen. PRINCE2 deckt Governance umfassend ab, ist aber von Haus aus nicht agil. DSDM steht dazwischen und füllt die Lücke: agile Lieferung mit Projektrahmen. Viele Organisationen kombinieren sogar. AgilePM und Scrum lassen sich verbinden, ebenso AgilePM und PRINCE2.

Wann passt AgilePM?

AgilePM glänzt, wenn drei Dinge zusammenkommen: ein fester Termin, ein begrenztes Budget und der Wunsch nach Nachweisbarkeit. Typisch sind grössere Vorhaben mit mehreren Stakeholdern, regulierte Branchen oder Programme, die ein Auftraggeber eng begleitet.

Für ein kleines Produktteam ohne externe Governance-Anforderung ist reines Scrum oft schlanker. Für ein starr plangetriebenes Bauprojekt passt eher PRINCE2. Liegt dein Vorhaben dazwischen, ist AgilePM meist die ruhigere Wahl. Es liefert Agilität und Kontrolle in einem Modell.

AgilePM und DSDM sind in Krelora die Standardkonfiguration, nicht ein Plugin. Phasen, Phase-Gates, die rund dreizehn Rollen und die Pflicht-Produkte sind eingebaut. Ein Compliance-Score von 0 bis 100 zeigt pro Projekt automatisch, wie sauber die Methode gelebt wird. Über 1 000 automatisierte Tests prüfen das Produkt bei jedem Release. Gehostet wird in der Schweiz und der EU, DSGVO- und CH-DSG-konform, On-Premise verfügbar.

AgilePM in der Praxis sehen: demo.krelora.com — ein Klick, kein Login.