Scaled Agile einführen: Do it myScaled So erstellen Sie Ihr eigenes Framework zur agilen Skalierung

Teil 1:
Die Transformation anstoßen und das Framework konzipieren
So erstellen Sie Ihr eigenes Framework zur agilen Skalierung

Wollen Sie Agilität skalieren und in ganzen Bereichen oder der Gesamtorganisation einführen? Dann kann es sich lohnen, zunächst ein unternehmensspezifisches Skalierungsframework zu erstellen, mit Elementen aus bestehenden Frameworks.

Herunterladen Download PDF

Artikelserie

  1. Die Transformation anstoßen und das Framework konzipieren
  2. Prozessentwicklung und Einführung

Scaled Agile einführen: Do it myScaled So erstellen Sie Ihr eigenes Framework zur agilen Skalierung

Teil 1:
Die Transformation anstoßen und das Framework konzipieren
So erstellen Sie Ihr eigenes Framework zur agilen Skalierung

Wollen Sie Agilität skalieren und in ganzen Bereichen oder der Gesamtorganisation einführen? Dann kann es sich lohnen, zunächst ein unternehmensspezifisches Skalierungsframework zu erstellen, mit Elementen aus bestehenden Frameworks.

In unserer heutigen komplexen Welt können nur wenige Produkte von einem einzigen agilen TeamTeamEin Team ist eine Gruppe von Personen, die gemeinsam eine Aufgabe erledigen sollen. Meist besteht innerhalb des Teams keine formelle Hierarchie. Grundidee der Arbeit im Team ist das Zusammenwirken ergänzender Fähigkeiten und Fertigkeiten der Teammitglieder, um ein Ergebnis zu erreichen, das für jedes einzelne Teammitglied allein nicht leistbar gewesen wäre. komplett entwickelt und betrieben werden. Die Konsequenz: Agile Arbeitsweisen wie Scrum oder KanbanKanbanKanban (jap.: Karte, Signalkarte) ist eine Methode zur dezentralen, selbstorganisierenden Steuerung von Materialflüssen in Fertigungsprozessen. Sie ist Grundlage der Just-in-Time-Produktion. werden nicht mehr nur in einzelnen Teams oder Projekten verwendet, sondern der Wunsch ist da, sie auf größere Teile einer OrganisationOrganisationDer Begriff "Organisation" wird in drei, eng miteinander verknüpften Bedeutungen verwendet: Organisation als System Die Aufgabe , innerhalb des Systems Prozesse und Strukturen zu gestalten. Die Struktur eines solchen Systems auszuweiten und damit zu "skalieren".

Bekannte Skalierungsframeworks wie SAFe®, LeSS oder Scrum@Scale bieten anhand von vorgezeichneten Blaupausen vermeintliche Sicherheit, doch ein blindes Adaptieren ist häufig schädlich, das konnte ich mehrmals in meiner Praxis beobachten. Zuerst schadet eine solche Adaptierung meist der Agilität selbst: KundenorientierungKundenorientierungDer Ausrichtung des Unternehmens am Kundennutzen liegt die Annahme zugrunde, dass der langfristige Geschäftserfolg auf der Kundenzufriedenheit beruht. Kundenorientierung bedeutet also die Bewertung von Produkten, Prozessen und Strategien eines Unternehmens unter dem Gesichtspunkte, welchen Nutzen die Kunden des Unternehmens daraus ziehen. und schnelle Entscheidungen rücken in den Hintergrund. An ihre Stelle treten komplizierte Prozesse, zusätzliche Rollen und längere Entscheidungswege.

In diesem zweiteiligen Beitrag beschreibe ich ein VorgehensmodellVorgehensmodellEin Vorgehensmodell stellt Methoden und Elemente des Projektmanagements zu Prozessen und Phasen eines standardisierten Projektablaufes zusammen., mit dem Projektleiter:innen, Agile Coaches und Führungskräfte ein passgenaues Skalierungsmodell für ihre eigene Organisation entwickeln oder ein bestehendes Framework weiterentwickeln können.

Im ersten Teil lege ich dar, wie Sie die Design-Prinzipien und Rahmenbedingungen für die Entwicklung Ihres Frameworks erarbeiten (nach einer schlanken Status-Quo-Analyse), welche und wie Sie strukturelle Anpassungen Sie angehen müssen und wie Sie dabei vorgehen, insbesondere bezogen auf die IT-Architektur und die -Infrastruktur. Das Vorgehen und die Schritte eignen sich für die Entwicklung eines Frameworks sowohl für einen kleinen Bereich mit drei bis vier agilen Teams als auch für eine gesamte Organisation.

Vorgehen zur Entwicklung eines eigenen Skalierungsframeworks

Da jede Organisation aufgrund ihrer Geschichte einzigartig strukturiert ist, benötigt jede nach agilen Prinzipien arbeitende Organisation ein individuelles Skalierungsframework. Die praktischen Erfahrungen zur (Weiter-)Entwicklung von agilen Skalierungsframeworks, die wir bei borisgloger consulting in diversen Transformationsprojekten gesammelt haben, bilden die Grundlage für das "myScaled Agile" Vorgehen (Bild 1). Das ZielZielZiel ist ein prognostizierter Zustand, der ein bestimmtes Handeln legitimiert. Um ein Ziel zu erreichen ist ein Plan erforderlich. Sowohl Ziel als auch Plan sind charakterischte Bestandteile eines Projekts . Siehe Projektziel . dieses Vorgehens ist das Abbilden und Priorisieren aller Themen und Entwicklungsstränge, die zur (Weiter-)Entwicklung eines agilen Arbeitsmodells notwendig sind.

Das "myScaled Agile" Vorgehen
Bild 1: Das "myScaled Agile" Vorgehen

Ablauf in drei Phasen

Insbesondere wenn es um die Framework-Entwicklung von größeren Abteilungen oder sogar von ganzen Organisationsbereichen geht, empfehlen wir, ein agiles Change Team zu bilden, welches die VerantwortungVerantwortungVerantwortung besteht aus den drei untrennbaren Bestandteilen Aufgabe, Befugnis und Rechenschaftspflicht. Es ist also nicht möglich, für die Durchführung einer Aufgabe ohne die entsprechenden Befugnisse (z.B. Zeichnungsrecht, Weisungsrecht) verantwortlich zu sein (sog. Kongruenzprinzip). Ebenso bedeutet Verantwortung, dass aus falschem Handeln oder Nicht-Handeln Konsequenzen wie z.B. Vertragsstrafen oder disziplinarische Strafen erwachsen. für die Veränderung trägt und als Ansprechstation innerhalb der Organisation fungiert. Seine Mitglieder bilden einen Querschnitt der Bereiche der Organisation, die verändert werden und arbeiten ebenfalls agil (vertiefend zur Arbeit und Zusammensetzung dieses Teams siehe "Agile Transformation: Mit dem Transition Team sicher durch die Veränderung steuern").

Der Ablauf gliedert sich grob in drei Phasen:

  1. In der ersten Phase wird das Change Team gebildet, oft auch Transformation Team genannt. Zusammen mit dem Top-Management entscheidet es, was das Ziel der Veränderung sein soll (z.B. Zusammenlegen von Business-Bereichen). Unsere Erfahrung zeigt, dass es gut ist, eine:n Sponsor:in aus dem Top-Management für sich zu gewinnen.
  2. In der zweiten Phase entwickelt dieses Team das neue Skalierungsframework, auf Grundlage der abgesteckten Rahmenbedingungen. Wir empfehlen dazu mit Ganztages-Workshops zu arbeiten und sich bei dem Prozess regelmäßig Feedback aus der Organisation und dem Top-Management einzuholen.
  3. Die dritte Phase umfasst die Planung und Einführung des neuen Frameworks.

Den Rahmen für die Framework-Entwicklung abstecken

Strategie und Vision

Agilität sollte nur dann skaliert werden, wenn sich die Organisation von der Ausweitung des agilen Arbeitens der Organisation einen Nutzen verspricht. Eine agile Organisation kann u.a. leichter Kundenbedürfnisse antizipieren und ihre Kundschaft regelmäßig mit neuen Produkten und Dienstleistungen befriedigen. Unserer Meinung nach kann ein Unternehmen nur auf diese Art am Markt überleben und nachhaltig erfolgreich werden.

Die wichtigste Frage vor dem Entwickeln eines Skalierungsframeworks lautet: In welche Richtung soll sich das Geschäftsmodel und mit ihm die Organisation entwickeln? Ein passgenaues agiles Skalierungsframework dient als Werkzeug, um diese Zielsetzung und Vision zu erreichen.

Beispiel ING-DiBa

Ein prominentes Beispiel hierfür ist die ING Group, die eine weltweite agile Transformation ausgerufen hat. In Deutschland verfolgt das Top-Management als erstes Ziel "Die erste Agile Bank Deutschlands" zu werden (siehe dazu "Die agile Transformation der ING-DiBa").

Für die Bankbranche, die zu großen Teilen noch immer in verstaubten Strukturen arbeitet (in der noch viele Prozesse händisch von Mitarbeitenden in IT-System aus dem vergangenen Jahrtausend abgearbeitet werden müssen), ist dies ein durchaus hehres Ziel. Es hat sowohl Auswirkung auf IT-Architektur sowie -Systeme und Infrastruktur als auch auf die Organisationsstruktur und die Art und Weise wie die Mitarbeitenden in Zukunft zusammenarbeiten werden.

Das Top-Management einer Organisation sollte eine Vision sowie eine Strategie für die kommenden Jahre besitzen. Hat es diese nicht, sollte beides im ersten Schritt gemeinsam erarbeitet werden (siehe z.B. "Eine Roadmap für die digitale Transformation" unter 3.).

Vision und Strategie sind der Startpunkt für die Veränderung und können die Grundlage bilden für die strategische Entscheidung, ein eigenes Skalierungsframework zu entwickeln und einzuführen – wie bei der ING Deutschland. Besteht bereits eine Strategie, kann die Entwicklung eines neuen oder die Anpassung eines bestehenden Skalierungsframeworks helfen, diese noch besser umzusetzen.

Analyse des Status Quo

Da ein neues Framework immer in die bestehenden Strukturen und Abläufe der Organisation eingreift, ist das Verstehen dieser zu Beginn unabdingbar. Dafür bewährt hat sich eine leichtgewichtige Status-Quo-Analyse, die vor allem zwei Fragestellungen beantwortet:

  • Welche Stärken hat die Organisation? Hier liegt der Fokus auf den Dingen, die aktuell gut funktionieren und in ein neues Modell auf jeden Fall übernommen werden sollen.
  • Welche Verbesserungspotentiale bestehen? Hier werden die Schmerzpunkte gesammelt, die die Zusammenarbeit und das schnelle Ausliefern von qualitativ hochwertigen Produkten behindern.

Die Daten für die Analyse erheben wir von borisgloger consulting gerne in Form von Retrospektiven, für die wir einen repräsentativen Querschnitt aus der Belegschaft der Organisation einholen. Die Anzahl von Personen, die von der Veränderung betroffen sind, bestimmt die Anzahl der Retrospektiven, in denen jeweils acht bis zehn Teilnehmende aus verschiedenen Führungsebenen (vom Teammitglied bis hin zur Führungskraft aus dem Top-Management) und den verschiedenen involvierten Bereichen und Abteilungen zusammenkommen. Bei Veränderungen innerhalb eines Bereiches von bis zu 120 Personen reichen meist zwei Gruppen aus, um repräsentative Antworten zu erhalten. Bei Veränderungen mit mehr Personen sollten besser drei oder vier Runden durchgeführt werden.

In der Retrospektive erhalten die Teilnehmer:innen zunächst einen kurzen Überblick über die geplante Veränderung und können anschließend jeweils zwei Fragen auf Klebezetteln beantworten:

  1. Welche Dinge laufen aktuell gut und sollten bei einer Veränderung unbedingt beibehalten werden?
  2. Welche Dinge müssen wir verbessern?

Bei der anschließenden Vorstellung kann man als Moderator:in bereits beginnen, ähnliche Antworten zu Themenclustern zusammenzuführen. Zum Ende der Session kann man die Themen noch priorisieren lassen, z.B. per Punktabstimmung (auch Dot-Voting genannt). Hierzu verteilt man drei Klebepunkte an die Teilnehmenden und bittet sie, diese Punkte zu den Themen mit dem größten Verbesserungspotenzial zu kleben. Für eine solche Retrospektive rechnen wir mit zwei bis drei Stunden.

Die Ergebnisse der Retrospektiven werden zusammengefasst mithilfe von sechs Faktoren für eine erfolgreiche Skalierung (zu den sechs Faktoren siehe dieses Video). Bild 2 zeigt beispielhaft das Ergebnis inklusive einer PriorisierungPriorisierungPriorisierung bedeutet die quantitative Bewertung von gleichartigen Elementen nach einem einheitlichen Maßstab und die anschließende Sortierung nach der so ermittelten Kennzahl in einer eindeutigen Reihenfolge. Zweck der Priorisierung ist es, die für ein bestimmtes Ziel wichtigsten Elemente (z.B. Aufgaben, Projekte, Produkte usw.) zu ermitteln und entsprechend zu berücksichtigen. (für Details siehe Rasche & Schmiedinger) sowie die sechs Faktoren. Um die Bedeutung und den Umfang einzelner Punkte hervorzuheben, – z.B. in einer Diskussion mit dem Top-Management, um zu verdeutlichen, dass es eine Veränderung an dem jeweiligen Punkt braucht, – können die Ergebnisse mit Zitaten und O-Tönen aus den Retrospektiven untermauert werden.

In dem in Bild 2 dargestellten Beispiel lag ein Verbesserungspotenzial in der fehlenden gemeinsamen Priorisierung. Folgender O-Ton bringt dies sehr anschaulich auf den Punkt und überzeugte auch das Management: "Es kommt häufiger vor, dass ich eine Aufgabe mit hoher Prio beginne umzusetzen. Dann wird eine Woche später die Prio geändert. Etwas anderes ist dann wichtiger. Dann muss ich die Sachen wieder zurückbauen, damit es wieder funktioniert. Das sind verschenkte Ressourcen."

Assessment anhand der sechs Faktoren erfolgreicher Skalierung
Bild 2: Assessment anhand der sechs Faktoren erfolgreicher Skalierung

Design-Prinzipien und Rahmenbedingungen für die künftige Organisation

Anfangs haben alle ein eigenes Bild von der künftigen Organisation und der Art und Weise, wie sie funktioniert – und oftmals weichen diese Bilder stark voneinander ab. Spätestens bei der Bewertung und Abstimmung des Organisationsdesigns werden die verschiedenen Vorstellungen offensichtlich und oft kommt es zu Meinungsverschiedenheiten. Meist wird dann ein Kompromiss entwickelt, der ein bunter Mischmasch ist. Dabei kann das Zielbild der Organisation leicht vergessen werden. Das Festlegen von Design-Prinzipien und Rahmenbedingungen für die Framework-Entwicklung hilft, solche Situationen zu vermeiden, denn diese definieren für alle Beteiligten transparent die Leitlinien und Regeln.

Beim bereits erwähnten Beispiel der ING Deutschland gab es klare Vorgaben aus der niederländischen Gruppe: Die bestehenden Business- und IT-Bereiche sollten aufgelöst und stattdessen übergreifende produktzentrierte Tribes gebildet werden (angelehnt an das Spotify-Modell).

Zu den folgenden Themenstellungen sollte gemeinsam mit dem Top-Management im Vorfeld abgeklärt werden, ob komplette Freiheit bei der Framework-Entwicklung besteht oder es bereits Vorgaben und Rahmenbedingungen gibt:

Idealerweise übergibt der:die erwähnte Sponsor:in die Design-Prinzipien und Rahmenbedingungen in Form eines Mandats an das Team, das die Framework-Entwicklung übernimmt.

Strukturentwicklung

Wenn ein klassisch aufgestelltes Unternehmen seine Arbeitsweise verändern möchte, sind in der Regel strukturelle Anpassungen notwendig. Bestehende Hierarchien, Abteilungsstrukturen und Wertschöpfungsprozesse sollten durchleuchtet und auf ihre Sinnhaftigkeit zur Erzeugung von Kundennutzen überprüft werden.

Organisations- und Teamzuschnitte sowie benötigte Skills

Durch skalierte agile Frameworks werden unsichtbare Grenzen aufgebrochen – vor allem zwischen den Business-Bereichen, der IT und dem Betrieb. Die meisten großen agilen Skalierungsframeworks wie SAFE®, LeSS oder NEXUS liefern kaum konkrete Vorschläge zu Organisationsstrukturen.

Lediglich das Spotify-Modell schlägt z.B. konkrete Bereiche (die sogenannten "Tribes") vor, die an Produkten oder Kundensegmenten orientiert sind. Diese Bereiche sollten nicht mehr als 100 bis 120 Personen umfassen und idealerweise alle Kompetenzen in sich vereinen, um neue Produkte auf den Markt zu bringen und bestehende weiterzuentwickeln. Der Kerngedanke und die Ursprungsidee von Agilität und agilen Teams sollte auch in einem solchen Tribe berücksichtig werden:

  • Kleine Teams besitzen ein Produkt oder eine Dienstleistung "Ende-zu-Ende"
  • Jedes Team kann unabhängig von anderen Teams Wert schaffen

Ende-zu-Ende-Verantwortung

Die Ende-zu-Ende-Verantwortung findet auf verschiedenen Ebenen statt. Externe Ende-zu-Ende-Prozesse erkennen die Bedürfnisse des Markts und befriedigen diese durch passende Produkte oder Services. Daneben erstellen interne Ende-zu-Ende-Prozesse Services oder Dienstleistungen, die in den externen Ende-zu-Ende-Prozessen benutzt werden, um den Durchsatz an Bedürfnisbefriedigung des Marktes zu erhöhen (siehe dazu auch den Blogbeitrag: "Ist bei End-to-End Prozessen auch immer wirklich End-to-End drin?").

Während traditionelle Organisationen hauptsächlich in internen Ende-zu-Ende-Prozessen bei Organisationsstrukturen denken, verwenden wir für das Design einer agilen Organisation externe Ende-zu-Ende Prozesse: Das bedeutet auch, dass jede interne Trennung eine Kundenrelevanz haben muss (egal ob bei Prozessen, Rollen, Methoden oder Standards etc.). Eine Trennung der Prozesse in Vertrieb und Einkauf z.B. ist nicht kundenrelevant.

Hingegen kann eine interne Trennung in Produktgruppen wie Lebensmittel und keine Lebensmittel eine Kundenrelevanz haben, da die Kundschaft möglicherweise höhere zeitliche Anforderungen an Lebensmittellieferungen hat. Diese sieht das Unternehmen stets als ein Ganzes und trennt nicht zwischen Bereichen. Ein Händler kann das beste Sortiment haben und die besten Preise. Das macht ihn aber nur dann erfolgreich, wenn die Artikel auch gemäß den KundenerwartungenKundenerwartungenKundenerwartungen sind in der Sprache des Kunden formulierte Anforderungen an eine durch einen Dienstleister erbrachte Leistung oder an ein durch einen Lieferanten geliefertes Produkt. geliefert werden.

Das Etablieren von Echten Ende-zu-Ende-Teams erfordert in den meisten Fällen die Auflösung von bestehenden Bereichen, Reporting-Strukturen und Führungsrollen. Daher verwenden viele Organisationen sogenannte virtuelle Teams oder Bereiche (wie z.B. im Framework SAFe® vorgeschlagen). Virtuell bedeutet in diesem Zusammenhang, dass die Teammitglieder offiziell noch Teil ihrer alten Teams sind und an die neue virtuelle Organisationsstruktur ausgeliehen werden. Diese virtuellen Teams können wie Projektteams mit recht wenig AufwandAufwandAufwand (Projektmanagement) ist die Menge aller monetär quantifizierbaren Eingangsgrößen in ein Projekt, in ein Programm, in ein Projektportfolio oder in einen Teil eines Projekts. gegründet und verändert werden, ohne in der offiziellen LinienorganisationLinienorganisationLinienorganisation bezeichnet die permanente, hierarchische ↑Aufbauorganisation einer ↑Organisationseinheit. Sie legt die Positionen der Stellen fest und beschreibt ihre wechselseitigen Berichtspflichten und Weisungsbefugnisse. abgebildet werden zu müssen. Dieses kann ein wertvoller erster Schritt beim Erkunden sein, in welche Richtung die Aufbaustrukturen der Organisation weiterentwickelt werden können.

Beispiel: Die Einführung eines neuen Kundenmanagementsystems kann von solchen virtuellen Teams übernommen werden, deren Mitglieder aus ganz unterschiedlichen Organisationsbereichen stammen (ähnlich wie bei Projekten). Wenn sich diese Strukturen in der Praxis bewähren, werden die Strukturen anschließend fest etabliert (im Gegensatz zu Projektteams, die aufgelöst werden).

Value Stream Mapping zur Analyse von geeigneten Team- und Bereichszuschnitten

Für das Design der neuen Struktur setzen wir gerne das Value Stream Mapping ein (auf Deutsch Wertstromanalyse), das sich sehr gut für Wertschöpfungsprozesse eignet, in die maximal 120 Personen involviert sind (siehe Methode Value Stream Mapping). Die Übung passt aber auch in Kontexte mit über 120 Beteiligten: In solchen Fällen lässt sich damit herausfinden, welche größeren bereichsübergreifenden Organisationseinheiten notwendig sind (z.B. Bereiche, Tribes oder Releasetrains), um im nächsten Schritt Teams zu bilden.

Bei dieser Methode ist es unerheblich, ob das Ziel ist, Strukturen für die künftige Linienorganisation abzuleiten oder zunächst virtuelle Teams zu bilden. Nach dem Ausarbeiten der Struktur, wird darüber diskutiert, welche Personen diese ausfüllen werden, wie die Governance zwischen Teams und Bereichen aussehen soll und welche anderen Abläufe im Unternehmen daran angepasst werden müssen.

Schritt 1: Ermitteln der Wertströme

Im Workshop ermitteln wir mithilfe von Value Stream Mapping zunächst die Produkte des Unternehmens und deren Wertschöpfungsketten. Abgebildet wird der komplette Prozess vom Eingangssignal eines:r Nutzer:ins bis zur Auslieferung des Mehrwerts, den ein Produkt bzw. eine Dienstleistung bietet. Wir empfehlen, das Mapping mit Klebezetteln auf einer großen Wand, mit Moderationskarten auf dem Boden oder mit einem geeigneten digitalen Tool durchzuführen, auf dem mehrere Nutzer:innen Karten gleichzeitig bewegen können. Auf diese Art können die Elemente immer wieder neu angeordnet werden, bis ein gemeinsames Bild gefunden ist, das der Realität entspricht.

Sobald die Wertschöpfungsschritte von links nach rechts sortiert sind, wird ermittelt, welche Expertise in den jeweiligen Schritten benötigt wird. Ich empfehle, hier die benötigen Skills abzubilden, statt der Personen, die aktuell diese Skills haben. Ich habe mehrfach erlebt, dass die Gruppe bei bestimmten Teamkonstellationen sofort in die Argumentation übergegangen ist: "Solch ein Team können wir nicht aufstellen, weil die Person XY mit ihren Skills dann in drei Teams benötigt wird". Die Verwendung von Skills erleichtert es, sich von der aktuellen Aufstellung zu lösen und die VisualisierungVisualisierungVisualisierung ist die bildliche oder grafische Darstellung eines Sachverhalts, der zunächst in einer anderen medialen Form vorliegt, meist als Text oder als Daten. als Startpunkt zu verstehen für die Diskussion, welche Skills einzelne Teams oder Bereiche in Zukunft benötigen. Bild 3 zeigt das exemplarisch für den Hypotheken-Kreditprozess in einer Bank.

Anschließend werden jene Unternehmensbereiche markiert, die im Zuge der Transformation verändert werden sollen. Idealerweise sind das alle Bereiche, aber möglicherweise gibt es einen guten Grund, z.B. den Betrieb oder Vertrieb zunächst außen vor zu lassen, da diese Bereiche aktuell noch sehr weit entfernt von agilem Arbeiten sind oder es seitens des Managements keine Bereitschaft für Veränderung gibt. Sofern es Übergabepunkte zu diesen vorerst ausgeklammerten Bereichen gibt, werden diese jetzt transparent. Wie die Zusammenarbeit und Synchronisation mit diesen Bereichen ablaufen können, wird später festgelegt.

Value Stream Mapping und Identifikation der betroffenen Expertisen für einen Kreditprozess in einer Bank
Bild 3: Value Stream Mapping und Identifikation der betroffenen Expertisen für einen Kreditprozess in einer Bank

 

 

 

 

 

 

 

 

 

 

 

 

Schritt 2: Festlegen und testen von Teamzuschnitten

Abschließend werden mögliche cross-funktionale Teamzuschnitte identifiziert und in die Grafik eingezeichnet (Bild 4). Das Ziel sind immer Teams mit möglichst wenigen gegenseitigen Abhängigkeiten, um viel Autonomie und schnelle Entscheidungsprozesse zu ermöglichen. Dies kann über cross-funktionale Teamzuschnitte sichergestellt werden, die komplette Schritte aus der Wertschöpfungskette abbilden: Solche Teams entwickeln unabhängig und haben eine Ende-zu-Ende-Verantwortung, entsprechend dem Leitsatz "You build it you run it". Beim Bilden solcher Teams geht es um das Ausprobieren, welche Konstellation am besten für den jeweiligen Kontext passt.

Unsere eindringliche Empfehlung ist, verschiedene Varianten zu testen und das Für und Wider mit verschiedenen Personen aus der Organisation zu diskutieren. In einigen Fällen wird die Gruppe zu dem Schluss kommen, dass sogenannte Support- oder Framework-Teams gebraucht werden, die in einem Wertstrom die nötige Softwarearchitektur für die anderen Teams bereitstellen, wie Team 6 „Kundenbetreuungstool" in dem hier dargestellten Beispiel (siehe Bild 4).

Mögliche Teamzuschnitte inkl. Teambeschreibungen
Bild 4: Mögliche Teamzuschnitte inkl. Teambeschreibungen

 

Schritt 3: Zusammenstellen der Teams

Sobald mögliche neue Teamzuschnitte gefunden wurden, geht es darum, diese Teams zu besetzen. Häufig fehlt im Transformation Team, das das Framework ausarbeitet dafür die nötige Expertise, weil keines der Teammitglieder alle in Frage kommenden Personen und deren Skills genau kennt. In diesem Fall kann die Aufgabe an die jeweiligen Bereiche übertragen werden. Die Gruppe sollte aber eine Empfehlung dazu geben, wie ein Workshop aussehen könnte, in dem die passenden Personen identifiziert werden.

Falls genügend Zeit vorhanden ist, empfehlen wir eine AusschreibungAusschreibungWenn die Erbringung einer bestimmten Leistung durch einen (Unter-)Auftragnehmer erfolgen soll, so muss diese Leistung beschrieben werden (z.B. durch ein Lastenheft) und Angebote eingeholt werden. Durch eine öffentliche (oder beschränkte) Ausschreibung dieser Leistung werden potentielle Anbieter aufgefordert, ihre Angebote abzugeben. Neben der Leistungsbeschreibung muss die Ausschreibung zusätzlich die Angebotsabgabefrist benennen, bis zu der die Angebote vorliegen müssen., damit sich die Teams selbst zusammenfinden können. Dafür sollte das Transformation Team die Kriterien für die Kompetenzen zusammenstellen, die in den Teams vertreten sein müssen. In einem TerminTerminEin Termin ist ein durch absolute Zeitangaben festgelegter Zeitpunkt in der Echtzeit. Die DIN 69900:2009-1: "Projektmanagement – Netzplantechnik: Beschreibungen und Begriffe" unterscheidet zwischen Termin und Zeitpunkt, wobei letzterer nicht absolut, sondern nur relativ zu einem Bezugspunkt (z.B. der noch nicht terminlich festgelegte Projektstart) angegeben ist. mit der gesamten Belegschaft stellen wir diese Kriterien vor und stellen danach die Aufgabe, sich in möglichen neuen Teamkonstellationen zu organisieren (DauerDauerDauer ist die Zeitdifferenz zwischen Endzeitpunkt und Anfangszeitpunkt einer Aktivität (z.B. Aufgabe, Vorgang, Projekt). Dauern können in kalendarischen Zeiteinheiten oder in Einheiten der Arbeitszeit angegeben sein. insgesamt zwei bis drei Stunden).

Zu diesem Zweck bereiten wir in verschiedenen Bereichen des Raums für jedes Team eine Metaplanwand vor. Nach 45 Minuten stellen die Personen aus den einzelnen Teams den Stand des Findungsprozesses vor: Welche Kriterien sind bereits erfüllt? Welche Teammitglieder werden noch gebraucht? Auch wenn sich das nach einem großen Durcheinander anhört: Die passenden Teammitglieder finden sich – bisher hat dieses Vorgehen immer funktioniert (siehe auch "Mehr Fokus und MotivationMotivation"Motivation" ist einerseits ein zentraler Begriff der Psychologie, der dort fachspezifisch zur Beschreibung menschlichen Verhaltens verwendet wird. Die Arbeitspsychologie wendet diesen Motivationsbegriff auf die spezielle Situation der Arbeitswelt an und versucht so, z.B. Regeln für Mitarbeiterführung zu entwickeln. für selbstorganisierte Teams dank der Marktplatz-Methode").

Natürlich kommt es bei der Neuaufteilung von Teams häufig zu der Situation, dass eine Person aufgrund ihrer Expertise am besten in zwei Teams mitarbeiten sollte. Da agile Teams aus Vollzeitmitgliedern bestehen, ist ein Aufteilen der Kapazitäten theoretisch unmöglich und wir empfehlen eine solche Konstellation auch nicht (höchstens kurzfristig). Es nimmt den Teams die Geschwindigkeit und zehrt sehr an der Substanz der betroffenen Mitarbeiter:innen. Stattdessen sollte ein guter Übergabe- und Einarbeitungsprozess entwickelt werden, damit diese Kolleg:innen ihr Wissen weitergeben können.

Schritt 4: Definieren und besetzen der Führungsrollen

Erst nachdem die Organisations- und Teamzuschnitte identifiziert sind, geht es an die Definition und die mögliche Besetzung von Führungsrollen. Warum? Wir haben festgestellt, dass bestehende Rollen und Funktionen und die Personen, die sie aktuell ausführen, die Kreativität für neue Organisations- und Teamzuschnitte entscheidend beeinflussen können, wenn bereits ein Bild besteht, dass Person XY auf jeden Fall die PO Rolle für Produkt XY weitermachen muss.

Generell ist jetzt zu klären, wie das Führungsmodell für diesen gesamten Wertschöpfungsprozess aussehen kann – sowohl auf Team- als auch Bereichsebene. Bei diesem Punkt braucht es großes Fingerspitzengefühl bei der Moderation, da es ziemlich sicher darum gehen wird, bestehende Rollen von Gruppenmitgliedern zu verändern oder gar abzuschaffen. Alle Teilnehmer:innen werden sich automatisch fragen: Was bedeutet das für mich? Möchte ich wirklich folgende Rolle ausführen oder kann es für mich bedeuten, dass meine jetzige Führungskraft wechselt?

Um mit den möglicherweise aufkommenden Emotionen gut umgehen zu können, sollte man sich im ersten Schritt mit agilen Führungskonzepten auseinandersetzen und eventuell den Austausch mit anderen Organisationen suchen, die solche Rollen bereits eingeführt haben (z.B. Spotify, siehe dazu "Das Spotify-Modell – so führen Sie das Framework in Ihre Projektorganisation ein").

Die meisten agilen Arbeitsmodelle sehen generell wenige hierarchische Führungsrollen vor, um die Selbstorganisation und die Entscheidungskompetenz der Teams zu stärken. Die disziplinarische Verantwortung liegt dabei meist bei einer Person außerhalb des Teams, z.B. bei einer extra dafür geschaffen Rolle wie einem Chapter Lead oder bei einer Bereichsleitung/Tribe Lead, die von jetzt auf gleich für bis zu 100 Personen verantwortlich ist – zumindest auf dem Papier.

Sobald die Gruppe ein geeignetes Führungsmodell identifiziert hat oder sich entschieden hat, das bestehende weiterzuverwenden, werden die Rollen in das Bild mit den Teams aufgenommen. Zu guter Letzt werden Querschnittsfunktionen ergänzt, die sich keinem Team zuordnen lassen und einen Platz in der neuen Struktur finden müssen, z.B. das PMO.

Exkurs Agile Führung

In einem agilen System umfassen die klassischen Führungsaufgaben im Wesentlichen drei Aspekte, wie sie Daniel Pink in seinem Buch "Drive" beschreibt (vgl. Pink 2011). Wenn alle drei Führungsbereiche sorgfältig bedient werden, finden sich Mitarbeiterinnen und Mitarbeiter in einer optimalen Arbeitsumgebung wieder. Diese optimale Arbeitsumgebung vereint drei Eigenschaften:

  • Einen gewissen Grad an Autonomie, also die Möglichkeit, selbstständig und eigenverantwortlich Entscheidungen treffen zu können.
  • Den persönlichen Sinn, der sich aus dem Wunsch ergibt, an etwas Wichtigem und Relevantem zu arbeiten (siehe dazu "Mehr Sinn in der Projektarbeit").
  • Die Möglichkeit, sein Können laufend zu erweitern und die geforderte Leistung erbringen zu können.
Klassisches vs. agiles Führungsverständnis
Bild 5: Klassisches vs. agiles Führungsverständnis
 

Im Übergang vom klassischen zum agilen Führungsmodell hat jede bisherige und künftige Führungskraft die Chance für sich festzustellen, in welcher der drei Rollen sie sich am wohlsten fühlt und am besten zum Erfolg des Unternehmens beitragen kann. Falls es diese Befürchtung gibt: Auch in den neuen Rollen gibt es Karrieremöglichkeiten – wenn auch etwas anders interpretiert. Nachwuchs-Führungskräfte haben weiterhin die Chance, schrittweise mehr Verantwortung zu übernehmen.

Beispiel: Die nächste Stufe der Weiterentwicklung im Bereich "Autonomie" könnte für einen Scrum Master die Rolle des Chief Scrum Masters sein. Der Chief Scrum Master hat die Verantwortung für die laterale Führung aller Scrum Master und arbeitet auf die Befähigung ganzer Systeme hin (z.B. Abteilungen oder Bereiche). Analog dazu kann im Bereich "Sinn" ein Product Owner zum Chief Product Owner werden und für ein Produkt oder eine Produkt-Suite verantwortlich sein, die von mehreren Teams entwickelt wird. Für den Chapter Lead bieten sich in puncto Fachlichkeit Rollen mit größerer Verantwortung an, z.B. in der IT-Architektur.

IT-Architektur und -Infrastruktur

Während oder spätestens nach der Strukturentwicklung sollte sich ein Teil des Transformation Teams näher mit der bestehen IT-Architektur und -Infrastruktur auseinandersetzen. Es gilt zu überprüfen, ob die aktuelle Architektur und Infrastruktur mit den Anforderungen aus dem Skalierungsframework zusammenpasst oder ob Dinge angepasst werden müssen. Häufig bietet es sich an, hierzu weitere Expert:innen hinzuzuziehen.

In der Softwareentwicklung setzen agile Skalierungsframeworks auf eine möglichst hohe Autonomie einzelner Teams für ein spezifisches Produkt (oder zumindest für Teile des Produkts). Das bedeutet im Umkehrschluss, dass die zugrunde liegende Softwarearchitektur möglichst voneinander entkoppelt und modular aufgebaut sein muss.

Beispiel: Ein Team, das beispielsweise den Check-Out-Prozess inklusive Bezahlvorgang und der Übergabe der BestellungBestellungEine Bestellung ist eine für den Besteller bindende Aufforderung an den Lieferanten, einen Vertrag über die bestellte Leistung abzuschließen. Der Lieferant hat die Wahl, die Bestellung entweder zu bestätigen und damit den Vertrag wirksam zu machen oder die Bestellung abzulehnen (z.B. da die Ware nicht vorrätig ist). Siehe " Auftragserteilung ". in das Fulfillment verantwortet, muss in der Lage sein, alleine Entscheidungen treffen und Anpassungen im Code vornehmen zu können. Letzteres ist nur möglich, wenn die verschiedenen Softwarekomponenten der E-Commerce-Plattform möglichst unabhängig voneinander aufgebaut sind und über vorher definierte Schnittstellen miteinander kommunizieren.

Anstoßen des langwierigen Prozesses

Gerade Organisationen, die über Jahrzehnte gewachsene IT-Landschaften- und Systeme besitzen, benötigen ein Konzept, wie auf lange Sicht möglichst viele Bereiche voneinander entkoppelt werden können. Da ein solcher Prozess häufig mehrere Jahre dauert, beschränkt sich die Aufgabe des Transformation Teams darauf, diesen Prozess anzustoßen und auf mögliche kleinere Experimente hinzuwirken, die mehr entkoppeltes Arbeiten in den neuen Organisationsstrukturen ermöglichen.

Neben der reinen Softwarearchitektur prüft das Team ebenfalls die vorhandene Software-Infrastruktur und Tools auf die Komptabilität mit dem agilen Skalierungsframework. Dies fängt bei dem Vorhandensein von Kommunikationstools wie Microsoft Teams oder Slack und Ticketmanagement-Systemen wie Jira oder Azure DevOps für kollaboratives Arbeiten an. Es umfasst weitere Tools wie z.B. GIT für die gemeinsame Versionsverwaltung von Software und Toolchains für kontinuierliche Deployments und Testautomatisierung.

Da diese Prozesse und Tools häufig von Release Management Teams in der Organisation verantwortet werden, sollte sich das Transformation Team als Bindeglied zwischen Architekten und Management verstehen. Durch das Etablieren von Standards im Sinne des Frameworks lassen sich technische Abhängigkeiten reduzieren und die Teams weiterentwickeln zu einer höheren Eigenverantwortlichkeit.

Ausblick

Im zweiten und abschließenden Teil dieses Beitrags erfahren Sie, wie Sie Ihre Prozesse für das Ziel- und PortfoliomanagementPortfoliomanagementOriginär wird der Begriff Portfoliomanagement in der Finanz- und Immobilienwirtschaft verwendet. Dort bedeutet er die Disposition vorhandenen Kapitals in Finanzprodukte oder Immobilien zur Erzielung maximaler Rendite. sowie zur Priorisierung und BudgetierungBudgetierungBudgetierung umfasst alle Aktivitäten im Projekt zum Aufstellen und Anpassen eines Projektbudgets sowie zur Abstimmung mit Auftraggeber , Lenkungsausschuss oder Fördergebern mit dem Ziel, eine Freigabe zu erreichen. überprüfen und an das neue Framework anpassen können. Anschließend skizziere ich eine Roadmap für das Implementieren, und wie Sie dabei iterativ vorgehen können. Zu guter Letztgebe ich Ihnen Tipps, wie Sie das Skalierungsframework "zum Leben erwecken" und kontinuierlich weiterentwickeln.

Literatur

  • Pink, Daniel: "Drive: The Surprising Truth About What Motivates Us", Riverhead Books 2011
  • Rasche, Carsten; Schmiedinger, Christoph: "Der Fahrplan zur kundenzentrierten agilen Organisation", kostenfreier Download nach Anmeldung unter https://www.borisgloger.com/publikationen/whitepaper

 

Herunterladen Download PDF

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 4
Kommentare 0

Fortsetzungen des Fachartikels

Teil 2:
Prozessentwicklung und Einführung

Wollen Sie Agilität skalieren und in ganzen Bereichen oder der Gesamtorganisation einführen? Dann kann es sich lohnen, zunächst ein unternehmensspezifisches Skalierungsframework zu erstellen. Verwenden Sie dazu die vorgestellte Roadmap.

Das könnte Sie auch interessieren

Scaled Agile - das passende Framework finden und einführen
E-Book mit 95 Seiten
Sie möchten Agilität organisationsweit einführen? In diesem E-Book lesen Sie, worauf Sie bei der Auswahl und der Einführung eines Frameworks achten sollten und wie verbreitete agile Skalierungsframeworks funktionieren.
Vorschaubild

Beim Software- und Medienanbieter Haufe Group gärte es: Multitasking, wachsender Overhead und Abhängigkeiten demotivierten viele Mitarbeiter.

Vorschaubild

Viele Unternehmen übersehen im Zuge der Digitalisierung, dass sie neben der Technik auch ihre Kultur und das Mindset der Mitarbeiter weiterentwickeln sollten. Diesen unterschätzten Erfolgsfaktoren widmet die hier vorgestellte praxiserprobte …

Vorschaubild

Carsten Rasche und Konstantin Engeler stellen Ihnen sechs Erfolgsfaktoren agiler Skalierung vor und zeigen, wie Sie mittels einer Framework-übergreifenden Toolbox ein Framework zusammenstellen, das auf die individuellen Ziele und Probleme Ihrer …<