vom klassischen Projektplan zur agilen Struktur - Teil 1

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:

Der Wechsel von klassischer Projektorganisation zu agilem Arbeiten ist in der Praxis anspruchsvoller, als es zunächst wirkt. Klassische Strukturen definieren Rollen, Zuständigkeiten und Verantwortlichkeiten meist eindeutig.

Projekte werden geplant, Arbeitspakete beschrieben, Verantwortliche benannt und Fortschritt entlang eines Projektplans gesteuert.

Agile Frameworks wie SAFe verändern diese Logik grundlegend: Im Zentrum steht nicht die Abarbeitung vorab definierter Arbeitspakete, sondern die kontinuierliche Lieferung von Kundennutzen.

Dafür werden Anforderungen in Epics, Features und User Stories strukturiert und in kleinere, wertstiftende Inkremente geschnitten. So wird Nutzen früh sichtbar, Feedback schnell nutzbar und die Umsetzung iterativ geschärft.

Gerade in der Übergangsphase entstehen dabei typische Fragen: Wer ist wofür verantwortlich? Wer beschreibt ein Epic, wer schneidet Features, wer formuliert User Stories? Wer führt, wenn fachliche, technische und organisatorische Aspekte zusammenkommen? Und wie wird aus einer strategischen Idee umsetzbare Arbeit für Teams?

Für mehr Klarheit habe ich sechs Learning Nuggets entwickelt. Sie beleuchten zentrale Aspekte agiler Artefakte in SAFe – von Strukturierung, Traceability und Slicing bis zu Estimation und Socializing. Die folgenden Abschnitte zeigen, wie agile Artefakte Orientierung, Verantwortung und Transparenz in skalierten agilen Umfeldern schaffen.

1.) Definition agile Artefakte

In SAFe arbeiten wir mit drei zentralen Artefakten: Epics, Features und User Stories.

Business-Artefakte beschreiben direkt sichtbaren Kundennutzen oder fachliche Funktionalität. Sie beantworten die Frage: Welcher geschäftliche Mehrwert entsteht für Kunden, Anwender oder Stakeholder? Beispiele sind neue Produktfunktionen, Prozessverbesserungen oder fachliche Erweiterungen.

Enabler-Artefakte schaffen die technische, architektonische oder organisatorische Grundlage für Business-Artefakte. Ihr Kundennutzen ist oft indirekt, aber entscheidend für effiziente, sichere und skalierbare Umsetzung. Beispiele sind Architekturarbeiten, Infrastruktur, technische Schulden, Explorationsaufgaben oder vorbereitende Analysen.

Kurz gesagt: Business-Artefakte liefern fachlichen Nutzen; Enabler-Artefakte schaffen die Voraussetzungen dafür.

2.) Traceability

Traceability beschreibt die Nachverfolgbarkeit von Anforderungen über mehrere Ebenen hinweg – vom strategischen Vorhaben bis zur Umsetzung im Team. Ziel ist, jederzeit nachvollziehen zu können, welche User Stories zu welchem Feature beitragen, welche Features ein Epic realisieren und wie weit die Umsetzung fortgeschritten ist.

Typischerweise werden Artefakte in einem ALM-System (z. B. Codebeamer oder JIRA) hierarchisch verknüpft:

Für das Status-Reporting bedeutet Traceability: Fortschritt muss nicht ausschließlich manuell berichtet werden, sondern kann aus verknüpften Artefakten abgeleitet werden. Der Status eines Features ergibt sich etwa aus zugeordneten User Stories, Tests und Defects; ein Epic aus dem Fortschritt seiner Features.

Wichtig bleibt: Ein übergeordnetes Artefakt ist nicht automatisch erledigt, nur weil alle darunterliegenden Stories geschlossen sind. Entscheidend ist, ob fachlicher Nutzen erreicht, Akzeptanzkriterien erfüllt und relevante Tests erfolgreich abgeschlossen wurden.

Traceability ermöglicht damit transparentes Realtime-Reporting, ersetzt aber nicht die fachliche Bewertung durch Product Management, Product Owner, System Architecture oder Business Owner.

3.) Agile Work-Breakdown-Structure

Der klassische Projektstrukturplan findet im agilen Umfeld seine Entsprechung in der strukturierten Zerlegung von Epics in Features und User Stories. Während der PSP Arbeitspakete organisiert, strukturiert SAFe den Scope entlang von Wertbeiträgen. Zu Beginn eines Vorhabens werden die wesentlichen Features eines Epics identifiziert, um Orientierung, Abhängigkeiten und Planbarkeit zu schaffen. Die Detaillierung erfolgt iterativ: Features werden priorisiert und für die nächsten Planungshorizonte konkretisiert; User Stories werden erst kurz vor der Umsetzung verfeinert.

Wie im PSP technische Arbeitspakete sichtbar werden, sollten auch im agilen Kontext notwendige technische oder architektonische Vorarbeiten explizit als Enabler erfasst werden. So bleiben Voraussetzungen transparent. Gleichzeitig ist der Enabler-Anteil regelmäßig zu prüfen, damit der Fokus auf Business Value erhalten bleibt.

Ein klassischer PSP versucht häufig, Arbeitspakete möglichst früh vollständig zu beschreiben. Agil sollte genau das vermieden werden: Zu Beginn genügt eine belastbare Feature-Struktur. User Stories werden erst dann detailliert, wenn sie für die nächste Planung relevant sind.

Damit die Struktur mehr ist als eine Anforderungsliste, braucht jede Ebene geeignete Akzeptanzkriterien, idealerweise durch Tests nachweisbar. Abhängigkeiten zwischen Artefakten müssen ebenso sichtbar sein wie Abhängigkeiten zwischen klassischen Arbeitspaketen.

Ein zentraler zusätzlicher Aspekt ist die Releaseplanung. Ein agiler PSP – also die grobe Strukturierung eines Epics in wesentliche Features und deren weitere Verfeinerung – ist nicht nur für Transparenz und Steuerung relevant, sondern auch Voraussetzung für einen belastbaren Releaseplan.

Ohne grobe Scope-Struktur gibt es keine belastbare Releaseprognose. Der agile PSP schafft die Grundlage, aus einem strategischen Epic eine planbare Roadmap abzuleiten – ohne die Flexibilität des agilen Vorgehens aufzugeben. Damit wird er auch zur Basis für belastbare Sales Commitments.

Fortsetzung folgt….