Reißbrett-Agilität und Marathons im Sprint.

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

Meine langjährige Berufserfahrung als Agile Coach und die damit gewonnen Erkenntnisse inspirierten mich vor kurzem einen ersten Artikel über typische, musterhafte Herausforderungen bei agilen Transformationen (Antipattern) zu schreiben. Diese Reihe wird nun um zwei weitere Muster ergänzt. Das erste Muster beschreibt die sogenannte „Reißbrett-Agilität“ – eine agile Organisation, die vorab im Elfenbeinturm geplant wurde. Das zweite Muster entspricht der Vorstellung eines „Marathons im Sprint“. Dies bedeutet, dass eine agile Transformation vermeintlich im Schnelldurchlauf vollzogen werden kann. Die Bezeichnung der Muster entspricht keiner (semi-)offiziellen Terminologie, sondern entstammt allein meinen eigenen Erfahrungswerten.

“Reißbrett-Agilität”

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.

„Ein Marathon im Sprint“

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.

Agile Fluency Model

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…

Artikel von:
Peter Kalvelage, Management Consultant, Cassini Consulting AG
Peter Kalvelage
Management Consultant
Seite teilen

Weitere Inhalte zum Thema Agilität

Video

Cassini Webinar: Agile Organisation: Skalierungsvorhaben erfolgreich gestalten

Sie wollen Ihre Projekte agil skalieren oder sogar ganze Organisationseinheiten agil transformieren? In diesem Webinar geben wir Ihnen eine Hilfestellung aus Praxistipps und Erfahrungswerten aus aktuellen und früheren Projekten von Cassini Consulting, mit der Sie grundlegende Fehler in Ihrem Projekt vermeiden werden.

Newsletter Cassini

Newsletteranmeldung

Sie möchten regelmäßig die neuesten Informationen zum Thema Digitalisierung und digitale Transformation erhalten und über spannende neue Jobangebote informiert werden?
Melden Sie sich kostenlos für unseren Newsletter an.


Ja, ich möchte den regelmäßigen Newsletter von Cassini erhalten. Weitere Informationen finden Sie in unseren Datenschutzbestimmungen.

*Pflichtangaben