Scrum hat ein Problem der frühen 2000er Jahre gelöst: zu lange Wasserfall-Projekte, zu wenig Kundennähe, zu wenig Liefertakt. 25 Jahre später hat Scrum selbst ein Problem. Studien zeigen, dass Entwicklungsteams bis zu 15 Prozent ihrer Zeit in Ceremonies verbringen, Backlogs wachsen endlos, und Ziele verschieben sich alle zwei Wochen. Shape Up, entwickelt von Basecamp und 2019 von Ryan Singer in einem gleichnamigen Buch beschrieben, ist ein Gegenentwurf. Ich habe von dem Ansatz im Gespräch mit einem Scale-up gehört, und was ich daran spannend finde, muss ich ausprobieren, bevor ich es weiterempfehle.

Woran Scrum stumpf wird

Das Kernproblem von Scrum in gereiften Organisationen ist nicht die Methode, sondern ihre Nebenwirkungen. Zwei-Wochen-Sprints erzeugen einen Takt, der sich irgendwann verselbstständigt. Das Sprint-Planning wird zum Pflichtritual, Retrospektiven wiederholen dieselben Problembeschreibungen, und das Team bewegt sich von User Story zu User Story, ohne zu fragen, ob der Backlog in seiner Gesamtheit noch dem eigentlichen Produktziel dient.

Dazu kommt ein struktureller Effekt: Der Product Owner priorisiert den Backlog, das Team liefert. Das trennt das Was vom Wie sauberer, als der Produktalltag es erlaubt. Gute Entwicklungsarbeit braucht technische Einschätzung früh, nicht erst im Sprint Planning. Gute Produktentscheidungen brauchen die Perspektive der Menschen, die die Lösung bauen. Scrum verhindert das nicht, aber es begünstigt die Trennung durch seine Rollen.

Der dritte Punkt ist die Scope-Frage. In Scrum ist die Zeit fix, der Scope der Sprint-Planung im Prinzip auch, aber in der Praxis wandern Stories in und aus dem Sprint, Deadlines werden geschoben, und Projekte, die eigentlich tot sein sollten, ziehen sich über Monate. Es gibt keinen eingebauten Mechanismus, der sagt: Schluss jetzt, entweder ist es fertig oder es fliegt.

Was Shape Up anders macht

Shape Up kippt drei dieser Grundannahmen. Statt Zwei-Wochen-Sprints arbeitet ein Team in Sechs-Wochen-Zyklen mit anschließendem Zwei-Wochen-Cool-Down. Die sechs Wochen sind geschützt, die Cool-Down-Phase ist für Bugs, technische Nacharbeit und das Shaping neuer Themen. Keine Sprint-Planungen dazwischen, kein zweiwöchentlicher Kontextwechsel.

Vor dem Zyklus steht das Shaping. Eine kleine Gruppe erfahrener Leute, bei Basecamp sind das Gründer und leitende Produkt- und Entwicklungspersonen, arbeitet an einem Pitch: Problem, grobe Lösungsrichtung, grober Umfang. Das Ergebnis ist keine fertige Spezifikation, sondern ein Dokument, das konkret genug ist, um eine Richtung zu setzen, und abstrakt genug, um dem umsetzenden Team echten Gestaltungsraum zu lassen. Dass beim Shaping Produkt-, Design- und Tech-Perspektive früh zusammenkommen, erinnert an das Product Trio nach Teresa Torres, auch wenn Shape Up den Begriff selbst nicht verwendet. Am Betting Table entscheidet danach die Leitung, welche Pitches im nächsten Zyklus gebaut werden. Das ist eine Wette, keine Backlog-Abarbeitung.

Während des Zyklus gilt Fixed Time, Variable Scope. Die sechs Wochen stehen, der Umfang kann während des Bauens zurechtgeschnitten werden. Wird ein Team nicht fertig, bekommt das Projekt keinen Nachschlag, es fliegt. Dieser eingebaute Circuit Breaker ist das stärkste Signal des Ansatzes: Features werden nicht nachverhandelt. Statt Story Points gibt es ein Appetite, also die Entscheidung vorab, wie viel Zeit uns ein Problem wert ist, nicht die Schätzung, wie lange es dauern wird.

Warum das in der Praxis besser funktionieren kann

Drei Effekte überzeugen mich auf dem Papier:

Was ich mir vornehme

Ich will die Kernidee testen, bevor ich sie als Methode weiterempfehle. Konkret nehme ich mir zweierlei vor. Erstens: Meine eigene Produktarbeit und meinen Lernpfad möchte ich in Sechs-plus-Zwei-Wochen-Rhythmen strukturieren, nicht in Zwei-Wochen-Sprints. Sechs Wochen Fokus auf ein klar geshaptes Thema, zwei Wochen Cool-Down für Bugs, Reflexion und das Shaping des nächsten Themas.

Zweitens: Vor jedem Zyklus schreibe ich einen kurzen Pitch für mich selbst. Problem, Appetite, grobe Lösungsrichtung. Keine To-Do-Liste, sondern ein Stück Orientierung, das mich vor Scope Creep schützt. Nach sechs Wochen ist Abgabe. Nicht fertig ist nicht verhandelbar. Was darüber hinaus wäre, wandert in den nächsten Pitch oder fällt.

Kritische Einordnung

Shape Up ist empirisch kein Patentrezept. Das französische Fintech Trustpair hat den Ansatz bei rund 100 Mitarbeitern und 30 Entwicklern wieder abgeschafft, weil am Ende jedes Zyklus Review- und QA-Staus entstanden und der Support in der Cool-Down-Phase nicht abzufangen war. John Cutler weist darauf hin, dass Shape Up fürs Shipping optimiert ist, nicht fürs Herausfinden des richtigen Produkts. Discovery, User Research und Validierung sind im Original nicht eingebaut. Und: Der Ansatz stammt aus einem Zwölf-Personen-Unternehmen. Wer ihn in größeren Organisationen nutzt, muss die fehlenden Ebenen selbst erfinden, etwa cross-team Sync, QA-Logik, Support-Rotation.

Für meinen eigenen Kontext, also eigene Produktarbeit und Lernzyklen, sind die Skalierungsbrüche nebensächlich. Für Teams sind sie entscheidend. Ob der Ansatz für meine Zyklen trägt, wird sich nach den ersten zwei Durchläufen zeigen.