vom klassischen Projektplan zur agilen Struktur - Teil 2

Der Newsletter für nachhaltige Transformation Made in Germany 🇩🇪

Über den Standort Deutschland wird viel geklagt. Doch Jammern bringt uns nicht weiter – Handeln schon!

Die globalen Rahmenbedingungen können wir kaum beeinflussen. Was wir beeinflussen können, ist wie gut Unternehmen digital, agil und zukunftsfähig aufgestellt sind.

In diesem Newsletter reflektiere ich wöchentlich meine Erfahrungen, Erkenntnisse und Impulse aus Digital-, Transformations- und Change-Projekten.

✔️Prägnant ✔️Praxisnah ✔️ Pro Bono.

Mein Antrieb: Viele kleine, konsequente Schritte können große Wirkung entfalten.

📣 Lass uns gemeinsam was bewegen!

Herzlich willkommen zu einer neuen Ausgabe von der Transformator:

Im ersten Teil ging es um die grundlegende Struktur agiler Artefakte: Wie werden aus strategischen Epics konkrete Features und daraus umsetzbare User Stories? Und wie sorgt Traceability dafür, dass die Verbindung zwischen Strategie, Planung, Umsetzung und Qualität erhalten bleibt?

Doch eine saubere Struktur allein macht noch kein agiles Vorhaben erfolgreich. Die entscheidende Frage lautet: Wie wird aus einem großen Vorhaben tatsächlich umsetzbare, planbare und gemeinsam getragene Arbeit?

Genau hier liegen einige der größten Unterschiede zum klassischen Projektmanagement. Während der klassische Projektplan möglichst früh versucht, Arbeitspakete vollständig zu definieren und zu schätzen, arbeitet SAFe mit schrittweiser Konkretisierung. Anforderungen werden geschnitten, priorisiert, geschätzt und gemeinsam mit den beteiligten Stakeholdern geschärft.

Das verändert nicht nur die Artefakte selbst, sondern auch die Zusammenarbeit dahinter.

In Teil 2 stehen deshalb die drei verbleibenden Learning Nuggets im Mittelpunkt: Slicing, Estimation und Socializing.

Sie zeigen, wie aus einer strukturierten Anforderung ein lieferbares Inkrement wird – und warum dabei nicht nur die Größe einer Anforderung zählt, sondern auch ihr fachlicher Nutzen, ihre Abhängigkeiten und das gemeinsame Verständnis aller Beteiligten.

4.) Feature / USerstory Slicing

Anders als ein klassischer PSP ist die agile Struktur nicht statisch. Features können geschnitten, zusammengelegt, verworfen oder neu priorisiert werden. Erkenntnisse aus Kundenfeedback, technischer Umsetzung oder Marktveränderungen fließen aktiv in die Struktur ein.

Beim Schneiden von Anforderungen wird zwischen horizontalem und vertikalem Slicing unterschieden. Entscheidend ist, ob Arbeit entlang technischer Schichten oder entlang eines nutzbaren Wertbeitrags strukturiert wird.

Horizontales Slicing teilt Anforderungen nach technischen Ebenen oder Komponenten auf – etwa Datenbank, Backend, Schnittstelle, Frontend oder Testautomatisierung. Das wirkt technisch naheliegend, liefert isoliert jedoch häufig keinen eigenständig nutzbaren Kundennutzen. Diese Struktur ähnelt klassischem Projektmanagement: Arbeit wird nach Spezialgebieten organisiert, Nutzen wird oft erst spät sichtbar.

Vertikales Slicing schneidet Anforderungen so, dass jedes Slice möglichst alle notwendigen technischen Schichten umfasst und einen kleinen, nutzbaren Wertbeitrag liefert – von Oberfläche über Logik und Datenhaltung bis Qualitätssicherung. Jeder Schnitt kann getestet, demonstriert und fachlich bewertet werden. Feedback entsteht früher, Risiken werden schneller sichtbar und Fortschritt lässt sich besser an gelieferter Funktionalität messen.

Im agilen Kontext wird vertikales Slicing bevorzugt, weil es konsequent auf Wertlieferung ausgerichtet ist. Horizontales Slicing kann technische Planung unterstützen, sollte aber nicht die primäre Struktur für Features oder User Stories bilden. Besonders User Stories sollten vertikal geschnitten sein, damit sie innerhalb einer Iteration umgesetzt, getestet und akzeptiert werden können.

Beim vertikalen Slicing spielt Shift Left eine zentrale Rolle. Qualitätsrelevante Aktivitäten werden früh berücksichtigt – Tests, Integration oder Security also nicht erst am Ende eines Features oder Releases. Dadurch wird ein Slice nicht nur umgesetzt, sondern früh validiert. Fehler, Integrationsprobleme und fachliche Missverständnisse werden früher sichtbar und günstiger korrigierbar.

5.) Estimation

Im agilen Kontext dient Estimation nicht der exakten Aufwandvorhersage, sondern dem gemeinsamen Verständnis von Größe, Komplexität, Unsicherheit und Risiken. Geschätzt wird häufig relativ: Ein Feature oder eine User Story wird im Vergleich zu anderen Anforderungen eingeordnet, nicht in absoluten Personentagen. So entsteht eine bessere Grundlage für Priorisierung, Planung und Forecasting.

Ein zentraler Grundsatz lautet: Schätzen sollten diejenigen, die die Arbeit später umsetzen. Nur das Team kann technische Herausforderungen, Abhängigkeiten, Risiken und offene Fragen realistisch bewerten.

6.) Socializing

Unter Socializing versteht man im agilen Kontext das frühzeitige Abstimmen, Erklären und gemeinsame Schärfen von Anforderungen mit den relevanten Beteiligten. In SAFe ist der Begriff nicht immer als formales Artefakt beschrieben; die Praxis dahinter ist jedoch zentral: Anforderungen sollten nicht erst im Planning „über den Zaun geworfen“, sondern vorab gemeinsam verstanden werden.

Eine passende Analogie ist das Backlog Refinement auf Scrum-Team-Ebene: User Stories werden gemeinsam durchgesprochen, fachlich geschärft, geschnitten, geschätzt und für die Umsetzung vorbereitet. Auf Feature-Ebene geschieht Ähnliches: Das Feature wird mit relevanten Stakeholdern, Product Ownern, Architekten und Teams sozialisiert, bevor es verbindlich in eine PI- oder Iterationsplanung eingeht.

Besonders wichtig ist die frühzeitige Einbindung des Product Owners, dessen Team das Feature umsetzen soll. Der PO muss Zweck, Nutzen, Akzeptanzkriterien, Abhängigkeiten und Risiken verstehen. Nur dann kann er das Feature sinnvoll mit dem Team diskutieren, in User Stories schneiden und in das Team Backlog überführen.

Fazit:

Verantwortung entsteht nicht durch Rollen allein, sondern durch Zusammenarbeit.

Agile Artefakte lassen sich in der Praxis nicht eindeutig und ausschließlich einer einzelnen Rolle zuordnen.

Zwar gibt SAFe einen klaren Rahmen für Verantwortlichkeiten, doch der Erfolg entsteht nicht durch ein starres Rollenmapping, sondern durch wirksame Kollaboration!

Ein kurzes Recap: Das Product Management bringt die Markt- und Kundensicht ein und trägt wesentlich dazu bei, dass ein generisches Produkt mit hohem Kundennutzen und gutem Product-Market-Fit entsteht. Daraus ergibt sich naheliegend, dass Business Epics und Business Features maßgeblich aus dieser Perspektive initiiert, beschrieben und geschärft werden.

Das System-Architecture-Team bringt dagegen das technische Verständnis, die architektonische Gesamtsicht und den Blick auf langfristige Umsetzbarkeit ein. Gerade deshalb liegt es nahe, dass insbesondere Enabler Features aus diesem Umfeld heraus entstehen oder dort wesentlich vorbereitet werden. Damit schafft die Architektur nicht nur technische Voraussetzungen, sondern unterstützt das Product Management aktiv dabei, Markterfolg überhaupt möglich zu machen.

Der Product Owner wiederum trägt die Verantwortung dafür, dass Anforderungen in eine umsetzbare Form für das Team überführt werden. Spätestens bei Schätzung, Zuschnitt und Konkretisierung sollte der PO eng eingebunden sein, denn hier entscheidet sich, ob aus einem Feature tatsächlich verständliche, realistisch planbare und wertstiftende User Stories werden.

Entscheidend ist daher nicht die Frage, wer ein Artefakt formal „besitzt“, sondern wer welchen Beitrag leisten muss, damit daraus umsetzbare, priorisierte und fachlich wie technisch tragfähige Arbeit entsteht. Business, Architektur und Umsetzung müssen dafür eng zusammenspielen.

Genau darin liegt die Stärke agiler Artefakte in SAFe: Sie schaffen nicht nur Struktur und Traceability, sondern fördern den notwendigen Dialog zwischen strategischer Idee, technischer Realisierbarkeit und operativer Umsetzung.

Der Gesamterfolg entsteht damit nicht in der isolierten Verantwortung einzelner Rollen, sondern im Zusammenspiel eines gut abgestimmten Teams.