Komplette Übersicht agiler Frameworks: Scrum, SAFe, OKR, Design Thinking & mehr
Ein praxisnaher Leitfaden durch alle wichtigen agilen Projektmanagement-Frameworks, Skalierungsframeworks, Zielsysteme, Organisationsmodelle und Produktentwicklungsmethoden, inklusive Download-Tabelle
Agilität ist kein einzelnes Framework, sondern ein Ökosystem aus Ideen, Praktiken und konkreten Bauplänen für Zusammenarbeit. In der Praxis triffst du heute auf Scrum, Kanban, SAFe, OKR, Design Thinking, Lean Startup, Holacracy und viele weitere Namen.
Die Folge: Ein Framework-Zoo, Zertifizierungsprogramme und interne Diskussionen, aber oft wenig Klarheit darüber, welches Framework welches Problem löst.
Genau hier setzt dieser Beitrag an. Du bekommst einen strukturierten Vergleich agiler Projektmanagement- und Skalierungsframeworks, der sich nicht auf Schlagwörter und Marketingfolien stützt, sondern auf eine systematische Auswertung von Framework-Beschreibungen, Praxisberichten und offiziellen Referenzen. Im Mittelpunkt stehen nicht die Etiketten, sondern diese zentralen Fragen:
Welches konkrete Problem löst ein Framework?
Wofür ist es geeignet, wofür nicht?
Auf welchen Ideen und Modellen baut es auf?
Wie verbreitet ist es tatsächlich in der Praxis?
Tipp: Damit du diese Informationen auch ausserhalb dieses Artikels nutzen kannst, findest du hier eine Download-Möglichkeit: Die komplette Framework-Übersicht als Datei mit allen Spalten aus deiner Recherche (Name, Kategorie, Beschreibung, Ideal/Nicht ideal, Verbreitung, Basis, Problemfokus). So kannst du in deinem Kontext filtern, sortieren und markieren.
In jeder Kategorie bekommst du für jedes Framework denselben klaren Steckbrief:
Name des Frameworks
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. Grundlage/Basis)
Wofür geeignet, wofür nicht
Verbreitung
So kannst du Frameworks vergleichen, ohne zwischen verschiedenen Darstellungsformen hin und her zu springen. Du erkennst, ob du ein Problem eher auf Team-Ebene, auf Organisationsebene, in der Strategieumsetzung oder in der Produktentwicklung angehen solltest.
Was sind agile Projektmanagement-Frameworks?
Wenn von Agilität die Rede ist, meinen viele spontan Scrum oder Kanban. Fachlich präzise betrachtet sind das agile Projektmanagement-Frameworks: strukturierte, bewusst reduzierte Rahmenwerke, die definieren, wie ein Team seine Arbeit organisiert, priorisiert, ausführt und regelmässig verbessert.
Kernelemente agiler Projektmanagement-Frameworks
Agile Projektmanagement-Frameworks haben unterschiedliche Details, teilen aber einige gemeinsame Merkmale:
Iteratives Vorgehen: Arbeit wird in kleine Einheiten zerlegt, die in kurzen Zyklen geliefert und bewertet werden.
Transparenz über Arbeit: Backlogs, Boards oder Artefakte machen sichtbar, woran das Team arbeitet, was als Nächstes ansteht und was erledigt ist.
Regelmässiges Feedback: In Reviews, Dailys oder ähnlichen Formaten holt das Team Feedback von Stakeholdern und aus der Nutzung ein.
Kontinuierliche Verbesserung: Retrospektiven oder Kaizen-Formate stellen sicher, dass das Team seine Arbeitsweise laufend reflektiert und anpasst.
Klare Rollen und Verantwortungen: Rollen wie Product Owner, Scrum Master oder Service Owner fokussieren Verantwortung und entlasten das Team von diffusen Erwartungshaltungen.
Der Fokus liegt dabei immer auf der Ebene einzelner Teams oder kleinerer Einheiten, die ein Produkt, einen Service oder ein Projekt verantworten. Agile Projektmanagement-Frameworks beantworten Fragen wie:
Wie priorisieren wir Arbeit?
Wie planen wir die nächsten Tage oder Wochen?
Wie messen wir Fortschritt?
Wie reagieren wir auf neue Erkenntnisse?
Sie liefern also das Tagesgeschäfts-Betriebssystem eines Teams.
Abgrenzung zu anderen Framework-Kategorien
Damit der Vergleich agiler Projektmanagement- und Skalierungsframeworks für dich sinnvoll ist, braucht es eine klare Abgrenzung zu anderen Bausteinen des agilen Ökosystems.
1. Agile Projektmanagement-Frameworks
Beispiele: Scrum, Kanban, Extreme Programming (XP), Scrumban, DSDM, FDD, ASD, RAD, OpenUP, RUP.
Sie regeln, wie ein Team arbeitet: Zyklen, Rollen, Artefakte, Meetings, Metriken.
2. Agile Skalierungsframeworks
Beispiele: Scrum of Scrums, Nexus, LeSS, Scrum@Scale, SAFe, Disciplined Agile Delivery (DAD), Disciplined Agile (DA).
Sie setzen auf bestehenden Team-Frameworks auf und beantworten die Frage: Wie koordinieren wir viele Teams, die am selben Produkt oder an eng gekoppelten Produkten arbeiten? Sie adressieren Abhängigkeiten, gemeinsame Planung, integrierte Inkremente und Governance auf höheren Ebenen.
3. Ziel- und Strategiemanagement
Beispiele: OKR, Hoshin Kanri, Balanced Scorecard.
Diese Frameworks legen fest, welche Ziele eine Organisation verfolgt und wie sie diese messbar macht. Sie sorgen für Fokus und Ausrichtung, ersetzen aber kein Projektmanagement-Framework.
4. Organisationsmodelle
Beispiele: Holacracy, Sociocracy 3.0, Spotify Model.
Hier geht es um Struktur und Entscheidungsprozesse einer Organisation: Wie sind Teams und Kreise aufgebaut, wie werden Rollen verteilt, wie fällt die Organisation Entscheidungen? Diese Modelle bilden den strukturellen Rahmen, in dem Teams ihre agilen Praktiken leben.
5. Lean- und Startup-Methoden
Beispiele: Lean Startup, Build-Measure-Learn, Lean Software Development.
Sie adressieren Innovation, Effizienz und Lernen unter Unsicherheit. Im Zentrum stehen Hypothesen, Experimente, schnelle Validierung und Vermeidung von Verschwendung.
6. Governance- und Hybrid-Modelle
Beispiele: PRINCE2 Agile, AgilePM.
Sie verbinden klassisches Projektmanagement und Governance mit agilen Praktiken. Relevant, wenn Organisationen regulatorische oder vertragliche Anforderungen erfüllen müssen, aber trotzdem agile Arbeitsweisen nutzen wollen.
7. Produktentwicklungsmethoden
Beispiele: Design Thinking, Dual Track Agile.
Sie beschreiben, wie Produkte und Services entstehen, oft mit starkem Fokus auf Nutzerbedürfnisse und auf die Trennung von Discovery (Verstehen und Experimentieren) und Delivery (Umsetzung).
Wichtig: Diese Einordnung hilft dir, typische Missverständnisse zu vermeiden. Wenn zum Beispiel jemand fragt, ob OKR „Scrum ersetzt”, ist die Antwort klar: OKR ist ein Zielsystem, Scrum ein Team-Framework. Sie lösen unterschiedliche Probleme und lassen sich kombinieren, statt sich zu konkurrieren.
Wozu dienen agile Projektmanagement-Frameworks in der Praxis?
In der Praxis begegnen agile Projektmanagement-Frameworks vor allem folgenden Herausforderungen:
Unsichere oder veränderliche Anforderungen: Klassische Planungsmodelle geraten hier schnell an Grenzen. Agile Frameworks akzeptieren Unsicherheit und integrieren Lernen in den Prozess.
Lange Feedbackschleifen: Wenn Kunden oder Nutzer erst am Ende eines Projektes etwas sehen, steigt das Risiko, am Bedarf vorbei zu entwickeln. Iterative Inkremente reduzieren dieses Risiko.
Intransparenter Workload und Überlastung: Visualisierung und WIP-Limits helfen, Überlastung sichtbar zu machen und zu begrenzen.
Koordination im Team: Klare Rollen, regelmässige Events und sichtbare Backlogs reduzieren Abstimmungsaufwand und Missverständnisse.
Qualitätsprobleme: Praktiken wie Definition of Done, automatisierte Tests oder Pair Programming (im Fall von XP) adressieren Qualität direkt im Prozess.
Wenn du agile Projektmanagement-Frameworks bewusst wählst, verstärkst du nicht einfach einen Trend, sondern triffst eine gezielte Entscheidung für bestimmte Problemstellungen. Genau hier setzt der spätere Vergleich an: Du kannst jedes Framework an seinem Problemfokus messen, statt an seinem Marketing.
Wie Frameworks zusammenwirken können
Ein wichtiger Punkt: In modernen Organisationen läuft selten nur ein Framework. Typische Kombinationen sind zum Beispiel:
Scrum oder Kanban auf Team-Ebene
SAFe, LeSS oder Scrum@Scale für die Koordination vieler Teams
OKR oder Hoshin Kanri für Ziele und Ausrichtung
Design Thinking und Dual Track Agile für die Produktentdeckung
Lean Startup in Innovationsprojekten oder neuen Geschäftsideen
PRINCE2 Agile oder AgilePM in regulierten Umgebungen
Statt „das eine richtige Framework” zu suchen, lohnt es sich, ein bewusstes Set aus Frameworks zu gestalten, das zu Produkt, Branche, Grösse und Regulierungsgrad deiner Organisation passt.
Agile Projektmanagement-Frameworks im Detail
Agile Projektmanagement-Frameworks bilden das Betriebssystem einzelner Teams. Sie legen fest, wie Arbeit sichtbar wird, wie du planst, priorisierst, lieferst und verbesserst. In diesem Kapitel fokussieren wir auf Frameworks, die direkt auf Teamebene wirken und damit das Fundament für jeden Vergleich agiler Projektmanagement- und Skalierungsframeworks bilden.
Du findest zu jedem Framework denselben Steckbrief:
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. theoretischer Basis)
Wofür geeignet, wofür nicht
Verbreitung in der Praxis
So kannst du rasch prüfen, ob ein Framework zu deinen aktuellen Herausforderungen passt.
1 Scrum
Dieses Problem löst das Framework Scrum adressiert fehlende Transparenz, lange Feedbackzyklen und starre Phasenpläne. Es ermöglicht Teams, in kurzen Iterationen funktionsfähige Inkremente zu liefern und Risiken früh sichtbar zu machen.
Kurze Beschreibung (inkl. Basis) Scrum ist ein iteratives Rahmenwerk mit festen Sprints, klar definierten Rollen (Product Owner, Scrum Master, Entwicklungsteam) und standardisierten Events (Sprint Planning, Daily Scrum, Review, Retrospektive). Es beruht auf empirischer Prozesskontrolle: Entscheidungen stützen sich auf Beobachtung, nicht auf Prognosen. Die Wurzeln liegen im Agile Manifesto und in früher Forschung zu iterativer Entwicklung und komplexen adaptiven Systemen.
Eignung
Geeignet: Produkt- und Softwareentwicklung, komplexe Vorhaben mit veränderlichen Anforderungen, Teams, die in 1–4 Wochen funktionsfähige Inkremente liefern können.
Nicht geeignet: Reine Wartungs- oder Supportkontexte ohne klare Sprintziele, Bereiche mit ständig ungeplanter Arbeit, die den Sprintfluss permanent stören.
Verbreitung Scrum ist das am weitesten verbreitete agile Projektmanagement-Framework. Viele Unternehmen nutzen es als Standard, von Tech-Startups bis zu Banken und Behörden. Studien wie der State of Agile Report zeigen seit Jahren eine führende Nutzung.
2 Kanban
Dieses Problem löst das Framework Kanban adressiert Überlastung, intransparente Warteschlangen und lange Durchlaufzeiten. Es reduziert Work in Progress (WIP) und macht Engpässe sichtbar.
Kurze Beschreibung (inkl. Basis) Kanban visualisiert Arbeit auf einem Board mit Spalten wie „To Do”, „In Arbeit”, „Erledigt”. WIP-Limits begrenzen parallele Aufgaben. Das Framework folgt dem Pull-Prinzip: Teams starten neue Aufgaben erst, wenn Kapazität frei wird. Es basiert auf der Lean-Philosophie und dem Toyota Production System.
Eignung
Geeignet: Dauerhafte Service- und Wartungsprozesse, Support-Teams, Ticket-Systeme, DevOps-Teams mit kontinuierlichem Fluss und wechselnden Prioritäten.
Nicht geeignet: Projekte mit starker Forschungsunsicherheit ohne klar definierbare Arbeitsschritte oder mit extremer Abhängigkeit von externen Entscheidern.
Verbreitung Kanban ist in IT Operations, Kundenservice, Infrastruktur und DevOps weit verbreitet. Viele Teams kombinieren es mit Scrum-Elementen oder nutzen es als „evolutionären” Einstieg in Agilität.
3 Extreme Programming (XP)
Dieses Problem löst das Framework XP adressiert schlechte Codequalität, lange Releasezyklen und fehlende technische Praktiken in agilen Umgebungen.
Kurze Beschreibung (inkl. Basis) Extreme Programming ist ein Framework für Softwareentwicklung mit starken technischen Praktiken. Es betont testgetriebene Entwicklung (TDD), kontinuierliche Integration, Pair Programming, einfaches Design und gemeinsame Codeverantwortung. XP basiert auf fünf Werten (Kommunikation, Einfachheit, Feedback, Mut, Respekt) und einer Reihe verbindlicher Praktiken.
Eignung
Geeignet: Kleine, hoch fokussierte Entwicklerteams mit engem Kundenkontakt, die Qualität und Liefergeschwindigkeit gleichzeitig optimieren wollen.
Nicht geeignet: Grosse, fragmentierte Organisationen ohne technische Exzellenz-Kultur, Teams ohne Bereitschaft zu Pair Programming oder zu konsequenter Testautomatisierung.
Verbreitung XP ist weniger als „Brand” sichtbar, seine Praktiken (TDD, Pair Programming, CI) sind jedoch in vielen modernen Softwareteams Standard. Besonders Startups und Teams mit anspruchsvoller Codebasis nutzen Elemente von XP.
4 Scrumban
Dieses Problem löst das Framework Scrumban adressiert Situationen, in denen Scrum als zu starr und Kanban als zu unstrukturiert empfunden wird. Es hilft Teams, planbare Arbeit und Ad-hoc-Anfragen gleichzeitig zu bewirtschaften.
Kurze Beschreibung (inkl. Basis) Scrumban kombiniert Scrum-Rituale (z. B. regelmässige Planung) mit Kanban-Prinzipien wie Pull und WIP-Limits. Arbeit wird auf einem Kanban-Board visualisiert, oft ohne starre Sprint-Zyklen oder mit flexibleren Zeitboxen. Die Basis bildet eine Synthese aus Scrum-Framework und Lean-/Kanban-Denken.
Eignung
Geeignet: Wartungs- und Plattformteams, Marketing- oder Produktteams mit Mischformen aus geplanten Aufgaben und spontanen Anforderungen.
Nicht geeignet: Organisationen, die klare Rollen und starke Struktur brauchen und in denen hybride Modelle eher Verwirrung als Freiraum erzeugen.
Verbreitung Scrumban hat an Popularität gewonnen, vor allem in IT Operations, Service-Teams und in Umgebungen, in denen fest getaktete Sprints nicht funktionieren. Es existiert meist als organisationsspezifische Variante, nicht als formal zertifiziertes Standardframework.
5 Crystal Method
Dieses Problem löst das Framework Crystal adressiert die Tatsache, dass Projekte unterschiedlich sind und ein starres, allgemeingültiges Prozessmodell selten passt. Es bietet anpassbare Vorgehensmodelle je nach Projektgrösse und Kritikalität.
Kurze Beschreibung (inkl. Basis) Crystal ist eine Familie leichter, menschenzentrierter Methoden (Crystal Clear, Crystal Orange usw.). Sie legt den Fokus auf Kommunikation, direkte Zusammenarbeit und minimale Dokumentation. Teams definieren ihre Prozesse selbst, orientiert an einigen Grundprinzipien. Die theoretische Basis stammt aus der Arbeit von Alistair Cockburn und den Werten des Agile Manifesto.
Eignung
Geeignet: Kleine, erfahrene Teams, die hohe Autonomie wünschen und Prozesse bewusst gestalten.
Nicht geeignet: Stark regulierte Projekte mit hohem Dokumentationsbedarf oder Organisationen, die auf klare Vorgaben angewiesen sind. Dort kann die Offenheit zu Scope Creep und Unklarheit führen.
Verbreitung Crystal ist im Vergleich zu Scrum oder Kanban wenig verbreitet. Es findet vor allem in Beratungsprojekten, innovativen Produktteams und in Organisationen Anwendung, die bewusst auf individuelle Prozessgestaltung setzen.
6 Feature Driven Development (FDD)
Dieses Problem löst das Framework FDD adressiert unklare Fortschrittsmessung und fehlende Struktur in grossen Softwareprojekten. Es macht Fortschritt über Features messbar und steuerbar.
Kurze Beschreibung (inkl. Basis) Feature Driven Development organisiert Entwicklung entlang konkreter Features. Der Prozess umfasst fünf Schritte: Domain-Modell erstellen, Featureliste bauen, Features planen, pro Feature designen und implementieren. Die Basis liegt in objektorientierter Analyse und Einflüssen aus dem Rational Unified Process.
Eignung
Geeignet: Grosse Teams mit Bedarf an klaren Standards, planbaren Funktionspaketen und einer strukturierten Sicht auf Fortschritt.
Nicht geeignet: Kleine Projekte mit begrenzten Ressourcen oder Umgebungen ohne erfahrene Architekten bzw. Chefentwickler, die die Modellierung tragen.
Verbreitung FDD ist insbesondere in Teilen Asiens und in grossen Softwareunternehmen verbreitet, jedoch deutlich weniger präsent als Scrum. Viele Organisationen nutzen einzelne Ideen daraus, ohne FDD „by the book” einzuführen.
7 Dynamic Systems Development Method (DSDM)
Dieses Problem löst das Framework DSDM adressiert die Lücke zwischen flexibler Entwicklung und formaler Governance. Es bietet ein agiles Vorgehensmodell mit klaren Rollen, Prinzipien und Projektphasen.
Kurze Beschreibung (inkl. Basis) DSDM ist ein umfassendes agiles Projektmanagement-Framework aus den 1990er-Jahren. Es betont Geschäftsnutzen, frühe Lieferungen und Timeboxing. Acht Prinzipien bilden das Fundament, darunter Fokus auf Geschäftsziele, fristgerechte Lieferung, Zusammenarbeit und kompromisslose Qualität. Praktiken wie MoSCoW-Priorisierung und modellgetriebene Entwicklung stammen aus Rapid Application Development. DSDM dient auch als Basis für AgilePM.
Eignung
Geeignet: Organisationen mit hohem Governance-Bedarf, etwa im öffentlichen Sektor oder in regulierten Branchen, die trotzdem agil arbeiten wollen.
Nicht geeignet: Sehr kleine, informelle Teams oder Startups, bei denen der Governance-Aufwand nicht im Verhältnis steht.
Verbreitung DSDM ist besonders in Grossbritannien bekannt und bildet dort eine wichtige Grundlage für zertifizierte Ansätze wie AgilePM. International ist es weniger sichtbar, wird aber in bestimmten Branchen gezielt genutzt.
8 Adaptive Software Development (ASD)
Dieses Problem löst das Framework ASD adressiert hohe Unsicherheit, schnelle Veränderung und die Notwendigkeit, während des Projekts massiv zu lernen.
Kurze Beschreibung (inkl. Basis) Adaptive Software Development basiert auf den Prinzipien Spekulation, Zusammenarbeit und Lernen. Projekte werden iterativ durchlaufen, Teams treffen dezentrale Entscheidungen und beziehen Feedback kontinuierlich ein. ASD entstand aus Rapid Application Development und der Arbeit von Jim Highsmith, einem der Mitautoren des Agile Manifesto.
Eignung
Geeignet: Komplexe, dynamische Umgebungen mit schwer vorhersagbaren Anforderungen, in denen Teams eng mit Kunden zusammenarbeiten und aus Experimenten lernen.
Nicht geeignet: Projekte mit wenig Kundenverfügbarkeit oder Teams ohne ausreichende Erfahrung. Dort besteht das Risiko von Scope Creep und chaotischem Vorgehen.
Verbreitung ASD ist eine Nischenmethode. Elemente wie „adapting, collaborating, learning” haben jedoch stark in die allgemeine agile Praxis eingewirkt.
9 Rapid Application Development (RAD)
Dieses Problem löst das Framework RAD adressiert lange Entwicklungszyklen und langsame Prototypen-Bildung. Es ermöglicht schnelle, funktionsfähige Ergebnisse durch starke Tool-Unterstützung.
Kurze Beschreibung (inkl. Basis) Rapid Application Development setzt auf kleine Teams, leistungsfähige Werkzeuge und kurze Zyklen mit Prototypen. Der Prozess gliedert sich in Phasen wie Anforderungsplanung, Benutzerdesign, Konstruktion und Übergabe. Die Methode wurde massgeblich von IBM geprägt und basiert auf Prototyping und inkrementeller Lieferung.
Eignung
Geeignet: Projekte mit relativ stabilen Anforderungen und modularer Architektur, bei denen schnell sichtbare Ergebnisse nötig sind.
Nicht geeignet: Sicherheitskritische Systeme, stark gekoppelte Legacy-Landschaften oder Umgebungen, in denen Prototypen schwer umzusetzen sind.
Verbreitung RAD wurde in den 1990er-Jahren weit diskutiert und fliesst heute eher als Ideenbasis in moderne, toolgestützte Entwicklungsansätze ein. In Reinform ist RAD weniger verbreitet, einzelne Prinzipien leben in Low-Code-Plattformen und Prototyping-Ansätzen weiter.
10 Open Unified Process (OpenUP)
Dieses Problem löst das Framework OpenUP adressiert den Bedarf nach strukturierter, aber schlanker Alternative zu schweren Prozessmodellen wie RUP.
Kurze Beschreibung (inkl. Basis) OpenUP ist eine leichtgewichtige, iterativ-inkrementelle Variante des Unified Process. Es teilt Projekte in vier Phasen (Initialisierung, Verfeinerung, Konstruktion, Übergabe), arbeitet in Mikro-Iterationen und bleibt toolunabhängig. Die Basis bildet der Rational Unified Process, kombiniert mit Einflüssen aus Lean und XP.
Eignung
Geeignet: Kleine bis mittlere Projekte, die Struktur wollen, aber keinen vollständigen RUP, sowie Teams, die Selbstorganisation und kurze Feedbackschleifen schätzen.
Nicht geeignet: Sehr grosse Programme mit hohen Compliance-Anforderungen oder Organisationen, die bereits fest auf andere Standards ausgerichtet sind.
Verbreitung OpenUP ist vor allem im Umfeld der Eclipse Foundation und in bestimmten Open-Source-Kontexten bekannt. In der breiten Unternehmenswelt bleibt es eine Nischenoption.
11 Rational Unified Process (RUP)
Dieses Problem löst das Framework RUP adressiert unkoordinierte Softwareentwicklung in grossen Organisationen. Es bietet einen durchgängigen, skalierbaren Prozessrahmen mit hohem Fokus auf Architektur, Qualität und Wiederverwendbarkeit.
Kurze Beschreibung (inkl. Basis) Der Rational Unified Process ist ein anpassbares Prozessframework mit vier Phasen: Inception, Elaboration, Construction, Transition. Er definiert Rollen, Artefakte und Workflows und baut auf sechs Best Practices auf, darunter iterative Entwicklung, Anforderungsmanagement, komponentenbasierte Architektur und kontinuierliche Qualitätssicherung. Die Basis bildet der Unified Process, kombiniert mit objektorientierten Methoden und UML.
Eignung
Geeignet: Grosse, komplexe Softwareprojekte mit hohem Architektur- und Dokumentationsbedarf, insbesondere in regulierten Branchen.
Nicht geeignet: Kleine Teams, Startups oder Organisationen ohne Ressourcen für umfangreiche Schulungen und Prozesspflege.
Verbreitung RUP war in den 1990er- und frühen 2000er-Jahren in vielen Konzernen der Standard. Heute ist es weniger im Fokus, wirkt aber in Prozesslandschaften und Toollandschaften grosser Unternehmen weiter und bildet eine historische Basis für leichtergewichtige Varianten wie OpenUP.
Agile Skalierungsframeworks – wenn ein Team nicht mehr reicht
Sobald mehrere Teams am selben Produkt oder an eng gekoppelten Produkten arbeiten, stossen reine Team-Frameworks an Grenzen. Abstimmungen, Abhängigkeiten, integrative Tests und gemeinsame Releases erzeugen Komplexität, die du mit Scrum oder Kanban allein nicht mehr sauber handhaben kannst.
An diesem Punkt kommen agile Skalierungsframeworks ins Spiel.
Sie bauen auf Team-Frameworks wie Scrum, Kanban oder XP auf und beantworten Fragen wie:
Wie koordinieren wir mehrere Teams, die an einem gemeinsamen Produkt arbeiten?
Wie stellen wir ein integriertes Inkrement sicher, statt isolierter Teillösungen?
Wie halten wir Transparenz über Dutzende oder Hunderte Personen?
Wie verbinden wir Produktvision, Portfolio und Teamarbeit?
In diesem Kapitel findest du die wichtigsten Skalierungsframeworks im gleichen Steckbrief-Format wie zuvor:
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. Basis)
Wofür geeignet, wofür nicht
Verbreitung
Damit vertiefst du deinen Vergleich agiler Projektmanagement- und Skalierungsframeworks von der Team-Ebene auf die System-Ebene.
1 Scrum of Scrums (SoS)
Dieses Problem löst das Framework Scrum of Scrums adressiert Koordinationsprobleme zwischen mehreren Scrum-Teams, die am gleichen Produkt arbeiten. Es reduziert Kommunikationsaufwand und sorgt dafür, dass Abhängigkeiten nicht erst kurz vor dem Release sichtbar werden.
Kurze Beschreibung (inkl. Basis) Scrum of Scrums ist keine vollständige „Methode”, sondern ein leichtgewichtiger Skalierungsmechanismus. Aus jedem Team nimmt typischerweise ein Delegierter (oft Entwickler) an einem regelmässigen Scrum-of-Scrums-Meeting teil. Dort werden Abhängigkeiten, Blocker und Integrationsfragen besprochen. Häufig ergänzen Rollen wie Chief Product Owner oder ein koordinierender Scrum Master dieses Setup. Die Grundlage ist das Scrum-Framework, erweitert um ein zusätzliches, cross-team Daily.
Eignung
Geeignet: 3–9 Scrum-Teams, die an einem gemeinsamen Produkt oder Produktbereich arbeiten und bereits solide Scrum-Praxis auf Teamebene haben.
Nicht geeignet: Organisationen mit nur einem Scrum-Team oder mit stark divergierenden Produkten, bei denen es kaum Abhängigkeiten gibt. Auch für sehr grosse Programme ohne weitere Struktur reicht SoS meist nicht aus.
Verbreitung Scrum of Scrums ist weit verbreitet als pragmatische Erweiterung von Scrum, oft ohne grosses Labeling. Viele Organisationen praktizieren SoS, ohne es formell als Framework zu benennen.
2 Nexus
Dieses Problem löst das Framework Nexus adressiert Integrationsrisiken, die entstehen, wenn mehrere Scrum-Teams am selben Produkt arbeiten. Es stellt sicher, dass am Ende eines Sprints ein gemeinsames, integriertes Inkrement existiert.
Kurze Beschreibung (inkl. Basis) Nexus ist ein von Scrum.org definiertes Skalierungsframework für typischerweise 3–9 Scrum-Teams. Es fügt dem klassischen Scrum-Setup ein „Nexus Integration Team” hinzu, das für die Integrationsqualität verantwortlich ist. Ausserdem erweitert es die Events: Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review und Nexus Retrospektive koordinieren die Teams. Basis: Scrum, ergänzt um klare Integrationsrollen und -events.
Eignung
Geeignet: Programme, in denen mehrere Teams parallel am selben Produkt mit hohem Integrationsbedarf arbeiten, zum Beispiel bei komplexen Plattformen oder Produkten mit vielen Komponenten.
Nicht geeignet: Kontexte mit nur einem Team oder Projekten mit lose gekoppelten Produkten. In solchen Umgebungen erzeugt Nexus zusätzlichen Overhead ohne echten Mehrwert.
Verbreitung Nexus wird seltener eingesetzt als SAFe oder LeSS, spielt aber in Organisationen eine Rolle, die sich eng an den Scrum.org-Empfehlungen orientieren und bewusst auf schlanke Skalierung setzen.
3 Large Scale Scrum (LeSS)
Dieses Problem löst das Framework LeSS adressiert die Tendenz, bei der Skalierung von Agilität zusätzliche Schichten, Rollen und Gremien aufzubauen. Es will die Komplexität bei mehreren Teams reduzieren, statt neue Komplexität einzuführen.
Kurze Beschreibung (inkl. Basis) Large Scale Scrum erweitert Scrum auf mehrere Teams (LeSS: zwei bis acht Teams, LeSS Huge: mehr). Alle Teams arbeiten an einem gemeinsamen Produkt, teilen sich einen Product Owner, ein Product Backlog und eine Definition of Done. LeSS legt grossen Wert auf systemisches Denken und Lean-Prinzipien. Viele organisatorische Praktiken (z. B. strukturelle Teamzuschnitte, Feature-Teams, De-Skalierung) gehören explizit zum Ansatz.
Eignung
Geeignet: Organisationen, die einen starken Produktfokus haben und bereit sind, ihre Struktur (Silostrukturen, reine Komponenten-Teams) tiefgreifend zu ändern.
Nicht geeignet: Kontexte mit starren Hierarchien, ausgeprägten Fachsilos oder sehr heterogenen Produktlandschaften, in denen ein gemeinsamer Product Owner und ein gemeinsames Backlog unrealistisch sind.
Verbreitung LeSS findet sich vor allem in technologiegetriebenen Unternehmen, die bewusst einen minimalistischen Weg zur Skalierung suchen. Es hat eine engagierte Community, ist aber mengenmässig weniger verbreitet als SAFe.
4 Scrum@Scale
Dieses Problem löst das Framework Scrum@Scale adressiert die Frage, wie sich Scrum-Prinzipien von einzelnen Teams auf ganze Organisationen ausdehnen lassen, ohne ein einziges starres Prozessmodell vorzuschreiben.
Kurze Beschreibung (inkl. Basis) Scrum@Scale wurde von Jeff Sutherland entwickelt. Es basiert auf zwei Zyklen: dem Scrum-Master-Zyklus (Fokus auf Fluss, Impediment-Management, kontinuierliche Verbesserung) und dem Product-Owner-Zyklus (Fokus auf Vision, Priorisierung, Wertstrom). Elemente wie Scrum of Scrums, Meta-Scrum und ein Executive Action Team sorgen für Koordination über Teams, Abteilungen und Hierarchieebenen. Basis: Scrum, Lean Thinking und systemisches Denken.
Eignung
Geeignet: Unternehmen, die Scrum bereits auf Teamebene etabliert haben und dieses Prinzip flexibel in die Breite tragen wollen, ohne ein sehr detailliertes Prozessframework zu übernehmen.
Nicht geeignet: Organisationen, die genaue Vorgaben, Rollenbeschreibungen und Prozesslandkarten erwarten, oder Kontexte, in denen wenig Erfahrung mit Scrum vorhanden ist.
Verbreitung Scrum@Scale gewinnt seit einigen Jahren an Sichtbarkeit, insbesondere in Unternehmen, die eine Alternative zu schwergewichtigeren Skalierungsframeworks suchen und stark mit Scrum-Seminaren und -Zertifizierungen arbeiten.
5 Scaled Agile Framework (SAFe)
Dieses Problem löst das Framework SAFe adressiert die Herausforderung, agile Praktiken in grossen Unternehmen mit vielen Teams, komplexen Programmen und starker Governance zu etablieren. Es will Agilität und Unternehmenssteuerung verbinden.
Kurze Beschreibung (inkl. Basis) Das Scaled Agile Framework ist ein umfangreiches, klar durchdefiniertes Enterprise-Framework. Es definiert Ebenen (Team, Agile Release Train, Solution, Portfolio), Rollen (z. B. Release Train Engineer, System Architect, Product Manager), Events (PI Planning, Inspect & Adapt) und Artefakte. SAFe integriert agile Werte, Lean Product Development und Systemdenken. Es liefert ein umfassendes Referenzmodell inklusive Metriken, Rollenbeschreibungen und Roadmaps.
Eignung
Geeignet: Grosse, oft verteilte Organisationen mit Hunderten von Mitarbeitenden in Entwicklung und Produktmanagement, die eine einheitliche Sprache, Struktur und Governance brauchen. Besonders relevant in Konzernen mit regulatorischen Anforderungen, Portfolio-Management und langfristigen Investitionsentscheidungen.
Nicht geeignet: Kleine Unternehmen, Startups oder Organisationen ohne grundlegende agile Erfahrung. Dort führt SAFe schnell zu Überbürokratisierung und zur Illusion von Agilität durch Begriffs-„Rebranding”.
Verbreitung SAFe ist aktuell das am weitesten verbreitete agile Skalierungsframework in grossen Unternehmen. Viele Fortune-100-Unternehmen nutzen SAFe in Teilen ihrer Organisation. Gleichzeitig ist es eines der kontroversesten Frameworks, weil es Agilität und klassische Steuerungslogik stark verzahnt.
6 Disciplined Agile Delivery (DAD)
Dieses Problem löst das Framework DAD adressiert die Begrenzung von Frameworks, die nur den Entwicklungsteil betrachten. Es bietet einen End-to-End-Ansatz vom ersten Konzept bis zur Auslieferung in Produktion und legt Wert auf Kontext, Optionen und DevOps-Kultur.
Kurze Beschreibung (inkl. Basis) Disciplined Agile Delivery ist ein hybrides Prozessframework, das Praktiken aus Scrum, Kanban, XP, Lean und weiteren Quellen integriert. Es deckt den gesamten Lebenszyklus ab: Inception, Construction, Transition. DAD liefert keine starre Methode, sondern einen Entscheidungsrahmen mit Optionen („Process Goals” und „Process Decision Points”). Basis: Agile, Lean, DevOps und klassische Projektmanagement-Elemente.
Eignung
Geeignet: Organisationen mit mehreren Teams und Produkten, die eine strukturierte, aber flexible Prozessbasis suchen und bereit sind, bewusst Prozessentscheidungen zu treffen, statt einem einzigen Kochbuch zu folgen.
Nicht geeignet: Teams ohne breites Methodenwissen oder mit wenig Zeit und Bereitschaft, sich in ein differenziertes Entscheidungsmodell einzuarbeiten. Dort kann DAD überfordern.
Verbreitung DAD ist in Organisationen verbreitet, die stark in Richtung DevOps und Continuous Delivery arbeiten und gleichzeitig Governance-Bedürfnisse haben. Es ist weniger bekannt als SAFe, hat aber eine stabile, eher fachlich orientierte Anhängerschaft.
7 Disciplined Agile (DA)
Dieses Problem löst das Framework Disciplined Agile adressiert das „One-size-fits-all”-Denken vieler Frameworks. Es bietet eine umfassende Entscheidungsbasis, damit Teams und Organisationen ihren eigenen Way of Working bewusst gestalten können.
Kurze Beschreibung (inkl. Basis) Disciplined Agile ist kein einzelnes Prozessmodell, sondern eine Wissensbasis und ein Entscheidungsrahmen. Es sammelt bewährte Praktiken aus Agile, Lean und traditionellem Projektmanagement und strukturiert sie entlang von Wertströmen und Domänen (z. B. Entwicklung, Governance, Portfolio). Teams treffen an jedem Prozesspunkt bewusste Entscheidungen und sehen Optionen samt Trade-offs. DA wurde von PMI übernommen und ist eng mit DAD, aber breiter angelegt.
Eignung
Geeignet: Organisationen, die Agilität umfassend verstehen und gestalten wollen, vom Team über Programme bis zu Portfolio und Governance, und die bereit sind, aktiv an ihrem Way of Working zu arbeiten.
Nicht geeignet: Sehr kleine Teams oder Organisationen, die eine einfache, sofort anwendbare „Rezepte-Sammlung” suchen, ohne Zeit für Reflektion und Kontextanalyse.
Verbreitung Disciplined Agile gewinnt vor allem im Umfeld von PMI an Bedeutung, zum Beispiel in Organisationen, die bereits PMP- oder andere klassische Zertifizierungen nutzen und ihre Projektlandschaft schrittweise in Richtung Agilität transformieren wollen.
Wie du Skalierungsframeworks für deinen Kontext einordnest
Mit diesen Steckbriefen kennst du die wichtigsten Optionen für die Skalierung von Agilität. Der Vergleich agiler Projektmanagement- und Skalierungsframeworks wird dann wertvoll, wenn du ihn mit deinen konkreten Problemen verknüpfst.
Einige Leitfragen für deine Praxis:
Hast du wirklich ein Skalierungsproblem oder „nur” ein Strukturproblem?
Arbeiten deine Teams bereits sauber mit einem Team-Framework (z. B. Scrum, Kanban), oder willst du Skalierung einführen, bevor die Basis stabil ist?
Brauchst du eher minimale Koordination (Scrum of Scrums, Nexus, LeSS) oder eine umfassende Enterprise-Architektur (SAFe, DA, DAD)?
Wie hoch ist dein Bedarf an Governance, Reporting und Portfolio-Management?
Wenn du diese Fragen klar beantworten kannst, erkennst du schneller, ob dein nächster Schritt eher ein leichtgewichtiges Skalierungssetup oder ein vollumfängliches Enterprise-Framework braucht.
Ziele, Strategie und Organisation
Agile Projektmanagement- und Skalierungsframeworks regeln, wie Teams und Programme arbeiten. Sie beantworten aber nur bedingt die Frage, wohin eine Organisation eigentlich will und wie sie sich strukturiert, damit viele Teams in die gleiche Richtung laufen. Ohne klares Ziel- und Strategiemanagement und ohne passendes Organisationsdesign bleibt Agilität oft auf Team-Workshops und ein paar Sprints beschränkt.
In diesem Kapitel schaust du zwei Ebenen an, die im Alltag stark ineinandergreifen:
Ziel- und Strategiemanagement: Wie setzt du Unternehmensziele so, dass Teams sie verstehen und in konkrete Arbeit übersetzen?
Organisationsmodelle: Wie strukturierst du Rollen, Teams und Entscheidungswege, damit diese Ziele auch erreicht werden können?
Du bekommst wieder die vertrauten Steckbriefe:
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. Basis)
Wofür geeignet, wofür nicht
Verbreitung
So kannst du deinen Vergleich agiler Projektmanagement- und Skalierungsframeworks sinnvoll um die Dimensionen Strategie und Organisation erweitern.
Ziel- und Strategiemanagement
1 OKR (Objectives & Key Results)
Dieses Problem löst das Framework OKR adressiert fehlenden Fokus und mangelnde Ausrichtung zwischen Unternehmensstrategie und der Arbeit einzelner Teams. Es verhindert, dass jede Einheit eigene Prioritäten verfolgt, ohne Beitrag zur Gesamtstrategie.
Kurze Beschreibung (inkl. Basis) OKR besteht aus zwei Elementen: Objectives (qualitative, ambitionierte Ziele) und Key Results (quantitative, messbare Ergebnisse). OKRs werden typischerweise quartalsweise gesetzt, auf Unternehmens-, Bereichs- und Teamebene. Sie machen transparent, woran gearbeitet wird und wie Erfolg gemessen wird. Die Methode basiert auf Management-by-Objectives-Konzepten (Peter Drucker), wurde bei Intel (Andy Grove) schärfer formuliert und durch John Doerr und Google weltweit bekannt.
Eignung
Geeignet: Unternehmen, die Strategie und operative Arbeit enger verknüpfen wollen, schnellere Lernzyklen in der Strategieumsetzung brauchen und Silos aufbrechen möchten.
Nicht geeignet: Organisationen ohne klare Vision oder Strategie. Dort führen OKRs nur zu sauber formatierten, aber inhaltsleeren Zielen. Ebenfalls kritisch: Kontexte, in denen OKRs als Bonus-System oder als reines Kennzahlensystem missverstanden werden.
Verbreitung OKR ist in der Tech-Branche weit verbreitet und findet zunehmend Eingang in klassische Konzerne, Verwaltungen und NGOs. Begriffe wie „Quarterly OKR” oder „OKR-Review” sind in vielen modernen Unternehmen Standard.
2 Hoshin Kanri
Dieses Problem löst das Framework Hoshin Kanri adressiert die Lücke zwischen langfristiger Strategie und täglichem Handeln. Es stellt sicher, dass strategische Prioritäten nicht in der Linienorganisation versanden.
Kurze Beschreibung (inkl. Basis) Hoshin Kanri ist ein japanisches System der Politikverteilung (Policy Deployment). Zentrale Durchbruchziele werden definiert und durch alle Ebenen der Organisation kaskadiert. Iterative Plan-Do-Check-Act-Zyklen und das sogenannte „Catchball” sorgen für Dialog zwischen Management und Teams: Ziele werden nicht nur „top-down verkündet”, sondern im Austausch konkretisiert. Die Basis liegt in Total Quality Management, Lean-Philosophie und dem PDCA-Zyklus.
Eignung
Geeignet: Organisationen, die wenige, aber entscheidende Prioritäten konsequent verfolgen wollen, ideal in Lean-geprägten Umfeldern mit Kultur kontinuierlicher Verbesserung.
Nicht geeignet: Extrem volatile Umfelder, in denen Jahres- oder Mehrjahresplanung schnell obsolet wird, oder Organisationen ohne Disziplin in Planung und Review. Dort verkommt Hoshin Kanri zu einer weiteren Papierübung.
Verbreitung Hoshin Kanri ist besonders in japanisch geprägten Lean-Unternehmen verbreitet, etwa in der Automobilindustrie. Im Westen ist es weniger bekannt als OKR, gewinnt aber in Lean-Communities an Bedeutung.
3 Balanced Scorecard (BSC)
Dieses Problem löst das Framework Die Balanced Scorecard adressiert eindimensionale Steuerung über finanzielle Kennzahlen. Sie ergänzt diese um Kunden-, Prozess- sowie Lern- und Entwicklungsperspektive.
Kurze Beschreibung (inkl. Basis) Die Balanced Scorecard übersetzt Vision und Strategie in konkrete Ziele und Kennzahlen in vier Perspektiven: Finanzen, Kunden, interne Prozesse, Lernen und Entwicklung. Sie verbindet diese Ziele über Ursache-Wirkungs-Beziehungen und ermöglicht ein ausgewogenes Performance-Management. Entwickelt wurde BSC von Robert Kaplan und David Norton in den 1990er-Jahren.
Eignung
Geeignet: Mittlere und grosse Organisationen, die ihre Strategie systematisch in Kennzahlen übersetzen wollen und ein standardisiertes Performance-Management brauchen.
Nicht geeignet: Sehr kleine Unternehmen ohne formale Strategie oder hochdynamische Startups, in denen starre Jahres-Kennzahlensysteme Innovation bremsen würden.
Verbreitung Die Balanced Scorecard ist weltweit in vielen Konzernen, Behörden und Non-Profit-Organisationen verbreitet. Sie gilt in klassischen Managementkreisen als Standardinstrument zur Strategieumsetzung.
Organisationsmodelle
Ziel- und Strategiemodelle legen fest, was erreicht werden soll. Organisationsmodelle bestimmen, wie Menschen zusammenarbeiten, wie Macht verteilt ist und wie Entscheidungen entstehen. Sie bilden den Rahmen, in dem agile Projektmanagement-Frameworks und Skalierungsframeworks überhaupt wirksam werden können.
1 Holacracy
Dieses Problem löst das Framework Holacracy adressiert starre Hierarchien, unklare Verantwortlichkeiten und Entscheidungsstau in traditionellen Linienorganisationen.
Kurze Beschreibung (inkl. Basis) Holacracy ersetzt klassische Hierarchien durch ein Rollen- und Kreismodell. Mitarbeitende üben mehrere klar definierte Rollen aus, die in Kreisen organisiert sind. Eine „Verfassung” legt Regeln für Meetings, Entscheidungsfindung und die Verteilung von Autorität fest. Entscheidungen folgen dem Konsent-Prinzip: Ein Vorschlag gilt, solange keine schlüssigen Einwände bestehen. Basis bilden Ideen der Soziokratie, systemisches Denken und agile Werte. Entwickelt wurde Holacracy von Brian Robertson.
Eignung
Geeignet: Unternehmen mit hoher Veränderungsdynamik, die Entscheidungsbefugnisse verteilen und Selbstorganisation erhöhen wollen, etwa Agenturen, Tech-Firmen oder Innovationsbereiche.
Nicht geeignet: Stark regulierte Umfelder mit klar vorgegebenen Verantwortlichkeiten oder Organisationen, die nicht bereit sind, ihre Machtstrukturen zu hinterfragen. Auch in sehr hierarchisch geprägten Kulturen stösst Holacracy schnell an Grenzen.
Verbreitung Holacracy ist bekannt, aber nicht flächendeckend verbreitet. Einzelne Unternehmen wie Zappos haben es prominent eingeführt, viele andere übernehmen einzelne Prinzipien, ohne das komplette Regelwerk zu adaptieren.
2 Sociocracy 3.0 (S3)
Dieses Problem löst das Framework S3 adressiert den Bedarf nach flexibler, schrittweiser Selbstorganisation, ohne ein geschlossenes, schwergewichtiges System einzuführen.
Kurze Beschreibung (inkl. Basis) Sociocracy 3.0 ist ein Musterkatalog für organisationsweite Selbstorganisation. Es bietet eine Sammlung von Patterns wie kreisförmige Strukturen, Konsententscheidungen, delegierte Autorität, Feedback-Loops und Alignment-Mechanismen. Teams wählen die für sie passenden Muster und passen sie an ihren Kontext an. Basis ist die klassische Soziokratie (Endenburg) kombiniert mit Lean- und Agile-Elementen. S3 ist offen lizenziert und wird laufend weiterentwickelt.
Eignung
Geeignet: Organisationen, die Selbstorganisation evolutionär einführen wollen, experimentierfreudig sind und bereit, mit Mustern zu arbeiten statt mit einem fixen „Betriebssystem”.
Nicht geeignet: Unternehmen, die eine schnelle, top-down verordnete Reorganisation erwarten, oder Kontexte, in denen wenig Bereitschaft besteht, abstrakte Prinzipien zu verstehen und anzuwenden.
Verbreitung S3 wird in KMU, Non-Profits, Netzwerken und einigen agilen Organisationen eingesetzt. Es ist eine Nischenlösung mit wachsender Community, aber kein Massenstandard.
3 Spotify Model
Dieses Problem löst das Framework Das Spotify Model adressiert Silos, starre Abteilungsstrukturen und fehlende Autonomie in grossen Entwicklungsorganisationen. Es gibt Teams mehr Freiraum und fördert gleichzeitig Alignment.
Kurze Beschreibung (inkl. Basis) Das Spotify Model beschreibt eine Organisation mit Squads (kleine, autonome, cross-funktionale Teams) als Grundeinheit. Squads mit verwandten Themen bilden Tribes. Fachliche Gemeinschaften werden als Chapters und Guilds organisiert. Das Modell betont Autonomie, Alignment, kontinuierliche Lieferung und eine starke Produktorientierung. Basis bilden Lean- und Agile-Prinzipien, insbesondere Scrum, Kanban und Lean Startup. Wichtig: Spotify selbst versteht das Modell als Momentaufnahme, nicht als starres Framework.
Eignung
Geeignet: Mittelgrosse und grosse Unternehmen mit vielen Produktteams, die Silos abbauen, Produktverantwortung stärken und Teams mehr Freiheitsgrade bei der Wahl ihrer Arbeitsweisen geben wollen.
Nicht geeignet: Sehr kleine Organisationen oder Konzerne mit extrem rigiden Vorgaben, in denen Autonomie nur auf dem Papier existiert. Ebenfalls problematisch: Wenn das Modell als reines Struktur-Schema kopiert wird, ohne Kultur und technische Voraussetzungen (z. B. Continuous Delivery) mitzudenken.
Verbreitung Das Spotify Model ist in der agilen Community sehr bekannt und wird oft zitiert. Viele Unternehmen „inspirieren” sich daran und führen Squads, Tribes oder Chapters ein, allerdings meist in adaptierten Formen. Eine standardisierte „Zertifizierung” gibt es bewusst nicht.
Zusammenspiel von Zielen, Struktur und agilen Frameworks
Ziel- und Strategiemodelle sowie Organisationsdesign wirken wie ein Rahmen, in dem sich deine agilen Projektmanagement-Frameworks und Skalierungsframeworks entfalten. Ohne diesen Rahmen bleiben Scrum, SAFe oder Kanban lokale Optimierungen.
Einige typische Kombinationen:
OKR + Scrum/Kanban: OKRs definieren die Richtung, Product Backlogs und Boards übersetzen sie in konkrete Arbeit.
Hoshin Kanri + Lean/SAFe: Hoshin Kanri verankert wenige Durchbruchziele, Lean- und SAFe-Mechanismen sorgen für deren Umsetzung in Wertströmen.
Holacracy oder S3 + agile Teams: Rollen- und Kreismodelle verteilen Autorität. Teams nutzen Scrum, Kanban oder XP, um ihre Arbeit zu organisieren.
Spotify Model + Dual Track Agile / Design Thinking: Squads und Tribes strukturieren die Organisation, Discovery- und Delivery-Tracks regeln Produktentwicklung.
Wenn du deinen Vergleich agiler Projektmanagement- und Skalierungsframeworks ernst nimmst, reicht es nicht, die Team-Frameworks anzuschauen. Du brauchst Klarheit über drei Ebenen:
Ziele: Wie setzt ihr Prioritäten, und wie werden sie messbar?
Struktur: Wie seid ihr organisiert, und wie entstehen Entscheidungen?
Ausführung: Wie arbeiten Teams und Programme konkret (Scrum, Kanban, SAFe, LeSS usw.)?
Lean-/Startup-Methoden und Governance-/Hybrid-Modelle
Agile Projektmanagement-Frameworks und Skalierungsframeworks regeln, wie Teams und Programme arbeiten. Ziel- und Organisationsmodelle bestimmen Richtung und Struktur. Zwei weitere Bausteine beeinflussen, wie wir Innovation und Steuerung verbinden:
Lean-/Startup-Methoden: Sie helfen dir, in unsicheren Situationen schnell zu lernen, Hypothesen zu prüfen und Verschwendung zu vermeiden.
Governance-/Hybrid-Modelle: Sie verbinden agile Arbeitsweisen mit klassischer Steuerung, Reporting und Compliance.
Gerade im Vergleich agiler Projektmanagement- und Skalierungsframeworks werden diese beiden Bereiche oft unterschlagen. In der Praxis entscheiden sie aber oft darüber, ob Agilität nur im Team spürbar ist oder ob sie das Geschäftsmodell und die Projektlandschaft tatsächlich verändert.
Auch hier nutzt du wieder die bekannten Steckbriefe:
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. Basis)
Wofür geeignet, wofür nicht
Verbreitung
Lean-/Startup-Methoden
Lean-/Startup-Methoden setzen direkt an Unsicherheit und Lernbedarf an. Sie richten sich weniger an einzelne Teams, sondern an die Art und Weise, wie du Produkte, Services und Geschäftsmodelle entwickelst.
1 Lean Startup
Dieses Problem löst das Framework Lean Startup adressiert das Risiko, viel Geld und Zeit in Produkte zu investieren, die am Markt scheitern, weil zentrale Annahmen nie getestet wurden.
Kurze Beschreibung (inkl. Basis) Lean Startup verfolgt das Ziel, Geschäftsmodelle und Produkte unter hoher Unsicherheit systematisch zu validieren. Kern ist der Build-Measure-Learn-Zyklus: Ein Team baut ein Minimum Viable Product (MVP), misst echtes Nutzerverhalten und lernt daraus. Auf Basis dieser Daten entscheidet es, ob es „perseveriert” (Kurs halten) oder „pivotiert” (Strategie ändert). Die Basis bilden Steve Blanks Customer Development, Lean-Prinzipien und wurden durch Eric Ries’ Buch „The Lean Startup” weltweit bekannt.
Eignung
Geeignet: Startups, Innovationsteams, neue Produktlinien, Corporate Ventures und alle Situationen, in denen die grösste Unsicherheit im Geschäftsmodell oder im Problem-Verständnis liegt.
Nicht geeignet: Kontexte mit sehr stabilen, stark regulierten Anforderungen (z. B. sicherheitskritische Medizinprodukte), in denen Experimente nur begrenzt möglich sind oder rechtliche Rahmenbedingungen enge Grenzen setzen.
Verbreitung Lean Startup ist in der Startup-Szene ein Standardansatz und in vielen Innovationsabteilungen grosser Unternehmen etabliert. Begriffe wie MVP, Pivot und Build-Measure-Learn sind heute breit bekannt, auch ausserhalb der Tech-Welt.
2 Build-Measure-Learn (Zyklus)
Dieses Problem löst das Framework Der Build-Measure-Learn-Zyklus adressiert lange, theorielastige Konzeptphasen, in denen Teams Annahmen nicht testen und dadurch in die falsche Richtung investieren.
Kurze Beschreibung (inkl. Basis) Build-Measure-Learn ist der zentrale Lernzyklus aus Lean Startup. Er beschreibt eine klare Reihenfolge: Zuerst baust du ein einfaches Produkt oder Experiment, dann misst du das Verhalten der Nutzer oder relevante Kennzahlen, danach ziehst du systematisch Schlüsse und passt Produkt oder Strategie an. Die Basis liegt in der wissenschaftlichen Methode: Hypothesen aufstellen, Tests definieren, Daten auswerten, nächste Hypothese formulieren.
Eignung
Geeignet: Produktentwicklung in dynamischen Märkten, Prozessverbesserungen mit direktem Nutzerfeedback, datengetriebene Teams, die Entscheidungen empirisch treffen wollen.
Nicht geeignet: Projekte, bei denen Änderungen extrem teuer sind und Prototypen schwer umsetzbar, etwa bei bestimmter Hardware oder Infrastruktur mit langen Bauzyklen.
Verbreitung Der Zyklus ist fester Bestandteil vieler Innovationsprogramme, Accelerator-Programme und moderner Produktentwicklung. Auch Teams, die Lean Startup nicht explizit nutzen, orientieren sich häufig am Build-Measure-Learn-Denken.
3 Lean Software Development
Dieses Problem löst das Framework Lean Software Development adressiert Verschwendung, Überlastung und lange Durchlaufzeiten in der Softwareentwicklung.
Kurze Beschreibung (inkl. Basis) Lean Software Development überträgt Prinzipien aus der Lean-Produktion auf Software. Zentrale Elemente sind das Eliminieren von Verschwendung, schnelles Liefern, Qualität von Anfang an, Optimierung des Gesamtflusses und das Verzögern von Entscheidungen, bis genügend Informationen vorliegen. Die Basis bilden das Toyota Production System und Lean Thinking, weiterentwickelt für Software durch Mary und Tom Poppendieck.
Eignung
Geeignet: Organisationen, die bereits grundlegende agile Praktiken nutzen und nun Engpässe, Wartezeiten und Überlastung auf Systemebene reduzieren wollen.
Nicht geeignet: Kontexte ohne Bereitschaft, Prozesse ganzheitlich zu betrachten. Wer Lean nur auf Team-Level als Schlagwort nutzt, ohne Wertströme und Strukturen zu analysieren, wird wenig Wirkung sehen.
Verbreitung Lean-Prinzipien fliessen in viele Frameworks ein, etwa SAFe oder LeSS. Als eigenständiges Label tritt Lean Software Development seltener auf, seine Ideen sind jedoch in vielen agilen Transformationsprogrammen verankert.
Governance-/Hybrid-Modelle
Viele Organisationen stehen zwischen zwei Welten: Agile Teams sollen schnell liefern, gleichzeitig verlangen Stakeholder, Aufsichtsbehörden oder Kunden nach klaren Budgets, Meilensteinen und Verantwortlichkeiten. Governance-/Hybrid-Modelle versuchen, diese Spannungen zu adressieren.
1 PRINCE2 Agile
Dieses Problem löst das Framework PRINCE2 Agile adressiert den Konflikt zwischen klassischer Projektgovernance und agilem Arbeiten. Es hilft Organisationen, die bereits PRINCE2 nutzen, agile Vorgehensweisen zu integrieren, ohne das bestehende Steuerungsmodell komplett aufzugeben.
Kurze Beschreibung (inkl. Basis) PRINCE2 Agile kombiniert den strukturierten Projektmanagementrahmen von PRINCE2 mit agilen Methoden wie Scrum und Kanban. PRINCE2 liefert weiterhin die Projektorganisation, Managementphasen, Business Case und Toleranzkonzepte. Agile Praktiken kommen auf Produkt- und Teamebene zum Einsatz. Die Basis ist das etablierte PRINCE2-Framework, erweitert um agile Prinzipien, Praktiken und Tailoring-Empfehlungen.
Eignung
Geeignet: Organisationen, die PRINCE2 bereits als Standard nutzen, etwa öffentliche Verwaltungen oder Konzerne mit starker Governance, und die mehr Agilität in der Produktentwicklung zulassen wollen.
Nicht geeignet: Kleine Unternehmen ohne vorhandene PRINCE2-Struktur oder Teams, die eine schlanke, minimalistische Lösung suchen. Dort führt PRINCE2 Agile zu unnötigem Overhead.
Verbreitung PRINCE2 Agile ist vor allem in Europa und im öffentlichen Sektor verbreitet, in Umgebungen, in denen PRINCE2 ohnehin als Projektstandard gilt. Zertifizierungen spielen eine zentrale Rolle bei der Verbreitung.
2 AgilePM (Agile Project Management)
Dieses Problem löst das Framework AgilePM adressiert die Lücke zwischen klassischer Projektsteuerung und agiler Produktentwicklung, insbesondere in Organisationen, die klare Projektphasen und Governance-Strukturen brauchen.
Kurze Beschreibung (inkl. Basis) AgilePM ist ein vom Agile Business Consortium entwickelter Ansatz, der DSDM-Prinzipien in ein praxistaugliches Projektmanagementmodell übersetzt. Er deckt den gesamten Projektlebenszyklus ab, von der Vor-Projekt-Phase bis zur Nachprojekt-Phase, und betont Geschäftsnutzen, Timeboxing, klare Rollen sowie kontinuierliche Zusammenarbeit mit den Stakeholdern. Die Basis bildet DSDM und das Agile Project Framework.
Eignung
Geeignet: Organisationen mit Bedarf an strukturierter Projektgovernance, die dennoch agil liefern wollen, etwa in regulierten Branchen, öffentlichen Projekten oder grossen Transformationsvorhaben.
Nicht geeignet: Sehr kleine Vorhaben, bei denen reine Team-Frameworks wie Scrum oder Kanban ausreichen, oder Kontexte, die keine formale Projektorganisation benötigen.
Verbreitung AgilePM ist weltweit verfügbar, mit Schwerpunkt in Europa. Es wird häufig dort eingesetzt, wo DSDM- oder AgilePM-Zertifizierungen nachgefragt werden und wo klassische Projektmanagement-Zertifikate bereits etabliert sind.
Wie Innovation und Governance zusammenfliessen können
Lean-/Startup-Methoden und Governance-/Hybrid-Modelle wirken auf den ersten Blick gegensätzlich: Hier schnelle Experimente mit MVPs, dort gesteuerte Projekte mit Phasen, Budgetfreigaben und Gremien. In der Praxis brauchst du oft beides.
Einige typische Kombinationen:
Lean Startup + Scrum/Kanban: Lean Startup liefert Hypothesen, Experimente und MVP-Logik. Teams setzen diese mit Scrum oder Kanban um.
Build-Measure-Learn + OKR: Key Results definieren messbare Ziele, Build-Measure-Learn liefert den experimentellen Weg dorthin.
Lean Software Development + SAFe / LeSS: Lean-Prinzipien helfen, Wertströme in Skalierungsframeworks zu optimieren und Verschwendung auf Systemebene zu erkennen.
PRINCE2 Agile oder AgilePM + agile Teams: Agile Teams arbeiten in Sprints oder Fluss, während Projektboard, Business Case und Governance-Strukturen die Richtung, Finanzierung und Risiken steuern.
In einem reifen Vergleich agiler Projektmanagement- und Skalierungsframeworks geht es nicht darum, eines dieser Modelle „gewinnen” zu lassen, sondern darum, bewusst zu entscheiden:
In welchen Teilen deiner Organisation brauchst du maximale Lern- und Experimentierfähigkeit?
Wo brauchst du klare Steuerung, Entscheidungsgremien und vertragliche Sicherheit?
Wie stellst du sicher, dass diese Bereiche nicht gegeneinander arbeiten, sondern sich ergänzen?
Produktentwicklungsmethoden – Design Thinking und Dual Track Agile
Agile Projektmanagement-Frameworks und Skalierungsframeworks regeln, wie Teams liefern. Zielsysteme, Organisationsmodelle und Governance klären, warum und unter welchen Rahmenbedingungen sie arbeiten. Produktentwicklungsmethoden setzen an einer anderen Stelle an: Sie beantworten die Frage, welches Problem du überhaupt lösen willst und welches Produkt sich dafür eignet.
In vielen Unternehmen sind genau diese Fragen unscharf. Teams liefern sauber nach Scrum, SAFe oder Kanban, aber niemand hat das Problem wirklich verstanden, die Nutzer sauber untersucht oder Hypothesen strukturiert getestet. Produktentwicklungsmethoden wie Design Thinking und Dual Track Agile schliessen diese Lücke.
Auch hier nutzt du wieder den Steckbrief:
Dieses Problem löst das Framework
Kurze Beschreibung (inkl. Basis)
Wofür geeignet, wofür nicht
Verbreitung
Damit erweiterst du deinen Vergleich agiler Projektmanagement- und Skalierungsframeworks um die Ebene der Produktfindung und -validierung.
1 Design Thinking
Dieses Problem löst das Framework Design Thinking adressiert unklare oder falsch verstandene Problemstellungen. Es verhindert, dass Teams Lösungen entwickeln, ohne die Bedürfnisse der Nutzer wirklich zu kennen oder zu prüfen.
Kurze Beschreibung (inkl. Basis) Design Thinking ist ein nutzerzentrierter Problemlösungsprozess. Er führt Teams iterativ durch Phasen wie:
Verstehen und Beobachten (Kontext, Nutzer, Stakeholder)
Sichtweise definieren (Problemdefinition aus Nutzersicht)
Ideen entwickeln
Prototyping
Testen mit echten Nutzern
Der Ansatz verbindet Methoden aus Psychologie, Design und Wirtschaft. Er wurde insbesondere durch die Stanford d.school und IDEO verbreitet. Zentrale Prinzipien sind Empathie, Visualisierung, iteratives Lernen und ein interdisziplinäres Teamsetting.
Eignung
Geeignet:
Frühe Innovationsphasen, in denen Problem und Zielgruppe noch nicht scharf definiert sind.
Entwicklung neuer Produkte, Services oder Erlebnisse mit starkem Nutzerbezug.
Interdisziplinäre Teams, die gemeinsam ein vernetztes Problem verstehen müssen.
Nicht geeignet:
Routineprojekte mit klaren, stabilen Anforderungen, bei denen bereits feststeht, was gebaut werden soll.
Rein technische Optimierungen ohne direkten Nutzerkontakt, bei denen Metriken und Systemparameter im Vordergrund stehen.
Kontexte, die keinen Zugang zu Nutzern erlauben und Feedback stark einschränken.
Verbreitung Design Thinking ist in Innovationslaboren, Corporate-Startup-Programmen, Hochschulen und Beratungen weit verbreitet. Viele Unternehmen nutzen Design-Thinking-Workshops als Einstieg, ohne immer den gesamten Prozess konsequent zu verankern. Einzelne Elemente wie Empathy Maps, Customer Journeys und Prototyping sind in vielen Produktteams Standard.
2 Dual Track Agile
Dieses Problem löst das Framework Dual Track Agile adressiert das Problem, dass Teams Entdeckung (Was sollen wir bauen?) und Lieferung (Wie setzen wir es technisch um?) vermischen oder Discovery komplett vernachlässigen. Es verhindert, dass Backlogs mit unvalidierten Ideen gefüllt werden, die das Team dann „nur noch” umsetzt.
Kurze Beschreibung (inkl. Basis) Dual Track Agile trennt bewusst zwei Arbeitsströme:
Discovery-Track: Hier validiert das Team Ideen, Hypothesen und Probleme. Es arbeitet mit Nutzerinterviews, Prototypen, Experimenten, Metriken und Tests. Ziel: Lernen, nicht liefern.
Delivery-Track: Hier setzt das Team validierte Anforderungen in Produktionsqualität um, typischerweise mit Scrum oder Kanban. Ziel: Stabile, wartbare, integrierte Lösungen.
Die beiden Tracks laufen parallel und beeinflussen sich gegenseitig. Discovery liefert Input für Delivery, und reale Nutzung im Delivery-Track liefert Daten für neue Discovery-Fragen. Dual Track Agile basiert auf moderner Produktmanagement-Literatur, Erfahrungen aus Lean Startup, Design Thinking und agilen Entwicklungsmethoden.
Eignung
Geeignet:
Produktteams mit kontinuierlicher Verantwortung für ein Produkt oder einen Service.
Märkte mit hoher Unsicherheit, in denen du regelmässig testen musst, welche Features wirklich Mehrwert bringen.
Organisationen, die Produktmanagement als lernorientierte Funktion verstehen, nicht nur als Anforderungsverwaltung.
Nicht geeignet:
Reine Projektorganisationen mit fixem Scope, Budget und Enddatum, in denen kaum Raum für Hypothesen und Experimente bleibt.
Teams ohne Zugriff auf Nutzerdaten oder ohne Möglichkeit, Prototypen schnell zu testen.
Umfelder, in denen Discovery strukturell nicht akzeptiert ist und nur „Output” zählt.
Verbreitung Dual Track Agile ist vor allem in produktorientierten Tech-Unternehmen verbreitet und gewinnt in klassischen Konzernen mit digitalen Produkten an Bedeutung. Viele Organisationen setzen Teile des Ansatzes um (z. B. Discovery-Formate, Product Discovery Sprints), ohne ihn immer explizit als „Dual Track Agile” zu benennen.
Zusammenspiel mit agilen Projekt- und Skalierungsframeworks
Design Thinking und Dual Track Agile ersetzen keine Projektmanagement-Frameworks und keine Skalierungsframeworks. Sie ergänzen sie. In einem reifen Setup greifen diese Ebenen ineinander:
Design Thinking + Dual Track Agile + Scrum/Kanban:
Design Thinking hilft, Problemraum und Nutzerbedürfnisse zu verstehen.
Im Discovery-Track von Dual Track Agile nutzt du viele Design-Thinking-Methoden.
Im Delivery-Track setzt das Team validierte Ergebnisse mit Scrum oder Kanban um.
Design Thinking + OKR:
OKRs definieren Outcomes, die du erreichen willst (z. B. Nutzerverhalten, Zufriedenheit, Geschäftsmetriken).
Design Thinking liefert Ideen und Prototypen, wie du diese Outcomes erreichst.
Dual Track Agile + Skalierungsframeworks (z. B. SAFe, LeSS, Scrum@Scale):
Discovery findet auf Produkt- oder Wertstromeinheiten statt.
Delivery wird über Teams und Züge (Trains) skaliert.
Portfolio- oder Programmlevel koordiniert, welche validierten Initiativen in den Delivery-Backlogs landen.
Wenn du deinen Vergleich agiler Projektmanagement- und Skalierungsframeworks ernsthaft nutzt, solltest du deshalb immer fragen:
Wo entsteht bei uns eigentlich Wert: in der Entdeckung des richtigen Problems, in der schnellen, sauberen Umsetzung oder in der Koordination vieler Teams?
Welche Produktentwicklungsmethoden setzt ihr heute bewusst ein, und wo lasst ihr Discovery einfach „nebenbei” laufen?
Abschliessende Gedanken: Wie du dein Framework-Set bewusst gestaltest
Agile Frameworks haben in diesem Artikel Gesichter bekommen. Du hast gesehen, dass hinter Scrum, Kanban, SAFe, OKR, Holacracy, Lean Startup oder Design Thinking klare Problemannahmen stehen. Kein Framework ist neutral. Jedes wurde für bestimmte Situationen entworfen und trägt blinde Flecken in sich.
Damit dein Vergleich agiler Projektmanagement- und Skalierungsframeworks mehr ist als eine Übungsaufgabe, brauchst du nun einen klaren Entscheidungsrahmen. Nicht für „das beste Framework”, sondern für dein passendes Set.
Vom Framework-Zoo zur Problem-Landkarte
Ein typischer Fehler: Organisationen starten bei der Lösung, nicht beim Problem. SAFe, OKR oder Holacracy werden eingeführt, weil andere es tun oder weil Zertifizierungen verfügbar sind. Danach versucht man, die Realität in das gewählte Modell zu pressen.
Drehe die Logik um. Starte mit einer Problem-Landkarte:
Wo fehlt dir Transparenz auf Teamebene?
Wo scheitert Koordination zwischen mehreren Teams?
Wo fehlt dir Klarheit über Ziele und Prioritäten?
Wo blockieren Struktur und Hierarchie schnelle Entscheidungen?
Wo vergeudest du Ressourcen in falschen Produkten oder Features?
Wo fordern Stakeholder mehr Governance, Nachvollziehbarkeit und Compliance?
Erst dann legst du die Frameworks aus diesem Artikel daneben und suchst nach gezielten Passungen. Genau hier hilft dir deine Download-Tabelle: Du kannst pro Problemspalte markieren, welche Frameworks dazu passen und wo sie beitragen.
Welche drei Probleme fallen dir spontan ein, wenn du an deinen Alltag denkst?
Dein Stack in Ebenen denken statt in Einzel-Frameworks
Statt „Wir machen Scrum” oder „Wir führen SAFe ein” lohnt sich ein Ebenenmodell. Du kannst dein Framework-Set in Schichten betrachten:
1. Team-Ebene
Frameworks: Scrum, Kanban, XP, Scrumban, DSDM, FDD, OpenUP, RUP, ASD, RAD
Frage: Wie organisiert ein Team seine tägliche Arbeit, Planung und Verbesserung?
2. Skalierungs-Ebene
Frameworks: Scrum of Scrums, Nexus, LeSS, Scrum@Scale, SAFe, DAD, DA
Frage: Wie koordinieren mehrere Teams ein gemeinsames Produkt oder Portfolio?
3. Ziel- und Strategie-Ebene
Frameworks: OKR, Hoshin Kanri, Balanced Scorecard
Frage: Wie werden Ziele gesetzt, gemessen und über Ebenen ausgerichtet?
4. Organisations-Ebene
Frameworks: Holacracy, Sociocracy 3.0, Spotify Model
Frage: Wie sind Teams, Rollen und Entscheidungswege strukturiert?
5. Innovation und Lernen
Frameworks: Lean Startup, Build-Measure-Learn, Lean Software Development
Frage: Wie lernst du unter Unsicherheit und reduzierst Verschwendung?
6. Governance und Hybrid-Modelle
Frameworks: PRINCE2 Agile, AgilePM
Frage: Wie kombinierst du agile Arbeitsweisen mit Budgets, Gremien und Compliance?
7. Produktentwicklung
Frameworks: Design Thinking, Dual Track Agile
Frage: Wie findest und validierst du Probleme und Produktideen?
Wenn du pro Ebene bewusst entscheidest, welche Rolle dort ein Framework spielen soll, gewinnst du Klarheit. Du vermeidest Doppelungen und Widersprüche und kannst transparent erklären, warum ihr was einsetzt.
Auf welcher Ebene ist dein Framework-Set heute am klarsten, und auf welcher Ebene herrscht Mischmasch?
Kleine, gezielte Eingriffe statt Big-Bang-Transformation
Viele Transformationsprogramme scheitern daran, dass sie zu viel auf einmal wollen. Ein Konzern führt gleichzeitig SAFe, OKR und ein neues Organisationsmodell ein. Die Teams sollen neue Rollen lernen, neue Prozesse verstehen und parallel weiterhin liefern. Überforderung ist vorprogrammiert.
Nutze deine Übersicht für gezielte Eingriffe:
Wenn das Hauptproblem fehlende Transparenz im Team ist, starte mit Scrum oder Kanban, bevor du Skalierung diskutierst.
Wenn du schon starke Teams, aber chaotische Programmkoordination hast, prüfe leichte Skalierungsformen wie Scrum of Scrums oder Nexus, bevor du SAFe einführst.
Wenn Teams gut arbeiten, aber die strategische Richtung unklar ist, fokussiere auf OKR oder Hoshin Kanri, nicht auf neue Team-Frameworks.
Wenn du viel Output, aber wenig Wirkung hast, setze Design Thinking, Dual Track Agile und Lean Startup an die Spitze der Produktentwicklung.
Du kannst in deiner Download-Tabelle markieren, welche Frameworks du bereits einsetzt, welche du bewusst wieder entfernen willst und welche du gezielt testen möchtest. Ein Framework zu streichen, ist oft genauso wertvoll wie ein neues einzuführen.
Wo könntest du noch in diesem Jahr ein überflüssiges oder widersprüchliches Framework offiziell „abbauen”?
Integration statt Konkurrenz
In der Praxis geraten Framework-Familien schnell in Konkurrenz: SAFe vs. LeSS, OKR vs. BSC, Holacracy vs. klassische Linie, Scrum vs. Kanban. Die Übersicht aus diesem Artikel zeigt aber: Viele dieser Frameworks können sich ergänzen, wenn du klar trennst, welches Problem sie adressieren:
Du kannst Scrum-Teams in einem SAFe-ART haben und gleichzeitig Lean Startup in einer frühen Innovationsphase nutzen.
Du kannst OKR zur Fokussierung kombinieren mit einer Balanced Scorecard, wenn du regulatorische Kennzahlen brauchst.
Du kannst in einer klassischen Linie einzelne Bereiche mit S3-Patterns arbeiten lassen, ohne sofort die ganze Organisation umzustellen.
Du kannst Kanban in Service-Teams und Scrum in Produktteams parallel einsetzen, solange Schnittstellen geklärt sind.
Statt Frameworks gegeneinander antreten zu lassen, lohnt es sich, Schnittstellen und Übergänge zu definieren. Wo entsteht ein Übergang von Discovery zu Delivery? Wo trifft Governance auf agile Teams? Wo übersetzen OKRs sich in Backlog-Items?
An welcher Stelle prallen in deinem Umfeld heute zwei Frameworks sichtbar aufeinander?
Messbar machen, ob ein Framework sein Problem wirklich löst
Ein Framework sollte kein Glaubensbekenntnis sein, sondern eine Hypothese:
„Wenn wir dieses Framework in diesem Kontext anwenden, verbessert sich folgende Kennzahl.”
Hier schliesst sich der Kreis zu Lean- und Startup-Methoden. Du kannst Framework-Einführungen wie Experimente behandeln:
Nenne klar das Problem (z. B. Durchlaufzeit, Fehlerrate, Überlastung, Koordinationsaufwand, Zielklarheit).
Wähle ein Framework, das dieses Problem adressiert.
Definiere wenige, messbare Indikatoren, die sich verbessern sollen.
Setze das Framework zunächst in einem begrenzten Bereich ein.
Ziehe nach einer festen Zeit Bilanz: Hat sich das Problem reduziert?
Wenn du so vorgehst, verlierst du weniger Zeit in Framework-Diskussionen und gewinnst mehr Erkenntnisse aus Daten.
Welche Metrik würdest du für das nächste Framework-Experiment definieren?