Organisatorische Trägheit - ein Prädiktor für den Erfolg von agilen Transformationen? (Teil 2)

In Teil 1(Organisatorische Trägheit - Teil 1) habe ich mich auf die Frage konzentriert: 'Organisatorische Trägheit - Was ist das?'. In diesem Blog geht es um die Frage 'Wie können wir sie messen?'. Ich beginne mit der Definition von Organisatorischer Trägheit, wie sie in Teil 1 definiert wurde. Dann stelle ich eine Verbindung zu bestehenden Modellen der organisatorischen Trägheit und der Beziehung zu agilen Teams her und zeige, wie die Analogie zur Physik genutzt wird, um ein Maß für die 'Beschleunigung' zu finden. Dann werde ich diese Elemente kombinieren, um eine Möglichkeit zur Messung der Trägheit zu finden. Zum Schluss werde ich einige grundlegende Beispiele anführen.

Definition von organisatorischer Trägheit

In Anlehnung an die Physik habe ich die organisatorische Trägheit in Organisatorische Trägheit - Teil 1 wie folgt definiert:

DEFINITION

Organisatorische Trägheit ist die Fähigkeit einer Organisation, sich zu verändern, nachdem eine Kraft auf sie einwirkt. Konkret definiere ich sie als das Verhältnis zwischen der ausgeübten Kraft und der Geschwindigkeit der organisatorischen Veränderung (Beschleunigung) als Reaktion auf eine ausgeübte Kraft, oder in der Formel "Trägheit (M) = Kraft / Beschleunigung".

Wir haben soeben das Problem der Definition der organisatorischen Trägheit auf die Definition von "einigen angewandten Kräften" und der "Geschwindigkeit der Veränderung" verlagert. In den nächsten Abschnitten finden Sie eine Interpretation dieser Begriffe im Zusammenhang mit agilen Teams und ein Modell zur Beschreibung der "angewandten Kräfte".

Ursprung der Kräfte, die den organisatorischen Wandel vorantreiben: Den Wandel hemmende und den Wandel fördernde Kräfte

Mit der organisatorischen Trägheit sind zwei konkurrierende Kräfte verbunden, die im Trägheitsmodell von Connor & Lake[Con88] beschrieben werden (siehe auch[Kin98]). Dieses Modell beschreibt die Kräfte, die den Wandel hemmen, und die Kräfte, die den Wandel erleichtern.

Das Modell erkennt an, dass es Kräfte gibt, die den Wandel behindern, und dass es Kräfte gibt, die den Wandel erleichtern. Eines der Agile-Prinzipien besteht darin, regelmäßig zu reflektieren, wie Sie vorgehen und sich verbessern. Auf diese Weise verbessern sich agile Teams nicht nur im Laufe der Zeit, sondern sie verändern sich auch. Ein agiles Team, das sich verändert, zwingt die Umgebung, sich mit ihm zu verändern. Ausführlichere Informationen hierzu finden Sie in der 'Fitness-Landschaft'[App11], Kapitel 15 "Wie man alles verbessert". Eine weitere gängige Methode, mit der agile Teams die Umgebung zur Veränderung zwingen, besteht darin, mehr Arbeit hereinzuholen, als die Umgebung liefern kann. Oder indem sie mehr Arbeitssoftware in die Produktion bringen und damit buchstäblich an die Grenzen dessen stoßen, was die Umgebung verarbeiten kann. Der letztgenannte Mechanismus treibt Organisationen zu DevOps[Deb11]. Die Kombination aus der Anwendung von Druck auf die vor- und nachgelagerten Teams ist der Grund für die Notwendigkeit von BusDevOps (Agile Delivery Model), siehe Agile Delivery. Beispiele, die ich in der Praxis häufig sehe, sind, wie agile Teams die Organisation (oder das Umfeld) zu Veränderungen zwingen:

• Eine schnellere Auslieferungsrate zwingt die Umgebung, mehr Releases zu bewältigen, und zwingt gleichzeitig das Unternehmen, mitzuhalten, indem es die User Stories in einem höheren Tempo liefert,
• Hindernisse zu überwinden,
• Das Unternehmen möchte mehr Funktionen, als die IT bereitstellen kann (dies ist oft der Grund für die Notwendigkeit, von einer traditionellen Arbeitsweise zu einer agilen Arbeitsweise überzugehen).

Für eine systemische Sicht auf Ursache und Wirkung im Zusammenhang mit organisatorischer Trägheit siehe z.B.[Lar96].

Wie (agile) Teams den Wandel vorantreiben

Agile Teams verbessern sich ständig. Die Art und Weise, wie sie sich verbessern, unterscheide ich in 3 Typen. Jedem Typ ordne ich eine 'Kraft' zu. Im nächsten Abschnitt werde ich sie im Detail quantifizieren. In Management 3.0[App11] Kapitel 15 "Wie man alles verbessert" wird das Konzept der 'Fitnesslandschaft' erläutert. In dieser Metapher ist das Team Teil der Landschaft (der Umgebung des Teams innerhalb der Organisation), in der das Team eine bestimmte Variable optimiert, zum Beispiel den von ihm geschaffenen Geschäftswert. Das Optimum wird durch den höchsten Berggipfel symbolisiert. Durch Verbesserungen findet das Team seinen Weg zum höchsten Gipfel. Neben teaminternen Veränderungen kann das Team auch die Umgebung verändern und damit die Landschaft verändern, indem es Berge auf das Team zubewegt, anstatt sich auf den Berg zuzubewegen. Dieser Metapher folgend gibt es drei Möglichkeiten für ein Team, den höchsten Gipfel zu erreichen: I) schrittweise Verbesserung (teaminterne Veränderungen), II) große Verbesserungen (kaikaku) und Sprung auf andere (nahe gelegene oder entfernte) Berge, oder III) Veränderung der Umgebung, d.h. Verlagerung der Berge zum Team. Allmähliche Verbesserungen (Änderungen vom Typ I) Agile Teams bewerten regelmäßig, wie sie vorankommen. Eine gängige Praxis ist, alle zwei Wochen eine Retrospektive durchzuführen. In der Retrospektive entscheidet das Team, was geändert werden soll und führt diese Verbesserungen im nächsten Sprint (oder Zeitraum) durch. Mit diesen Verbesserungen wandert das Team die 'Fitnesslandschaft' zum nächsten Berggipfel. Die Verbesserungen können schrittweise und teamintern sein. Damit meinen wir, dass sie die Geschwindigkeit erhöhen und das Umfeld des Teams, d.h. die Organisation, nicht zu einer Veränderung zwingen. Das Team übt keine Kraft auf die Organisation aus. Große Verbesserungen (Typ-II-Änderungen) Es kann auch sein, dass die Verbesserungen innerhalb des Teams entweder die Geschwindigkeit dramatisch erhöhen oder viele schrittweise Verbesserungen die Geschwindigkeit über einen bestimmten Schwellenwert hinaus erhöhen. Wenn dies geschieht - meiner Erfahrung nach ist es keine Frage, ob dies geschieht, sondern eher 'wann' - wird es das direkte Umfeld des Teams zwingen, sich mit zu verändern. Wenn Teams beispielsweise beginnen, User Stories schneller zu liefern, muss das Unternehmen mithalten, indem es genügend User Stories bereithält. Ein anderes Beispiel ist, dass der Betrieb mithalten muss, indem er mehr Funktionen in Produktion bringt. Auf diese Weise übt das Team eine Kraft auf die umgebende Organisation aus, die sich ebenfalls verändern muss. Das Team geht nicht nur durch die "Fitnesslandschaft", sondern zwingt auch die Landschaft, sich zu verändern[App11]. Berge versetzen (Typ III Änderungen) Die dritte Möglichkeit für Teams, eine Kraft anzuwenden, besteht darin, Hindernisse anzusprechen und sich von der Organisation helfen zu lassen, indem die wichtigsten Hindernisse angegangen werden. Durch die strukturelle Lösung von Hindernissen verändert die Organisation die 'Fitnesslandschaft'[App11], indem sie die Berggipfel zum Team verschiebt. Mit 'struktureller Lösung von Hindernissen' meine ich, dass die Lösung der Hindernisse eine Änderung der Unternehmensrichtlinien erfordert.

Die Geschwindigkeit des Wandels in einer Organisation

Der letzte Teil besteht darin, eine Möglichkeit zu haben, die Geschwindigkeit der Veränderung zu messen, während das agile Team eine Kraft auf die Organisation ausübt. Bevor wir diese Frage beantworten können, müssen wir herausfinden, wie wir beobachten können, dass sich eine Organisation verändert. Mögliche Variablen sind:

• den Trend der (durchschnittlichen) Auflösungszeit von Hindernissen,
• Veränderung der Geschwindigkeit, mit der die Funktionen in die Produktion gebracht werden,
• Änderung der Geschwindigkeit, mit der Arbeit an das/die Team(s) übergeben wird,
• Unternehmensrichtlinien werden geändert.

Das könnte eine lange Liste werden. Aber sind all diese Änderungen relevant? Letztendlich ist es das Endergebnis, das zählt. Es geht nur um das Ergebnis. Lassen Sie uns versuchen, Variablen zu finden, die für das Unternehmen von Wert sind. Das kommt dem Endergebnis ziemlich nahe. Zumindest nahe genug. Zu den Variablen, die mir in den Sinn kommen, gehören:

• Änderung der Rate des Geschäftswerts pro Zeiteinheit,
• Veränderung der Geschwindigkeit des (agilen) Reifegrades einer Organisation,
• Veränderung der Rate der Produktvorfälle pro Zeiteinheit.

Dies sind alles Variablen, die gemessen werden können und das (komplexe) Ergebnis der vorgenommenen Änderungen sind. Die Wahl hängt von dem Ziel ab, das Sie mit dem (agilen) Übergang erreichen wollen. Solange dies der Organisation klar kommuniziert wird und die Fortschritte anhand dieser oder jener Variablen gemessen werden, messen Sie die Erfolgsrate und es wird genug Energie in der Organisation vorhanden sein, um den Übergang fortzusetzen und zu verhindern, dass die organisatorische Schwerkraft einsetzt.

Metriken für organisatorische Trägheit

Aus den vorgenannten Beispielen erkennen wir die folgenden Metriken für die 'Kräfte' (Change Facilitating):

• [F1] die Anzahl der erhobenen Hindernisse pro Zeitraum, z.B. pro Sprint oder pro Monat, Force = <Anzahl der erhobenen Hindernisse pro Zeitraum>,
• [F2] Unterschied in der Rate (Durchsatz) für die Teile vor dem Sprint, im Sprint und nach dem Sprint in einem sogenannten kumulativen Flussdiagramm, Kraft [F2a] = <Gelieferter Geschäftswert in der Produktion pro Periode> - <Arbeit nach DoR Wert des Geschäftswertes pro Periode>, oder Kraft [F2b] = <In die Produktion gelieferter Geschäftswert pro Periode> - <Abgeschlossene Arbeiten gemäß DoD Geschäftswert pro Periode>

Force [F2a] misst die "Stärke", mit der das (Scrum-)Team dem Product Owner Arbeit abnimmt. Ein positiver Wert bedeutet, dass der PO nicht mit dem Team mithalten kann. Force [F2b] ist ähnlich für die Interaktion zwischen IT-Ops und (Scrum)-Team. Positive Werte zeigen an, dass das (Scrum) Team die Arbeit für die Produktion schneller vorantreibt, als die Organisation in der Lage ist, sie in die Produktion zu übernehmen. Die zugehörigen Metriken zur Messung der 'Beschleunigung' (Geschwindigkeit der Veränderung) sind:

• [A1] die Entwicklung der durchschnittlichen Anzahl der behobenen Hindernisse pro Zeitraum; zählen Sie nur die behobenen Hindernisse, die Änderungen der Unternehmensrichtlinien erforderten, Beschleunigung = Î"(<Anzahl der behobenen Hindernisse pro Zeitraum>)/<Zeitraum>,
• [A2] der Trend oder die Veränderung der Rate des gelieferten Geschäftswerts (Ergebnis) pro Zeitperiode, Acceleration = Î"(<Business Value Delivered in Production per Period>)/<Period>.

Die soeben genannten Metriken sind für Scrum-Teams leicht verfügbar und können problemlos auf jedes Team, jede Art von Kanban-System oder jeden Teil des gesamten Wertstroms angewendet werden.

Alles zusammenfügen

Anhand der Ergebnisse des vorherigen Abschnitts quantifiziere ich die organisatorische Trägheit in Form von messbaren Variablen, die (agilen) Teams zur Verfügung stehen. Allmähliche interne Verbesserungen, die das Team vornimmt (Änderungen vom Typ I), führen nach einer gewissen Zeit oft zu Änderungen vom Typ II. Daher gehe ich explizit nur auf Änderungen vom Typ II und Typ III ein (wie bereits erläutert). Versetzen wir die Berge? (Typ II Änderungen) Ausgehend von den veränderungsfördernden Kräften wird die organisatorische Trägheit wie folgt abgeleitet. Betrachten wir zunächst die Metrik für die Trägheit (( Mmathrm{org} )) auf der Grundlage des Geschäftswertes, d.h. [F2b] und [A2] aus dem vorherigen Abschnitt. Kombiniert man diese, erhält man: [ langletext{Wert geliefert pro Periode}Bereich - langletext{Wert bereit (DoD) pro Periode}Bereich = M mathrm{org}timesDelta(langletext{Wert geliefert pro Periode}rangle)/langletext{Period}rangle ] Was sagt uns diese Formel?

• wenn die Lieferrate des Teams die Produktionsrate der Organisation ausgleicht, wird keine Kraft ausgeübt und die Organisation wird nicht gezwungen, sich zu ändern; dann gibt es auch keine Änderung (Î") der Lieferrate,
• Wenn das Team mehr Funktionen liefert, als die Organisation in Produktion nehmen kann, übt das Team eine gewisse Kraft auf die Organisation aus, die strukturelle Verbesserungen vornehmen muss, was zu einer positiven Veränderung (Î") der Lieferrate führt,
• für kleine Werte der Trägheit (( M_mathrm{org} )) ist die Auswirkung auf die Änderung der Fördermenge größer.

Hinweis: Eine Maßeinheit für ( M_mathrm{org} ) ist "Zeit", z.B. "Wochen" oder "Sprints" für Scrum-Teams. Beispiel 1. Nehmen wir an, dass das Team in jedem Sprint 5 % mehr Geschäftswert liefert. Nehmen wir weiter an, dass das Team 20% des Wertes schneller liefert, als es in die Produktion gehen kann. Dann beträgt die Trägheit '4 Sprints' (20% geteilt durch 5%). Beispiel 2. Angenommen, es wird keine Veränderung der Rate des gelieferten Geschäftswerts gemessen. Dann ist die organisatorische Trägheit unendlich groß; unter einer veränderungsfördernden Kraft ändert sie sich nicht.

[caption id="attachment_12295" align="alignright" width="336"] Die Auswirkung von organisatorischer Trägheit auf den erzielten Geschäftswert[/caption]

Beispiel 3. Nehmen wir eine Trägheit von '4 Sprints' an (Beispiel 1). Nehmen wir weiter an, dass das Team pro Sprint 20 % mehr Funktionen einbringt, als in die Produktion aufgenommen werden können. Dann braucht es (M mathrm{org})/20% = 20 Sprints zur Verdoppelung der Produktionsrate. Beispiel 4. Wie im vorherigen Beispiel zeigt das Diagramm auf der rechten Seite dasselbe Team, aber in einer Umgebung, in der die Trägheit doppelt so groß ist wie in der anderen Umgebung. Das Team in der Umgebung mit der geringsten Trägheit liefert einen doppelt so hohen Wert wie das andere Team. Dies führt dazu, dass doppelt so viel Geschäftswert generiert wird. Bewegen sich die Berge? (Typ III Veränderungen) Eine andere Möglichkeit besteht darin, die Hindernisse als Grundlage für die Definition und Messung der organisatorischen Trägheit (( Mmathrm{org} )): [ M_mathrm{org} = frac{F_1}{A_1} = frac{langletext{Anzahl der aufgetretenen Hindernisse pro Periode}rangle}{Delta(langletext{Anzahl der aufgelösten Hindernisse pro Periode}rangle)/langletext{Period}rangle} ] Hinweis: Es sollten nur Hindernisse berücksichtigt werden, die tatsächlich zu Veränderungen in der Organisation führen. Hinweis: Dies kann auch in Form von Geschäftswert ausgedrückt werden, indem Sie abschätzen, wie viel mehr Geschäftswert das Team in die Produktion einbringen könnte, wenn das Hindernis beseitigt wird. Hinweis: Die Maßeinheit ist "Zeit", z.B. "Wochen" oder "Sprints".

Fazit

Organisatorische Trägheit ergänzt das Konzept der Organisatorischen Schwerkraft und ist ein Indikator dafür, wie gut das Umfeld des Teams das Wachstum des Teams fördert. Die beiden gegensätzlichen Antriebskräfte für die Geschwindigkeit des organisatorischen Wandels sind die veränderungshemmenden und die veränderungsfördernden Kräfte. Ein Indikator, der agilen Teams für die veränderungshemmenden Kräfte zur Verfügung steht, ist die durchschnittliche Anzahl der gelösten Hindernisse pro Zeitperiode. Veränderungsfördernde Kräfte sind die Kräfte, die Teams auf ihre Umgebung ausüben. Ein Indikator, der agilen Teams zur Verfügung steht, ist das Ausmaß, in dem sie vom Unternehmen mehr fertige Funktionen verlangen und die fertiggestellte Arbeit in die Produktion bringen. Wenn man die aus der Physik bekannte Formel ( F=M A ) im Sinne der veränderungshemmenden und veränderungsfördernden Kräfte interpretiert, wie sie im Modell für organisatorische Trägheit von Connor und Lake[Con88] definiert sind, und (M) mit ( M_{textrm{org}} ) werden Ausdrücke für die organisatorische Trägheit abgeleitet. Sobald die Trägheit der Organisation bekannt ist, kann dies als Vorhersage dienen, wie lange es dauern wird, die Lieferrate der Organisation um einen bestimmten Betrag zu erhöhen, und steht im Zusammenhang mit dem Business Case von Agile Transformations.

Referenzen

[App11]	Management 3.0, Jurgen Appelo, 2011, Pearson Education,
[Deb11]	Devops: A Software Revolution in the Making, Patrick Debois, August 2011, Cutter IT Journal, Vol. 24, No. 8, https://www.cutter.com/promotions/itj1108/itj1108.pdf,
[Con88]	Managing organization change, P.E. Connor & L.K. Lake, 1988, New York: Praeger,
[Kin98]	The development of an instrument for measuring organisational inertia, C Kinnear, G Roodt, Journal of Industrial Psychology, 1998, 24(2), 44-54; siehe https://ujdigispace.uj.ac.za/handle/10210/1047,
[Lar96]	The Dynamics of Organisational Inertia, Survival and Change, Erik R. Larsen, Alessandro Lomi, 1996, System Dynamics conference, https://www.systemdynamics.org/conferences/1996/proceed/papers/larse308.pdf