Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
Um große Unternehmen in sich schnell verändernden Märkten anpassungsfähig zu halten, hat sich der Ansatz von SAFe®, dem Scaled Agile Framework, sehr bewährt. Hierbei werden die wichtigsten agilen Frameworks wie Scrum, Kanban, Lean und Agile kombiniert, was sich zunehmender Beliebtheit erfreut.
In diesem Buch erfahren Sie, wie Sie SAFe® in großen Unternehmen erfolgreich einführen. Dabei geht der Autor Jan Ahrend insbesondere auf die wichtigsten Rollen der einzelnen Akteure im Zusammenspiel ein.
Darüber hinaus erhalten Sie ebenso Einblick in typische Muster des Scheiterns, die in direktem Zusammenhang mit der deutschen Kultur und der Organisationsstruktur in Großunternehmen stehen.
Der Autor richtet sich sowohl an Berater und Führungskräfte als auch an Mitarbeiter in einem agilen Unternehmen.
Nutzen Sie dieses Buch wie einen Reiseführer zu einer erfolgreichen SAFe®-Einführung.
Aus dem Inhalt:Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 142
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Jan Ahrend
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN 978-3-7475-0744-5 1. Auflage 2023
www.mitp.de E-Mail: [email protected] Telefon: +49 7953 / 7189 - 079 Telefax: +49 7953 / 7189 - 082
© 2023 mitp Verlags GmbH & Co. KG
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Dieses E-Book verwendet das EPUB-Format und ist optimiert für die Nutzung mit Apple Books auf dem iPad von Apple. Bei der Verwendung von anderen Readern kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des E-Books das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine E-Books vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die E-Books mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert. Bei Kauf in anderen E-Book-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Lektorat: Katja Völpel Sprachkorrektorat: Petra Heubach-Erdmann Covergestaltung: Christian Kalkert Bildnachweis: Smile Studio AP/stock.adobe.com Satz: III-satz, Kiel, www.drei-satz.deelectronic publication: III-satz, Kiel, www.drei-satz.de
Unternehmen agilisieren sich, um in schnell ändernden Marktumfeldern besser handlungsfähig zu werden. Das liegt im Trend der Zeit. Ein sehr erfolgreiches Modell dazu ist SAFe®, Scaled Agile Framework. Besonders in Deutschland erfreut es sich zunehmender Beliebtheit. Es ist gut dokumentiert und standardisiert. Trainings und Berater sind zertifiziert und erfahren. Aktuell gibt es über 15 verschiedene standardisierte Kurse und eine Community-Plattform für Best Practice und Templates. Viele Workshops sind vorbereitet und stehen zum Download bereit. Wozu also ein Buch zum Thema SAFe®? Genau die Fülle an Best Practice, Schulungen und Workshops hat sich in der Praxis für viele Kunden und Berater als Problem erwiesen. Sie sehen sprichwörtlich den Wald vor lauter Bäumen nicht mehr. Hier wird es um die Reise zu SAFe® und um die Transformation von Organisationen gehen. Die Vorteile von SAFe®, um deren Willen es eingeführt wird, sind als Navigations-Rose auf der SAFe® Implementation Roadmap dargestellt.
Business-Ergebnisse:
30–75% schnellere Time-to-Market
25–75% bessere Qualität
20–50% erhöhter Produktivität
10–50% mehr Engagement der Mitarbeiter
Diese Ergebnisse sind belegt und zeigen das Potenzial auf. Sie sind jedoch keinesfalls garantiert. Sie lassen sich nur erreichen, wenn das Modell auch vollständig und korrekt eingeführt wurde. Die SAFe® Implementation Roadmap zeigt den Ablauf der Transformation einer Organisation auf. Diese Roadmap wird auch der rote Faden für dieses Buch sein. Neben der Beschreibung, wie es richtig geht, werden in diesem Buch Muster des Scheiterns aufgezeigt. Diese Muster haben sich in diversen Implementierungen und Unternehmen im deutschsprachigen Raum gezeigt. Viele dieser Muster stehen im direkten Zusammenhang mit der deutschen Kultur und der Organisationskultur in Großunternehmen. Sie werden hier beschrieben, um aus den Fehlern anderer zu lernen.
SAFe® Implementation Roadmap[1]
Die Stationen auf der Reise zu SAFe® sind die folgenden Kapitel:
GoSAFe® Implementation Roadmap – hier wird beschrieben, wie ein guter Start für die Transformation gelingen kann.
Das Change-Team – hier wird aufgezeigt, wie ein Change-Team aufgebaut wird, um die Transformation der Organisation zu steuern.
Leadership in SAFe® – SAFe® beinhaltet ein Führungsmodell, das von der Führung verstanden und verinnerlicht werden muss.
Organise Around Value – entlang des Wertstroms des Unternehmens werden die Teams ausgerichtet.
ARTs ausbilden und starten – hier wird die Implementierung auf Entwicklungsebene geplant und umgesetzt.
Das Portfolio ausbauen – hier wird ein agiles Portfolio-Management aufgebaut.
Den Ablauf beschleunigen – anhand von Kennzahlen wird der eingeführte Prozess optimiert und beschleunigt.
Auf dieser Reise werden das Modell und die wichtigsten Rollen in ihrem Zusammenspiel erklärt. Dabei wird immer der Blick für das Wesentliche bewahrt. Es werden nur unbedingt notwendige Elemente und Prozesse betrachtet. Details können jederzeit im Internet und in Schulungsunterlagen nachgeschlagen werden. Das Buch ist sowohl für Berater, Mitarbeiter als auch Führungskräfte interessant. Es soll ein Reiseführer zu einer erfolgreichen SAFe®-Einführung sein. Man bereitet eine Reise damit gut vor, nimmt ihn aber auch während der Reise immer wieder in die Hand, um an bestimmten Stellen noch einmal Details nachzulesen. Das ist der Anspruch dieses Buches.
[1] https://scaledagileframework.com/wp-content/uploads/2023/01/IMPL-Roadmap_6.0_test.png
Das erste Kapitel beschreibt den ersten initialen Schritt auf der SAFe® Implementation Roadmap. Viele Auswirkungen dieser Entscheidung werden Ihnen erst später klar. In diesem Kapitel geht es um einen Überblick über die Folgen des ersten Schrittes für den Ablauf der Reise.
Das SAFe® BigPicture überfordert viele Betrachter auf den ersten Blick. Da sind viele kleine Icons zu sehen. Auf jedes kann man klicken und bekommt weitere Texte und Grafiken angezeigt. Auf der rechten Seite kann man den Implementation Level ändern. Dabei verschwinden und erscheinen Teile der Grafik. Das liegt daran, dass es verschiedene Bausteine in SAFe® gibt, die man wie LEGO zusammensetzen kann. Aus diesen Bausteinen wird ein Netzwerk entlang der Wertschöpfung des Unternehmens aufgebaut. Die oberste Ebene wird direkt aus der Strategie des Unternehmens abgeleitet. Das Portfolio steuert die strategische Entwicklung des Geschäfts. Hier werden die Budgets für die Umsetzung verteilt. Unter dem Portfolio gibt es zwei operative Level für die Umsetzung dieser Geschäftsideen. Die Large Solution ist dabei optional. Sie wird nur genutzt, wenn intensive Abstimmung im untersten Level notwendig ist. Das unterste Level nennt sich Essential. Hier wird Software entwickelt, getestet und betrieben. Maximal 150 Mitarbeiter in bis zu 15 Teams werden zu einem sogenannten Agile Release Train – ART – zusammengeschlossen. Sie planen und liefern Software gemeinsam. Es werden immer fünf zweiwöchige Sprints zu einem Product Increment – PI – zusammengeschlossen. Diese werden von allen Teams gemeinsam in einem großen Workshop geplant – PI Planning. Diese Planung wird in den Folgewochen von den Teams agil in den Sprints umgesetzt. Die Teams arbeiten in Kanban oder Scrum.
Auf der linken Seite der Grafik in Abbildung 1.1 sind die jeweiligen Rollen in dem jeweiligen Level und deren Kollaboration dargestellt. Die Anordnung der Rollen übereinander bedeutet nicht, dass diese eine hierarchische Beziehung zueinander haben. Die oben angeordneten Rollen haben größere Verantwortungsbereiche. Sie arbeiten alle gemeinsam auf Augenhöhe entsprechend der Rollenbeschreibung miteinander.
Abb. 1.1: SAFe® Big Picture[1]
Die runden Icons links und unten in der Grafik stellen die Kernkompetenzen auf dem jeweiligen Level dar. Diese Kompetenzen werden in der Implementierung der Level benötigt. Auf der rechten Seite sind übergreifend relevante Elemente. Sie werden auf allen Level benötigt.
Der untere dunkle Balken bildet das Fundament ab, auf dem SAFe® steht. Auf dieser Basis bauen alle Rollen und Prozesse auf. Der obere dunkle Balken ist die Business Agility. Sie stellt sich ein, wenn SAFe® vollständig implementiert ist. Die unteren Ebenen setzen die technische Agilität um, sie ist die Basis für strategische und organisationale Beweglichkeit. Das Unternehmen ist in der Lage, schnell auf sich ändernde strategische Herausforderungen zu reagieren.
Die bestehende Hierarchie der Führungskräfte ist das klassische Betriebssystem einer Organisation. Alle Aufgaben und Verantwortungen werden klassisch darüber abgebildet. Dieses Betriebssystem bleibt auch in SAFe® bestehen. Es wird zusätzlich ein zweites Betriebssystem ergänzt und die beiden Systeme werden miteinander verbunden. Das neue Betriebssystem wird als Netzwerk entlang der Wertströme gestaltet. Die Elemente, aus denen dieses Netzwerk besteht, wurden im vorherigen Abschnitt beschrieben. Man kann dieses System auch Prozessorganisation nennen. In diesem System wird die Verantwortung für die IT-Produktentwicklung und den Betrieb übernommen.
Abb. 1.2: Zwei Betriebssysteme[2]
Der große Vorteil, die Entwicklung und Lieferung der IT-Systeme aus der Aufbauorganisation herauszulösen, liegt in der Ausrichtung nach Wertströmen und damit auf den Kunden. Es wird möglich, schneller zu liefern und Feedback zu bekommen. Die notwendigen Entscheidungen können direkt von den Experten getroffen werden. Sie brauchen nicht mehr den Umweg über die Hierarchie zu gehen, um eine Entscheidung zu erwirken. Den Mitarbeitern wird über die SAFe®-Rollen Verantwortung übertragen. Sie können gemeinsam über die Produktentwicklung entscheiden. Dies wird durch das SAFe®-Prinzip Nummer 9 gestärkt: dezentralisierte Entscheidungen.
Ganz wichtig für eine Einführung von SAFe® ist es, zu verstehen, dass es nicht nur um das Erlernen von Neuem geht, sondern auch um das Verlernen von Bestehendem. In der Zeit vor SAFe® war die gesamte Verantwortung in der Hierarchie verankert. Bestimmte Führungskräfte, Stabsstellen und Mitarbeiter hatten die Aufgabe der Produktentwicklung. Dort gibt es bestehende Prozesse und Regularien. Es ist davon auszugehen, dass diese nicht ohne Weiteres mit SAFe® vereinbar sind. Das Unternehmen hat selbst Rollen entwickelt, die zum großen Teil auch in den Arbeitsverträgen verankert sind. Diese passen in der Regel nicht zu SAFe®. Ein Großkonzern ist keine grüne Wiese, wo man ein neues System neu aufbauen kann. Es wird viele Menschen geben, die gefühlt etwas verlieren. Es wird Menschen geben, die der Meinung sind: »Früher war alles besser und einfacher«, »Da haben wir mal eben was live eingespielt«. Diese Menschen müssen überzeugt und mitgenommen werden auf die Reise.
Viele Unternehmen haben bereits SAFe® eingeführt und es war in der Praxis nicht immer nur ein Spaziergang entlang der SAFe® Implementation Roadmap. Es hat auch Konflikte und Fehlentscheidungen gegeben. Alle Stellen, an denen ich und meine Kollegen Erfahrungen mit solchen Fehlentwicklungen gesammelt haben, sind in diesem Buch als Anti-Pattern dargestellt. Also Muster, die beschreiben, wie man es auf keinen Fall machen sollte. Sie werden hier immer mit ihrer Auswirkung dargestellt, um die Möglichkeit zu geben, aus den Fehlern anderer zu lernen. Manchmal sind auch Lösungen von Problemen beschrieben.
Anti-Pattern »Klare Verantwortung«
Eine Organisation hat die Verantwortung für die Entwicklung von Software nicht vollständig an die Ablauforganisation entlang des Wertstroms übergeben. Die alten Stabsstellen und deren Regularien wurden nicht abgeschafft. Als Folge mussten die alten Prozesse und die neuen gleichermaßen befolgt werden. Dies führte zu einer steigenden Komplexität und dadurch zu einer Verlangsamung aller Prozesse. Neben der Prozesskomplexität hat dies zu Rollen- und Verantwortungskonflikten geführt. Zentrale Entscheidungen der alten Struktur standen im Widerspruch zu lokalen Entscheidungen der neuen Struktur. Der Konflikt konnte nicht immer konstruktiv zu einer Lösung moderiert werden und es gab offene Auseinandersetzungen. Neben heißen Konflikten entstanden auch kalte Konflikte eines gegenseitigen Ignorierens. »Wir machen hier einfach weiter, als ob es euch nicht gäbe.« Entscheidungen wurden verzögert oder ignoriert. Durch die vielen kleinen Detailprobleme wurde das darunter liegende Strukturproblem verdeckt und entzog sich auf diese Weise einer wirklichen nachhaltigen Lösungsfindung. Es dauerte sehr lange, bis der Konflikt aufgelöst werden konnte.
Neben dem Bereich, der vollständig an das zweite Betriebssystem übergeben wird, gibt es weitere Bereiche der gemeinsamen Verantwortung. Diese Bereiche sind:
Strategie
Kundenbindung und Kundeneinbindung
Kundensupport
Lernkultur
Hier sind besonders die Bereiche Strategie und Kundenbindung als Teil des Marketings eine große Herausforderung. Strategie wird üblicherweise von der Geschäftsführung unterstützt und von Beratungsteams ausgearbeitet. Auch hier gilt es wieder, das Bestehende zu verlernen, um Platz für etwas Neues zu schaffen. Geteilte Verantwortung bedeutet das Agieren auf Augenhöhe. Dieser Teil ist besonders für die Führungskräfte an der Spitze neu und ungewohnt. Die Integration der beiden Betriebssysteme kann nur gelingen, wenn an den Stellen der gemeinsamen Verantwortung kein hierarchisches Gefälle mehr existiert.
Anti-Pattern »Business-Integration«
Ein Shared Service Center eines großen Konzerns führte SAFe® ein. Das Shared Service Center hatte selbst eine Strategie. Sie bestand darin, den Entwicklungs- und Betriebsservice für den Konzern bereitzustellen. Die inhaltliche Strategie und der Kundenkontakt wurden in anderen Bereichen des Konzerns verantwortet und gestaltet. SAFe® wurde jedoch nur in dem Shared Service Center eingeführt. Dies verlief anfangs reibungslos. Die ersten Probleme zeigten sich bei der Besetzung der Business- und Epic Owner. Es gab niemanden, der wirklich ein Geschäft verantwortete. Ein Zugriff auf die Mitarbeiter außerhalb des Shared Service Centers war nicht möglich. Dieses Problem ließ sich noch mit bestimmten Vertretern, die als Proxy fungierten, überbrücken. So richtig problematisch wurde es jedoch, als auf der Konzern-Roadmap immer mehr Erwartungen an das Shared Service Center formuliert wurden, die nicht mehr erfüllbar waren. Alle neuen Themen wurden mit Fertigstellungstermin geplant. Die Mitarbeiter des Shared Service Centers konnten die strategischen Themen weder beeinflussen noch ablehnen. Auch der Endkundenkontakt für Prototypen stellte sich als hochproblematisch heraus. Hier hatten die Produktverantwortlichen in SAFe® nicht nur das Marketing, sondern auch die Rechtsabteilung gegen sich aufgebracht. SAFe® musste im Konzern auf eine höhere Stufe gehoben werden, um alle Kompetenzen, die für interdisziplinäre Teams notwendig sind, integrieren zu können.
Die Bereiche, die in der klassischen Hierarchie verbleiben, sind von den wenigsten Veränderungen betroffen. Diese sind:
Umsatz und Kosten
Finanzen und Buchhaltung
Vertrieb und Marketing
Rechtsabteilung und Revision
Personalabteilung
Produktion und Fertigung
Die grauen Striche auf der Grafik zwischen den zwei Betriebssystemen sollen Verbindungen symbolisieren. Diese Verknüpfungen werden über Personen und Rollen realisiert, die in beiden Systemen Verantwortung tragen. Die häufigste Verbindung entsteht durch die Rolle des Business Owners oder die des Epic Owners. Diese zwei SAFe®-Rollen sollen die Integration der entwickelten Lösung in die Hierarchie unterstützen. Auch an vielen anderen Stellen kann eine Verbindung hilfreich sein. Die Personalabteilung sollte zum Beispiel Arbeitsverträge und Stellenausschreibungen haben, die für beide Systeme passen. Auch die Rechtsabteilung wird in bestimmten Phasen der Produktentwicklung immer wieder benötigt werden. Hier ist temporär sogar eine aktive Mitarbeit in dem SAFe®-Prozess zu erwarten. Fragestellungen könnten hier z.B. sein: Wie ist ein bestimmter Service DSGVO-konform? Eventuell sind sogar Abnahmen und Zertifizierungen notwendig.
Anti-Pattern »Einflüsse aus der Linie«
Die Personalabteilung eines Konzerns bestimmte die Gehaltsgruppen für alle Mitarbeiter. Die SAFe®-Rolle des RTE ist ein Coach und Koordinator für einen ART. Diese Rolle war im Gehaltsgefüge sehr weit unten angesiedelt. In SAFe® ist der RTE eine moderierte Führungskraft für bis zu 150 Mitarbeiter. Das bedeutet erhebliche Verantwortung und Komplexität der Aufgabe. Das Ergebnis der fehlenden Attraktivität der Rolle war, dass interne Mitarbeiter sich nicht auf die ausgeschriebenen Stellen beworben haben. Auch am externen Markt gab es keine ausreichend qualifizierten Kandidaten. In der Folge musste diese Rolle von externen Beratern übernommen werden. Diese waren jedoch selbst bei einem anderen Unternehmen angestellt und wurden entsprechend oft ausgetauscht. Die Rolle RTE hat für die Einhaltung und Weiterentwicklung der Prozesse auf ART-Ebene eine zentrale Bedeutung. Diese konnte durch die hohe Fluktuation nicht zu jeder Zeit hochwertig wahrgenommen werden. Als es aufgrund von wirtschaftlichen Engpässen zu Budgetkürzungen bei externen Beratern kam, wurden viele Verträge von RTEs nicht weiter verlängert. Dies führte zu einer Überlastung der Mitarbeiter und zu einer weiteren Verschlechterung der Qualität der Koordination. Das Coaching der ART wurde als Erstes eingestellt. Es wurden nur die nötigsten operativen Themen erledigt. Der Verbesserungsprozess stockte und die Qualität sank weiter.
In den beiden vorangestellten Abschnitten sind die ersten Elemente und das Zusammenspiel von SAFe® dargestellt worden, um einen ersten Eindruck zu geben, welche Tragweite die GoSAFe®-Entscheidung für die Organisation hat. Reza Razavi sei an dieser Stelle zitiert mit seiner Einordnung von Change und Transformation:
»A butterfly is a TRANSFORMATION, not a better caterpillar.«
CHANGE
CHANGE macht das System besser, schneller, qualitativer ...
Vergangenheit ist der Bezugspunkt.
Zukunft ist eine überarbeitete oder verbesserte Version der Vergangenheit.
Alte bzw. verbesserte Spielregeln, Denkweisen
Kein Paradigmenwechsel
TRANSFORMATION
Durch TRANSFORMATION entstehen neue Systeme.
Zukunft ist der Bezugspunkt.
Die Zukunft wird verwirklicht, indem man sich von den Zwängen der Vergangenheit befreit.
Neue Spielregeln, Denkweisen
Paradigmenwechsel
