Agiler Workflow

Kernpunkte:

die Ablauforganisation wird durch zwei wesentliche Kernpunkte charakterisiert:

Aufgabenfluss nach dem PULL-Prinzip durch wertschöpfende, dezentrale und vertrauensvolle Kommunikation und Verantwortung
Steuerung durch eindeutige Priorität, klare Synchronisationspunkte und Iterationen zum Analysieren und Justieren

Wie werden Abläufe und Interaktionen gestaltet?

Agilität verspricht die kontinuierliche Lieferung von Kundennutzen. Wer die Planung zentralisiert und das Projekt in starre Phasen aufteilt, wird den Nutzen erst zum Schluss mit der Systemintegration zeigen können. Beim agilen Workflow findet hingegen eine flexible Aufgabenverteilung nach dem Pull-Prinzip statt – jedes Team ist in der Lage, Aufgaben selbständig und in dynamischer Kopplung mit den anderen Teams zu erledigen. Durch regelmäßige Integrationspunkte wird es möglich, die verschiedenen Domänen zusammenzuführen und das System kontinuierlich zu validieren. Iterationen zur Analyse, verbessertes Lernen und Adaptionsmöglichkeiten schaffen eine klare Ausrichtung und vermeiden späte Kurskorrekturen.

Der Ablauf in einer agilen Entwicklungsumgebung ist geprägt durch die grundsätzlich iterative Vorgehensweise. Die Iteration gibt einen festen Ablauf und damit Sicherheit und Zuverlässigkeit. Inhaltlich ermöglicht ein iteratives Vorgehen aber die notwendige Flexibilität und Anpassungsfähigkeit wie auch sehr gute Voraussetzungen für einen kontinuierlichen Prozess der Reflexion und Verbesserung der Fähigkeiten und Leistung. Am Beispiel von SCRUM sind im Folgenden mögliche, aufeinander abgestimmte Ereignisse einer Iteration dargestellt.

Backlog Refinement

Klärung der Erwartungshaltung und gemeinsames Verständnis über das WAS inkl. Akzeptanzkriterien und einer groben Abschätzung zu Komplexität oder Aufwand

Übergreifend sind alle Aufgaben, Verantwortlichkeiten und erwarteten Ergebnisse in Product Backlog und Team Backlogs einsehbar und steuerbar
Der Product Manager organisiert das Product Backlog Refinement
Beteiligt sind die Product Owner und – wenn erforderlich – andere Stakeholder
Aufgabe ist es den Status bestehender Backlogeinträge zu bewerten, Abhängigkeiten zu identifizieren, ggf. Maßnahmen zu ergreifen und neue Backlogeinträge einzuschätzen. Gemeinsam werden eine veränderte Priorisierung und Aufgabenverteilung beschlossen
Um den Fortschritt teamübergreifend zu synchronisieren und die reibungslose Zusammenarbeit zup gewährleisten sind zwei Elemente wesentlich für den Erfolg
- ein abgestimmter, synchroner Takt, in dem die Ergebnisse jedes Teams erwartet und anschließend integriert werden
- ein abgestimmtes Prozessmodell inkl. Methodenbaukasten, das die Form der Ergebnisse bestimmt und damit die Schnittstellen zwischen den Teams und z.B. Regeln zum Aufbau einer gemeinsamen Architektur definiert. Zum Tailoring gibt es dabei klare Regeln, um definierte Freiheitsgrade zur lokalen Optimierung für die Teams zu schaffen
Das gleiche Verfahren, mit einem jeweils spezifischen Ziel, führt jeder Product Owner zusammen mit seinen Teammitgliedern durch.

Release Planning

zeitliche Grobplanung und Klärung einer langfristigen Reihenfolge der Erwartungen inkl. Umsetzbarkeit und notwendiger Aufgabensteuerung

Voraussetzung – ein „sauberes“ Product Backlog (Anforderungsspezifikation inkl. Identifikation von Features und mindestens ein Abnahmekriterium pro Feature enthalten (definition of done)
Product Manager priorisiert Einträge nach geschäftlichem Nutzen und Bewertung des Risikos. Ergebnis ist eine Releaseplanung in dem Feature und Aufgaben sowohl Kundenreleases, Entwicklungszyklen als auch den agilen Teams (ggf. verschiedene Ebenen) zugeordnet werden
Vertreter der Agile Teams erstellen eine grobe Aufwandschätzung. Der Product Manager steht für Rückfragen zur Verfügung und empfängt die Schätzinformation
Product Owner übernimmt die Einträge in das Team Backlog zur Teamplanung und identifiziert frühzeitig Konflikte zwischen Erwartungen an Ergebnisse, dem Durchsatz bzw. der Leistungsfähigkeit des Teams und der mittel- und langfristigen Ressourcen
Ziel bzw. Ergebnis der Release Planung (Grobplanung) ist:
- Zuordnung der Features zum Release, Priorisierung innerhalb des Release auf Zyklen
- grobe Aufwandschätzung, Abgleich des notwendigen Aufwandes mit den Teamressourcen, Identifikation von Konflikten und Risiken, Identifikation von Abhängigkeiten/Zulieferungen
- Abgleich zwischen den Erwartungen des Product Managers und den Möglichkeiten der agilen Teams

Sprint Planning

zeitliche Detailplanung und finale Klärung einer detaillierten, priorisierten Reihenfolge innerhalb einer Iteration (Sprint)

Die Detailplanung wird jeweils für den aktuellen Sprint vervollständigt und den folgenden Sprint erstellt. So entsteht eine detaillierte Vorausplanung von mind. zwei Sprints
Einträge des Team Backlogs werden in Aufgaben mit passendem Aufwand zum verwendeten Taskboard aufgebrochen und abgeschätzt. Je nach Variante des Taskboard können Aufgaben zwischen 1, 2, 4, oder 8 Tage (Fibonacci-Folge) dauern
Wer übernimmt die Verantwortung für welches (Teil-)Ergebnis des aktuellen Sprints?
Hierdurch erfolgt die Zuordnung der Aufgaben zu den Mitarbeitern
Welche Hindernisse bei der Umsetzung der Aufgaben bzw. zur Erreichung des erwarteten Ergebnisses sind aktuell bekannt?
Hierdurch werden Aufgaben für den Scrum Master (Impediment Backlog) identifiziert.
Abnahme des Team Backlog für den aktuellen Sprint durch den Product Owner
Ziel bzw. Ergebnis der Sprint Planung (Detailplanung) ist:
- ein Ziel für den aktuellen Sprint ist erstellt
- es besteht Einigung über die Aufgaben des aktuellen Sprints
- Termine für Sprint Review und das tägliche Statusmeeting sind verabredet
- Liste der Teammitglieder samt deren Verfügbarkeit ist zusammengestellt

Daily Stand-up der Teams

Feststellung von Status, Fortschritt, Risiken und aktuellen Hindernissen

Täglich, stehend vor dem Taskboard, immer < 15-20 min (auch bei Teams von 12 – 15 Personen)
Drei Fragen die den Status innerhalb des Sprints transparent darstellen:
- Was habe ich seit gestern erledigt?
- Was mache ich bis morgen?
- Was behindert mich / hat mich behindert?
Das Team aktualisiert
- Status der Aufgaben auf dem Taskboard auf Basis der Antworten
- Burn-down Chart (Wie viele Aufgaben sind noch zu erledigen?)
- Liste der Hindernisse (Impediment Backlog)
Feststellung von Ereignissen wie z.B. Ressourcen Ausfall, Hindernisse, Fortschrittsprobleme, Zusatzaufgaben (Express Ticket) und im Anschluss des Standup Analyse der Auswirkungen
- Welche Auswirkungen haben die identifizierten Ereignisse?
- Welche Maßnahmen leiten sich aus den Ereignissen ab?
- Welche Ziele sollen die Maßnahmen erfüllen?
- Welcher Aufwand ist zur Umsetzung der Maßnahmen notwendig?
- Wer übernimmt die Verantwortung zur Erreichung der zusätzlichen Ziele/Ergebnisse?

Sprint Review

Präsentation der fertig gestellten Team-Backlog-Einträge gegenüber dem Product Owner

Abnahme und Überprüfung des Sprint-Zieles durch den Product Owner, unterstützt oder vertreten durch Quality Product Owner und/oder Safety Product Owner
Diskussion zu offenen Aufgaben und deren Auswirkung
Feedback der Beteiligten, evtl. neue oder veränderte Einträge im Team- oder Product Backlog
Folgende Fragen unterstützen die Durchführung
- Welche Ergebnisse wurden erwartet?
- Sind die Kriterien zur Abnahme der erwarteten Ergebnisse vollständig erfüllt?
Wenn erwartete Ergebnisse nicht vollständig erfüllt sind, folgt eine Analyse der Auswirkungen
- Welche Auswirkungen haben die unvollständig vorliegenden Ergebnisse?
- Welche Maßnahmen leiten sich aus den unvollständigen Ergebnissen ab?
- Welche Ziele sollen die Maßnahmen erfüllen?
- Welcher Aufwand ist zur Umsetzung der Maßnahmen notwendig?
- Welche Priorität innerhalb des Teambacklog ist angemessen für die Maßnahmen?

Retrospektive

Raum für kontinuierliche Verbesserung der Leistung und Fähigkeiten

Retrospektive ist der Abschluss eines Sprints und folgt im Anschluss an das Sprint Review
Retrospektive fokussiert auf das Agile Team, seine Zusammenarbeit, die äußeren Einflüsse und Rahmenbedingungen, auf die Motivation und Selbstbestimmung
Die Teilnahme an der Retrospektive ist ohne spezifische Einladung/Zusage beschränkt auf das Agile Team, den Product Owner und den Scrum Master um eine maximale Offenheit zu geben
Vier Fragen bilden die Grundlage jeder Retrospektive
- Was war positiv während des Sprints?
- Was was negativ während des Sprints?
- Was sollte unbedingt erhalten bleiben oder in den nächsten Sprints fortgesetzt werden?
- Was muss verändert oder verbessert werden?
Der Schwerpunkt einer Retrospektive wechselt je nach Situation z.B. Verbesserung der Teamzusammenarbeit, Analyse der Rahmenbedingungen, Detailanalyse eines spezifischen Hindernisses bzw. einer Störquelle
Zum Ende einer Retrospektive erfolgt eine Priorisierung möglicher Maßnahmen, nur 1-2 davon werden in das Team Backlog oder das Impediment Backlog übernommen und ab dem nächsten Sprint bearbeitet bzw. umgesetzt

Zurück