Das ungeschriebene Playbook: Agilität in der realen Welt

Das ungeschriebene Spielbuch: Beratungstipps, die man Ihnen in der Ausbildung nicht beibringt

Agile in der realen Welt: Jenseits des Lehrbuchs

"Wir sind vollständig agil", versicherte mir der Delivery Director des Kunden an meinem ersten Tag. Am Ende der Woche hatte ich herausgefunden, was ihre Version von "vollständig agil" bedeutete:

• Zweimonatige "Sprints"
• Ein 400-seitiges Anforderungsdokument, das nicht geändert werden konnte
• Tägliche Stehversuche, die routinemäßig 45 Minuten dauerten
• Ein Produktverantwortlicher, der für seine Entscheidungen fünf Genehmigungsstufen benötigte

Das war nicht die Ausnahme - es war die Norm. In über einem Jahrzehnt der Beratungstätigkeit habe ich noch nie eine Kundenumgebung erlebt, die perfekt zu den in Schulungskursen oder Zertifizierungsprogrammen beschriebenen agilen Methoden passte.

Willkommen zur dritten Folge von "The Unwritten Playbook", in der ich Ihnen die Wahrheiten über die Beratung verrate, die Sie in der formalen Ausbildung nicht lernen. Heute befassen wir uns mit der Kluft zwischen der Agile-Theorie und der Kundenrealität und damit, wie man Werte schafft, wenn nichts im Lehrbuch steht.

Agiles Theater vs. Agiler Wert: Erkennen des Unterschieds

Viele Organisationen haben die Zeremonien von Agile übernommen, ohne sich die Prinzipien zu eigen zu machen. Sie spielen das, was ich "Agiles Theater" nenne - sie gehen die Bewegungen durch, ohne den Nutzen zu ernten.

Ich habe einmal an einem Projekt teilgenommen, bei dem mir das Team stolz seine Kanban-Tafel mit perfekt angeordneten Spalten und farblich gekennzeichneten Karten zeigte. Doch als ich fragte, wie oft sich die Karten auf der Tafel bewegten, sagte mir das peinliche Schweigen alles. Die Tafel wurde nur für die Sprint-Reviews aktualisiert - im Grunde ein statisches Präsentationstool und kein lebendiges Workflow-Management-System.

Der Unterschied zwischen Agile Theatre und Agile Value liegt in den Ergebnissen, nicht in den Aktivitäten:

Zeichen des agilen Theaters:

• Zeremonien, die religiös, aber ohne Zweck abgehalten werden
• Ausführliche Dokumentation von "User Stories", die wie traditionelle Anforderungen funktionieren
• Sprintpläne, die sich während der Ausführung nie ändern
• Retrospektiven, bei denen dieselben Probleme wiederholt auftreten, ohne dass sie gelöst werden
• Product Backlogs werden ausschließlich von Projektmanagern verwaltet, nicht von Produktverantwortlichen

Anzeichen für agilen Wert:

• Häufige Lieferung von funktionsfähiger Software
• Echtes Kundenfeedback beeinflusst die Prioritäten
• Befähigung des Teams, technische Entscheidungen zu treffen
• Sichtbare Verbesserung der Prozesse im Laufe der Zeit
• Fokus auf Ergebnisse statt auf Output

Als Berater befinden wir uns oft in einer schwierigen Lage: Kunden beauftragen uns mit der Implementierung von Agile, sind aber nicht auf die organisatorischen Veränderungen vorbereitet, die für den Erfolg erforderlich sind. Ich habe festgestellt, dass es am effektivsten ist, sich auf die schrittweise Wertschöpfung zu konzentrieren und nicht auf methodische Reinheit.

Ungeschriebene Regel 1️⃣: Kämpfen Sie nicht für agile Reinheit, sondern für die Prinzipien, die im Kontext Ihres Kunden einen Mehrwert bieten. Eine echte Verbesserung ist mehr wert als hundert Lehrbuchimplementierungen.

Methodologien übersetzen: Agile Ansätze auf Kundenkulturen abstimmen

Nicht jede Organisation ist für die gleiche Art von Agile bereit, und ein erzwungenes Missverhältnis erzeugt eher Widerstand als Ergebnisse.

Diese Lektion lernte ich bei der Arbeit mit einer Regierungsbehörde mit strengen Governance-Anforderungen. Unser erster Versuch, Scrum einzuführen, scheiterte spektakulär, weil der zweiwöchige Sprint-Zyklus mit der monatlichen Struktur des Lenkungsausschusses kollidierte. Als wir dann zu einem eher Kanban-artigen Ansatz mit monatlichen Demonstrationspunkten übergingen, die auf die Governance der Behörde abgestimmt waren, machten wir plötzlich Fortschritte.

Beurteilen Sie die Agile-Bereitschaft Ihres Kunden anhand dieser Dimensionen:

Organisatorische Struktur:

• Hierarchisch → Selbstverwaltend
• Getrennt → Funktionsübergreifend
• Zentralisierte → Verteilte Entscheidungsfindung

Planungshorizont:

• Jährliche Budgetierung → Kontinuierliche Finanzierung
• Fester Umfang → Flexible Prioritäten
• Detailliert im Voraus → Progressive Ausarbeitung

Risikotoleranz:

• Risikoscheu → Risikobalanciert
• Prozessorientiert → Ergebnisorientiert
• Versagen bestrafend → Lernorientiert

Wählen Sie dann Ihren Ansatz aus und passen Sie ihn entsprechend an:

• Für traditionelle Organisationen: Erwägen Sie Scrumban mit längeren Zyklen, die auf die Governance abgestimmt sind
• Für regulatorische Umgebungen: Legen Sie Wert auf Dokumentation und Rückverfolgbarkeit innerhalb der iterativen Lieferung
• Für hierarchische Strukturen: Implementieren Sie klare Eskalationswege und Entscheidungsrahmen
• Für risikoscheue Kulturen: Beginnen Sie mit risikoarmen Bereichen, um Erfolge zu demonstrieren

Ich habe die Erfahrung gemacht, dass ein Ansatz, bei dem die Prinzipien im Vordergrund stehen, besser funktioniert als ein Ansatz, bei dem die Praxis im Vordergrund steht. Wenn Kunden das Warum von Agile verstehen und akzeptieren (schnelleres Feedback, geringeres Risiko, höhere Anpassungsfähigkeit), sind sie eher bereit, ihre Prozesse anzupassen, um diese Vorteile zu erreichen.

Ungeschriebene Regel 2️⃣: Holen Sie Ihre Kunden dort ab, wo sie sind, und nicht dort, wo sie nach dem agilen Manifest sein sollten. Der Weg zu echter Agilität ist selbst schrittweise.

Das Festpreis-Paradoxon: Agilität in nicht-agilen Geschäftsmodellen

Der vielleicht größte Widerspruch in der Beratung besteht darin, dass von Ihnen verlangt wird, Agile im Rahmen von Verträgen mit festen Preisen und festem Umfang zu implementieren. Dieses grundlegende Spannungsverhältnis schafft Herausforderungen, auf die Sie kein Zertifizierungskurs vorbereiten kann.

Bei einem Projekt zur digitalen Transformation wurde mein Team beauftragt, eine bestimmte Anzahl von Funktionen zu einem Festpreis zu liefern. Der Kunde wollte eine "agile Lieferung", war aber nicht bereit, den Umfang anzupassen, wenn wir mehr über die Bedürfnisse der Benutzer erfuhren. Wir waren gefangen zwischen vertraglichen Verpflichtungen und agilen Prinzipien.

Hier erfahren Sie, wie Sie dieses Paradoxon überwinden können:

1. Trennen Sie das Geschäftsmodell vom Liefermodell
   → Der Vertrag kann feststehen, aber der Implementierungsansatz kann immer noch iterativ sein
   → Schaffen Sie einen "Umfangspuffer", indem Sie Posten mit niedrigerer Priorität identifizieren, die gehandelt werden könnten

2. Definieren Sie ergebnisorientierte Akzeptanzkriterien
   → Wechseln Sie von "Funktionen bauen" zu "Probleme lösen"
   → Schaffen Sie Raum für Entdeckungen, während Sie die kommerziellen Grenzen wahren

3. Verwenden Sie abgestufte Umfangsklassifizierungen
   → Must-have-Anforderungen (vertraglich bindend)
   → Should-have-Fähigkeiten (Flexibilität bei der Implementierung)
   → Could-have-Erweiterungen (wenn Zeit/Budget es erlauben)

4. Implementierung einer rollierenden Wellenplanung
   → Detaillierung der kurzfristigen Arbeit bei gleichzeitiger Flexibilität der zukünftigen Arbeit
   → Regelmäßige Neupriorisierung innerhalb des Gesamtumfangs

5. Vereinbaren Sie Schwellenwerte für Änderungen
   → Definieren Sie, was eine wesentliche Änderung ist, die eine kommerzielle Anpassung erfordert
   → Schaffen Sie leichtgewichtige Änderungsprozesse für kleinere Anpassungen

Der erfolgreichste Ansatz, den ich verwendet habe, ist, Agile als Strategie zur Risikominderung bei Festpreisprojekten zu betrachten. Indem wir schrittweise liefern und frühzeitig Feedback einholen, verringern wir das Risiko, etwas Falsches zu bauen - ein Vorteil für Kunde und Berater.

Ungeschriebene Regel 3️⃣: Festpreisverträge und Agile Delivery können nebeneinander bestehen, wenn Sie trennen, was fest sein muss (kommerzielle Bedingungen) und was flexibel sein sollte (Implementierungsansatz).

Zeremonien, die wirklich funktionieren: Rituale durchbrechen, um Werte zu schaffen

Agile Zeremonien verkommen oft zu bedeutungslosen Ritualen, die die Teams eher ertragen, als dass sie davon profitieren. Als Berater müssen wir diese Praktiken wiederbeleben, damit sie ihren beabsichtigten Wert entfalten.

Ich kam zu einem Projekt, bei dem die tägliche Besprechung zu einem 40-minütigen Statusbericht für den Projektleiter verkommen war. Die Teammitglieder waren unkonzentriert, prüften während des Gesprächs ihre E-Mails oder betrieben Multitasking. Durch eine Umstrukturierung der Besprechung, bei der es eher um Hindernisse als um Statusmeldungen ging, konnten wir sie auf 12 Minuten verkürzen und die Zusammenarbeit erheblich verbessern.

Hier erfahren Sie, wie Sie die wichtigsten Zeremonien von Ritualen in wertschöpfende Elemente verwandeln können:

Tägliche Stand-ups:

• Konzentrieren Sie sich auf die Blockierung von Problemen, nicht auf Statusberichte
• Verwenden Sie ein physisches oder virtuelles Board als zentralen Punkt, nicht Menschen
• Implementieren Sie den "Walk the Board"-Ansatz anstelle der drei Fragen
• Planen Sie technische Diskussionen unmittelbar nach dem Stand-up, aber getrennt davon

Sprint-Planung:

• Bereiten Sie sich vor der Sitzung vor (Verfeinerung)
• Konzentration auf die Ergebnisse, nicht nur auf die Aufteilung der Aufgaben
• Ausdrückliche Erörterung von Risiken und Abhängigkeiten einbeziehen
• Beenden Sie mit einer Teamverpflichtung, nicht nur mit einem Auftrag

Rezensionen/Demos:

• Machen Sie sie interaktiv, nicht präsentativ
• Konzentration auf den geschäftlichen Nutzen, nicht auf die technische Fertigstellung
• Betroffene Stakeholder einbeziehen, nicht nur den Produktverantwortlichen
• Erfassen Sie systematisch Feedback für Maßnahmen

Rückblicke:

• Variieren Sie das Format, um das Engagement aufrechtzuerhalten
• Konzentration auf umsetzbare Verbesserungen, nicht nur auf Diskussionen
• Verfolgen Sie die Umsetzung früherer Retro-Aktionen
• Schaffen Sie Sicherheit für ehrliche Gespräche

Die effektivsten agilen Teams, mit denen ich gearbeitet habe, behandeln die Zeremonien als Werkzeuge, nicht als Verpflichtungen. Sie passen das Format, die Dauer und die Häufigkeit ständig an die Bedürfnisse des Teams und den Projektkontext an.

Ungeschriebene Regel 4️⃣: Agile Zeremonien dienen dazu, Probleme zu lösen und die Lieferung zu verbessern, und nicht dazu, einem Skript zu folgen. Wenn eine Zeremonie keinen Mehrwert bringt, ändern Sie sie oder lassen Sie sie fallen.

Die Geheimwaffe des Beraters: Inkrementeller Wert in traditionellen Umgebungen

Selbst in den traditionellsten, wasserfallorientierten Kundenumgebungen können wir agile Prinzipien einführen, die unmittelbare Vorteile bringen, ohne dass die Methodik grundlegend geändert werden muss.

Bei der Arbeit mit einem Kunden aus dem Finanzdienstleistungssektor, der an seinem Stage-Gate-Prozess festhielt, gelang es mir dennoch, seinen Ansatz zu verändern, indem ich drei agile Prinzipien einführte, die seine Governance nicht bedrohten:

1. Nachweisbare Inkremente
   → Aufteilung großer Leistungen in kleinere, nachweisbare Teile
   → Schaffung von Überprüfungspunkten innerhalb von Phasen, nicht nur zwischen ihnen

2. Feedback-Schleifen
   → Frühzeitige Einbindung der Endnutzer
   → Erstellung von Mockups und Prototypen zur Validierung vor der vollständigen Entwicklung

3. Sichtbares Workflow-Management
   → Sichtbarmachen von Arbeit und Blockern
   → Sichtbare Verfolgung des tatsächlichen gegenüber dem geplanten Fortschritt

Der Kunde behielt seinen gewohnten Prozess bei und profitierte gleichzeitig von vielen Agile-Vorteilen. Später, als sie den Wert erkannten, waren sie offener für umfassendere Änderungen der Methodik.

Bei einigen meiner erfolgreichsten "agilen Transformationen" wurde das Wort "agil" nie verwendet. Stattdessen habe ich mich auf bestimmte Schmerzpunkte konzentriert:

• "Verringern wir das Risiko von Missverständnissen, indem wir funktionierende Software früher zeigen"
• "Wir können Integrationsprobleme früher erkennen, indem wir die Komponenten schrittweise testen.
• "Ein visuelles Workflow-Board wird uns helfen, Engpässe zu erkennen, bevor sie das Projekt verzögern.

Ungeschriebene Regel 5️⃣: Kämpfen Sie nicht frontal gegen die Methodik des Kunden an, sondern führen Sie die agilen Prinzipien als Lösungen für bestimmte Probleme ein, die sie erkennen.

Das Dilemma der Definition des Erledigten: Qualität vs. Geschwindigkeit

Im agilen Lehrbuch sorgt die Definition of Done dafür, dass Qualität in jedes Inkrement eingebaut wird. In der Realität setzen die Kunden die Teams oft unter Druck, der Geschwindigkeit Vorrang vor der Vollständigkeit zu geben, was zu technischen Schulden und zukünftigen Problemen führt.

Bei einem Projekt eines Einzelhandelskunden führte der Druck, eine Marktfrist einzuhalten, zu einer "das kriegen wir später schon hin"-Mentalität. Sechs Monate später kam das "später" nicht mehr und die angehäuften technischen Schulden hatten die Entwicklungsgeschwindigkeit um 60% reduziert.

Hier erfahren Sie, wie Sie mit dieser Spannung umgehen können:

1. Erstellen Sie eine abgestufte Definition von Erledigt
   → Mindest-DoD für alle Arbeiten (nie gefährdet)
   → Standard-DoD für die meisten Arbeiten (gelegentlich gebogen)
   → Ideal-DoD für kritische Komponenten (wenn es die Zeit erlaubt)

2. Machen Sie technische Schulden sichtbar
   → Verfolgen Sie Abkürzungen explizit als "Schuldengeschichten"
   → Schätzen Sie den Zinssatz (zukünftige Kosten) für jeden Schuldenposten
   → Nehmen Sie Schuldenmetriken in die Berichterstattung auf

3. Erstellen Sie einen Schuldentilgungsplan
   → Weisen Sie einen Prozentsatz jedes Sprints dem Schuldenabbau zu
   → Priorisieren Sie Schulden, die die aktuelle Entwicklung behindern
   → Verbinden Sie die Schuldentilgung mit der Bereitstellung zukünftiger Fähigkeiten

4. Informieren Sie über die wirtschaftlichen Aspekte technischer Schulden
   → Zeigen Sie, wie die anfängliche Geschwindigkeit zu späteren Verlangsamungen führt
   → Quantifizieren Sie die Kosten einer verzögerten Schuldentilgung
   → Demonstrieren Sie die Auswirkungen der Geschwindigkeit anhand von Daten

Der effektivste Ansatz, den ich gefunden habe, ist, die Diskussion von "Qualität vs. Geschwindigkeit" auf "kurzfristige Geschwindigkeit vs. nachhaltige Geschwindigkeit" umzustellen. Damit verlagert sich die Diskussion von einem technischen Problem zu einer geschäftlichen Entscheidung über die langfristige Lieferkapazität.

Ungeschriebene Regel 6️⃣: Kämpfen Sie nie um Qualität in technischer Hinsicht, sondern in wirtschaftlicher Hinsicht, d.h. in Bezug auf nachhaltige Lieferung und Gesamtbetriebskosten.

Verteilte Agilität navigieren: Wenn das Team überall ist

Das Ideal eines agilen Teams, das an einem gemeinsamen Standort arbeitet, gibt es bei Beratungsaufträgen nur selten. Häufiger arbeiten wir mit Teams, die über verschiedene Standorte, Zeitzonen, Organisationen und konkurrierende Prioritäten verteilt sind.

Bei einem globalen Transformationsprogramm erstreckte sich unser Team über vier Länder und sieben Zeitzonen. Der Lehrbuchansatz der täglichen Kommunikation von Angesicht zu Angesicht war unmöglich. Wir mussten unsere agilen Praktiken für die verteilte Realität neu erfinden.

Strategien, die für verteiltes Agile tatsächlich funktionieren:

1. Überkommunizieren Sie visuell
   → Verwenden Sie digitale Kanban-Tafeln mit reichhaltigen Informationen
   → Erstellen Sie Informationsradiatoren, die für alle Standorte zugänglich sind
   → Entwickeln Sie visuelle Statusberichte, die keine Erklärung in Echtzeit erfordern

2. Legen Sie Kernzeiten für die Zusammenarbeit fest
   → Bestimmen Sie Zeitfenster, in denen alle Teammitglieder zusammenarbeiten können
   → Planen Sie wichtige Zeremonien innerhalb dieser Zeitfenster
   → Rotieren Sie die Besprechungszeiten, um die Belastung durch die Zeitzone zu verteilen

3. Schaffen Sie standortbezogene Unterteams
   → Bilden Sie an jedem Standort vollständige, funktionsübergreifende Kapazitäten
   → Minimieren Sie Abhängigkeiten zwischen den Standorten
   → Schaffen Sie lokale Teamleiter, die für die Koordination verantwortlich sind

4. Implementieren Sie asynchrone Zeremonien
   → Zeichnen Sie Demos zum asynchronen Anschauen auf
   → Nutzen Sie digitale Tools für laufenden retrospektiven Input
   → Erstellen Sie Standup-Slacks oder Kanäle für Updates

5. Investieren Sie in den Aufbau von Beziehungen
   → Beginnen Sie Projekte mit virtueller Teambildung
   → Schaffen Sie Gelegenheiten für Verbindungen außerhalb der Arbeit
   → Wenn möglich, bringen Sie Teams an kritischen Punkten physisch zusammen

Die verteilten Teams, die am besten funktionieren, legen klare Protokolle für synchrone und asynchrone Kommunikation fest und machen deutlich, was in Echtzeit diskutiert werden muss und was offline erledigt werden kann.

Ungeschriebene Regel 7️⃣: In verteilten Agile-Teams muss die Kommunikation bewusst gestaltet werden und darf nicht dem Zufall überlassen werden. Was in räumlich getrennten Teams selbstverständlich ist, muss in verteilten Teams explizit strukturiert werden.

Fallstudie: Pragmatische Agilität in einer widerständigen Umgebung

Ich möchte Ihnen ein Beispiel aus der Praxis geben, wie Sie diese Herausforderungen meistern:

Ich leitete ein digitales Transformationsprojekt für ein traditionelles Versicherungsunternehmen mit einer starken Befehls- und Kontrollkultur. Der Hauptsponsor wollte eine agile Umsetzung, aber die Organisation hatte:

• Vierteljährliche Überprüfung der Finanzierung
• Ein detaillierter Business Case mit festem Umfang
• Getrennte Entwicklungs- und Testteams
• Ein schwergewichtiges Kontrollgremium für Änderungen
• Eingeschränkter Benutzerzugang für Feedback

Anstatt Scrum aus dem Lehrbuch zu erzwingen, haben wir einen hybriden Ansatz entwickelt:

1. Wir legten zweiwöchige Entwicklungsiterationen innerhalb von sechswöchigen "Lieferschritten" fest, die mit ihrem Governance-Zyklus übereinstimmten.
2. Wir haben die feste Umfangsgrenze beibehalten, aber Flexibilität bei der Implementierung der Funktionen geschaffen.
3. Wir führten agile Zeremonien mit dem Kernteam durch, übersetzten die Ergebnisse jedoch in die von der Organisation erwartete Governance-Dokumentation
4. Wir haben eine "Benutzer-Vertretungsgruppe" aus internen Interessenvertretern gebildet, wenn die tatsächlichen Benutzer nicht verfügbar waren.
5. Wir haben am Ende jeder zweiwöchigen Iteration eine funktionierende Software vorgeführt, aber nur an den Sechs-Wochen-Grenzen formell geliefert.

Das Ergebnis? Wir lieferten das Projekt erfolgreich ab und, was noch wichtiger war, der Kunde übernahm nach und nach mehr agile Praktiken, als er die Vorteile erkannte. Zwei Jahre später hatte er seinen gesamten Lieferansatz umgestellt - nicht, weil wir auf methodischer Reinheit bestanden, sondern weil wir einen pragmatischen Nutzen zeigten.

Schlussfolgerung: Prinzipien vor Praktiken

Nach Jahren der Implementierung von "Agile" in Umgebungen, die von Startups bis hin zu Regierungsbehörden reichen, bin ich zu einem einfachen Schluss gekommen: Die Prinzipien sind wichtiger als die Praktiken.

Das Agile Manifest stellt "Individuen und Interaktionen über Prozesse und Tools", doch ironischerweise sind viele Agile-Implementierungen von bestimmten Prozessen und Tools besessen. Die erfolgreichsten Agile-Berater, die ich kenne, konzentrieren sich unerbittlich auf die Ergebnisse, die mit Agile erreicht werden sollen:

• Frühzeitige und häufige Bereitstellung von Mehrwert
• Die Kosten des Wandels reduzieren
• Verbesserung der Qualität durch Feedback
• Verbesserung der Zusammenarbeit im Team
• Schaffung eines nachhaltigen Liefertempos

Wenn Sie sich auf diese Ergebnisse und nicht auf methodische Reinheit konzentrieren, können Sie Wege finden, die Vorteile von Agile auch in den traditionellsten Umgebungen zu nutzen.

In der Beratung besteht unsere Aufgabe nicht darin, Agile zu implementieren, sondern unseren Kunden dabei zu helfen, bessere Software auf effektivere Weise zu liefern. Manchmal bedeutet das Scrum wie aus dem Lehrbuch, manchmal bedeutet es eine pragmatische Hybridisierung und manchmal bedeutet es eine subtile Einführung agiler Prinzipien in bestehende Frameworks.

Der Maßstab für den Erfolg ist nicht, wie rein Sie die Methodik umgesetzt haben, sondern ob Sie den Kunden besser in der Lage waren, einen Mehrwert zu liefern, als Sie es bei Ihrer Ankunft waren.

Im nächsten Beitrag dieser Serie werde ich mich mit "Teamgeflüster" beschäftigen: Navigieren durch die menschliche Dynamik, auf die Sie niemand vorbereitet hat" - die ungeschriebenen Regeln für den Umgang mit der komplexen Teamdynamik, die über Ihren Beratungserfolg entscheiden kann.

Bis dahin sollten Sie daran denken, dass Agile ein Mittel zum Zweck ist, kein Selbstzweck. Seien Sie prinzipienfest in Ihren Zielen, aber pragmatisch in Ihrem Ansatz.

Was ist die größte Lücke, die Sie zwischen der agilen Theorie und der Praxis festgestellt haben? Teilen Sie Ihre Erfahrungen unten in den Kommentaren mit!

---

Foto von Medienstürmer auf Unsplash