Reißbrett-Agilität und Marathons im Sprint. Nicht schon wieder - Teil 2.

Das erste Pattern beschreibt den Versuch, eine agile Organisation mit ihren Werten und Strukturen per Excel, Projektplan und Organigramm zu planen. Ziel ist es, eine trotz des Verständnisses für VUCA-Szenarien (Volatility, Uncertainty, Complexity, Ambiguity) in Zukunft vermeintlich dynamische Organisation eben auf dem Reißbrett zu definieren.

Gründe für ein solches Vorgehen gibt es genügend und diese sind häufig auch valide. Speziell im Zusammenhang mit der Implementierung gegebener skalierender Frameworks wie beispielsweise Nexus, SAFe oder LeSS werden standardisierte Vorgehen genutzt, die sich bewährt haben, aber dann potenziell dem gegebenen Kontext einfach nicht entsprechen.
Aber es gibt gute Gründe für die konzeptionelle Planung: Um potenziellen Widerständen im Zuge strategischer Unternehmensentwicklungen wirksam zu begegnen, müssen sämtliche Entscheidungsträger auf Top-Management-Level ein Bewusstsein für den Change entwickeln. Die Umsetzung der Transformation sollte dann auf einer agilen Herangehensweise basieren: Iterativ und inkrementell.

Wie lange kann es dauern, Scrum in einem Team einzuführen? Oder ein skalierendes Framework in einer IT-Abteilung? Wie lange dauert es, die richtigen Technologien zu erlernen, um schnell Produktinkremente liefern zu können? Wann beginnen die Product Owner wirklich zu „ownen“? Wann wird ein agiles Mindset im Unternehmen gelebt?

Dies sind wichtige und nicht pauschal zu beantwortenden Fragen. Insbesondere, wenn die Absicht besteht, dieses „agil“ möglichst schnell zu etablieren, um die „Vorteile“ in Anspruch nehmen zu können. Das Problem, was an dieser Stelle auftreten kann, ist, dass eben dieser Change-Marathon als Sprint geplant wird. Eine Kultur in einem Unternehmen zu verändern, dauert in etwa fünf Jahre oder mehr. Dabei können zunächst negative Effekte auftreten:

• Effizienzverlust
• Unsicherheiten bei den Mitarbeitern
• Fluktuation
• Gefühlter Kontrollverlust
• Steigende Kosten

Um diese negativen Effekte möglichst gering zu halten, ist es umso wichtiger, vor Beginn des Changes ein Bewusstsein und eine Akzeptanz für eben diesen zu schaffen. Nur so kann die Veränderung erfolgreich umgesetzt werden.

Um die oben genannten Zeiträume einzuordnen, kann auf das Agile Fluency Model zurückgegriffen werden. Annahmen des Models besagen:

1. Die Einführung eines agilen Frameworks (Scrum oder Kanban) in ein Team mit der damit verbundenen Veränderung der Teamkultur beträgt ca. zwei bis sechs Monate. Hierzu gehören unter anderem auch die Anpassungen der Rahmenbedingungen (Teamraum, Vollzeit Teammitglieder, Trainings).
2. Die Ausbildung eines agilen Teams mit der notwendigen Expertise, um konstant in hoher Qualität neue Produktinkremente liefern zu können, kann ca. drei Monate bis zwei Jahre dauern. Die hohe Abweichung begründet sich vor allem im potenziellen Aufbau neuer Infrastrukturen (Deployment Pipelines in der Software Entwicklung) und entsprechender Qualitätsansprüche aus dem Team heraus (DevOps-Verständnis).
3. Die Überarbeitung der in agilen Organisationsstrukturen (sei es von einem Reißbrett oder nicht) und deren Einführung nimmt voraussichtlich einen Zeitraum von ein bis fünf Jahren in Anspruch. Nachdem die vorherigen Stufen erreicht worden sind und die Teams ein agiles Verständnis und notwendige Fähigkeiten erreicht haben. Ab diesem Zeitpunkt kann ein Verständnis für BizDevOps in Betracht gezogen werden. Product Owner, welche ihre Produkte auch wirklich aus der Sicht des Marktes „ownen“ können. Lean Startup könnte auch ein Thema werden.
4. Wenn die Reorganisation stattgefunden und alle Zahnräder ineinander greifen, besteht die Chance, eine selbstlernende, sich konstant restrukturierende Organisation zu schaffen. Es wäre aber unseriös einen Zeitraum zu prognostizieren, ohne den konkreten Kontext betrachtet zu haben.

Das Agile Fluency Model zeigt, dass eine agile Transformation kein Sprint sein kann.

Unabhängig der genannten Muster ist eine agile Transformation aber immer eine gute Idee und im Grunde auch ein Muss für Unternehmen. Diese Auflistung kann hoffentlich in vielen Fällen dabei helfen, dass der Change noch mehr Spaß macht. Fortsetzung folgt…