Was ist ein agiler Prozess?

Der bekannteste Vorläufer des agilen Vorgehens ist der Demingkreis oder auch  PDCA-Zyklus des US-Statistikers W. Edwards Deming. Dabei steht PDCA für einen vierphasigen Lern- und Verbesserungsprozess.

Da der Demingkreis auf den Arbeiten des US-Physikers Shewhart basiert, bezeichnete Deming seinen PDCA- auch als Shewhart-Zyklus. Praktische Anwendung fand der Demingkreis ab den 1940er und 1950er-Jahren vor allem im Bereich des Qualitätsmanagements. Damit wurde der PDCA-Zyklus auch zu einer tragenden Säule und integralem Bestandteil des Lean Management.

Agile Prozesse ermöglichen Dir Arbeiten unter Unsicherheit. Dabei resultiert Unsicherheit aus unklaren Anforderungen oder unbekannten Lösungswegen.

1. Anforderung: Du kannst die Anforderungen nicht abschließend definieren, sondern nur grob abstecken.
2. Lösung: Der Lösungspfad ist nicht eindeutig, d.h. die ideale Lösung bzw. das Vorgehen zum Erreichen der Lösung sind nicht abschließend definiert.

Diesen Arbeiten unter Unsicherheit stehen Aufgaben gegenüber, deren Anforderung und Lösungsweg Du klar und abschließend beschreiben kannst.

Vertiefende Erklärungsmodelle für die Arbeit in einem agilen Prozess sind die Stacey Matrix und das Cynefin Framework. Dabei findest Du eine Unterteilung in einfache, komplizierte und komplexe Aufgaben. Bei einfachen Aufgaben lautet die Devise “einfach machen”, diese kannst Du einfach über Checklisten und Standards ausweiten. Komplizierte Aufgaben erfordern unter Umständen Experten und eine umfangreiche Analyse. Damit kannst Du einen umfassenden Plan entwickeln und in die Umsetzung gehen. Dagegen kannst Du komplexe Aufgaben nie abschließend planen, Du benötigst immer ein agiles Vorgehen, um dich der idealen Lösung anzunähern.

Dabei kann es durchaus sein, dass auch komplexe Aufgaben einfache oder komplizierte Anteile enthalten. Deswegen orientiere ich mich für die Darstellung des agilen Prozesses vor allem an der Frage, ob Du die Anforderungen abschließend definieren (und beschreiben kannst) und jemand auf dieser Basis eine abschließende Lösung vorschlagen (und beschreiben) kann. Wenn Du beides mit JA beantwortest, dann brauchst Du kein agiles Vorgehen, sondern kannst auf traditionelle Methoden zurückgreifen. Wenn zumindest eine der Antworten NEIN ist, dann willkommen im agilen Prozess.

Arbeiten in einem agilen Prozess ist nichts weiter als ein Instrument zum Risikomanagement. Denn wenn Du Anforderungen und Lösungen nicht abschließend definieren kannst, dann kannst Du weder das benötigte Budget noch die Dauer der Fertigstellung abschätzen. Das Versprechen des agilen Prozesses ist, dass Du mit jeder Iteration eine höhere Sicherheit erhältst bzw. Du den Schätzfehler systematisch senkst. Dieses systematische Risiko und der damit verbundene Schätzfehler ist auch als “Cone of Uncertainty” bekannt. Demnach liegt der Schätzfehler bei neuen Vorhaben beim Faktor 16 und sinkt, je weiter Du mit der Implementierung und in deinem agilen Vorgehen fortgeschritten bist.

Der agile Prozess ist eine Abfolge von kurzen zeitlichen Intervallen (Iterationen). Jede dieser Iterationen ist in Anlehnung an den PDCA Zyklus in folgende Phasen unterteilt:

1. Planung (Plan): Zu Beginn der Iteration formulierst Du Aufgaben, Ziele oder auch Hypothesen für das vor Dir liegende Arbeitsintervall.

2. Umsetzung (Do) Du setzt die Arbeiten mit dem Ziel um, konkrete Arbeitsergebnisse und Fortschritte (“Done Work”) zu erzielen.

3. Überprüfung (Check): Zum Abschluss der Iteration überprüfst Du Arbeitsergebnisse auch und vor allem mit dem Kunden. Dabei gleichst Du gewonnene Erkenntnisse und mit den geplanten / erwarteten Ergebnissen ab.

4. Anpassung (Adjust): Auf Basis der erzielten Ergebnisse ziehst Du Rückschlüsse für dein gesamtes Vorhaben. Du reflektierst den Arbeitsprozess, die gewonnenen Erkenntnisse sind Basis für die kommende Iteration.

Dabei gelten für die Arbeit in einem agilen Prozess und einzelnen Iteration im speziellen folgende Daumenregeln:

1. Die Länge eines Arbeitsintervalls ist Ausdruck deiner Unsicherheit. Je höher deine Unsicherheit, desto kürzer ist eine Iteration. Je besser Du Aufgaben für eine vor dir liegende Iteration spezifizieren kannst, desto länger eine Iteration. Wenn eine Iteration länger ist als vier Wochen, baust Du Dir möglicherweise mehr Risiko in deinen agilen Prozess ein, als Du eigentlich haben willst.

2. Nach ist immer vor der Iteration. Das heißt, dass Iterationen in einem agilen Vorgehen nahtlos aufeinanderfolgen und sich “die Klinke in die Hand geben”.

Jede einzelne Iteration im agilen Prozess startet mit einer Planung. Dabei formulierst Du Aufgabenpakete, Fragestellungen oder Hypothesen, die Du zum Abschluss der Iteration gerne geklärt bzw. erledigt hättest. Du planst immer nur für die vor Dir liegende Iteration und besprichst die notwendigen Schritte, um dein gewünschtes Ergebnis zu erreichen. Was in der vor Dir liegenden Iteration nicht priorisiert und erledigt werden kann, bleibt in deinem Backlog.

Du setzt deine Aufgaben und Fragestellungen gemäß deinen Planungen um. Das heißt, während der Umsetzung machst Du nicht einfach “irgendwas”. Sondern Du orientierst dich im agilen Prozess sehr konsequent an den priorisierten Aufgaben aus deiner Planung. Nur wenn sich Aufgaben auf Basis neuer Erkenntnisse erledigt haben, Du alle vereinbarten Ergebnisse erzielt hast, werden neue Aufgaben priorisiert. Das Ziel deiner Umsetzung ist, konkrete Arbeitsergebnisse und Erkenntnisse zu gewinnen, um insgesamt deine Unsicherheit zu reduzieren und dein Risiko zu managen.

Zum Abschluss deiner Iteration überprüfst und besprichst Du die erzielten Arbeitsergebnisse und Erkenntnisse. Dabei geht es um eine ehrliche und kritische Reflexion der erzielten Ergebnisse auch und vor allem mit dem Kunden. Nicht etwa darum, dass alle Ampeln auf Grün stehen. Schließlich bedeutet agiles Vorgehen ein Navigieren in unsicheren Gewässern, d.h. Fehler sind ein Teil des Prozesses.

Auf Basis der gewonnenen Erkenntnisse und der erzielten inhaltlichen Ergebnisse ziehst Du Rückschlüsse für die weitere Umsetzung deines Vorhabens. D.h. die Überprüfung hat unmittelbaren Einfluss auf die Planung der kommenden Iteration. Je nachdem, in welchem agilen Vorgehensmodell Du zusammenarbeitest, gehen Anpassung und Planung unmittelbar ineinander über (Lean Startup) oder werden bei stark regelbasierten Framework (z.B. Scrum) auch zeitlich voneinander getrennt. Über die inhaltliche Anpassung hinaus reflektierst Du auch die Qualität deines agilen Vorgehens und passt diese bei Bedarf an.

Der agile Prozess wird durch Frameworks konkret operationalisiert. Dabei sind Design Thinking und Lean Startup weniger regelbasiert und etwas “chaotischer”, ohne dabei jedoch die Grundstruktur des agilen Vorgehens zu verletzen. Formate wie Scrum oder OKR sind dagegen deutlich strukturierter.

Design Thinking wendest Du an, um Anforderungen an dein Produkt oder deine Leistung in sehr frühen Phasen zu verstehen. Dabei definierst Du zunächst das zu lösende Problem des Kunden, bevor Du Lösungen entwickelst und durch Prototypen mit dem Kunden verprobst. Der agile Prozess spiegelt sich in folgenden Phasen des Design Thinking Prozesses.

• Plan: Das Problem des Kunden definieren, mit dem Kunden validieren und einen Standpunkt ermitteln (Phase 1-3).
• Do: Entwicklung eines Prototypen (Phase 4-5).
• Check: Verprobung des Prototypen mit dem Kunden (Phase 6).
• Adjust: Debriefing, Reflexion, mit welchen Erkenntnissen Du wieder in den Design Thinking Prozess einsteigst.

Lean Startup ist für seinen dreistufigen Prozess “build, measure, learn” bekannt, um ein MVP (“Minimum Viable Product”) zu entwickeln. Das heißt, die “Plan” Phase des agilen Prozesses findet dabei nicht ausdrücklich Erwähnung, sondern verschmilzt mit der ersten Phase des “Bauens”:

• Plan: Kein eigenständiger Schritt; an der Schwelle von “learn” zu “build”.
• Do = Bauen “build” des MVP und Bereitstellung für den Kunden.
• Check = Messen “measure”, d.h. Einsammeln von Daten als Basis für die weitere Beurteilung und Weiterentwicklung.
• Adjust = Lernen “learn”, d.h. Auswertung und Reflexion und Planung für die nächste Iteration deines MVP.

Das Scrum Framework hat den agilen Prozess perfektioniert. Dabei heißt eine Iteration im Scrum Framework “Sprint”, die permanente Überprüfung und Anpassung ist eines der tragenden Scrum Prinzipien. Während die Länge einer Iteration z.B. bei Design Thinking nicht definiert ist, hat ein Scrum Zyklus eine Dauer von 1-4 Wochen. Zudem formalisiert Scrum den agilen Prozess mit konkreten Meetings, definiert Rollen und Artefakte, um die Zusammenarbeit im agilen Vorgehen zu perfektionieren.

• Plan: Zu Beginn des Sprints trifft sich das Team in einem “Planning”, um Anforderungen, Aufgaben und das Sprint-Ziel zu besprechen.
• Do: Das Team geht in eine 1-4-wöchige Umsetzung, es findet ein tägliches Synchronisation-Meeting (“Daily”) statt.
• Check: Zum Ende des Sprints präsentieren Entwickler im Rahmen einer “Review” ihre Arbeitsergebnisse, inhaltliche Anpassungen werden durch den Product Owner im Backlog dokumentiert und für kommende Sprints priorisiert.
• Adjust: Das Team reflektiert in einer “Retrospektive” seinen agilen Prozess und trifft Vereinbarungen für den kommenden Sprint.

Diese Art des agilen Vorgehens eignet sich ganz besonders für Teams, die dauerhaft mit mehr als 5 Personen an einem Vorhaben arbeiten. 

OKR ist ein Rahmenwerk, um die strategische Entwicklung deines Unternehmens in einem agilen Prozess zu steuern. Dazu formulierst Du Unternehmensziele, an deren Erreichung dann eine Vielzahl von Teams in einem agilen Prozess von 2-4 Monaten arbeiten. Dabei ist, wie auch der Scrum Sprint, jeder OKR Zyklus durch eine feste Serie von Meetings eingerahmt.

• Plan: Jedes Team definiert und synchronisiert seine OKR, dabei stellen Teams sicher, auf die Unternehmensziele einzuzahlen.
• Do: Teams gehen in die Umsetzung ihrer OKR. Während der Umsetzung synchronisieren sich Teams über die Aktualisierung ihrer Confidence Level.
• Check: Zum Ende des OKR Zyklus präsentieren Teams im Rahmen einer “Demo” ihre Zielerreichung.
• Adjust: Die OKR Master, Teams und die gesamte Organisation reflektieren in einer “Retrospektive” den agilen Prozess und treffen Vereinbarungen für die Anpassung des OKR Prozesses.

Wie eingangs erwähnt, ist der agile Prozess ein Instrument zum Risikomanagement. Denn erstens senkst Du systematisch dein Schätzrisiko. Zweitens lernst Du im agilen Prozess zu verstehen, wie die ideale Lösung aussieht, was dein Kunde also braucht, um glücklich zu sein. Das heißt, Du senkst durch regelmäßige Checks mit dem Kunden das Risiko, Dinge zu bauen, die keinen Wert stiften. Darüber hinaus profitierst Du von einem agilen Prozess auf mehreren Ebenen:

1. Visibilität: Statt dass Teams wochen- und monatelang in der Versenkung verschwinden, sind Teams in einem agilen Prozess durch regelmäßige Checks permanent sichtbar, d.h. Du hast eine durchgehend hohe Visibilität.
2. Anpassungsfähigkeit: Da Du immer nur für ein Arbeitsintervall planst, behältst Du eine hohe Anpassungsfähigkeit bei. Denn nach jeder Iteration kannst Du neu priorisieren und planen.
3. Business Value: Wenn Du den agilen Prozess dahingehend beherzigst, dass Du zum Ende einer Iteration vorzeigbare konkrete Arbeitsergebnisse vorzuweisen hast, dann schaffst Du nachweislich mit der Iteration konkreten Business Value.

Agiles Vorgehen ermöglicht Arbeiten unter Unsicherheit. Dabei arbeitest Du in kurzen zeitlichen Iterationen, an deren Ende Du - im Idealfall gemeinsam mit dem Kunden -  konkrete Arbeitsergebnisse präsentierst und überprüfst, um daraus deine Schlüsse zu ziehen. Das heißt, agiles Vorgehen bedeutet nicht, einfach ein paar zusätzliche Termine einzutragen, zu denen Du den Stand deines Wasserfall-Vorgehens überprüfst. Sondern agiles Vorgehen bedeutet, sehr konsequent an der Fertigstellung von Inkrementen zum Ende einer Iteration zu arbeiten und diese gemeinsam mit deinem Kunden zu checken. Um auf Basis dieser Erkenntnisse immer wieder die inhaltliche Ausrichtung und das gewählte prozessuale Vorgehen zu reflektieren. Dabei spielen zwei aus der japanischen Lean Philosophie bekannte Prinzipien eine wichtige Rolle. Erstens Kaizen, also der Wunsch, sich immer weiter zu verbessern. Zweitens ShuHaRi, die Disziplin, dem agilen Prozess treu zu bleiben. Wenn Du das beherzigst, dann ist der agile Prozess ein wahrer Lern- und Kulturbeschleuniger. Und das wichtigste Mittel im Rahmen deiner agilen Transformation. “Trust the process.”

Viel Erfolg dabei.