Viele agile Praktiken und Ansätze basieren auf dieser Vorgehensweise. Prägend ist allen voran der PDCA-Zyklus oder DEMING-Kreis mit seinen vier Phasen „Plan - Do - Check - Act“, für hypothesengeleitetes und erfahrungsbasiertes kontinuierliches Lernen und Verbessern.90 In agilen Prozessen werden einzelne, kundenrelevante Anforderungen geplant bzw. Hypothesen dazu aufgestellt (Plan), dann in kurzen Zyklen fokussiert umgesetzt bzw. getestet (Do), dazu jeweils möglichst messbares Kundenfeedback eingeholt (Check) und daraus gelernt, was wie gut funktioniert. Was empirisch belegt funktioniert, wird gefestigt, alles andere wird in den nächsten Iterationen angepasst (Act bzw. begrifflich treffender Adapt91 oder auch Learn92). Über diese Vorgehenslogik findet eine kontinuierliche Anpassung, Weiterentwicklung und Leistungssteigerung statt (vgl. Abbildung 18). Die Vorgehenslogik kann sowohl für die Optimierung des Produkts (Arbeit im System), als auch für die Optimierung der Arbeitsteilung und Koordination, d. h. der Organisation (Arbeit am System), genutzt werden.
Abb. 18: Iterative Feedback- und Lernschleifen im PDCA-Zyklus
Um zu testen, ob „Same Day Delivery“ auf positives Kundenfeedback stößt, ging man bei ZALANDO einen pragmatischen Weg. Täglich wurden im Logistikzentrum nahe der Berliner Zentrale 30 bestellte Sendungen herausgegriffen, in Autos gepackt und noch am selben Tag ausgeliefert. Sogar die Chefs schlüpften in die Rolle des Paketboten. Die ZALANDO-Mitarbeiter erhielten dadurch schnell direktes Feedback von ihren Kunden und konnten die logistischen Anforderungen eines solchen Angebots selbstständig erheben. „Wir hätten auch ein paar Hundert Leute abstellen können, die einen großen Projektplan entwerfen, wie ZALANDO innerhalb der nächsten zwei Jahre das Thema „Same Day Delivery“ aufrollt, … aber wenn wir dann am Ende feststellen, dass wir das falsche Problem gelöst haben, sind jede Menge Ressourcen verbrannt. Immer wenn wir eine … Möglichkeit erkennen … ist es für uns der logische nächste Schritt, das möglichst schnell auszuprobieren“, sagt DANIEL SCHNEIDER, Head of Onsite Customer Journey.93 Diese „trial and error“- bzw. „safe enough to try“-Mentalität sorgt für ein hohes Tempo und ist ein wesentliches Grundprinzip agiler Betriebssysteme, wie z. B. Holacracy (vgl. Kapitel 8.3).
Ein solches agiles, hypothesengeleitetes Vorgehen bedeutet auch, dass bloßes Kopieren zu kurz greift. Einfach „skippen“, eine Abkürzung nehmen oder Prozesse und Arbeitsweisen von anderen abkupfern, das kann auf Dauer nicht funktionieren. „Wir sind doch schon agil“, heißt es dann oft nach gefühlten 4-5 Sprints. Es ist, als wolle man den eigenen Film vorspulen, um schneller zum Ende zu kommen, und verdrängt dabei, dass man den eigenen Film nicht versteht. Am Ende ist man genauso schlau wie zuvor. Von außen betrachtet heißt es dann häufig abschätzig (vgl. Kapitel 2.2 und 9): „Ihr verwechselt doing agile mit being agile.“
Fokussierung
Ein wichtiger Aspekt beim iterativen Vorgehen und schrittweisen Lernen ist die Priorisierung von Aufgaben und die Fokussierung in den einzelnen Iterationen (Sprints) auf die dringlichen und wichtigen kundenrelevanten Anforderungen. Agile Ansätze versuchen nicht, in einem „großen Wurf“ die 100 %-perfekte Lösung zu erstellen, sondern gehen in kleinen Schritten und fokussierten Hypothesen vor. Man möchte der Gefahr aus dem Weg gehen, sich im komplexen Ganzen zu verlieren. Mangelnde Kundenorientierung durch intransparente Strukturen, lange Entscheidungswege und folglich wenig effiziente oder uneffektive Prozesse, soll vermieden werden. Getreu dem Motto „done is better than perfect“ konzentrieren sich agile Unternehmen auf die wichtigen und dringlichen Aufgaben. Es gilt: „stop starting – start finishing!“ Dadurch können sie schneller liefern (in Form von Prototypen, Produktinkrementen und Minimal Viable Products, vgl. Kapitel 6), erhalten früher Kundenfeedback und können diese Erkenntnisse nutzen, um nachfolgende Iterationen und Inkremente inhaltlich und prozessual an die neuen Bedingungen zu adaptieren.
So gelang es beispielweise der STADTSPARKASSE DÜSSELDORF, ein agiles Projekt mit mehr als 60 Mitarbeitenden auf die Beine zu stellen, die innerhalb kürzester Zeit ein Corona-Soforthilfeprogramm entwickelten, mit dem Ziel, Firmenkunden schnell und unbürokratisch Liquidität zu verschaffen. Aufgrund der aktuellen Krisensituation hatte das Vorhaben hohe Priorität. Die Projektteams verständigten sich darauf, eine funktionierende und schnelle Lösung einer perfekten vorzuziehen. Prozesse und Abstimmungsrunden konnten dadurch enorm verkürzt werden, mit dem Ergebnis, dass eine Erstversion bereits nach 26 Stunden vorlag, die Liveschaltung nach 59 Stunden erfolgte und die ersten Kreditanträge bereits nach 99 Stunden ausgezahlt werden konnten.94
Organisiert wird idealerweise nur so viel, wie es die kundenorientierte Ausrichtung des Wertstroms erfordert. Die agilen Teams (vgl. Kapitel 4.3) erhalten weitreichende Kompetenzen und Priorisierungswerkzeuge, damit sie Aufgaben eigenverantwortlich einschätzen und transparent bewerten können. Im Mittelpunkt steht dabei stets der Kundennutzen, der in Relation zum korrespondierenden Umsetzungsaufwand den Return on Investment darstellt. Die Handelnden sind dadurch in der Lage, den Fokus auf die Fertigstellung der wertschöpfenden „Features“ zu richten. Wenn zu viele Aufgaben gleichzeitig auf dem Tisch liegen, dann sind zwar alle beschäftigt, ein funktionales Ergebnis für den Kunden lässt aber oft auf sich warten, wenn ständig zwischen Aufgaben hin und her gesprungen wird und man sich verzettelt. Es ist daher wichtig, sich auf die Fertigstellung und Lieferung der Inkremente zu konzentrieren. „Work in Process/Progress“-Limits (WIP-Limits, vgl. Kapitel 6.2) beispielsweise disziplinieren die Handelnden dabei, priorisierte Aufgaben zuerst fertigzustellen, bevor mit neuen begonnen werden kann.
Pull-Prinzip
Die Auswahl der in der nächsten Iteration fokussiert zu bearbeitenden Anforderungen und die Verteilung der Arbeit erfolgt in agilen Organisationen nicht wie in klassisch-hierarchischen Systemen zentral nach dem sogenannten Push-Prinzip, bei dem Aufträge „top down“ – von oben nach unten – in das System „gedrückt“ werden (vgl. Kapitel 3). Denn hier drohen Kapazitätsengpässe und personelle Überlastungen – sowohl an der Spitze, durch ein Zuviel an Entscheidungszentralisation, als auch an der Basis, durch das Input-getriebene „pushen“ von Aufträgen.
Stattdessen dominiert in agilen Prozessen das umgekehrte Pull-Prinzip. Hierbei werden die Aufträge von den operativ ausführenden Akteuren in den agilen Teams „gezogen“. Steuerung und Arbeitsteilung erfolgen eigenverantwortlich und selbstorganisiert. Dadurch sollten nur so viele Aufträge angenommen werden, wie Ressourcen und Personalkapazitäten zu gegebenen Zeitpunkten vorhanden sind. Wenn dies gelingt, kann es in agilen Organisationen idealtypisch nicht zu einer Überlastung kommen (vgl. zum Pull-Prinzip ausführlich die Kanban-Methode in Kapitel 6.2).
Hier tritt auch wieder der enge Bezug zu den Lean-Ansätzen (vgl. Kap. 2.2) in den Vordergrund, die mit dem sogenannten Just-in-Time-Prinzip und One-Piece-Flow-Konzept einen perfekt aufeinander abgestimmten und synchronisierten Arbeitsfluss anstreben, bei dem Werkstücke ohne Unterbrechung und Liegezeiten über den gesamten Produktionsprozess bis zu deren Fertigstellung durch einen Mitarbeiter oder ein Team begleitet werden.95 Übertragen auf die agile Organisation bedeutet diese Vorgehensweise, dass die Mitarbeiter eines Entwicklungs- oder Produktionsprozesses alle anfallenden Aufgaben beherrschen, diese selbstständig koordinieren, selbstorganisiert verrichten, und dadurch für den Gesamtprozess und das Ergebnis (-Inkrement) Verantwortung übernehmen.
Zusammenfassend