Erfolgreich skalieren!

von Martin Hillbrand
 

Es gibt viele theoretische Modelle, wie agile Prinzipien für Unternehmen umgesetzt werden können. Diese Modelle klingen in der Theorie logisch und verführen Sie schnell dazu, diese 1:1 einsetzen zu wollen. Die Modelle beschreiben oft Idealszenarien, die Sie in der Wirklichkeit nicht antreffen werden. Dieser Artikel beschreibt Aspekte, die bei einer Skalierung agiler Methoden zu beachten sind, damit Sie Ihr Unternehmen erfolgreich neu ausrichten können.

Die Anzahl der theoretischen Modelle für skalierte agile Ansätze ist in den letzten Jahren immer weiter angestiegen. Vor allem für skalierte Scrum- und Kanban- Prozesse gibt es viele Modelle, wie SAFe [SAFe], LESS [Lar16], Nexus [NEXU], SoS [Suth01] oder Kanban Flight Levels [LEAN] (siehe Abbildung 1). Aber entspricht die Theorie tatsächlich immer der Realität in Ihrem Umfeld?
Es besteht die Gefahr, sich zu dogmatisch auf diese Modelle zu stützen. Darunter verstehe ich im Wesentlichen, dass Sie so überzeugt von diesem einen ausgewählten Modell sind, dass Sie ohne Rücksicht auf Verluste versuchen, Ihr Unternehmen so umzustrukturieren, dass Sie das Modell anwenden können. In diesem Artikel werden Ihnen Argumente aufgezeigt, weshalb Sie eine dogmatische Einführung eines skalierten agilen Modells vermeiden sollten.
Da eine Skalierung agiler Vorgehensweisen in den meisten Fällen vom Management initiiert wird, betrachten wir hier auch nur diese Seite. Eine Einführung vonseiten der Teams in Richtung Management kann erfahrungsgemäß auch nur mit Unterstützung der Führungskräfte erfolgen.
Wenn Sie sich für die Einführung eines skalierten Vorgehensmodells entschieden haben, empfehle ich Ihnen, folgende Aspekte zu bedenken und das Modell nicht unreflektiert zu übernehmen.

George Box, englischer Statistiker (1916 – 2013), sagte einst: „Ihrem Wesen nach sind alle Modelle falsch, aber einige sind nützlich.“ Aus dieser Aussage können wir zwei wesentliche Punkte für die Skalierung agiler Methoden identifizieren, die uns bei der Bewertung der Modelle helfen:

• Kenne die Bestandteile der Modelle und
• verwende jene Teile, die für dich nützlich sind.

Der erste Punkt stellt klar, dass wir erst verschiedene Modelle kennen müssen, um die einzelnen Unterschiede evaluieren und den jeweiligen Nutzen für das Unternehmen bewerten zu können. Stellen Sie deshalb auf Managementebene fest, weshalb Sie ein gewähltes Modell befürworten. Das unterstützt Sie dabei, die Einführung auch Ihren Mitarbeitern gegenüber zu verteidigen.
Eine dogmatische Einführung würde bedeuten, dass Sie ein Modell nehmen und es in beinahe allen Punkten so einsetzen wollen, wie es in der Theorie beschrieben ist. Dieser Ansatz ist jedoch eine denkbar ungünstige Ausgangssituation für eine Transition, um ein agiles Vorgehen unternehmensweit einzuführen. Die Studie „Status Quo Agile“ 2014 ([Kom14], siehe Abbildung 2) zeigt auf, dass nur ein Viertel der Befragten tatsächlich glaubt, dass sie ein agiles Vorgehen so verwenden, wie es in der Theorie beschrieben ist (weitere fünfzehn Prozent arbeiten noch nach einem klassischen Ansatz). Unter den agilen Vorgehensmodellen werden hier keine skalierten Ansätze verstanden, sondern die Vorgehensmodelle auf Teamebene.
Ein skalierter Ansatz benötigt mehr Synchronisation, Abstimmung, Artefakte, Ereignisse und Rollen als ein Modell auf Teamebene, wodurch die prozentuale Verteilung der Mischformen steigt. Hier müssen Sie erst das theoretische Modell finden, das tatsächlich in allen seinen Punkten auf Ihr Unternehmen maßgeschneidert ist.
Das soll nicht bedeuten, dass wir von Beginn an die Theorie ausschließen wollen, jedoch machen Sie sich vielmehr Folgendes bewusst: Die Erfahrung sagt uns, dass jedes zweite agile Vorgehen eine Mischform unterschiedlicher Theorien ist. Nutzen Sie deshalb regionale Angebote und besuchen Sie die Agilen Treffen in Ihrer Region, um einen Eindruck von anderen Ansätze zu erlangen. Vor allem der Austausch über Unternehmensgrenzen hinweg kann Ihnen einen zusätzlichen Eindruck geben.

Die Basis für agiles Vorgehen ist noch immer das agile Manifest [Agile]: Befolgen Sie es bereits bei der Einführung, damit Sie als Beispiel vorangehen. Es weist uns immer noch darauf hin, dass die Werte auf der linken Seite der Prinzipien Vorrang haben vor jenen auf der rechten Seite (vgl. die Kernaussagen des agilen Manifests im Folgenden). Was nicht ausschließt, dass die rechte Seite wichtig ist.

• Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Eine dogmatische Einführung widerspricht dieser Aussage. Führen wir ein Modell dogmatisch ein, konzentrieren wir uns auf das Modell (die Prozesse und Werkzeuge) und nicht auf unsere Mitarbeiter und Interaktionen im Unternehmen. Werden Individuen und Interaktionen im Unternehmen bei der Einführung nicht berücksichtigt, wird man feststellen, dass die Mitarbeiter die Werte des agilen Manifests auch nicht leben werden. Wie bereits oben erwähnt, sollte ein Führungsgrundsatz sein, immer als Beispiel voranzugehen.

• Funktionierende Software (-Produkte) steht über einer umfassenden Dokumentation
• Zusammenarbeit mit dem Kunden steht über Vertragsverhandlungen

Diese beiden Gegenüberstellungen haben auf den ersten Blick keine Verbindung zu der Einführung einer Skalierung agiler Methoden. Sie wirken sich jedoch indirekt auf die Umstellung aus. Trotz Transition müssen die Unternehmen funktionierende Produkte liefern. Zusätzlich müssen sie darauf achtgeben, dass die Zusammenarbeit mit den Kunden nicht merklich darunter leidet.
Aus meiner Erfahrung zeigt sich, dass der Kunde sehr oft auch Einfluss auf die internen Prozesse hat, im Speziellen, wenn die Zusammenarbeit mit dem Kunden intensiv ist beziehungsweise intensiviert werden soll. Oftmals ist die Verfügbarkeit von Kunden jedoch eingeschränkt, wodurch die dogmatischen Ansätze von umfangreichen Planungsbesprechungen oder Reviews nicht so praktikabel sind wie gewünscht, da direktes Kundenfeedback nicht eingeholt werden kann. Können Kunden wirklich zwei Tage an einer Planungsbesprechung teilnehmen (z. B. Programm- Inkrement-Planung, vgl. [SAFe]) oder benötigen sie im Veränderungsprozess Stellvertreter, die ihre Rolle einnehmen und ihre Positionen verteidigen?

• Reagieren auf Veränderung steht über dem Befolgen eines Plans

Seien Sie in Ihrem Veränderungsprozess von Beginn an offen für Veränderungen. Sie müssen einen Plan verfolgen, aber eben nicht dogmatisch. Eine alte Weisheit aus dem deutschen Sprachraum lehrt uns bereits: „Planung ersetzt Zufall durch Irrtum“.
Wenn wir nicht planen, dann ist alles, was wir tun, Zufall oder es wird uns von anderen vorgegeben. Die jeweiligen Folgen unseres Handelns sind erst abschätzbar, wenn wir einen Plan verfolgen – wir können uns irren oder richtig liegen. Wenn wir dann einen Irrtum erkennen, müssen wir unseren Plan ändern. Das kann auch bedeuten, dass das gewählte Vorgehensmodell abgewandelt werden muss.
Sehen Sie das dann nicht als Misserfolg, sondern als neue Erfahrung und passen Sie Ihre Pläne auf Basis der neuen Erkenntnisse regelmäßig weiter an. Sehen Sie den Abgleich zwischen Planung und Realität als Ihre erste Möglichkeit, für die Zukunft zu lernen. Thomas Edison sagt von sich selbst, er habe niemals versagt, sondern: „Ich habe mit Erfolg zehntausend Wege entdeckt, die zu keinem Ergebnis führen.“ Diese Einstellung müssen wir uns auch als Unternehmen zunutze machen und Irrtümer als Umweg auf unserem Weg zu einem erfolgreichen skalierten agilen Ansatz sehen.
Das agile Manifest beschreibt wichtige Punkte, die Sie beachten sollten, wenn Sie eine agile Methode skaliert einführen wollen. Im Speziellen widerspricht es einer Einführung nach einem theoretischen Modell, da dieses lediglich als Ausgangsbasis für einen Plan, für die Diskussion mit den Kunden und als erste Analyse der Prozesse dienen kann. Sie können den Weg danach zwar grob planen, aber wie Ihr skalierter Ansatz am Ende aussieht, können Sie zu Beginn noch nicht festlegen.

In der Studie „The irrational side of change management“ von McKinsey (vgl. [KINS]) erreichen lediglich 30 Prozent der Unternehmen ihre ursprünglich gesetzten Ziele zur Veränderung. Bei einem dogmatischen Festhalten an einem skalierten agilen Vorgehensmodell gibt es eine 70-prozentige Wahrscheinlichkeit, dass diese Ziele nicht erreicht werden. Die inkrementelle Einführung eines skalierten agilen Vorgehensmodells unterstützt uns dabei, dieses Risiko zu minimieren. Lean Change Management [Lit14] kann dabei helfen, schrittweise mit kleinen Experimenten Änderungen einzuführen und diese im Kleinen zu etablieren, bevor sie im ganzen Unternehmen ausgerollt werden (siehe dazu Abbildung 3).
Die Experimente werden von einem oder mehreren Experten für agiles Vorgehen unterstützt, was dem Team die Möglichkeit gibt, von diesen das iterative Vorge Symptohen zu erlernen. Wenn das Experiment erfolgreich war, sollte nicht nur der Experte, sondern auch das Pilotteam das weitere Rollout unterstützen. 

In Abbildung 4 wurde schematisch dargestellt, wie ein gesetzter Zielbereich iterativ erreicht werden kann.
Wichtig dabei ist die Bildung eines Teams aus Personen mit Erfahrung aus Ihrem Unternehmen und den Experten, die die Skalierung vorantreiben. Wenn Sie sicherstellen wollen, dass die Skalierung höchste Priorität hat, sollte die einzige Aufgabe dieses Teams die Einführung und Unterstützung dieser Experimente sein. 

Mit der Einführung eines skalierten Ansatzes wollen Sie Ihre Produktentwicklung für Ihr gesamtes Unternehmen oder einen Bereich davon ändern. Dafür benötigen Sie ein klares Verständnis des Systems, in dem die Änderung durchgeführt wird. Wenn Sie sich auf die Optimierung eines Aspekts fokussieren, ohne Abhängigkeiten und Nebeneffekte zu berücksichtigen, kann die Veränderung zu einer Verschlechterung des Gesamtsystems führen [Rub12].
Löst das theoretische Modell tatsächlich alle Ihre Probleme und deren Ursachen oder lediglich einige davon? Machen Sie sich bewusst, wo das Modell Lücken hat und wie Sie diese schließen können.
Wenn Sie bereits Praktiken Ihres Modells im Einsatz haben, dann verifizieren Sie, dass diese den gewünschten Erfolg bringen und keine Nebeneffekte verursachen. Es besteht die Gefahr, dass nur Symptome beseitigt werden. Das eigentliche Ziel besteht jedoch immer darin, die Probleme ursächlich zu beseitigen.
In der „Lean Production“ gibt es die Praktik GEMBA (jap. „Ort des Geschehens“). Das bedeutet: „Überzeugen Sie sich selbst.“ Nur vor Ort können Sie ungefilterte Informationen aufnehmen und für sich selbst analysieren, ob Ihre theoretischen Annahmen der Realität entsprechen. Speziell in einem Prozess, in dem ein mitunter tief greifender Wandel etabliert werden soll, müssen Sie überprüfen, ob Ihre Annahmen auch tatsächlich eintreffen.
Vertrauen Sie als Führungskraft nicht nur Berichten, die Sie vorgelegt bekommen, sondern nehmen Sie sich die Zeit und lassen Sie sich von Ihren Mitarbeitern in deren Arbeit einweisen oder versuchen Sie, deren Probleme zu verstehen. Dadurch bekommen Sie selbst einen Eindruck von den einzelnen Bereichen und können diese in Ihre Gesamtsicht einfließen lassen. Besuchen Sie nicht nur Präsentationen des Teams, sondern besuchen Sie es auch während des Alltags. Was hindert Sie daran, einen halben Tag pro Woche bei den Teams direkt zu sitzen und Informationen aus erster Hand zu erhalten?  

Ziel einer Transition sollte nie die Einführung eines bestimmten Vorgehensmodells sein. Die Einführung eines solchen Modells kann nur ein Schritt zur Erreichung eines übergeordneten Ziels sein, wie etwa kürzere Installationszyklen und dadurch bessere Marktchancen.
Machen Sie sich deshalb die tatsächlichen Ziele immer wieder klar. Kommunizieren Sie sie dabei kontinuierlich, damit Sie auch jeden Mitarbeiter erreicht. Konzentrieren Sie sich auf wenige dafür klar verständliche Ziele.
Visualisieren Sie also Ihre Ziele und publizieren diese im Unternehmen, damit die Ziele immer im Auge behalten [Cov13] und die richtigen Entscheidungen getroffen werden.
Geben Sie den Mitarbeitern die Chance, dass sie Feedback zu den angewandten Praktiken geben können. Dieser Realitätsabgleich aus der Innovation [Mor14] eröffnet Ihnen unterschiedliche Sichtweisen. Sie erhalten ein klareres Bild, wo Sie auf dem Weg zur Zielerreichung tatsächlich stehen.

Eine nachhaltige Veränderung der Arbeitsweise, im Speziellen in Richtung der agilen Werte, bedeutet immer auch, dass sich die Unternehmenskultur ändern wird.
Durch eine dogmatische Einführung eines skalierten agilen Vorgehens ändern Sie nicht automatisch die Kultur eines Unternehmens. Vielmehr werden Sie sich in einer Vielzahl von Bereichen die Zeit nehmen müssen, damit erfahrene Mitarbeiter die Praktiken und das Vorgehensmodell erlernen können.
Ken Rubin hat die Haltung vieler Mitarbeiter auf der Keynote beim Scrum Gathering in New Orleans 2014 mit folgenden Worten beschrieben: „Bend over and let it pass.“ Ein Teammitglied meinte einmal zu mir: „Das ist doch wieder nur eine Prozesseinführung. Das hatten wir schon öfters. Einfach ruhig verhalten, dann ändert sich für uns nichts.“ Damals wurde mir klar, dass mit den Menschen im Team mehr gearbeitet werden muss, damit sie ihre Einstellung und Werte anpassen und den Mehrwert in der Veränderung erkennen. Wir müssen allen Mitarbeitern die Zeit geben, sich an die Veränderung zu gewöhnen und sie zu akzeptieren.
Daraus lässt sich schließen, dass wir mit einem dogmatischen Ansatz nicht alle Mitarbeiter eines Unternehmens mitnehmen können. Wir müssen auf die Bedürfnisse und Wünsche der Mitarbeiter eingehen und versuchen, ihre Probleme zu lösen. Das erfordert Zeit und enge Zusammenarbeit mit den Mitarbeitern, damit sie die dafür nötigen Praktiken beherrschen und die Gründe dafür verstehen. Damit sie lernen, dass die Praktiken ihnen selbst helfen sollen und auch, dass die Praktiken zur Disposition stehen, wenn sie nicht nützlich sind. Somit verändern sie stetig auch ihre Werte und ihre Kultur. Im Speziellen geben sie den Mitarbeitern die Sicherheit, dass ihr Arbeitsplatz nicht zur Disposition steht, auch wenn dieser durch Transparenz gläserner wird. Es ändert sich lediglich die Verantwortung. Von Experten, die ihr Wissen schützen, hin zu Experten, die Mitarbeiter emanzipieren, damit das Wissen im Unternehmen verteilt wird. Die Führungskräfte in Ihrem Unternehmen müssen dafür sorgen, dass diese Maßnahmen als Kriterien in den Mitarbeitergesprächen aufgenommen werden und nicht nur das Streben nach eigener Exzellenz gewertet wird.
Sie müssen auch auf den Einstellungsprozess für neue Mitarbeiter Einfluss nehmen. Klären Sie die zukünftigen angestrebten Werte und die Kultur Ihres Unternehmens mit den Bewerbern ab. Denn Unternehmen ziehen jene Personen an, die dieselben Werte haben wie das Unternehmen [Len12]. Dadurch wissen Bewerber, auf was sie sich in Ihrem Unternehmen einlassen. Sie werden dadurch einige Bewerber nicht für sich gewinnen, die die Umwandlung Ihres Unternehmens nicht mitgehen wollen, aber Sie werden jene Mitarbeiter finden, die sich darauf einlassen und damit einen Beitrag zur Umwandlung liefern werden.
Lencioni schreibt in seinem Buch „The Advantage: Why Organizational Health Trumps Everything Else In Business“, dass Organisationen nur einen Bruchteil ihrer intellektuellen Möglichkeiten, der Erfahrung und des Wissens ausnutzen [Len12]. Bei vielen Transitionen wurde mir immer wieder berichtet, dass „früher“, als das Unternehmen noch nicht groß war, bereits agil gearbeitet wurde. Die Mitarbeiter Ihres Unternehmens kennen also bereits einige der Praktiken und würden diese gerne wieder einführen, oft werden sie jedoch von zu starren Prozessen zurückgehalten. Versuchen Sie diese Erfahrung in Ihre Transition aufzunehmen und fragen Sie Ihre Mitarbeiter nach deren Meinung. Sie werden erkennen, dass die meisten gewillt sind, etwas an ihrer Arbeit zu verbessern.

Der Einfluss der technischen Faktoren wird bei der Skalierung oft zu stiefmütterlich behandelt. Die theoretischen Modelle setzen in den meisten Fällen auf einer grünen Wiese auf, was bedeutet, es gibt kaum Altlasten. Dies ist aber nur selten der Fall. Meistens haben Sie ein bestehendes Produkt mit gewachsener Organisationsstruktur, Programmcode und IT-Infrastruktur.
Das bedeutet: Wenn Sie dogmatisch ein theoretisches Modell verfolgen, können Sie sehr wahrscheinlich nicht von Beginn an von dem Modell profitieren und damit Ihre Entscheidung für das Modell nicht bestärken. In der agilen Softwareentwicklung lassen wir uns von Tools den Alltag erleichtern, aber nicht diktieren. Dadurch erreichen wir kürzere Zyklen, um unsere Software zu testen, sie zu entwickeln und zu installieren. Wir müssen dafür die Struktur und die technische Basis schaffen. Sie müssen die technischen Grundlagen schaffen, damit Sie die kurzen Zyklen auch tatsächlich erreichen, wie es in den theoretischen Modellen gefordert ist.
Sie müssen also Kompromisse zulassen und Ihre Altlasten ablösen und überarbeiten. Daraus lässt sich schließen, dass Sie keine dogmatische Einführung für das Modell verfolgen können. Diese wäre nur komplett oder gar nicht umzusetzen. Sie müssen deshalb nicht nur die Einführung eines Vorgehensmodells planen, sondern auch die Überarbeitung ihrer technischen Grundlagen, welche in jedem Produkt und in jedem Team anders aussehen kann. Bei diesem Punkt müssen Sie im Speziellen Ihre Mitarbeiter einbinden und bedenken, dass dies auch Zeit in Anspruch nehmen wird.
Eine Quellcodedatei mit über 1.000 Zeilen Code, der über Jahre gewachsen ist und externe Abhängigkeiten hat, können Sie leider nicht über Nacht auf mehrere Quellcodedateien oder Klassen nach Zuständigkeit aufteilen, damit er wartbarer und lesbarer wird. Diese technische Schuld müssen Sie abarbeiten und das müssen Sie bei der Skalierung einplanen, da es Auswirkungen auf das Gesamtsystem haben kann.

Unterstützt Sie ein Experte des theoretischen Modells? Haben Sie Schulungen besucht, damit Sie das theoretische Vorgehensmodell einführen können, und fühlen Sie sich jetzt als firmenweiter Experte? Unterstützen Sie die Einführung oder leiten Sie diese sogar? Dann machen Sie sich die systemische Fehleinschätzung bewusst: die Selbstüberschätzung und den Bestätigungsfehler. Denn viele Aspekte, die implizit in Modellen vorhanden sind, versteht man erst, wenn man längere Zeit in einem agilen Umfeld gearbeitet hat.
Die Selbstüberschätzung verleitet Sie dazu, Ihr eigenes Wissen über das Wissen der anderen zu stellen. Sie könnten dadurch wichtige Informationen der anderen Mitarbeiter übersehen oder die Mitarbeiter demotivieren, wenn Sie den Meinungen der anderen keinen Raum geben. Verwechseln Sie jedoch die Selbstüberschätzung nicht mit der Bestimmtheit, mit welcher Sie eine Aufgabe verfolgen.
Beobachten Sie auch die Art und Weise, wie Sie Ihre gesammelten Daten und Informationen interpretieren. Der Bestätigungsfehler verleitet eine Person dazu, dass sie die Daten und Informationen immer so interpretiert, dass sie ihre Erwartungen erfüllt. Um erfolgreich zu sein, dürfen Sie aber nicht die Daten analysieren, die Ihre Erwartungen bestätigen, sondern müssen auch die – für Sie und das Projekt – ungünstigen Daten sichtbar machen und bewerten.
Ein Ansatz der agilen Innovation ist es, Annahmen schnell durch unterschiedliches Feedback zu verifizieren (vgl. [Mor14]). In Einsatzorganisationen, wie etwa der Armee, werden nie die Daten analysiert, die das persönliche Ziel unterstützen, sondern es wird von dem Eintreten des schlimmsten anzunehmenden Falls ausgegangen.
Aus diesen systemischen Fehleinschätzungen unseres Gehirnes können wir erkennen, dass das dogmatische Festhalten an einem theoretischen Modell unsere Entscheidungen dahin gehend beeinflussen kann, alles so zu interpretieren, dass unser gewünschter Ausgang eintritt.
Als Unternehmen setzen Sie daher auf Transparenz. Verstecken Sie Ihre Rückschlüsse nicht vor Ihren Mitarbeitern. Geben Sie den Mitarbeitern die Möglichkeit, Ihren Entscheidungsprozess zu verstehen und Rückmeldungen zu geben. Dadurch erhalten Sie eine Fremdsicht, die auch Ihr Unternehmen kennt. Zusätzlich können Sie verifizieren, ob Ihre Rückschlüsse der Realität entsprechen. Wenn Sie also feststellen, dass Mitarbeiter mit einigen Entscheidungen nicht zufrieden sind, lassen Sie sich diese genauer beschreiben und laden Sie zu einem Dialog ein. Nur dadurch können Sie erkennen, welche Seite einer Fehleinschätzung unterlegen ist und können dadurch den Kurs korrigieren.

Es gibt, wie zu Beginn bereits erwähnt, viele skalierte agile Modelle, die Sie in Ihrem Unternehmen einführen können. Stellen Sie sich deshalb immer die Frage: „Wozu?“ Nicht nur das theoretische Modell müssen Sie hinterfragen, sondern auch jede Besprechung, jede eingesetzte Methode und Praktik. Auch warum es die Rollen gibt, die das Modell vorschreibt.
Im Artikel „Heart of Agile“ [HEAR] wird festgestellt, dass selbst die agilen Vorgehensmodelle bereits zu überladen sind.
Mir wurde dadurch klar, dass es nicht das Ziel ist, eine Praktik einzuführen, sondern zuerst zu verstehen: „Wozu will man die Praktik, das Vorgehensmodell oder die Besprechung einführen?“ Es gibt keinen dogmatischen Ansatz, der zum Erfolg führt – wir müssen verstehen, welche Problemursache wir lösen wollen, und müssen uns der Lösung durch Anwendung der vier Hauptaktionen annähern. Und dies in einem sich wiederholenden Zyklus (siehe Abbildung 5). Die Hauptaktionen stehen, laut Alistair Cockburn [HEAR], im Zentrum jeder agilen Entwicklung und sind: Ausliefern (Deliver), Reflektieren (Reflect), Verbessern (Improve) und Zusammenarbeiten (Collaborate).
Achten Sie deshalb bei einer Skalierung agiler Vorgehensmodelle darauf, dass Sie bei der Einführung die vier Hauptaktionen durchführen. Dadurch ist es davon unabhängig, welche Praktik Sie tatsächlich einsetzen. Wichtig ist, dass die eingesetzte Praktik die Hauptaktionen fördert und unterstützt. Das verändert die Diskussion darüber, welche Praktik nun tatsächlich eingesetzt werden soll, weg von einer dogmatischen Diskussion, hin zu einer Diskussion, wie die vier Hauptaktionen am besten gefördert werden können.  

Es ist essenziell, dass es theoretische Modelle gibt, die uns einen ersten Anhaltspunkt liefern. Nutzen Sie theoretische Modelle. Lernen Sie diese kennen und setzen Sie sie ein. Beachten Sie aber, dass es kein Modell gibt, das für alle Projekte und Unternehmen funktioniert. Legen Sie sich deshalb nicht zu früh auf ein Modell fest, sondern verwenden Sie die Modelle, solange sie hilfreich sind und zu beobachtbaren Verbesserungen führen.
Aus persönlicher Erfahrung: Vermeiden Sie theoretische Diskussionen über Pros und Kontras der einzelnen Modelle. Diskutieren Sie vielmehr die Praktiken immer im Kontext Ihres Unternehmens. Ist es tatsächlich schlussendlich entscheidend, ob Sie Kanban oder Scrum einsetzen? Finden Sie Ihren eigenen Weg. So wie es auch einst Steve Jobs (2005, Stanford Commencement Address) sagte: „Deine Zeit ist begrenzt und deshalb solltest du sie nicht darauf verschwenden, das Leben eines anderen zu leben. Lass dich nicht von einem Dogma festhalten – mit den Ergebnissen/Gedanken anderer leben zu müssen.”
Setzen Sie für Ihre Transition ein Ziel und verfolgen Sie es. Inkludieren Sie Ihre Mitarbeiter in die Skalierung und geben Sie die Zeit, dass Altlasten aufgearbeitet werden. Sie werden dadurch Ihre Mitarbeiter motivieren, ein Teil der Veränderung zu werden, und Sie werden ein Modell erhalten, das auf Ihr Unternehmen und die Bedürfnisse des Unternehmens zugeschnitten ist.