Shape Up vs. Scrum Guide — Einschätzung und Vergleich

Wer mit Scrum an die Grenzen gekommen ist, sollte sich einmal Shape Up ansehen.

Shape Up wurde von Ryan Singer entwickelt und 2019 als Buch „Shape Up: Stop Running in Circles and Ship Work that Matters" veröffentlicht. Die Methode entstand aus der praktischen Arbeitsweise bei Basecamp (heute 37signals), wo Singer sie über Jahre im Produktentwicklungsalltag geformt hat.

→ basecamp.com/shapeup

Ich möchte zunächst eine kleine Einordnung geben und anschließend seht Ihr nochmal die Unterschiede aufgelistet.

Teil 1: Meine Einschätzung

Wetten statt Backlog

Shape Up arbeitet mit Wetten anstatt mit einem Backlog. Das halte ich für eine sehr große Verbesserung im Vergleich zum Scrum Guide.

In den agilen Transformationen, in denen ich mitgestaltet habe, haben wir auch hypothesenbasiert gearbeitet oder hatten einen Business Case. Beides ähnelt dem Konstrukt einer Wette.

Ein Backlog wird schnell übervoll mit Dingen, die nicht relevant sind, man verliert leicht den Fokus und baut vielleicht Dinge, die noch nicht notwendig waren, und driftet damit von der Lean-Philosophie ab, die darauf achtet, Verschwendung zu reduzieren mit den acht Typen von Muda.

Shape Up geht wieder zurück zu den Wurzeln und konzentriert sich auf Wetten, die durch den engen Rahmen stark eingrenzen und damit Verschwendung von vorneherein eindämmen.

Zyklus statt Sprints

Ein weiterer Fortschritt ist der Zyklus. Wir alle kennen „Waterfall in Sprints", die Witze, die man darüber macht, und die Witze haben einen wahren Ursprung, nämlich, dass man ewig lange an Dingen arbeitet, die vielleicht gar nicht den erwünschten Wert bringen.

Die Begrenzung in Shape Up auf feste Zyklen verhindert das, minimiert das Risiko einer wasserfallartigen Entwicklung.

Kleine, dedizierte Teams mit Fokus

Im Shape-Up-Modell sind die Teams kleiner und dediziert einer Wette zugeordnet.

In Scrum-Teams sieht die Realität häufig so aus, dass die Teams zu groß sind, dass sie nicht wirklich cross-funktional sind, dass sie nicht vollends befähigt sind und dass sie an vielen Projekten gleichzeitig arbeiten.

In der Realität der meisten Unternehmen ist eine vollständige Implementierung nach Scrum selten passiert, außer in denen, die die agile Transformation ernst genommen und gleich Scrum mit anderen Methoden kombiniert haben.

Kein Prozesstheater — Outcome statt Tickets

Shape Up gibt keinen festen Prozess vor, was die Regeltermine betrifft. Damit verhindert man das „Prozesstheater".

Es gibt Organisationen, die benutzen zwar alle vorgegebenen Termine des Scrum Guides, nur der gewünschte Effekt, die Wirkung, stellt sich nicht ein, da die Einhaltung des Prozesses nicht sicherstellt, dass auch wirklich die Philosophie hinter Agile gelebt wird.

Shape Up konzentriert sich mehr auf Projekte, auf Outcome.

Scrum, wenn man es nicht richtig reflektiert, kann schnell dazu führen, dass man sich mehr auf den Prozess als auf den Outcome konzentriert.

Es gibt Organisationen, da arbeitet man nur einen Haufen Tickets ab und sieht das große Ganze nicht mehr als Engineer.

Shape Up verhindert das von vornherein, indem gar keine Tickets erstellt werden, sondern die Wetten ganz klar formuliert werden, sodass ein Team überhaupt die Chance hat, cross-funktional an einer Aufgabe mit Outcome, mit Wert zu arbeiten.

Vielen Scrum-Teams wird diese Chance nicht gegeben.

Abbruchkriterien von Anfang an

Es gibt Organisationen, da wurde Scrum zwar eingeführt, aber die Führungskräfte wurden nicht geschult in dem, was agil für sie verändern wird.

Das heißt, niemand definiert Kill-Kriterien, Abbruchkriterien. Man misst nicht den Outcome mit harten Fakten und Daten.

Es gibt Organisationen, die das sehr wohl verstanden und die agile Transformation genau mit diesen Vorgaben durchgeführt haben. Aber das ist nicht bei allen der Fall.

Shape Up ist hierfür eine gute Alternative, um es nochmal zu versuchen. Es ist von vornherein klar, wann abgebrochen wird. Es gibt nicht diesen Selbstläufer, dass man etwas verlängert, weil man keine Handhabe definiert hat, wie man etwas stoppen kann.

Der Zug hat keine Bremse ist ein deutscher Hit. Und ich muss manchmal daran denken, wenn Unternehmen keine Methodik haben, um Vorhaben zu stoppen, die nicht den gewünschten Wert bringen, weil man den gewünschten Wert nicht klar genug vorher definiert hat und auch keine Handhabe definiert hat, nach der Entscheider stoppen dürfen.

Shape Up ist dafür eine ideale Alternative, um genau dieses Vorgehen zu erlernen.

Scope-Reduktion bei gleichbleibender Qualität

Scrum, wenn man es wirklich ernst nimmt, gibt schon vor, dass die Qualität einzuhalten ist und am Scope gearbeitet wird.

Und das heißt logischerweise, der Scope muss eigentlich regelmäßig reduziert werden, um ein Inkrement von Qualität zu liefern.

In der Praxis passiert das selten, da das auch nicht gerade intuitiv ist.

Shape Up ist hier wiederum leichtgewichtiger und zwingt das Team innerhalb des Zyklus, etwas zu liefern, was die Wette erfüllt.

Dadurch wird Scope geschnitten bei gleichbleibender Qualität. Das heißt, die engen Grenzen sind hilfreich beim Erlernen der kontraintuitiven Arbeit von Scope-Reduktion.

Die Portfolio-Ebene wird mitgedacht

Das Scrum Guide gibt kein Skalierungsframework vor. Deshalb entstanden ja Dinge wie das Spotify-Modell oder das SAFe-Modell.

Shape Up denkt die nächste Ebene gleich mit.

In den agilen Transformationen, in denen ich tätig war, die wirklich eine Veränderung brachten, wurde die Portfolio-Ebene von Anfang an mit designt.

Denn das ist der Hebel, um nicht zu viele Dinge gleichzeitig zu machen, um gegenzusteuern, um abzubrechen.

Es ist immer notwendig, diese Ebene mitzudenken und wenn möglich noch eine Ebene drüber.

Shape Up hilft hier enorm. Und es ist leichtgewichtiger als SAFe.

Grenzen und Voraussetzungen: Wo Shape Up allein nicht trägt

Shape Up wird schwierig sein in der Umsetzung bei Teams, die nicht nur Produkte oder Software entwickeln, sondern zusätzlich ganz viel Anfragen, Daily Business, Wartung, Operations, Service Requests haben.

Dafür würde Shape Up nicht ausreichen, man würde noch zusätzliche Methoden benötigen.

Eine große Herausforderung sehe ich ebenfalls darin, wenn mehrere Teams notwendig sind, deren Outcome aufeinander aufbaut oder miteinander integriert werden muss.

Diese Fragestellungen müssen vorab durchdacht werden, sodass die Wetten, die die verschiedenen Teams erfüllen, nicht irgendwie lose im Raum hängen, sondern miteinander integriert werden können.

Dazu müsste man beim jeweiligen Unternehmen ganz genau schauen, was man zusätzlich an maßgeschneiderten Frameworks entwickeln muss, sodass es ineinandergreift.

Shape Up wird auch dort nicht funktionieren, wo die hierarchischen Strukturen oder die Berichtswege eine Implementierung nicht möglich machen und wo Führungskräfte noch keine eigene Vision zum Thema agiles Arbeiten entwickelt haben.

Es muss der Boden bereitet werden durch ein aktives Auseinandersetzen mit der Philosophie dahinter, die ja auch wiederum in Lean wurzelt und über die Jahrzehnte weiterentwickelt wurde.

Und es müssen für die jeweiligen Projekte, die nach Shape Up durchgeführt werden sollen, die Hierarchien und Berichtswege angepasst werden, sodass es nicht konterkariert.

In der Lean-Praxis im Automotive-Bereich verwendet man gerne War Rooms, Obeya auf Japanisch. Und es wäre zu überlegen, ob in der Phase der Transformation nicht auch so etwas wörtlich oder im übertragenen Sinne notwendig ist, um einer neuen Methodik wie Shape Up überhaupt einen Boden liefern zu können, auf dem es gedeihen kann.

Lean war noch nie eine Graswurzelbewegung, sondern wurde immer vom Top-Management eingeführt. Daher ist es wichtig, für Organisationen, die sich mit Shape Up beschäftigen, vom Top-Management an zu diskutieren, wie man es versteht und wie man es anwenden möchte.

Teil 2: Übersicht — Shape Up vs. Scrum Guide (2020)

Quellen: basecamp.com/shapeup (Ryan Singer) · Scrum Guide 2020 (Schwaber/Sutherland). Nur Aussagen, die sich direkt aus den beiden Quellen belegen lassen. Wo eine Quelle zu einem Thema nichts sagt, ist das als solches gekennzeichnet.

1. Charakter der Methode

Scrum Guide

• definiert sich als leichtgewichtiges, bewusst unvollständiges Rahmenwerk
• erklärt sich selbst für unveränderlich: Wer nur Teile umsetzt, macht laut Guide kein Scrum
• beschreibt keine konkreten Techniken; verweist darauf, dass Taktiken kontextabhängig sind und anderswo beschrieben werden

Shape Up

• Buch, das die Arbeitsweise von Basecamp beschreibt
• enthält konkrete Techniken (z. B. Breadboarding, Fat Marker Sketches, Hill Charts)
• Anhang „Adjust to Your Size" unterscheidet ausdrücklich zwischen Grundwahrheiten und spezifischen Praktiken, d. h. Anpassung ist vorgesehen

2. Arbeitsvorrat & Auswahl der Arbeit

Backlog

• Scrum: Product Backlog ist die einzige Quelle der Arbeit des Scrum Teams; emergent, geordnet, kontinuierlich per Refinement verfeinert
• Shape Up: Kapitel „Bets, Not Backlogs" — es gibt bewusst kein zentrales Backlog; stattdessen dezentrale Listen und wenige potenzielle Wetten pro Zyklus. Begründung im Buch: wichtige Ideen kommen von selbst wieder

Entscheidung, was gebaut wird

• Scrum: der Product Owner ordnet das Product Backlog; die Developers wählen im Sprint Planning Items daraus aus
• Shape Up: der Betting Table — ein Meeting im Cool-down, in dem Stakeholder entscheiden, auf welche Pitches im nächsten Zyklus gewettet wird

Vorbereitung der Arbeit

• Scrum: Refinement als laufende Aktivität (Items zerlegen, Details, Ordnung, Größe ergänzen)
• Shape Up: Shaping als eigener Track parallel zum Bauen; Ergebnis ist ein Pitch mit fünf Bestandteilen: Problem, Appetite, Lösung, Rabbit Holes, No-Gos

3. Zeitmodell

Zykluslänge

• Scrum: Sprints von einem Monat oder kürzer; ein neuer Sprint beginnt unmittelbar nach dem vorherigen
• Shape Up: 6-Wochen-Zyklen plus 2 Wochen Cool-down zwischen den Zyklen

Cool-down (nur Shape Up)

• Zeit für Ad-hoc-Aufgaben, Bugfixes und den Betting Table
• im Scrum Guide existiert kein vergleichbares Element

Umgang mit Umfang und Zeit

• Shape Up: „Fixed time, variable scope" — der Appetite legt fest, wie viel Zeit man ausgeben will, statt zu schätzen, wie lange etwas dauert
• Scrum: die Developers wählen aus, wie viel in einen Sprint passt; der Guide nennt vergangene Performance, Kapazität und Definition of Done als Grundlage für die Zuversicht des Forecasts; die Developers sind für das Sizing der Items verantwortlich

4. Fokus, Unterbrechungen & Parallelarbeit

Shape Up

• eine Wette ist laut Glossar die Entscheidung, ein Team für einen Zyklus ohne Unterbrechungen einem Projekt zu widmen, mit der Erwartung zu liefern
• eigener Abschnitt „Uninterrupted time" im Kapitel zum Betting Table
• „Keep the slate clean": der nächste Zyklus startet ohne vorbelegte Verpflichtungen
• Bugs werden nicht in den Zyklus gezogen, sondern im Cool-down behandelt (Abschnitt „What about bugs?")

Scrum

• das Scrum Team ist eine Einheit, die sich auf ein Ziel zur Zeit konzentriert: das Product Goal; es muss erfüllt (oder aufgegeben) werden, bevor das nächste begonnen wird
• während des Sprints werden keine Änderungen vorgenommen, die das Sprint Goal gefährden
• Arbeit in Sprints in nachhaltigem Tempo verbessert laut Guide Fokus und Konsistenz
• der Guide regelt nicht, ob Personen oder Teams parallel an mehreren Produkten/Projekten arbeiten dürfen; das Thema kommt im Text nicht vor

Teamzusammensetzung

• Scrum: ein Scrum Team mit typischerweise 10 oder weniger Personen; bei mehreren Teams am selben Produkt teilen sie sich Product Goal, Product Backlog und Product Owner
• Shape Up: Projektteams aus einem Designer und ein bis zwei Programmierern; Teams werden pro Zyklus/Projekt besetzt — eine der Fragen am Betting Table lautet „Are the right people available?"

5. Rollen

• Scrum: drei definierte Accountabilities — Product Owner, Scrum Master, Developers; der Product Owner ist eine Person, kein Komitee
• Shape Up: definiert keine Rollen im Sinne des Scrum Guides
  • beschreibt Tätigkeiten und Personengruppen: Shaper (laut Buch Senior-Leute), Teilnehmer des Betting Table, Bauteams
  • eine dem Scrum Master vergleichbare Prozessrolle kommt im Buch nicht vor

6. Ereignisse

• Scrum: fünf Events — Sprint (Container), Sprint Planning (max. 8 h), Daily Scrum (15 min), Sprint Review (max. 4 h), Sprint Retrospective (max. 3 h); Timeboxen gelten für einen Ein-Monats-Sprint
• Shape Up:
  • beschreibt als wiederkehrendes Meeting den Betting Table im Cool-down
  • Daily, Review und Retrospektive kommen im Buch nicht vor
  • Statuskommunikation läuft über Hill Charts, Abschnitt „Status without asking"

7. Planung während der Umsetzung

Scrum

• Sprint Backlog = Sprint Goal + ausgewählte Items + Plan; wird während des Sprints laufend aktualisiert
• Items werden häufig in Arbeitsschritte von einem Tag oder weniger zerlegt; wie, entscheiden allein die Developers

Shape Up

• Teams bekommen Projekte, keine Tasks („Assign projects, not tasks")
• das Buch unterscheidet „imagined tasks" (vorab gedachte) von „discovered tasks" (bei der Arbeit entdeckte)
• Arbeit wird in Scopes organisiert — Teile des Projekts, die unabhängig gebaut, integriert und fertiggestellt werden können
• Nice-to-haves werden mit „~" markiert und entfallen, wenn die Zeit nicht reicht

8. Nicht-Lieferung & Abbruch

• Shape Up: Circuit Breaker — Projekte, die nicht in einem Zyklus liefern, werden per Default nicht verlängert, sondern beendet; Verlängerung ist die Ausnahme (Abschnitt „When to extend a project")
• Scrum:
  • ein Sprint kann abgebrochen werden, wenn das Sprint Goal obsolet wird; nur der Product Owner hat diese Befugnis
  • Items, die die Definition of Done nicht erfüllen, gehen zurück ins Product Backlog
  • ein Default-Mechanismus, der Vorhaben beendet, existiert im Guide nicht

9. Fertigstellung & Qualität

• Shape Up: „Done means deployed" — fertig heißt innerhalb des Zyklus ausgeliefert
• Scrum:
  • Definition of Done als formale Beschreibung des Qualitätszustands eines Increments
  • Increments können jederzeit ausgeliefert werden; das Sprint Review ist ausdrücklich kein Freigabe-Gate

Umgang mit wachsendem Umfang

• Shape Up: Scope Hammering — Design, Implementierung oder Use Cases werden hinterfragt, um innerhalb der festen Timebox fertig zu werden; das Buch hält fest: „Cutting scope isn't lowering quality"
• Scrum: Scope kann während des Sprints mit dem Product Owner geklärt und neu verhandelt werden, ohne das Sprint Goal zu gefährden; Qualität sinkt nicht

10. Theoretische Grundlage

• Scrum: gründet explizit auf Empirie und Lean Thinking; drei Säulen (Transparenz, Inspektion, Adaption) und fünf Werte (Commitment, Fokus, Offenheit, Respekt, Mut)
• Shape Up: enthält kein vergleichbares Theorie- oder Wertekapitel; als durchgehende Motive nennt das Buch selbst u. a. Risiko-Fokussierung („Targeting risk") und Verantwortungsübergabe an Teams

11. Portfolio-Ebene (Flight Level 3)

• Shape Up beschreibt einen wiederkehrenden Entscheidungsmechanismus oberhalb der Teamebene: Pitches → Betting Table → Wette pro Zyklus; dazu die Fragen am Betting Table (Problem relevant? Appetite richtig? Lösung attraktiv? richtiger Zeitpunkt? richtige Leute verfügbar?)
• der Scrum Guide beschreibt keine Ebene oberhalb des Scrum Teams bzw. mehrerer Teams an einem Produkt; Skalierung wird nur insoweit erwähnt, als mehrere Teams am selben Produkt Product Goal, Backlog und PO teilen
• Beide Quellen verwenden den Begriff „Portfolio" nicht