Warum agil? Discovery, Delivery, Reparatur, Resilienz
Bild: Andy Mabbett / Wikimedia Commons - CC BY-SA 3.0 |
Sinn- und Zweck-Fragen sind immer wieder erhellend. Im Umfeld agiler Transformationen ist eine von ihnen ein grosser Klassiker: die nach dem Grund wegen dem dort überhaupt agil gearbeitet werden soll. Häufig gibt es die generische Antworten, dass mehr Flexibilität oder höhere Reaktionsgeschwindigkeit angestrebt würden. Auf die Folgefrage wofür genau die nötig sind kommt dann häufig nicht mehr viel. Dabei gibt es gleich mehrere gute Antwortvarianten, z.B. Discovery, Delivery, Reparatur und Resilienz.
Bevor wir dazu kommen aber eine schnelle Definition: als Agilität wird hier die Fähigkeit verstanden in kurzen Abständen reaktions- und lieferfähig zu sein, sonst nichts. Allen die noch mehr darunter verstehen, wie z.B. Humanismus, (Basis-)Demokratie, New Work oder Achtsamkeit, seien zuerst dieser und dieser Artikel empfohlen. Ihre Kernaussage: wie alle Begriffe sollte man auch den der Agilität nicht überfrachten, wenn er benutzbar bleiben soll. Und damit zurück zu den vier Varianten.
Discovery
Um es als Beispiel-User Story zu formulieren:1 Als Startup möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um Kundenbedürfnisse die ich neu entdecke schnell bedienen zu können. Einer der grossen Klassiker unter den Anwendungsfällen der Agilität - ein neues Produkt entsteht erst nach und nach in zu Beginn noch rudimentären Umfängen, und erst wenn mit denen validiert wird, dass es Nutzungs- und Zahlungsbedeitschaft gibt, kommt die nächste Umfangs-Erweiterung. Wenn nicht wird die Entwicklung eingestellt. Umgekehrt kann es auch sein, dass die Neuentdeckung von Nutzern oder Bedürfnissen dazu führt, dass Produktentwicklungsziele schnell dorthin ausgerichtet werden. Das klassische Framework dafür ist Lean Startup.
Delivery
Beispiel-User Story: Als Unternehmen im gesetzlich regulierten Umfeld möchte ich in kurzen Abständen reaktions- und lieferfähig
sein, um meine Produkte schnell an neue Vorschriften anpassen zu
können. Zunächst weniger intuitiv verständlich, bei etwas Nachdenken macht es aber Sinn. Stark regulierte Branchen wie z.B. der Banken- und Versicherungs-Sektor müssen mitunter im Monatsrhythmus neue Vorschriften in ihren automatisierten Prozessen abbilden. Starre Planung und unflexible Umsetzung sorgen oft dafür, dass Stichtage nicht eingehalten werden können, mit Strafen durch die Aufsichtsbehörden als Folge. Ausgerechnet dort wo es starke Regulierungen gibt wird daher in immer mehr Firmen versucht agil zu arbeiten. Die Methoden-Klassiker sind dabei Scrum und SAFe.2
Reparatur
Beispiel-User Story: Als Konzern mit veralteter, fehleranfälliger Software möchte ich in kurzen Abständen reaktions- und lieferfähig
sein, um die häufig auftretenden Fehlfunktionen schnell reparieren zu
können. Man mag es sich kaum vorstellen, aber in vielen Behörden und Unternehmen gibt es Anwendungen die seit dreissig oder vierzig Jahren in Betrieb sind, oder noch länger. In den meisten derartigen Fällen führen unentdeckte Bugs, übersehene Seiteneffekte oder historisch gewachsene Komplexität zu ständig auftretenden Funktionsfehlern. Wenn zentrale oder profitable Geschäftsprozesse davon betroffen sind ist es von kritischer Bedeutung, dass Ressourcen schnell umgeplant und Reparaturen zeitnah und unbürokratisch stattfinden können. Methodisch können einige DevOps-Aspekte sehr hilfreich sein.
Resilienz
Beispiel-User Story: Als von ständigen Disruptionen betroffenes Unternehmen möchte ich in kurzen Abständen reaktions- und lieferfähig
sein, damit ich die Schäden durch externe Störungen begrenzen kann. Ein mit dem letzten verwandter Fall, mit dem Unterschied, dass die Probleme nicht (versehentlich) selbst erzeugt wurden sondern von aussen kommen. Das kann der neue und innovative Wettbewerber sein, aber auch Naturkatastrophen, Hackerangriffe oder Netzausfälle. Die Agilität wird hier gebraucht um diese Störungen früh zu erkennen, ihre Auswirkungen schnell zu begrenzen und möglichst schnell Kompensations- und Wiederherstellungsmassnahmen einleiten zu können. Das vermutlich am besten geeignete agile Framework ist Chaos Engineering.
Im Zweifel wird es auch noch weitere Herausforderungen geben wegen denen Agilität erstrebenswert ist, der allergrösste Teil wird sich aber einer dieser vier zuordnen lassen. Und dort wo das nicht möglich ist, ist es eine gute Idee genau zu prüfen ob nicht eine eher unsinnige Motivation der eigentliche Treiber ist (z.B. "Ich als Manager möchte überall schnell durchregieren können, wenn ich eine meiner monatlichen spontanen Eingebungen habe." oder "Wir wollen Modernität vortäuschen um Bewerber anzulocken".).
Und natürlich wird es immer wieder vorkommen, dass gleich mehrere der hier genannten Gründe für das Streben nach Agilität vorliegen, und zwar parallel. Das macht das Leben zwar nicht einfacher, es bietet aber immerhin einen kleinen Trost: mit der Einführung passender agiler Arbeitsweisen kann man in mehreren dieser Bereiche gleichzeitig für Verbesserungen sorgen.
2Es gibt natürlich noch andere Konstellationen in denen Delivery im Focus steht, das hier ist nur ein Beispiel