In Kürze: Die Bedeutung von Agilität
Was wäre, wenn die mangelnde Agilität Ihres Unternehmens nicht auf ein Implementierungsproblem zurückzuführen ist, sondern auf fehlende Voraussetzungen, die beispielsweise durch die Umstellung auf ein Produktbetriebsmodell auch nicht behoben werden können?
Dieser Artikel identifiziert die Erfolgsfaktoren für Agilität, die in Ihrem Unternehmen fehlen. Er bietet Ihnen konkrete Maßnahmen, die Sie am Montagmorgen umsetzen können, um zu prüfen, was Sie in Ihrem Einflussbereich an Veränderungen vorantreiben können. Denn in einer komplexen, von Unsicherheiten geprägten Welt ist Agilität mehr denn je von entscheidender Bedeutung für den Erfolg einer Organisation.
Fühlt sich Agilität in Ihrem Unternehmen so an?
Lassen Sie mich raten: Sie haben die Schulung absolviert. Sie kennen die „Zeremonien”. Ihr Unternehmen bezeichnet sich stolz als „agil”, während jede wichtige Entscheidung drei Ebenen über Ihnen getroffen wird. Ihre Retrospektiven generieren Aktionselemente, die regelmäßig im Managementtheater untergehen. Ihre Daily Scrums sind Statusberichte für Personen, die nie erscheinen. Die Produkt-Roadmap wurde festgelegt, bevor Ihr Team überhaupt existierte.
Nun ist jemand begeistert von der Einführung eines „Produktbetriebsmodells”. Andere Bezeichnung, gleiche Vorgehensweise.
Kommt Ihnen das bekannt vor?
Ist Ihnen aufgefallen, dass Sie agile Rituale praktizieren, ohne dass die Voraussetzungen dafür gegeben sind, dass sie sinnvoll sind? Das ist nicht Ihr Problem, sondern ein Problem der Systemgestaltung.
Ihr Unternehmen hat die Rituale aus dem agilen Framework Ihrer Wahl extrahiert. Bestenfalls wurde dabei der grundlegenden Zweck dieser Ereignisse ignoriert, wahrscheinlich aber implizit abgelehnt. („Wir brauchen das nicht; wir machen das hier anders.“)
Lassen Sie uns herausfinden, was nicht funktioniert, warum das wichtig ist und was Sie tatsächlich dagegen tun können, ohne auf das Einsehen der Führungskräfte zu warten oder zum nächsten angesagten Trend im Bereich Agilität zu wechseln: dem Produktbetriebsmodell oder "product operating model".
Warum Agilität wichtig ist und wozu sie tatsächlich dient
Lassen Sie die Frameworks beiseite. Agile Praktiken lösen ein Problem: Wie können Sie einen Mehrwert schaffen, wenn Sie nicht im Voraus alle Bedürfnisse Ihrer Kunden kennen?
Das ist alles. Nicht „Wie können wir bessere Meetings abhalten?“ oder „Wie können wir uns stärker eingebunden fühlen?“ oder „Wie können wir die Entscheidungsfindung demokratisieren?“. Die Frage lautet: Wie können wir effektiv arbeiten, wenn Unsicherheit Teil der Arbeit selbst ist?
Benutzer wissen oftmals erst, was sie benötigen, wenn sie sehen, dass es funktioniert. Technische Lösungen offenbaren Einschränkungen während der Implementierung. Anforderungen ändern sich während der Entwicklung. Durch die Integration werden Dinge zunichte gemacht, die isoliert betrachtet gut aussahen. Diese Phänomene sind kein Versagen der Planung, sondern liegen in der Natur einer komplexen Produktentwicklung.
Agile Praktiken sind Instrumente zur Risikominderung in unsicheren Umgebungen. Das Ziel besteht nicht darin, Unsicherheiten zu beseitigen (unmöglich) oder schneller zu entwickeln (wünschenswert, aber zweitrangig). Das Ziel besteht darin, Unsicherheiten zu erkennen und darauf zu reagieren, bevor Sie Monate damit verbringen, das Falsche zu entwickeln.
Die drei Fragen, die wirklich wichtig sind
Begrenztes Budget. Unbegrenzte Anforderungen. Jede Entscheidung ist ein Kompromiss mit Opportunitätskosten: Die Ressourcen, die wir hier einsetzen, können wir dort nicht ein zweites Mal verwenden.
Agile Praktiken dienen dazu, drei Fragen schnell und kostengünstig zu beantworten:
- Lösen wir das richtige Problem?
- Lösen wir es auf die richtige Weise?
- Ist dies das Wertvollste, woran wir derzeit arbeiten könnten?
Traditionelle Ansätze versuchen, diese Fragen nach sechs Monaten zu beantworten, wenn die Ergebnisse in einer großen Zeremonie präsentiert werden. Agile Praktiken beantworten sie bei jedem Sprint, mit jeder Veröffentlichung, manchmal sogar täglich.
Wenn die Antworten auf alle drei Fragen bereits vor Beginn der Teamarbeit festgelegt wurden, was entwickelt wird, wann es ausgeliefert wird und wie der Erfolg gemessen wird, dann sind diese Fragen für Ihre tägliche Arbeit irrelevant.
Sie praktizieren dann nicht Agile, was in Ordnung ist, da wir nicht dafür bezahlt werden, „Agile“ zu praktizieren, sondern die Probleme unserer Kunden innerhalb der vorgegebenen Rahmenbedingungen zu lösen und gleichzeitig zur Nachhaltigkeit des Unternehmens beizutragen. Was Sie praktizieren, ist viel schlimmer: Sie führen Agile Theater in einer Feature-Fabrik auf. Das ist eine Folge des Systemdesigns, kein persönliches Versagen.
Warum Ihre „Zeremonien” sich wie Theater anfühlen
Retrospektiven wirken wie ein Theaterstück, wenn Sie das Gelernte nicht umsetzen können. Sprint-Planungen werden zu Theater, wenn die Produkt-Roadmap und das Produktziel an anderer Stelle festgelegt werden. Daily Scrums werden zu Statusberichten, wenn niemand dem Team zutraut, Entscheidungen zu treffen.
Dieser Effekt entsteht nicht, weil Sie beispielsweise Scrum „falsch” anwenden. Er entsteht, weil die Bedingungen, die Scrum wertvoll machen, nicht gegeben sind.
Was tatsächliche Agilität erfordert
Agilität, also die Fähigkeit, schneller als die Konkurrenz zu lernen und diesen Vorteil in überlegene Produkte und Dienstleistungen umzusetzen, erfordert die Abstimmung der Fähigkeiten auf drei Ebenen:
Organisatorische Ebene:
- Teams mit unbedingten Entscheidungsbefugnissen (kein „Empowerment-Theater”).
- Eine Führung, die Kontext und Rahmenbedingungen vorgibt, aber keine vorbestimmten Lösungen.
- Budgets, die für Ergebnisse und nicht für Feature-Listen bereitgestellt werden.
- Toleranz für das Lernen aus Fehlern.
- Zugang zu tatsächlichen Kunden oder Anwendern.
Teamebene:
- Klare Ziele und Grenzen (das „Warum” und die Einschränkungen).
- Autonomie beim „Wie”.
- Informationen und Ressourcen für die Entscheidungsfindung.
- Psychologische Sicherheit, um Probleme anzusprechen.
- Gemeinsames Verständnis von „Done“ und Qualität.
Ebene des Einzelnen:
- Verantwortung für Ergebnisse, nicht bloße Aufgabenerfüllung.
- Fokus auf Wertschöpfung, nicht auf Aktivismus.
- Bereitschaft zu lernen und sich anzupassen.
- Team-Erfolg vor persönlicher Heldentat.
- Komfort mit Unsicherheit.
Zählen Sie einmal, wie viele dieser Punkte in Ihrer Organisation vorhanden sind. Seien Sie ehrlich mit sich selbst, denn Agilität ist wichtig.
Beachten Sie in Folge die Zusammenhänge: Wenn organisatorische Autonomie fehlt, wird die Sprint-Planung zu einer Farce, da Entscheidungen an anderer Stelle getroffen werden. Wenn psychologische Sicherheit fehlt, führen Retrospektiven zu harmlosen, aber bedeutungslosen Aktionspunkten. Wenn Erfolgskennzahlen eher Aktivitäten als Ergebnisse belohnen, optimieren die Menschen ihr Verhalten, um auf die Führungsebene beschäftigt zu wirken.
Diese Dysfunktion ist kein Zufall. Sie ist das vorhersehbare Ergebnis fehlender Erfolgsfaktoren. Die „Zeremonien” können nicht funktionieren, weil die Voraussetzungen dafür nicht gegeben sind; sie werden folglich nie zu bedeutungsvollen Ereignissen führen.
Die Falle des Product Operating Modells
Wenn die Voraussetzungen für Agilität nicht gegeben sind, lassen sie sich durch die Umbenennung von Rollen und die Umstrukturierung von Teams nicht schaffen. Sie werden dafür bezahlt, Kundenprobleme innerhalb der organisatorischen Grenzen zu lösen. Ob Sie dabei Scrum, SAFe, ein „Produktbetriebsmodell“ oder Haftnotizen an der Wand verwenden, spielt keine Rolle.
Was zählt: Können Teams lernen, was Kunden benötigen? Können die Teams auf der Grundlage dieser Erkenntnisse Entscheidungen treffen? Können sie Wertschöpfung über vorab festgelegte Funktionslisten Dritter stellen? Haben sie Zugang zu den Ressourcen und Informationen, die sie für die Umsetzung benötigen?
Wenn diese Voraussetzungen unter Ihrer aktuellen „agilen Transformation” nicht gegeben sind, werden sie auch nicht dadurch geschaffen, dass Projektmanager in „Produktmanager” umbenannt oder Teams als „Produktteams” bezeichnet werden. Das ist „product washing“: neue Visitenkarten, gleiche Funktionsstörungen.
Ein Produktbetriebsmodell wird nur dann Realität, wenn das Unternehmen Entscheidungsrechte, Budgetverteilung, Erfolgskennzahlen und Führungsverhalten gemeinsam ändert. Ohne diese Änderungen ist es nur eine weitere theatralische Darbietung. Und davon hatten wir in der Vergangenheit bereits genug.
Wie man beginnt, wenn Agilität wichtig ist
Sie sind nicht ohnmächtig. Sie können innerhalb Ihres Einflussbereichs handeln. Das reicht oft aus, um etwas zu beginnen. Der Teufelskreis basiert auf erlernter Hilflosigkeit. Um ihn zu durchbrechen, ist kein Transformationsprogramm erforderlich, sondern nur ein Schritt, den Sie ohne Erlaubnis tun können:
Wenn Sie ein Teammitglied sind:
Montag: Entscheiden Sie sich zwischen zwei technischen Ansätzen, ohne um Erlaubnis zu bitten. Dokumentieren Sie Ihre Überlegungen. Beobachten Sie, was passiert.
Was Sie testen: Benötigen Sie tatsächlich eine Genehmigung für technische Entscheidungen oder sind Sie lediglich daran gewöhnt, um Erlaubnis zu ersuchen?
Wenn Sie Scrum Master oder Agile Coach sind:
Diese Woche: Sagen Sie einen Event ab, bei welchem regelmäßig keine Entscheidungen getroffen und keine neuen Erkenntnisse gewonnen werden. Ersetzen Sie diesen nicht. Erläutern Sie Ihrem Team die Gründe dafür.
Was Sie testen: Dient die Veranstaltung der Arbeit oder nur der Performance oder dem Bedürfnis, sichtbar beschäftigt zu sein?
Wenn Sie Manager sind:
Morgen: Wählen Sie eine Genehmigung aus, die Sie kontrollieren. Geben Sie die Entscheidungskriterien an das Team weiter, anstatt die Entscheidung selbst zu treffen. Lassen Sie das Team entscheiden.
Was Sie testen: Ermöglichen klare Vorgaben Autonomie? (In der Regel ist dies der Fall.)
Wenn Sie dies konsequent tun, schaffen Sie Beweise dafür, dass Autonomie kein Chaos verursacht, dass Menschen, die näher an der Arbeit sind, bessere Entscheidungen treffen und dass Vertrauen, wenn es gegeben wird, verdient wird.
Lassen Sie uns nun wiederholen, was Agilität ist: die Fähigkeit der Organisation verbessern, schneller zu lernen, als sich die Einschränkungen ändern. Finden Sie heraus, was es wert ist, für die Kunden gebaut zu werden, bevor Sie sechs Monate mit der falschen Sache verbringen.
Wenn Sie kleine Räume schaffen, in denen Menschen echte Entscheidungen treffen, tatsächliche Annahmen testen und aus der Realität lernen, haben Sie etwas Nützliches begonnen. Möglicherweise verbreitet es sich nicht über Ihr Team hinaus. Ihre Organisation ist möglicherweise noch nicht bereit. Aber Sie werden echte Probleme lösen, anstatt nur eine „agile Methodik” anzuwenden.
Wenn das nächste Framework kommt (und das wird es), fragen Sie sich: Welche Voraussetzungen sind dafür erforderlich? Sind diese Voraussetzungen hier gegeben? Können wir diese alternativ erschaffen? Wenn nicht, was geben wir dann vor zu erreichen?
Diese Klarheit ist wertvoller als jede Zertifizierung.
Fazit
Agile Praktiken sind nicht erfolgreich, wenn die organisatorischen Voraussetzungen für Lernen nicht gegeben sind. Dies lässt sich nicht durch bessere Veranstaltungen oder durch die Übertragung dieser Dysfunktion auf ein Produktbetriebsmodell beheben, in der Hoffnung auf bessere Ergebnisse.
Sie können jedoch innerhalb Ihres Einflussbereichs handeln, Beweise dafür liefern, dass Autonomie funktioniert, und aufhören, einfach die Methodik anderer zu übernehmen. Wählen Sie eine Maßnahme aus diesem Artikel aus und führen Sie das Experiment diese Woche durch. Wenn es funktioniert, wiederholen Sie es. Wenn nicht, haben Sie etwas Wertvolles über Ihre Einschränkungen gelernt. In jedem Fall haben Sie ein echtes Problem gelöst, anstatt auf das nächste Transformationsprogramm zu warten, das Sie erlösen soll.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 40.000 Abonnenten anschließen.