Die vier Frameworks auf einen Blick
Das Video hat euch die Entscheidungsmatrix vorgestellt. Diese Leseeinheit vertieft jeden Framework mit den wichtigsten Merkmalen, Rollen und Einsatzszenarien — als Nachschlagewerk für deine Praxis.
Scrum
Wofür geeignet?
Produkt- und Softwareentwicklung mit hoher Komplexität und sich ändernden Anforderungen. Teams von bis zu 10 Personen (Scrum Guide 2020), die selbstorganisiert arbeiten können.
Kernmerkmale
- Sprints: Feste Iterationen von 1–4 Wochen mit klarem Sprint Goal
- Artefakte: Product Backlog, Sprint Backlog, Increment
- Events: Sprint Planning, Daily Scrum, Sprint Review, Retrospektive
- Rollen: Product Owner, Scrum Master, Developers
Stärken & Grenzen
| Stärken | Grenzen |
|---|---|
| Schnelles Feedback durch kurze Zyklen | Skalierung über mehrere Teams komplex |
| Klare Rollenverantwortung | Erfordert stabiles, dediziertes Team |
| Transparenz durch Artefakte | Weniger geeignet für laufende Betriebsprozesse |
Kanban
Wofür geeignet?
Kontinuierliche Lieferung, Support-Prozesse, Wartungsaufgaben und überall dort, wo Arbeit in unterschiedlichen Rhythmen ankommt — ohne feste Sprints.
Kernmerkmale
- Kanban-Board: Visualisiert den Arbeitsfluss durch Workflow-Stufen
- WIP-Limits: Begrenzen parallele Arbeit je Spalte
- Pull-Prinzip: Neue Aufgaben werden gezogen, wenn Kapazität frei ist
- Metriken: Cycle Time, Lead Time, Durchsatz, CFD
Typische Einsatzbereiche
- IT-Operations und Support-Teams
- Marketing-Teams mit laufendem Content-Output
- HR-Prozesse mit variablen Eingangsraten
- Als Ergänzung zu Scrum auf Team-Ebene („Scrumban“)
AgilePM®
Wofür geeignet?
Projekte mit klarem Budgetrahmen und Zeitplan, bei denen Scope flexibel gehalten werden soll. Besonders stark bei Business-Change-Projekten, nicht rein technischen Produktentwicklungen.
Kernmerkmale
- MoSCoW-Priorisierung: Must / Should / Could / Won't — Scope wird flexibel gesteuert
- Timeboxing: Zeit, Budget und Qualität sind fix; Scope ist die Variable
- Projektlebenszyklus: Pre-Project → Feasibility → Foundations → Evolutionary Development → Deployment → Post-Project
- Rollen: Executive Sponsor, Business Visionary, Business Ambassador, Project Manager, Technical Coordinator, Business Analyst, Solution Developer, Solution Tester
AgilePM®-Projektphasen
| Phase | Inhalt | Hauptartefakt |
|---|---|---|
| Pre-Project | Projektidee prüfen, Sponsor sichern | Terms of Reference |
| Feasibility | Business Case, grobe Lösungsprüfung | Feasibility Assessment |
| Foundations | Architektur, Rollen, grober Plan | Business Foundations |
| Evolutionary Development | Iterative Lieferung in Timeboxen | Evolving Solution |
| Deployment | Lösung in Betrieb überführen | Deployed Solution |
| Post-Project | Nutzenrealisierung messen | Benefits Assessment |
PRINCE2 Agile
Wofür geeignet?
Organisationen mit bestehender PRINCE2-Governance, die agile Liefermethoden auf Team-Ebene einführen wollen. Kombiniert klassische Projektkontrolle mit agilem Lieferansatz.
Kernmerkmale
- Governance: Behält alle PRINCE2-Prozesse (Initiieren, Steuern, Managen, Abschließen)
- Delivery: Teams arbeiten mit Scrum oder Kanban innerhalb der Projektstruktur
- Management Stage Plans: Steuerung über Phasengrenzen mit Gate-Reviews
- Flexibilität: Agile Delivery vom klassischen Projektmanagement entkoppelt
Framework-Schnellvergleich
| Kriterium | Scrum | Kanban | AgilePM® | PRINCE2 Agile |
|---|---|---|---|---|
| Iterationen | Sprints (fix) | Kontinuierlich | Timeboxen | Phasen + Sprints |
| Scope | Flexibel | Flexibel | Flexibel (MoSCoW) | Flexibel |
| Governance | Niedrig | Niedrig | Mittel | Hoch |
| Zertifizierung | PSM / CSM | KMP | AgilePM® Practitioner | PRINCE2 Agile Practitioner |
Key Takeaways
- Scrum und Kanban sind team-zentrierte Delivery-Frameworks ohne eigene Projekt-Governance
- AgilePM® eignet sich für Projekte mit fixen Budget/Zeit-Grenzen und flexiblem Scope
- PRINCE2 Agile ist die richtige Wahl für Organisationen, die PRINCE2-Governance beibehalten wollen
- Kein Framework ist universell — die Wahl hängt von Projektkontext, Team und Governance-Anforderungen ab