Rollen in Shape Up
:mgmt: :shape-up: :leadership: Nov 04, 2026Table of Contents
1. Warum wir Shape Up eingeführt haben
Meine Firma hat Anfang diesen Jahres Teile des Produkt-Entwicklungsprozess auf die Shape-Up Methode umgestellt. Der Grund war, dass unser "normaler" Produkt-Entwicklungsprozess immer langsamer und träger wurde. Die Kollaboration wurde immer weniger und es fühlte sich für das Engineering wie ein reines Abarbeiten ohne Beteiligung an der Lösung an. Dabei sind oft Probleme erst sehr spät im der Entwicklung aufgefallen oder erst nach einem Release. Durch Nacharbeiten haben sich dann oftmals Releases verzögert oder Hot-Fixes mussten verteilt werden.
Um diese Probleme anzugehen, haben wir uns die Shape-Up Methode angeschaut. Sie baut stärker auf Kollaboration auf und benutzt dafür Ad-hoc cross-funktionale Teams die mit viel Eigenverantwortung Ideen umsetzen. Wichtig ist, dass Shape-Up eine Methode ist, die viel Spielraum für Anpassung lässt und auch auf die Firma angepasst werden muss. Damit ist es ähnlich zu Scrum oder SAFE, die auch angepasst werden sollten. Gefühlt funktionieren Scrum und SAFE auch nicht angepasst gut genug, sodass dieser Schritt gerne übersprungen wird. Shape-Up funktioniert unangepasst wesentlich schlechter als andere Entwicklungsprozesse und muss unbedingt auf die Firma zugeschnitten und weiterentwickelt werden.
2. Adaption von Shape Up als Prozess
Um Shape-Up in einer Firma einzuführen und anzupassen sind einige Personen die mit tiefen Verständnis der aktuellen Prozesse und der Shape-Up Methode notwendig.
Wir haben dafür ein Mentoring System aufgesetzt, bei dem die Engineering Manager sich sehr gut mit dem Shape-Up Prozess auskennen und die Shape-Up-Teams in der Building Phase begleiten. Des Weiteren kennen sie sich sehr gut mit Software Engineering aus und begleiten die interne Produktentwicklung von der technischen Seite. Sie unterstützen die Teams in der Building-Phase mit ihrem Wissen und coachen das gesamte Engineering langfristig.
Zum Beispiel haben sie die meiste Erfahrung im Erarbeiten von Meilensteinen und Stories. Diese Erfahrung fehlt zumeist den Engineers und muss erst erlernt werden. Im Buch wird zwar das Slicing erklärt, aber in der Praxis ist es oftmals keine einfache Checkliste, die abgearbeitet werden kann. Das Team dabei zu leiten und sie zu guten Entscheidungen zu führen, hilft beim erfolgreichen Umsetzen eines Candidate. Ein weiterer Punkt der oftmals unklar ist, sind die Rollen, die verschiedene Personen bei einem Shape Up Zyklus spielen.
3. Rollen in einem Shape Up Zyklus
Diese Rollen zu definieren soll, denn Personen helfen konkrete Erwartungen zu entwickeln und auch ihre Rolle entsprechend auszufüllen. Nach ca. einem dreiviertel Jahr haben sich bei uns verschiedene wichtige Rollen etabliert.
3.1. Mentor
Der Mentor ist eine Kombination aus Agile Coach und Prozessaufsicht und ist außerhalb des Teams angesiedelt. Er kennt den Prozess am besten und führt ein Team durch die verschiedenen Phasen. Er moderiert Ankermeetings im Prozess, zum Beispiel das initiale Kick-off. Er Unterstützt die Teams mit seinem Methodenwissen bei der Umsetzung und achtet auf die Einhaltung von Engineering-Standards.
3.2. Stakeholder
Der Stakeholder hat den Shape-Up-Kandidaten eingebracht (meist Produkt). Sie ist außerhalb des Teams angesiedelt und fungiert als Kunde des Teams. Bei uns beteiligt sie sich an der initialen Lösungsfindung und steht für Rückfragen aus dem Team zur Verfügung. Der Fortschritt im Team wird regelmäßig mit ihr geteilt und die finale Abnahme des Projekts liegt bei ihr.
Sie hält sich aus der konkreten Umsetzung zurück. Das betrifft etwa die Reihenfolge der Tickets oder wie Slices erstellt werden.
Am Ende eines Shape Up Zyklus trägt das Team alle offenen Themen stellt sie dem Stakeholder vor. Dieser entscheidet dann zusammen mit dem Team über das weiter Vorgehen.
3.3. Tech-Lead
Die wichtigste Komponente eines funktionierenden Shape-Up-Teams ist der Tech-Lead. Er übernimmt vor allem organisatorische und leitende Aufgaben im Team. Dazu gehört das Erarbeiten der Slices (Tickets) zusammen mit dem Team. Er identifiziert Spikes (Probleme deren Lösung erst erarbeitet werden muss), die als Exploratory oder Technical Enabler umgesetzt werden sollten. Dafür braucht die Person ein gutes Verständnis von Vertical Slicing, dem Product Building Canvas, sowie von der Software Architektur.
Er achtet darauf, dass das Team gleichmäßig an den Aufgaben arbeitet (keine Platform ist wesentlich schneller) und unterstützt die Teammitglieder bei Problemen. Die finale Entscheidung bei Disputen liegt beim ihm.
Er stellt sicher, dass die Punkte Feature Flags, Tracking, Lokalization, Changelogs, Best Practices und Releases von den Engineers beachtet und umgesetzt werden.
Er gibt dem Stakholder und der Firma regelmäßige Updates.
3.4. Engineer
Der größte Teil des Teams sind Engineers aus den verschiedenen funktionalen (Platform-)Teams. Sie setzen das Projekt kollaborativ um und bringen ihre Erfahrungen in der Lösungsfindung, Slicing und im Software Development Lifecycle ein, um eine termingerechte Umsetzung des Projektes zu ermöglichen.
Einzelne Engineers in einem Team übernehmen Speziallthemen wie Tracking oder Lokalization.
Sie sind das Bindeglied zu den funktionalen Teams und holen bei Bedarf Unterstützung von dort.
3.5. Designer
In den meisten Shape-Up-Teams ist ein Designer an Board. Er ist in die Lösungsfindung eingebunden und bringt vor allem eine UX-Perspektive ein. Die Lösungen sollen pragmatisch sein, aber nicht unansehnlich oder dysfunktional für den Endnutzer. Zusammen mit den Engineers erabeitet der Designer die finale UI/UX. Bei großen Projekten ist das Design schon vor der Building-Phase eingebunden im Shaping eingebunden und entwickelt erste Ideen.
Wichtig ist, dass Design und Engineering gemeinsam das finale Design erarbeiten. Der Designer trägt die finale Entscheidung über das Design, sollte dieses aber nicht vorab festlegen.