Weniger Agilität wagen
Bosch ist angeblich agil, BMW auch. Natürlich die Telekom und Vodafone, und selbst Siemens. Und gefühlt alle anderen. Wer in der IT auch nur ein wenig auf sich hält, verspricht Agilität. Warum und wozu eigentlich? Oder geht das auch ohne? Ich würde das ja mal feiern…
Agilität, das ist im Wortsinn “Beweglichkeit”. Und da das moderne Management geprägt ist von persönlicher Hochleistungs-Optimierung seiner Top-Vertreter (weil selbst CEOs Marathon, besser Triathlon machen, und am Wochenende neben instagramtauglicher Family-Quality-Time auch 200km Rad fahren) gefällt sich die Geschäftsführung bei dem Gedanken, auch in ihrer sowieso als viel zu teuer empfundenen IT-Abteilung wenigstens methodisch für ein wenig Bewegung zu sorgen: Agil sei effizienter, hört man, und das wird doch bestimmt auch billiger werden. Also machen jetzt alle Scrum und Kanban, Obeya-Räume werden errichtet, SAFe-Coaches haben Hochkonjunktur und Atlassian verkauft Jira-Lizenzen, als wenn es kein Morgen gäbe.
Darf ich mal fragen, wozu das eigentlich gut sein soll?
Als ich die Frage vor einiger Zeit in hochrangig besetzter Runde stellte, meinte ich bei meinen Gegenüber Schnappatmung zu vernehmen. Da fragt doch einer nach dem “Wieso?”, obwohl “Agil!” doch schon seit Jahren das Mantra ist? Ja, allerdings, und bisher hab ich von jenen Gesprächspartnern keine überzeugende Antwort bekommen.
Agilität bedeutet nicht zuletzt Vertrauen
Versteht mich bitte nicht falsch: Die Methode hat Sinn und Zweck. Agilität bedeutet, in kurzen Zyklen immer wieder begründete Hypothesen aufzustellen und danach zu arbeiten, um den maximalen Kundennutzen zu erzielen - und dann zu messen, ob dieser Nutzen eingetreten ist. Wenn nicht, dann ist es Freiheit und Verantwortung des agilen Teams, umgehend Alternativen zu entwickeln. Darin stecken die drei Grundpfeiler der Agilität: Empirik (Objektivität, Messbarkeit), Ermächtigung (Entscheidungsfreiheit) und Eigentum (Verantwortung). Agilität ist nicht “mach mal irgendwas”, wie es von Skeptikern gern böse übersetzt wird. Aber Agilität ist sehr wohl “mach was anderes, wenn du objektiv festgestellt hast, dass das bisherige nicht funktioniert” - und daran stoßen sich viele Organisationen.
Agilität entscheidet sich nicht zuletzt am Geld, der Finanzierung. Wenn ein Investor Geld an ein Startup gibt, dann ist es sicher schön, einen Plan vorweisen zu können. Viel wichtiger ist dem Investor aber, dem Team hinter der Idee zu vertrauen: Kann er sicher gehen, dass das Team das bestmögliche Resultat mit dem Kapital erzielen wird? Wenn ja, dann muss das Team immer wieder prüfen, ob der Kundennutzen bestmöglich erzielt wird - denn das (und nur das!) führt am Ende auch dazu, dass der Investor sein Ziel erreicht.
Kurz: Ein agiles Team muss Handlungsfreiheit besitzen und das Vertrauen geniessen, die vorhandenen Mittel bestmöglich einzusetzen. Nur dann kann der agile Regelprozess aus “messen und anpassen” funktionieren.
Quo vadis, pecuniam?
Große Organisationen funktionieren traditionell nicht nach diesem Schema. Budget- und Kostenrechnung lässt es nicht zu, Teams “einfach mal Geld zu geben”. Anteilseigner und Aufsichtsrat sitzen dem Vorstand im Nacken mit der Forderung, die Kosten zu senken, wo immer es geht. Rigide “Sparprogramme” werden ausgerufen, Vorhaben werden eingeschränkt und reglementiert. Bevor ein Projekt gestartet werden darf, muss es in einem formalisierten Abstimmungsprozess spezifiziert und gegen andere Ideen abgewogen und priorisiert werden, das nennt man dann demand management. Governance und Regulierung in Branchen wie Banken & Versicherungen tut ein übriges hinzu: Da geht gar nichts mehr “spontan”.
Die Folge ist fake agile, agile Scheinprozesse in einer nicht-agilen Umgebung. Wie soll ein Team iterativ Features entwickeln und in kurzen Zyklen verfügbar machen, wenn zugleich ein 3-Jahres-Plan gefordert ist, um die Finanzierung zu rechtfertigen? Wie soll ein Product Owner Verantwortung für sein Produkt übernehmen, wenn mächtige Stakeholder in der Organisation sich vorbehalten, hineinzuregieren und seine Entscheidungen zu überlaufen? Wie soll ein Team eigenverantwortlich arbeiten, wenn es nicht mit allen Fähigkeiten besetzt ist, die für eine Ende-zu-Ende-Verantwortung nötig sind? Wie soll DevOps funktionieren, wenn Ende-zu-Ende-Verantwortung (die sowohl Produktentwicklung als auch Wartung und Betrieb einschließt) nicht der erwünschten Aufbau- und Ablauforganisation entspricht?
Alles das sind Umstände, die so oder ähnlich in vielen großen Organisationen auftreten. Sie haben ihre Ursache in etablierten, hierarchischen Strukturen, in branchentypischen Gepflogenheiten und regulatorischen Vorgaben. Man kann das gut finden oder schlecht, einzig ignorieren sollte man die Erkenntnis nicht. Die Antwort auf die Frage “Woher kommt das Geld?” dient mir persönlich als Lackmustest zur Erkennung von “fake agile”.
Reibungsverluste
Wenn man Agilität ernst nimmt, dann ergibt sich ein fundamental anderes Bild von Zusammenarbeit, als in traditionellen Organisationen üblich. Nur einzelne Projekte “agil” aufzustellen führt in der hierarchischen Organisation zu Mehraufwänden, Missverständnissen, realitätsfremden Rollenbildern, zu Frust und innerer Abkehr. Nicht selten stimmen Menschen dann mit den Füßen ab, die Folge ist eine höhere Personalfluktuation als üblich. Alles das ist aus Unternehmenssicht teuer, sinnlos und schlicht schädlich. Organisationen sind gut beraten, diese negativen Effekte genau zu beobachten und -wenn es irgendwie geht- zu vermeiden.
Beispielsweise, indem man auf den Mummenschanz verzichtet. Ich würde mich ja mal über eine große Organisation freuen, die klipp und klar macht: Bei uns gibts keine Agilität. Machen wir nicht, aus Gründen. Nicht, weil ich von Agilität grundsätzlich nichts halte, ich würde das auch nicht zwingend attraktiver finden, nur weil es eben nicht agil ist. Aber eine solche Organisation würde zumindest Selbstreflektion und eigenständiges Denken beweisen, was ich ebenfalls respektieren kann. Und für die Menschen dort würde es bedeuten, dass man sich nicht zwischen Wunsch und Wirklichkeit aufreiben müsste.