Warum wir uns von Scrum verabschieden
Vor etwa sechs Jahren haben wir Scrum im Unternehmen eingeführt – mit dem Ziel, flexibler zu werden und Schätzungen näher an die Realität von Softwareentwicklung heranzuführen. Wir wollten Auslieferungen verlässlicher planen und unsere Arbeit klarer strukturieren. In dieser Zeit haben wir viel gelernt und einige Elemente funktionieren bis heute sehr gut und sind weiterhin Bestandteil unserer täglichen Arbeit. Besonders das Aufteilen von Features in kleine, eigenständige Anforderungspakete reduziert Komplexität und erhöht die Klarheit für Entwickler:innen. Kleinere Funktionalitäten werden schneller testbar und releasefähig.
Im Verlauf der Jahrehaben wir festgestellt, dass das Arbeiten in Sprints und festen Release-Zyklen jedoch nicht ideal zu unserem Agenturalltag passt. Unsere Kunden denken meist in Versionen mit fixem Scope und klar definierten Zeitplänen – also eher klassisch „wasserfallartig“. Scrum hingegen priorisiert fertige Features zum Sprintende und verschiebt Unfertiges flexibel nach hinten. Dieser Unterschied im Planungsverständnis erzeugt Spannungen zwischen interner Arbeitsweise und externer Erwartungshaltung.
Kompliziert statt komplex – ein entscheidender Unterschied
Agile Methoden spielen ihre Stärke besonders in komplexen Umfeldern aus – also dort, wo sowohl das „Was“ (Anforderungen) als auch das „Wie“ (Umsetzung) mit hoher Unsicherheit behaftet sind. Unser Projektalltag sieht jedoch anders aus.
Wir entwickeln Apps und verfügen über ein sehr großes Erfahrungswissen hinsichtlich Architektur, Technologie und Führung der Nutzer:innen. Das „Wie“ ist in den meisten Fällen klar. Und auch das „Was“ lässt sich gemeinsam mit unseren Kunden in Konzeptphasen so präzise definieren, dass nur noch geringe Unsicherheiten bestehen. Unsere Projekte sind daher in erster Linie kompliziert – sie enthalten viele Abhängigkeiten, aber wenig grundsätzliche Unklarheit.
Für komplizierte Projekte mit klaren Anforderungen und zahlreichen Abhängigkeiten ist Scrum nicht die bestmögliche Methode. Hier benötigen wir ein System, das Abhängigkeiten aktiv steuert und Durchsatz optimiert.
Die Herausforderung mit Schätzungen
Ein zentrales Thema blieb für uns unter Scrum ungelöst: der Umgang mit Aufwandsschätzungen. Grundsätzlich gilt – wenn man exakt wissen will, wie lange etwas dauert, muss man es bereits erledigt haben. Jede Schätzung enthält also Unsicherheit.
Scrum begegnet diesem Problem mit Story Points, die Komplexität abstrahieren und bewusst nicht in Zeit messen. Für uns funktionierte dieser Ansatz nur bedingt, da wir gegenüber Kunden mit Zeitbudgets arbeiten. Unser Team schätzte intern häufig in Stunden oder Tagen und „übersetzte“ diese anschließend in Story Points – ein zusätzlicher Umweg ohne echten Mehrwert.
Wir brauchen daher ein Toolset, das zeitliche Planung ermöglicht und gleichzeitig systematisch mit der inhärenten Ungenauigkeit von Schätzungen umgeht.
Was ist CCPM – und warum passt es besser zu uns?
CCPM (Critical Chain Project Management) ist eine Methode für komplizierte Projekte mit klaren Abhängigkeiten und begrenzten Ressourcen. Im Mittelpunkt stehen nicht einzelne Aufgaben, sondern der Durchsatz des Gesamtsystems, also des Projektportfolios.
Die Methode basiert auf mehreren zentralen Prinzipien:
· Single-Tasking statt Multitasking: Fokus auf eine Aufgabe, um Kontextwechsel zu reduzieren und effizienter arbeiten zu können.
· Berücksichtigung von Student Syndrome und Parkinson’s Law : Menschen neigen dazu, Aufgaben erst kurz vor der Deadline zu beginnen oder Arbeit so lange auszudehnen, wie Zeit dafür eingeplant ist. CCPM begegnet dem mit ambitionierten Schätzungen und zentralen Projektpuffern statt versteckten Sicherheitsreserven auf Aufgabenebene.
· Empirisch definierte Puffer: Die Erfahrungen aus vergangenen Projekten bilden die Grundlage für realistische Projektpuffer.
· Schutz des Projekts statt einzelner Aufgaben: Sicherheit wird bewusst auf Projektebene gebündelt, anstatt jede Aufgabe einzeln mit Puffer zu versehen.
· Fokus auf Ressourcen und Engpässe: Menschen, Teams und ihre Kapazitäten bestimmen den Projektdurchsatz – im Sinne der Theory of Constraints.
Statt jede Aufgabe individuell „abzusichern“, wird Sicherheit gebündelt und transparent gesteuert.
CCPM in der Praxis – das Flughafenmodell
Unser Projektportfolio lässt sich wie ein internationaler Flughafen verstehen: Täglich starten und landen zahlreiche Flüge (= Projekte) mit unterschiedlichen Zielen, Kapazitäten und Prioritäten. Entscheidend ist dabei nicht der einzelne Flug, sondern das reibungslose Zusammenspiel aller Flüge im Gesamtsystem. Ein Flughafen funktioniert nur dann stabil, wenn Starts, Landungen und Ressourcen aufeinander abgestimmt sind – nicht, wenn jeder Flug für sich isoliert optimiert wird.
In diesem Bild ist die Critical Chain die zentrale Landebahn des gesamten Flughafens. Sie repräsentiert die Ressourcenkette im Portfolio, die den Durchsatz des Systems bestimmt. Wird diese Landebahn blockiert, staut sich der gesamte Betrieb. Genau hier setzt CCPM an: Statt einzelne Projekte lokal zu optimieren, steuern wir das Portfolio als Gesamtsystem. Projekte werden priorisiert und bewusst getaktet gestartet, sodass Engpässe geschützt und Ressourcen gezielt eingesetzt werden.
Unsere Teams und Spezialist:innen sind dabei der systembestimmende Faktor – vergleichbar mit Crews oder Fluglots:innen. Sie sind begrenzt verfügbar und können nicht beliebig parallel arbeiten. Deshalb maximieren wir nicht die Auslastung jeder einzelnen Person (lokale Optimierung), sondern den stabilen Durchsatz des gesamten Portfolios (Systemoptimierung).
Projekte werden genau dann aktiviert, wenn sie „fliegen“ sollen – nicht früher und nicht später. So vermeiden wir Student Syndrome und Parkinson’s Law und reduzieren Multitasking konsequent. Entscheidend ist am Ende nicht der perfekte Einzelflug, sondern ein stabiler, planbarer Gesamtbetrieb. CCPM optimiert daher den gesamten Flugplan – also unser Projektportfolio – und nicht nur einzelne Projekte isoliert.
Unser Ausblick
Unsere Projekte sind kompliziert – mit klaren Anforderungen, vielen Abhängigkeiten und begrenzten Ressourcen. Deshalb benötigen wir eine Projektmanagement-Methode, die genau diese Realität adressiert: transparent, ressourcenorientiert und mit einem strukturierten Umgang mit Unsicherheit.
Seit dem Sommer 2025 führen wir CCPM Schritt für Schritt in unseren Projekten ein und sehen bereits klare Verbesserungen:
· Die Projektpuffer fangen die in Schätzungen inhärenten Unsicherheiten in den meisten Fällen sehr gut ab.
· Wir können den Projektstatus deutlich klarer bewerten und frühzeitig gegensteuern, wenn sich ein erhöhter Pufferverbrauch abzeichnet. Gleichzeitig gelingt es uns immer besser, Multitasking konsequent zu vermeiden.
· Die Termintreue unserer Lieferungen hat spürbar zugenommen.
Natürlich stehen auch wir weiterhin vor Herausforderungen, denen wir mit dem nötigen Pragmatismus begegnen. Eine stärker wasserfallartige Planungslogik soll uns schließlich nicht die Flexibilität nehmen, die in der Softwareentwicklung essenziell bleibt. CCPM verstehen wir daher nicht als starres Regelwerk, sondern als strukturierten Rahmen, den wir kontinuierlich weiterentwickeln.
In den kommenden Monaten werden wir CCPM weiter systematisch in all unseren Projekten verankern. Wir sind gespannt auf die weiteren Erfahrungen und werden berichten, wie sich die Methode langfristig in unserem Agenturalltag bewährt. Wenn euch interessiert, wie wir Projekte heute planen oder ihr euch zu CCPM austauschen möchtet, meldet euch gerne bei uns.