Agile Transformation in der Praxis

Die Telekom IT (und ihre Vorgänger) hatte einige Jahre einen festen Lieferrhythmus – dreimal im Jahr wurden aufwendig alle Lieferungen koordiniert und getestet. Mehr Geld hat geholfen, mehr zu liefern. Die interne IT stand im Wettbewerb mit externen Lieferanten, auch Konzern-intern gab es Ausschreibungen, Pönale usw. Das Lieferversprechen zu halten, war ein elaborierter Prozess, in [Wal08] sind die Herausforderungen zu erkennen. Das etablierte Anreizsystem führte zu mehr IT-Systemen, Controlling und Abhängigkeiten. Die IT hat sich irgendwann gefragt, wie können wir öfter liefern? Dahinter steckte nicht der Gedanke, wir liefern statt dreimal nun vier- oder gar sechsmal im Jahr, sondern – wie liefern wir 10.000-mal im Jahr? Dazu hat das Managementteam in mehreren Schritten Richtungsentscheidungen getroffen:

• Das IT-Budget ist fest (also hilft der berühmte Lkw vor der Haustür mit Geld nicht mehr),
• Nutzung agiler Methoden (und der Philosophie dahinter, „Das Team entscheidet“),
• gemeinsame Teams zwischen Fachseiten und IT (sog. „Tribes“, „Squads“ s. u.),
• Abschaltung von Tools zum zentralen Anforderungsmanagement, Skilldatenbanken, …,
• massive Fortbildung und
• Stärkung der Testautomatisierung.
• Als Folge gab es zum Beispiel eine Schwächung der Linie („Servant Leadership“).

An dieser Stelle der Transformation entsteht notwendigerweise Orientierungslosigkeit, und Playbooks kommen ins Spiel.

Was ist ein Playbook?

Ein Tribe als Ablauforganisation übernimmt die Kundenperspektive und somit die komplette E2E-Verantwortung für ein Marktprodukt und gegebenenfalls auch für die Prozesse, wie etwa Magenta TV. Diese Form der Zusammenarbeit in gemeinsamen Teams, crossfunktional, unabhängig von der eigenen GmbH, war zunächst für alle Beteiligten ein Stück Forschung, es gab keine Blaupause. Die Zusammenarbeit im Tribe wurde in einem sogenannten „Playbook“ beschrieben. Kasten 1 zeigt die Quelle des Begriffs.

Dieses Grundverständnis hatte uns geholfen. Ein Playbook beschreibt

• Wer sind wir?
• Wo wollen wir hin?
• Wie bringen wir Anforderungen zur IT?
• Nutzen wir agile Methoden wie den Einsatz von „Objectives and Key Results“?
• Wie reihen wir unsere Backlogs?
• Welche Rollen und Rituale haben wir?

Unser Playbook hat mit gut 10 Seiten begonnen und hatte in der Spitze knapp 100 Folien. Das war, um es vorwegzunehmen, viel zu viel.

Die erste Version des Playbooks – MVP

Meine Erfahrung: Die erste Version des Playbooks scheiterte am eigenen Anspruch, alles möglichst präzise beschreiben zu wollen, Standards zu setzen, und gleichzeitig den Teams möglichst viele Freiheitsgrade zu lassen. Viele Beschreibungen von zum Beispiel der Vision, Scrum, Kanban, SAFe (siehe Kasten 2), Jira, Workflows, Rollen, hybriden Modellen und vielem mehr waren erforderlich.

Gleichzeitig startete das Business, das nicht wartet, bis Folien fertig sind. Kaum waren wir zufrieden, gab es die ersten Veränderungen, eine neue Rolle oder ein neues Werkzeug. Mit der Zeit hatte sich auch unser Verständnis verbessert – wir liefen also mit den Folien immer hinterher. Die Lösung war simpel: Wir entfernten alles, was kein Standard war, oder was man einfach nachlesen kann, und haben nur noch die grundlegenden Fragen beantwortet. Gleichzeitig legten wir unser Augenmerk weniger auf das Malen weiterer Folieninhalte, sondern auf deren Erklärung in Gesprächen. Abbildung 1 zeigt einen vereinfachten Ausschnitt aus dem Playbook – bei aller Präzision ist das erklärungsbedürftig. Parallel machten wir klassisches Stakeholder-Management, etwa Suchen eines Sponsors. Und nein, auch wenn wir es als Minimum Viable Product (MVP) vermarktet haben, es war eine Version 1.0.

Eat your own dog food – der umgedrehte kategorische Imperativ

„Was Du nicht willst, das man Dir tu‘ – das füg auch keinem anderen zu“, sollte man umdrehen: „Willst Du Transparenz und Reihung ohne Eigentor – dann leb‘ es vor!“ Wenn wir also in Jira von Portfolio-Epics, ihrer Zerlegung in kleinere Schritte und dem Pull-Prinzip reden, müssen wir das in einer analogen Form genauso machen, mit denselben Spielregeln. Das heißt auch, dass die Kadenz im Playbook mit der Kadenz in den Lieferungen abgestimmt sein muss – Hübe in Prozessen und Tools müssen etwa mit den Planungsrunden der Teams übereinstimmen. Und es muss einem bewusst sein – eine Änderung im Playbook (etwa: Einführung eines neuen Issue-Typs oberhalb von Portfolio-Epics) oder eine Änderung im Business („Wir schieben die Anwendung X von A nach B, weil es den Wertstrom verbessert“) erfordert nicht nur Verständnis, sie erzeugt eventuell auch massive Migrationsarbeit innerhalb der Tools. Letztendlich müssen Enabler-Themen, technische Schulden und Business-Themen alle abgestimmt sein (das ist eine Binsenweisheit, aber dadurch nicht automatisch einfach).

Wer ist der Autor des Playbooks? Welche Rollen hat das Redaktionsteam?

Wir haben mit einem Team zunächst jede Folie selbst erstellt. Im Laufe der Monate hatten wir öfters mit Frust zu kämpfen und unsere Rollen hinterfragt:

• Geben wir die Regeln vor? (Rolle: Gesetzgeber)
• Oder überwachen wir die Einhaltung dieser Regeln? (Rolle: Polizei)
• Kommen wir, wenn es bei der Umsetzung brennt? (Rolle: Feuerwehr)
• Beten wir die Inhalte vor? (Rolle: Evangelist)
• Bestrafen oder belohnen wir? (Rolle: Justiz, Kindergärtnerin)
• Oder machen wir Politik mit? (Rolle: Diplomaten)

Darüber hinaus ist der Umgang mit Spielregeln von Mensch zu Mensch unterschiedlich:

• Ich kann nicht, aber ich will („Wie melde ich mich in Jira an?“) 
• Ich kann, und ich will („So ist das halt, wenn ich das so mache, komme ich am besten durch“)
• Ich kann, aber ich will nicht („Wenn ich jetzt meinen Cost of Delay hochsetze, dann bin ich der Gewinner“)
• Ich kann nicht, und ich will nicht („Bei uns ist alles anders, und außerdem muss ich arbeiten“)

Konstruktives („Kennt Ihr schon dieses Feature, um bei der Definition of Done zu helfen?“) und Destruktives hielten sich zunächst ungefähr die Waage. Die Lösung war ein Rückzug auf eine Coach-Rolle – wir bieten jede Hilfe an, sind aber nicht für den Erfolg und die Umsetzung verantwortlich. Und wenn eine Änderung im Playbook erfolgen soll, dann geschieht das ausschließlich auf Wunsch anderer Leute, oder externer Ereignisse (z. B. Jira-Workflow geändert). Auf den Spruch „Man sollte mal im Playbook …“ ging sofort ein freundliches Hinweisschild hoch – „Dann mache es, wir sorgen nachher für die Integrität“. Das war eine Einladung, aber auch eine Abgrenzung sowie die Chance auf höheren Praxisbezug. Wir hatten zeitweise Sprints von zwei Wochen im Playbook. Das war ein großer Erfolg, hieß aber auch – alle zwei Wochen verändert sich etwas.

Den Wechsel willkommen heißen

Im Change-Management ist das eine zentrale Aussage, und auch wenn sie richtig ist, wer stimmt dem mit vollem Herzen zu? In der Telekom wurde zu den oben genannten Tribes eine weitere Ebene eingeführt, die sich Canvas nennt. Ein Canvas ist eine nach fachlichen Abläufen sortierte Delivery-Einheit (SAFe: Portfolio-Ebene).

Abbildung 2 zeigt den Zusammenhang zwischen Tribes und Canvas-Elementen. Übrigens gibt es in der Praxis interessante Zusatzdimensionen, die hier aber den Rahmen sprengen würden.

Unabhängig vom konkreten Beispiel handelt es sich um einen Change, der gerade eingespielte Teams und Verfahrensweisen massiv verändert. Auf der bekannten Maslowschen Bedürfnispyramide sind davon die unteren beiden Ebenen (Existenz, Sicherheit) nicht betroffen, weil die Sozialpartner deutliche Sicherheitssignale aussprechen („Wir verändern uns, Du musst Dich verändern, aber wenn Du Dich veränderst, bist Du sicher“). Aber ab der mittleren Ebene gerät alles durcheinander. Ein Playbook kann hier Orientierung geben, aber auch zur Verwirrung und Entfremdung beitragen. Hinter dem kleinen oder größeren Change steht aber der Kulturwandel (siehe [Sch99]): Im Laufe der Jahre hat sich eine Telekom IT-Kultur gewandelt von

• Competence (Ich bin anerkannt, wenn ich der beste … bin), über
• Control (Vorhersehbarkeit, wir liefern genau das, koste es, was es wolle), zu einer Mischung aus
• Collaboration (wir gemeinsam) und
• Cultivation (Wir wachsen, wir sind kreativ)

Das sind Changes, die richtig wehtun (oder auch richtig begeistern). Meine persönliche These ist, persönliche Stabilität ist das Fundament von Firmenagilität. Zum kritischen Weiterlesen siehe [Koc18].

Tools und Prozesse

Die Diskussion kennt man – passe ich das Werkzeug den Prozessen an, oder umgekehrt? Unsere Erfahrung war, dass die Playbook-Autoren, die Prozessleute und die „Toolsmiths“ ein Team sein müssen. Alles andere ist akademisch und hilft niemandem. Auch dabei hilft immer, ein Vorbild zu sein. Mit „Vorbild“ ist gemeint, und das passt zum „Eat your own dog food“, die Möglichkeiten der Werkzeuge zu zeigen, ganz selbstverständlich im Alltag, und dann auf die Frage „Wow, Du siehst ja auf einen Blick alle Abhängigkeiten einer Anforderung“ zu zeigen, wie es geht. Seniorität dabei ist übrigens, wenn man nicht zeigt, wie es geht, sondern es den Fragenden selbst machen lässt. An dieser Stelle kommt ein Playbook-Team an seine Kapazitätsgrenzen; wie kann man mehreren Hundert Menschen einzeln helfen? Ein magischer Moment der Arbeit war, als Kollegen vom Playbook begeistert waren und freiwillig Schulungsreihen organisierten. Darüber hinaus gab es Open Calls, Blogs, E-Mails, Teilnahme an Ritualen und vieles mehr. Aber – vieles war trotz allem viel Push, das heißt Informationsangebote aus dem Team heraus. Inzwischen achten wir darauf, dass ein Pull-Prinzip angewendet wird. Hier ist der Trick, zu sagen „Mein Kalender ist gepflegt, nimm Dir gerne 30 Minuten“ und nicht „Ich lade … ein und sage denen, wie sie arbeiten sollen“.

Übrigens war unser Anspruch, dass die Leser des Playbooks kein elaboriertes SAFe-Wissen haben müssen und auch kein Spezial-Jira-Wissen – die Hürden sollten niedrig sein. Gleichzeitig brauchen alle Autoren eines Playbooks ein Gefühl für Sprache (siehe Kasten 3).

In welcher Struktur werden Anforderungen bearbeitet?

Agile Expertise wächst von unten nach oben. In der Telekom IT gibt es seit Ewigkeiten Scrum-Teams und schon einige Jahre ART. Daher ist die Jira-Ebene von Epics/Storys und Kanban/Scrum-Boards gut verstanden. Abbildung 3 zeigt eine vereinfachte Sicht auf die Struktur.

Diese Struktur ist auch ein Beispiel für die Grenzen eines Playbooks – gemeinsame „Schnittstellen“ zwischen Teams müssen gemeinsam abgestimmt sein. Höhere Ebenen machten uns zunächst Probleme: Die oberste Anforderung war ein Portfolio-Epic. Dieses war überfrachtet mit fachlichen und Nutzenaspekten („Business-Hypothese“), die Initiative enthielt den sogenannten Lean Business Case. Hier gab es folgende Probleme:

• Jira ist im Kern ein Workflow-Tool. Fachlichkeit hat auch einen statischen Anteil (die schließt man nicht in Tickets).
• Die fachseitige Ebene oberhalb eines Epics war zu eng, damit war die Komplexität bezüglich Liefereinheiten, Lieferterminen und Zerlegung großer Themen nicht gegeben.

Alle Anforderungsthemen wurden in sogenannte „Business Epics“ verschoben. Dort gibt es laufende Diskussionen, wie viele Ebenen es geben darf (genau eine, genau zwei oder n?). Damit ist Jira rein für die Zerlegung in Teams, Zeitpunkte, Tätigkeiten und das Liefern vorbehalten. Streng genommen gibt es zwei getrennte Werkzeuge, Confluence und Jira, die aber gut zusammenarbeiten. Die erwähnten Migrationsaufwände bleiben bei größeren Änderungen. Aber diese Entkopplung erlaubt notwendige Vielfalt, hybride Methoden und implizit auch das Anerkennen der Leistung von Teams. Struktur ist aber nicht alles, das entspricht der taktischen Aufstellung im Fußball – das Spiel wird ganz verschieden gespielt. Im Folgenden sind die Herausforderungen in der Nutzung von Jira beschrieben.

Jira-Modell und Komplexität

Jira ist total simpel: Im Kern steht der Vorgang, mit definierten Status, zahlreichen Attributen und Beziehungen wie „Eltern/ Kind“, „implementiert“, „blockiert“. Der Vorgang wird durch einen definierten Workflow geschleust. Es gibt dann noch Rollen, Rechte, Suchen, Views, Plug-ins, Benachrichtigungen, Automatisierung, Bildschirmmasken. Und Projekte. Und freie Stichwörter. Boards. Jira ist total kompliziert: Im Kern ist es ein strukturiertes Vererbungsnetz, das heißt, Jira ist mehr als ein Baum oder eine Klassenhierarchie. Durch die strukturelle Tiefe, zeitliche Breite (strategische Themen dauern länger als 2 Jahre), Integration verschiedenster Teams, lokalen Freiheitsgraden sowie Dynamik einer Organisation ist es vielleicht sogar komplex. [Kompl] sagt: „Die Komplexität eines Sachverhaltes wird widergespiegelt durch die Menge der Details, die sich von allen anderen Details des Sachverhalts so unterscheiden, dass es keine vereinfachende Abstraktion gibt, die den Detaillierungsgrad verkleinert. Komplexität wird auch geschaffen durch sich widersprechende Zielsetzungen, Dilemmata und nicht determinierbares Verhalten autonomer Systemeinheiten und ist ein wesentliches Merkmal von sozialen, gesellschaftlichen und kulturellen Systemen.“

Die Telekom ist ein soziales und kulturelles System. Der praktische Ansatz ist, die Freiheitsgrade in Jira einzuschränken, Festlegungen zu treffen und Beispiele zur Verfügung zu stellen. Erweiterungen, wie etwa zusätzliche Attribute zur Portfoliosteuerung, erzeugen zusätzliche Komplexität. Woher weiß man, dass diese Attribute wirklich helfen, und nicht nach 8 Wochen wieder geändert werden? Es gibt zwei Ansätze: Prototypen bauen sowie Beispiele aus der Vergangenheit nachträglich betrachten.

Das Playbook der Playbooks

Wir erinnern uns, jeder Tribe hat ein Playbook (vielleicht heißt es anders, aber die grundsätzlichen Fragen sind überall gleich). Nun haben auch die Canvas ein eigenes Playbook, oder teilen sich eins. Darüber hinaus haben manche ART ein eigenes Playbook, oder die Teams haben aus alten Zeiten Projekthandbücher. Wir ermuntern ja sogar jedes Team, sich selber Spielregeln zu geben und als Team zu lernen („Inspect & Adapt“). Noch mal auf Abbildung 2 geschaut – hier gäbe es in jedem Kasten womöglich mehrere Playbooks. Als Folge hat man Widersprüche und Überlappungen. In der Anfangsphase mussten Product Owner/Manager in verschiedenen Jira-Instanzen wühlen, manche wollten Powerpoint, andere verbaten sich das Ändern eigener Dokumente, andere wiederum wollten das so. Wie viele Playbooks will ich lesen? Man sieht schon das Gesetz von Conway die Zähne fletschen, auf der Suche nach neuen Opfern. An dieser Stelle gibt es einen großen Konflikt:

• Wollen wir, dass sich Teams ihre eigenen Methoden konfektionieren?
• Wollen wir in der Konsequenz, dass sich jedes Team mit allen Partnerteams abstimmt, wie es arbeiten will?
• Wollen wir zentrale Vorgaben?
• Wollen wir gegebenenfalls Prototypen zum Üben und dann klare Ansagen?
• Ist das Team, das diese klaren Ansagen macht, anerkannt?

Die letzte Frage ist die, die aus diesem Experiment nach vorne führt: Es gibt inzwischen dieses anerkannte Team, das sich selbst gegründet hat und in einer offenen Diskussion Aspekte wie Tools, Prozesse, Finanzen usw. klärt. Der Grundgedanke ist weiterhin ein „Orientierung geben“ und kein „Wenn Ihr abweicht, schicken wir Euch automatisierte E-Mails mit Euern Fehlern“. Und ein kleiner Fun Fact am Rande – „die IT will hier dieses komische Jira“ hört man auch weniger.

Was ist noch ungelöst?

Viele Dinge sind inzwischen selbstverständlich – Transparenz, Fokussierung auf Business Value, das Team entscheidet, kürzere Laufzeiten von Anforderungen, Akzeptanz, dass dynamisch neu priorisiert wird. Auch die Berücksichtigung obligatorischer Themen wie der Datenschutzgrundverordnung ist Routine. Der Takt der Telekom hat sich von einem mehr oder weniger starren 3/4 Takt zu einem 4/4 Takt mit polyrhythmischen, jazzigen Einschüben verschoben. SAFe versagt meines Erachtens aktuell bei Priorisierungsfragen in großen Organisationen. Ein Verweis auf WSJF (Weighted Shortest Job First) hilft nicht. Bei der Telekom gibt es inzwischen konzernweite Backlogs, die im Team gereiht werden (!). Hier das Augenmaß zwischen strategischen Themen und minimalen Anpassungen etwa in einem Portal zu finden, ist herausfordernd. Der Kernsatz ist – „Reihung ist immer eine bewusste Willensentscheidung“. Dabei ist das eine Kunststück, alles zu reihen, das andere, zu wissen, was geliefert werden kann. In einer einfachen Welt habe ich einen Anforderer, eine Delivery, die werden sich einig. In einer Matrix-Organisation ist es schwieriger. Praxisbeispiel: Wenn zwei verschiedene ART mit einer gemeinsamen Anforderung im Abstand von 4 Wochen ihre Programm-Inkrementplanung (PIP) vornehmen, ist es erlaubt, dass im zweiten PIP ein Thema abgelehnt (herunterpriorisiert) wird, und damit das erste Team gar nicht anfangen braucht zu bauen. Auch dafür gibt es Lösungen, aber nicht aus dem Lehrbuch. Wie viele Stadthallen und Messezentren möchte man zur selben Zeit belegen? Wie oft möchte sich ein Product Owner klonen? Das hängt mit dem dritten großen Problem zusammen – komplexe Marktprodukte für Geschäftskunden erfordern Lösungen, die an vielen Stellen ansetzen. Auch dafür kann man einiges tun, aber Ansätze wie „Baue nur das MVP“ oder „Schneide den Elefanten klein“ sind schwer zu algorithmisieren. In [SS19] gab es interessante Fallstudien und Praxisberichte, etwa Volvo oder Bosch. Hier ist ein Vergleich mit einem Autohersteller aber schwer, weil das Produkt und die Produktionsstraßen verschieden sind. Und Verantwortung ist sehr verteilt, es gibt Rollen aus Scrum, aus SAFe, aus der Telekom. Letztendlich ist jedes Team verantwortlich für sein Backlog. Die Prüfungsantwort sagt, es ist der Product Owner, aber ich sehe dort das Team/die Teams.

Wann ist das Ende eines lokalen Playbooks erreicht?

Allgemeine Antwort – wenn die Organisation reif genug ist. Konkrete Antwort – wenn die Häufigkeit der Änderungen zurückgeht, und die Inhalte immer weniger werden. Natürlich braucht ein Team Ziele, Inhalte usw. Und natürlich gibt es immer spezielle Situationen, die einzeln gelöst werden. Im Kern sind aber die Fragen „Wie arbeiten wir als kleines Entwicklungsteam?“ oder „Wie tickt ein Team aus Tribes?“ beantwortet. Der Teamgedanke steht auch oberhalb von Menschen und Rollen. Ein Beispiel: Claudio Pizarro, Ailton und Rudi Völler waren Stürmer bei Werder Bremen. Waren die drei gleiche Spielertypen? Nein. Waren sie als Teil eines Teams erfolgreich? Meistens ja. Also ist eine „Rolle“ immer nur eine grobe, nicht hinreichende Annäherung an die Position eines Mitarbeiters im Miteinander.
Fazit: Das Playbook kann geschlossen werden, wenn es keine Dynamik mehr gibt, die Menschen ihre Rollen und Aufgaben gefunden haben, allgemeinere Antworten und speziellere Fragen kommen. Diese kann man wunderbar ohne Folien klären.

Literatur & Links

[Aym21] S. C. Aymans, J. Fahr, Agile und Lean Methoden im Prozessmanagement, in: OBJEKTspektrum, 01/2021

[Koc18] A. Koch, Change mich am Arsch, Econ, 2018

[Kompl] Komplexität, siehe: https://de.wikipedia.org/wiki/Komplexität

[NFL] Playbook, siehe: www.nfl-crush.com/football-erklaert/begriffe/playbook

[SAFe] Scaled Agile Framework 5.1, siehe: https://www.scaledagileframework.com/

[Sch99] W. E. Schneider, The Reengineering Alternative, McGraw-Hill, 1999

[SS19] SAFe Summit 2019, siehe: https://europe2019.safesummit.com/

[UMLgD] UML auf gut Deutsch, siehe: https://www.oose.de/nuetzliches/uml-auf-gut-deutsch/

[Wal08] A. Wallrabe, Ad-hoc-Multiprojektmanagement großer Systemverbünde, in: OBJEKTspektrum 04/2008