Warum klassische Sprints nicht für jede Organisation funktionieren
Shape Up ist das Projektmanagement-Framework, das Basecamp entwickelt hat, weil klassische zwei-Wochen-Sprints für ihr Produktteam nicht mehr funktionierten. Wer regelmäßig mit Scrum arbeitet, kennt das Problem: Der Backlog wächst schneller als er geleert wird, Schätzungen treffen nie zu, und das Team liefert zwar Output, aber selten fertige Lösungen, die echten Wert schaffen.
Shape Up dreht dieses System um. Statt fortlaufender Sprint-Zyklen mit zunehmend aufgeblähten Backlogs setzt das Framework auf klare Grenzen, echte Eigenverantwortung und einen Arbeitsrhythmus, der mentale Energie langfristig erhält. In diesem Artikel schaue ich mir das Framework systematisch an, erkläre die Kernprinzipien und zeige, wo Shape Up sinnvoll ist, und wo nicht.
Sechswöchige Zyklen: Der Grundrhythmus von Shape Up
Der Arbeitsrhythmus von Shape Up basiert auf sechswöchigen Zyklen. Sechs Wochen ist eine bewusste Entscheidung: Lang genug, um ein Projekt von Anfang bis Ende fertigzustellen. Kurz genug, damit der Druck der Deadline von Tag eins an spürbar ist.
Was danach kommt, ist genauso durchdacht: eine zweiwöchige Cool-down-Phase. In dieser Zeit gibt es keine geplanten Projekte. Das Team nutzt die Zeit für Fehlerbehebungen, Weiterbildung oder technische Experimente. Kein Burnout durch Dauervollgas, kein sofortiger Sprung in den nächsten Zyklus ohne Atemraum.
Wer Teams kennt, die von Sprint zu Sprint hetzen und sich nie Zeit nehmen, technische Schulden abzubauen oder neue Ansätze auszuprobieren, versteht sofort, warum diese Phase nicht optional ist. Sie ist strukturell eingebaut, damit das Team nicht mittelfristig an Qualität verliert.
Shaping: Projekte formen, bevor sie an Teams gehen
Bevor ein Projekt überhaupt an ein Team übergeben wird, durchläuft es den sogenannten Shaping-Prozess. Erfahrene Personen, meist auf Senior-Ebene, arbeiten die Lösung so weit aus, dass sie weder zu vage noch zu detailliert ist.
Das klingt abstrakt, ist aber ein präzises Handwerk. Zwei konkrete Werkzeuge helfen dabei:
- Breadboarding: Kein visuelles Design, sondern ein Schema der funktionalen Flüsse. Welche Schnittstellen braucht es? Welche Schritte macht der Nutzer? Vergleichbar mit einem Elektroschaltplan, der Funktion zeigt, nicht Optik.
- Fat-Marker Sketches: Grobe Skizzen mit einem sprichwörtlich dicken Marker. Kein Detail passt dort drauf. Das ist Absicht, denn hochaufgelöste Wireframes ersticken die Kreativität des bauenden Teams, bevor es angefangen hat.
Entscheidend ist außerdem das aktive Risikomanagement im Shaping. Das Team identifiziert Rabbit Holes, also Bereiche, in denen man endlos versinken kann, und definiert explizite No-Gos. Was wird ausdrücklich nicht gebaut? Diese Grenzen sind keine Einschränkung, sondern ein Schutz.
Wer sich für die Abgrenzung zwischen frühzeitigem Planen und agiler Flexibilität interessiert, sollte auch meinen Artikel zu Agile Frameworks und warum der Kontext entscheidet lesen.
Appetite statt Schätzungen: Eine andere Frage stellen
Schätzungen im klassischen Sinne gibt es bei Shape Up nicht. Stattdessen stellt das Framework eine fundamental andere Frage: Nicht „Wie lange dauert das?“, sondern „Wie viel Zeit wollen wir dafür investieren?“
Dieser Wert heißt Appetite. Das Ergebnis ist immer eine von zwei Kategorien:
- Small Batch: Ein bis zwei Wochen. Mehrere solcher Projekte werden innerhalb eines Zyklus gebündelt und von einem kleineren Team erledigt.
- Big Batch: Ein großes Projekt, das den vollen Sechs-Wochen-Zyklus eines Teams beansprucht.
Daraus folgt ein Prinzip, das ich persönlich für eines der stärksten in Shape Up halte: Fixed Time, Variable Scope. Die Zeit steht fest. Der Umfang ist verhandelbar. Wenn sich herausstellt, dass ein Feature drei Wochen zusätzlich bräuchte, wird das Feature gestutzt, nicht die Deadline verschoben. Dadurch entsteht ein realistischer Umgang mit Unsicherheit, den Schätzungen nie liefern können.
Der Betting Table: Keine Backlogs mehr
Der klassische Backlog ist eines der hartnäckigsten Probleme agiler Teams. Er füllt sich schnell, wird selten sauber priorisiert und enthält nach einigen Monaten Ideen, die längst überholt sind. Shape Up löst das radikal: Der Backlog wird abgeschafft.
Stattdessen gibt es den Betting Table. Ausgearbeitete Pitches, also kurze Dokumente, die Problem, Lösung und Appetite beschreiben, werden dort von Stakeholdern diskutiert. Am Ende einer Runde wird entschieden, worauf das Unternehmen für den nächsten Zyklus „wettet“.
Eine Wette bedeutet Commitment: Das Team arbeitet ohne Unterbrechungen an diesem Projekt. Kein spontanes Umpriorisieren, keine eingeschobenen Bug-Fixes von außen. Wird ein Pitch nicht gewählt, wird er verworfen. Wer die Idee für wichtig hält, pitcht sie neu, wenn der Zeitpunkt besser passt. Das erzwingt ehrliche Priorisierung.
Dazu passend empfehle ich meinen Artikel über Agile Werte vs. agile Methoden, weil der Betting Table ein gutes Beispiel dafür ist, wie eine Methode das Werteprinzip der Transparenz strukturell verankert.
Eigenverantwortung im Building-Track
Sobald der Zyklus startet, übergibt Shape Up die vollständige Verantwortung an ein kleines Team: typischerweise ein Designer und ein oder zwei Entwickler. Keine Tickets, die vom Management erstellt wurden. Keine vordefinierten Aufgabenlisten.
Das Team liest den Pitch, versteht das Problem und definiert seine eigenen To-dos basierend auf dem, was es entdeckt. Das klingt nach viel Freiheit, ist aber gezielt so gestaltet: Wer selbst entscheidet, wie ein Problem gelöst wird, trägt echte Verantwortung für das Ergebnis.
Die Arbeitsweise im Zyklus folgt zwei Konzepten:
- Slices: Das Team beginnt nicht mit einem vollständigen UI und wartet dann auf das Backend. Es schneidet vertikale Scheiben: Eine Funktion, komplett von Datenbankebene bis zur Oberfläche, wird als erstes fertig. Das schafft früh etwas Funktionierendes und zeigt Probleme schneller auf.
- Scopes: Im Laufe der Arbeit teilt das Team das Projekt in klar abgrenzbare Bereiche auf, die unabhängig voneinander fertiggestellt werden können. Jeder Scope hat einen Namen, der für das Team bedeutungshaltig ist, nicht für externe Stakeholder.
Hill Charts: Fortschritt sichtbar machen ohne Statusabfragen
Eine der praktischsten Erfindungen von Shape Up sind die Hill Charts. Sie lösen ein grundlegendes Problem: To-do-Listen sind als Fortschrittsindikator unzuverlässig. Je tiefer man in ein Problem einsteigt, desto mehr Aufgaben tauchen auf. Eine Liste, die von 30% auf 60% schrumpft, kann morgen wieder bei 90% stehen.
Hill Charts visualisieren stattdessen zwei Phasen der Arbeit:
- Uphill (bergauf): Die Phase der Unsicherheit. Man weiß noch nicht genau, wie die Lösung aussehen wird. Probleme werden noch verstanden, Wege ausgelotet.
- Downhill (bergab): Die Phase der Ausführung. Alles ist klar. Es werden bekannte Aufgaben abgearbeitet. Kein neues Unbekanntes mehr.
Führungskräfte sehen auf einen Blick, ob ein Scope seit einer Woche auf halbem Weg bergauf „feststeckt“. Das ist ein Signal für Hilfe, nicht für Kontrolle. Statusmeetings werden dadurch überflüssig, denn der Fortschritt ist jederzeit lesbar.
Circuit Breaker und Scope Hammering: Der härteste Teil
Der Circuit Breaker ist der stärkste, gleichzeitig unbequemste Mechanismus in Shape Up. Die Regel lautet: Wenn ein Projekt nach sechs Wochen nicht fertig ist, wird es abgebrochen. Keine automatische Verlängerung. Keine Ausnahmen als Standard.
Das klingt brutal. In der Praxis ist es befreiend. Teams wissen von Anfang an, dass die Uhr läuft, und treffen Entscheidungen entsprechend. Dafür nutzen sie das sogenannte Scope Hammering: das aggressive, bewusste Streichen von Funktionen, die nicht absolut notwendig sind.
Dabei vergleicht das Team das Ergebnis nicht mit einem theoretischen Ideal, sondern mit der Baseline: dem heutigen Zustand ohne das Feature. Alles, was besser ist als die Baseline, ist ein Gewinn. Diese Perspektive verhindert Perfektionismus und hilft, schnell zu entscheiden, was wirklich lieferbar ist.
Das Prinzip ähnelt dem Kanban-Gedanken des kontinuierlichen Flusses: Fertig ist besser als perfekt. Wer tiefer in flussorientiertes Arbeiten einsteigen möchte, findet in meinem praktischen Leitfaden zur Kanban-Methode einen guten Einstieg.
Für wen ist Shape Up geeignet?
Shape Up wurde für Produktteams entwickelt, die Software bauen. Es setzt voraus, dass ein kleines Team autonom arbeiten kann und dass es Personen gibt, die Zeit und Erfahrung haben, Projekte vorab zu formen. Außerdem braucht der Betting Table echte Entscheidungsträger, die wirklich committen können.
Das Framework passt also schlecht zu Teams, die stark von externen Abhängigkeiten abhängen, oder zu Organisationen, in denen Priorisierungen wöchentlich neu verhandelt werden. Daher ist Shape Up kein Allheilmittel, sondern eine bewusste Wahl für einen bestimmten Kontext.
Es funktioniert gut in produktgetriebenen Unternehmen mit stabilen Teams, klarer Produktvision und der organisatorischen Reife, Eigenverantwortung wirklich zu delegieren. Wer noch mitten im agilen Grundlagenaufbau steckt, sollte zuerst die Basisstrukturen festigen.
Was Shape Up von Scrum unterscheidet
Der Vergleich zu Scrum ist unvermeidlich. Beide Ansätze wollen regelmäßige Lieferung in kurzen Zyklen. Die Philosophie dahinter ist aber grundlegend verschieden:
- Scrum plant in festen Sprints mit einem priorisierten Backlog und Daily Stand-ups. Shape Up plant in sechs Wochen mit Pitches am Betting Table und ohne tägliche Statusmeetings.
- Scrum-Teams bekommen User Stories zugeteilt. Shape-Up-Teams bekommen ein Problem und lösen es eigenständig.
- In Scrum verlängert sich ein unfertigeres Feature in den nächsten Sprint. In Shape Up wird es abgebrochen oder neu gepitcht.
Weder das eine noch das andere ist grundsätzlich besser. Shape Up löst spezifische Dysfunktionen, die in reifen Scrum-Teams auftreten: aufgeblähte Backlogs, Schätzungsspiele, fehlende Eigenverantwortung. Scrum bietet dafür mehr Struktur für Teams, die diese Eigenverantwortung noch aufbauen.
Shape Up ausprobieren: Drei erste Schritte
Wer Shape Up in der eigenen Organisation einführen will, muss nicht sofort alles umwerfen. Drei Einstiege haben sich in der Praxis bewährt:
- Einen Zyklus als Experiment: Wähle ein überschaubares Projekt, das in sechs Wochen sinnvoll abgeschlossen werden kann. Forme es vorab mit einem Pitch, gib dem Team die Kontrolle und halte den Circuit Breaker ein.
- Den Shaping-Prozess einführen, ohne den Backlog abzuschaffen: Beginne damit, neue Features vor dem Einplanen durch einen Shaping-Prozess zu schicken. Das verbessert die Qualität der Diskussionen am Planungstisch, ohne das gesamte System umzukrempeln.
- Hill Charts für ein laufendes Projekt testen: Ersetze das klassische Status-Update in einem Projekt durch Hill Charts. Das allein ändert die Qualität von Fortschrittsgesprächen spürbar.
Shape Up ist kein Zertifizierungssystem. Es gibt keinen offiziellen Shape-Up-Coach und kein Rahmenwerk von Consulting-Firmen, das du einkaufen musst. Das Buch von Ryan Singer ist kostenlos online verfügbar unter basecamp.com/shapeup. Lesen, reflektieren, ausprobieren.
Wer ernsthaft erwägt, Shape Up zu implementieren, sollte auch einen Blick in die Ressourcen von Marty Cagan und dem Silicon Valley Product Group werfen. Deren Arbeit zu empowered Teams ergänzt die Shape-Up-Philosophie hervorragend.
Fazit: Ein Framework, das Mut verlangt
Shape Up ist kein leichter Weg. Es verlangt Organisationen Dinge ab, die unbequem sind: echte Eigenverantwortung für Teams, harte Entscheidungen am Betting Table und den Mut, ein Projekt nach sechs Wochen abzubrechen, auch wenn es fast fertig ist.
Dafür bietet es etwas, das viele agile Frameworks schuldig bleiben: einen Arbeitsrhythmus, der langfristig trägt. Teams liefern fertige Dinge statt halbfertiger Inkremente. Führungskräfte treffen bewusste Wettentscheidungen statt Backlog-Verwaltung zu betreiben. Und alle beteiligten Personen wissen, woran sie sind.
Wenn du Shape Up in deiner Organisation einführen willst oder Fragen zum Framework hast, schreib mir gerne direkt. Ich begleite Teams bei der Einführung neuer Arbeitsweisen und helfe dabei, den richtigen Einstieg zu finden.
