EvA (Teil 3): Die ETC als Beispiel für eine Top-Down-Einführung – Gemeinsam sind wir stark

Da den theoretischen Grundlagen der Top-Down-Einführung aus dem letzten Teil der Blogserie zur Einführung von Agilität momentan noch eine praktische Komponente fehlt, beschäftigen wir uns in diesem Beitrag mit der ETC, der Enterprise Transition Community.

EvA_Teil 3_Bild 1

Die von Mike Cohn entwickelte ETC hat die Aufgabe, das Unternehmen zu agilisieren, indem sie Hindernisse und Probleme, die die Einführung stören oder verhindern könnten, aufdeckt und beseitigt. Sie wird dabei von mehreren Improvement Communities unterstützt.

In der ETC sollten erfahrene Mitarbeiter aus allen Bereichen des Unternehmens vertreten sein, sowie jeder Mitarbeiter, der direkt von der Einführung betroffen ist oder der aktiv mitwirken möchte. Es gibt keine Mitgliederbeschränkung, die Mitglieder bringen sich abhängig von ihrer Stellung im Unternehmen mehr oder weniger in den Veränderungsprozess ein.[1] Zusammen initiieren und unterstützen sie die Einführung und Etablierung von Scrum.[2] Die ETC hat einen Sponsor, der aus dem Top-Management stammt und von der Einführung von Scrum leidenschaftlich überzeugt ist, damit das Vorhaben ein Erfolg werden kann. Dieser Sponsor fungiert als Product Owner für die ETC und nimmt die Rolle einer Führungskraft ein, jedoch darf er Führung nicht im traditionellen Sinn verstehen, sondern muss eine Führung leben, die auf Unterstützung, Ermutigung und Einfühlvermögen baut.[3]

Die ETC wirkt als Multiplikator für die Einführung und schafft eine Atmosphäre, in der sich neue agile Keimzellen bilden können. Zu diesem Zweck fordert sie alle Mitarbeiter auf, Initiative zur Veränderung zu zeigen[4] und motiviert sie intrinsisch[5], also durch Anerkennung und Möglichkeiten zur Selbstverwirklichung, die ETC zu unterstützen.

Die ETC arbeitet in Sprints wie ein normales Scrum-Team, [6]wobei die Mitglieder meistens nicht Vollzeit für die ETC arbeiten, sondern in den unterschiedlichen Abteilungen teils Schlüsselpositionen haben, in denen sie ebenfalls Verantwortung übernehmen müssen. Die ETC ist für die Identifizierung und Beseitigung von Problemen verantwortlich und erstellt zu diesem Zweck mithilfe aller Mitarbeiter und Teams ein Improvement Backlog, in das alle „Impediments“ (deutsch: Hindernisse, Probleme) und zu ändernden Rahmenbedingungen aufgenommen werden. Bei einer initialen Einführung enthält es grundlegende Punkte, wie «agiles Mindset etablieren» oder «Mitarbeiter motivieren», wohingegen bei einer bereits stattfindenden Umstellung Punkte wie «Ausbau der agilen Community innerhalb des Unternehmens» oder «Prozessverbesserung» stehen.[7]

Konkrete Tasks könnten wie folgt aussehen:

  • „Etablieren eines internen Programms um Scrum-Master auszubilden“
  • „Sammeln und Verbreiten von Scrum-Erfolgsgeschichten im Unternehmen“
  • „Erstellen einer Mitteilung, warum Scrum eingeführt werden soll“[8]

Die folgende Abbildung verdeutlicht den Zusammenhang zwischen der ETC und den ICs [9]:

EvA_Teil 3_Bild 2

Die Einträge im Improvement Backlog werden nun von jeder Abteilung priorisiert und an die Improvement Communities (ICs) weitergegeben.  ICs sind Gruppen von Mitarbeitern, die Aufgaben von der ETC erhalten oder sich selbst Einträge aus dem Improvement Backlog heraussuchen, um ein Problem bei der Umstellung zu Scrum aus dem Weg zu räumen. Sie können, im Gegensatz zu den von der ETC beauftragten ICs, auch spontan entstehen, indem einige Mitarbeiter ein Verbesserungspotenzial identifiziert haben und dieses gemeinsam zu lösen beginnen. Die ICs arbeiten die bevorstehenden Einträge des Improvement Backlogs ebenfalls in iterativem Vorgehen mittels Sprints ab.

Spontan entstandene ICs agieren selbst als Product-Owner, während von der ETC gegründete ICs auch einen Product-Owner aus dem ETC bekommen. Der Sprint der ICs beginnt mit dem Sprint-Planning, in dem der Eintrag aus dem Improvement Backlog der ETC in kleinere Teilaufgaben zerlegt wird und in das Improvement Backlog der ICs übertragen wird.[10] Der oben genannte Punkt „Etablieren eines internen Programms, um Scrum-Master auszubilden“ kann zum Beispiel auf folgende Teilaspekte herunter gebrochen werden:

  • Etablieren eines internen Mentoring-Programms
  • Untersuchen, was intern geschult werden kann
  • Budget für externe Schulungen abschätzen und beantragen[11]

Die Mitglieder der ETC unterstützen die Improvement Communities weiterhin beratend, kommunizieren den Kontext der Einführung an alle Mitarbeiter und stimulieren deren Neugierde auf die bevorstehende Veränderung. Das Verständnis für den Nutzen und die Notwendigkeit von Agilität soll verdeutlicht werden, sodass die Mitarbeiter das Wie und Warum der Umstellung verstehen. Zu guter Letzt ist das ETC außerdem für Kritik, Feedback, Konfliktlösung und Ressourcenplanung verantwortlich.[12]

Der Erfolg der ETC kann an zwei Zahlen abgelesen werden:

  • Die Anzahl der spontan entstandenen ICs
  • Das Verhältnis der spontan entstandenen ICs zur Anzahl aller ICs

Je höher die Zahl die spontanen ICs ist, desto mehr Akzeptanz und Aufmerksamkeit wird der neuen agilen Vorgehensweise entgegengebracht. Noch besser ist es, wenn die Anzahl der spontanen ICs die der vom ETC gegründeten übersteigt, was das eigenmotivierte Interesse an der Umstellung und der daraus resultierenden Veränderung deutlich macht.

Eine ähnliche Herangehensweise haben Ken Schwaber und Jeff Sutherland in ihrem Buch „Software In 30 Days“ wieder aufgegriffen und einige Begriffe angepasst Die Enterprise Transition Community wird zum Transformation Team und die Improvement Communities zu Rollout Teams. Auch hier wird eine Liste mit Hindernissen und Verbesserungsvorschlägen erstellt, welche als Transformation Product Backlog bezeichnet wird. Mit dem Begriff „Scrumming Scrum“ beschreiben sie, dass die Einführung von Agilität selbst agil angegangen werden soll.[13]

In den nächsten Blogbeiträgen möchten wir Ihnen das Modell ETC SOPHISTadvanced vorstellen, in dem wir ein Szenario zur Anwendung des ETC beschreiben. Wir gehen dabei von den Randbedingungen einer Beratungsfirma wie SOPHIST aus, um die reine Theorie mit  konkreten, praktischen Informationen anzureichern.

———————————————————-
Teil 1: Einführung von Agilität (EvA) – Wenn nicht jetzt, wann dann?  
Teil 2: EvA: Die Top-Down-Einführung – Alles Gute kommt von oben 
Teil 4: EvA: EvA mit ETC: Durch die Klippen der agilen See    ———————————————————-



[1] Vgl. Cohn (2010): Cohn, Mike: Succeeding with Agile: Software Development Using Scrum. 1. Auflage, Amsterdam: Pearson Education, 2010, Seite 76f.
[2] Vgl. Ebd., Seite 63f.
[3] Vgl. Ebd., Seite 66f.
[4] Vgl. Ebd., Seite 68f. und 79
[5] Vgl. Seitz (2010): Helmut Seitz: Arbeitsmotivation und Arbeitszufriedenheit – dargestellt am Beispiel operativ und nicht operativ tätiger Krankenhausärzte, 1. Auflage, Wien, facultas.wuv / maudrich, 2010, Seite 29
[6] Vgl. Cohn (2010, Seite 65
[7] Vgl. Ebd., Seite 62f.
[8] Vgl. Ebd., Seite 64 (Tabelle 4.1): Teile aus dem Englischen übersetzt
[9] Angelehnt an Cohn (2010), Seite 71 (Abbildung 4.1).
[10] Vgl. Ebd.,Seite 70f.
[11] Vgl. Ebd., Seite 74f (Tabelle 4.2): Teile aus dem Englischen übersetzt.
[12] Vgl. Ebd., Seite 70f.
[13] Vgl. Schwaber/Sutherland (2012): Ken Schwaber und Jeff Sutherland: Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. 1. Auflage. New York: John Wiley & Sons, 2012, Seite 123ff.

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


5 − drei =

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>