Zwischen Tradition und Wandel - Die Geschichte eines

„Sie sind es, die die Transformation von Unternehmen und Branchen vorantreiben: mutige Querdenker, risikobereite Andersmacher und Visionäre. Jeder Wandel, jede Innovation braucht Menschen, die über Grenzen hinweg denken, den Status Quo hinterfragen und andere von ihren Ideen überzeugen. Wir nennen sie Vordenker, Rebellen oder Treiber„, so Haufe in der Aufforderung zur neusten Blogparade mit dem Hashtag Organisationsrebellen. An dieser möchte ich mich gerne beteiligen und habe mir vorgenommen folgende Fragen zu diesem Thema zu beantworten:

Was sind meine ganz persönlichen Erfahrungen in meinem Leben als Rebell?
Welche Best Practices kann ich weitergeben – und was waren meine größten Fehler, aus denen andere lernen können?

Im ersten Schritt möchte ich meine ganz persönliche Geschichte über einen Change erzählen, an dem ich ein ganzes Jahr beteiligt war. Aus dieser Geschichte leite ich Best Practices ab, die einem Organisationsrebellen im Alltag helfen können. Die folgende Geschichte hat sich in den letzten 3 Jahren im Laufe meiner Beratertätigkeit ereignet. Ich möchte keine Zeiträume nennen, da das Unternehmen anonym bleiben soll. Im Folgenden wurden einige Details verändert, damit das Unternehmen nicht nachvollzogen werden kann. Eingestellt als Consultant, fand ich mich dort in einem Umfeld aus Tradition und Wandel wieder.

Lesetipp: KMU zwischen Tradition und Wandel

Meine ganz persönlichen Erfahrungen

Eines Tages habe ich ein spannendes Projekt erhalten. Ich sollte ein Jahr lang ein Unternehmen unterstützen, eine Abteilung neu zu strukturieren und neben Beratung auch den Change mit Management und Mitarbeitern anpacken.

Von heute auf morgen zum Rebellen

Veränderungen sind schwer – kaum jemand mag sie. Schon gar nicht in einem Konzern mit festen Strukturen. Doch um ein Unternehmen weiter voranzubringen, sind Veränderungen essentiell. Also wurde ich von einem Unternehmen dazu berufen, eine Abteilung mit knapp 100 Mitarbeitern neu zu strukturieren. In 50 Prozent meiner Zeit half ich den verantwortlichen Managern, die Organisation zu ändern – die anderen 50 Prozent übernahm ich wichtige Projekte mit agilen Methoden. Ich war also gekommen, um etwas zu verändern – ein Organisationsrebell – den vielleicht nicht alle Mitarbeiter im ersten Moment mit offenen Armen empfangen.

Planung, Planung, Planung und Klappe halten

Mir hat einmal ein sehr bekannter agiler Kopf und Buchautor vor ein paar Jahren den Tipp gegeben: „Wenn du wo neu reinkommst, dann halte erstmal die Klappe und schau dir alles genau an.“ Genau das habe ich getan. In den ersten Wochen war ich damit beschäftigt, mich einzuarbeiten, Prozesse zu verstehen und habe mir von den Seniors das Unternehmen erklären lassen. Zusammen mit dem Manager und seinen Teamleitern trafen wir uns regelmäßig zu Tagesworkshops über die Planung der neuen Abteilung. Speziell am Anfang hörte ich aufmerksam zu. Ich brachte weniger eigene Ideen ein, sondern überlegte mir, wie ich die Visionen des Managers konkretisieren kann. Bevor ich eine Idee anbrachte, habe ich diese meist mit einem der Teamleiter im persönlichen Gespräch abgestimmt. Wenn Sie übrigens etwas Theorie lesen wollen, können Sie meinen Artikel zur Organisationsentwicklung anklicken.

Lesetipp: Organisationsentwicklung

Das Zielbild war geschaffen!

Nach einiger Zeit hatten wir das Zielbild für die Abteilung definiert. Folgende Rahmenbedingungen hatten wir zu beachten:

Konform zur zertifizierten Norm
Konform zu Prozessen anderer Abteilungen
Viele Menschen, die nicht alle agil arbeiten wollen
Verschiedene Kunden, die auch nicht alle begeistert von Agilität waren
höchste Flexibilität bei maximaler Stabilität

Aktuell gab es im Unternehmen sehr große Teams, die nach klassischen Methoden arbeiteten. Dies sollte geändert werden. Wir hatten die Idee zwei neue Teamleiter zu bestimmen und aus zwei Teams nun vier Teams zu formen. Diese sind:

Interne IT: Automatisierung und Betrieb – Kanban
Projektteam – große Kundenprojekte – komplette Selbstorganisation und Autonomie
DevOPs: Für mittlere Projekte und agile (Scrum) Kunden – Scrum und DevOps
Klassische Einheit: Kleinkunden und Kunden mit Standardaufgaben – ITIL

Challenge accepted! Um dies umzusetzen, haben wir uns ein Modell mit vier Schritten überlegt. Ein Teil der Mitarbeiter sollten noch weiter in der alten Organisation arbeiten, der andere Teil zog langsam mit den Kunden um. Wichtig war uns, dass die Stabilität der Abteilung aufrechterhalten blieb. Dazu habe ich eine Grafik erstellt – auf die einzelnen Phasen gehe ich später noch genauer ein. Zur Erklärung: DevOps ist ein Kunstwort, dass sich aus den Worten Development und Operations zusammensetzt.

Mit voller Kraft gegen die Wand

Nach einigen Wochen kam ich in mein erstes Projekt, das ich in 50 Prozent meiner Zeit durchführen sollte. Ich hatte eine Projektleitung für einen großen Kunden. Über mir gab es noch einen Programmmanager und unter mir zwei Teilprojektleiter. Ich tat also das, was ich im Zielbild gelernt hatte und organisierte dieses Projekt so agil wie es mir möglich war.

Ein Aspekt dieser Agilität bestand darin, den Teilprojektleitern hohe Freiheiten und Autonomie in ihrer Aufgabenerledigung zu lassen und ihnen als Scrum Master den Rücken freizuhalten. Auch sah ich mich eher als Anwalt vor dem Kunden und der Programmleitung. Leider fiel mir erst viel zu spät auf, dass mein Projekt vollkommen aus der eher ITIL-orientierten Linie des Programms tanzte und trotz des Erfolgs für den Programmanager als unkontrollierbar und chaotisch wahrgenommen wurde. ITIL ist eine Art eine IT zu organisieren und ist oft nicht einfach mit agilen Methoden zu vereinbaren.

Besser: Leider fiel mir erst viel zu spät auf, dass zwei Welten auf einander prallten. Agilität gepaart mit einer ITIL-orientierten Linie des Programms ließ mein Projekt aus der Reihe tanzen. Trotz des Erfolgs nahm der Programmanager den Change als unkontrollierbar und chaotisch wahr.

Um sein Projekt zu schützen, durfte ich nach drei Monaten überraschend meinen Hut aufsetzen und „gehen“ – die Einheit wurde wieder klassisch organisiert. Ich hatte es also geschafft! Ich flog nach drei Monaten aus meinem ersten Projekt. Glücklicherweise stand der Manager meiner Abteilung hinter mir und beschloss, mir einfach ein neues Projekt zu geben. Es gab dort nur mich als Projektleiter und ein Team. Der Vorgänger sollte mich einarbeiten. Wenn Sie übrigens mehr zur Etablierung von Scrum in klassischen Unternehmen lesen wollen, dann habe ich hier ein kostenloses Whitepaper für Sie!

Lesetipp: Agile in the Waterfallworld

Networking schafft Abhilfe – das Change Board

Zwischen dem alten und neuen Projekt vergingen jedoch zwei Monate und ich konnte mich dem Change widmen. Nachdem ich am Tag des Ausschlusses recht früh nach Hause bin, war ich dafür am nächsten Tag umso früher im Büro. Ich nutzte die nächste Zeit mit 40 der 60 Mitarbeiter ein kurzes Einzelgespräch von 15 min zu führen und machte mir Notizen. Ich bildete Cluster und hatte die Wünsche und Anregungen der Abteilung auf einen Blick für den Manager grob zusammengefasst. Nun bildeten wir das Change-Board, das aus folgenden Mitarbeitertypen bestand:

Starker Skeptiker gegen Veränderung
Kennt viele Leute
Ist sehr engagiert und hat viele Ideen
Teamleiter anderer Abteilungen

Im ersten Anlauf haben wir dem Change Board einen Plan vorgestellt und die neuen Teams. Gemeinsam mit dem Board haben wir einen Backlog mit Aufgaben gefüllt. Alle zwei Wochen fand ein Sprint statt und jeder Mitarbeiter durfte sich aus dem Change Board Aufgaben nehmen. Jeder der zehn Teilnehmer hat mit angepackt. Teamleiter wurden aus angrenzenden Abteilungen eingeladen, mit der Bitte Feedback zu geben. Nach vier Sprints hatten wir alle Vorbereitungen abgeschlossen und konnten den Change beginnen. Jede Phase war genau durch vier Sprints zu je zwei Monaten abgebildet.

Mit neuEm Anlauf und klassischen Methoden

Nun startete ich mein neues Projekt, das ich neben dem Change durchführen sollte. Es war wieder ein großer Kunde mit einem innovativen Technologiestack. Ich habe diesmal genau die Methodik des Vorgängers übernommen und das Projekt vorerst genauso weitergeführt. Ich wollte exakt den Status Quo erreichen. Dies habe ich anscheinend geschafft und holte mir langsam das Vertrauen des Teams – auch das des Managements. Ich widmete mich also zu 50 Prozent dem Change und zu 50 Prozent dem klassischen Projektmanagement.

Durchhalten und Marketing machen

Nun hieß es durchhalten und die Sprints des Changes weitertreiben. Jede Woche gab es ein Statusmeeting und alle zwei Wochen war Review und Retrospektive. Die Teilnahme am Change Board war freiwillig und ich sah meine Aufgabe darin, immer wieder zu motivieren weiter dran zu bleiben. Wir haben uns Sprint für Sprint weiter vorgearbeitet.

Im Zuge meines Projekt habe ich neben dem Change immer mehr vom klassischen Projektsystem nach Jira umgezogen und wir haben erste kleine Sprints durchgeführt. Ich hatte mittlerweile mehr Vertrauen im Unternehmen und durfte das Projekt langsam etwas agiler gestalten.

Jeder Change hat auch ein Ende

Jeder Change muss auch irgendwann mal abgeschlossen sein. Die ersten Phasen waren größtenteils eine technische Umstellung sowie der Umzug in die neuen Büros und das Umsetzen der Mitarbeiter. Später kam vor allem das Coaching und das Zurechtfinden in den neuen Rollen hinzu. Es war auch so, dass man sich freiwillig für ein Team melden konnte. Die letzten 25 Prozent der Mitarbeiter mussten allerdings eher überredet werden, in die neue Organisation zu wechseln. Ich habe jeden einzelnen von ihnen individuell begleitet und versucht, zu helfen.

Es geht weiter: Nach agil kommt virtuell

Nun ist der Change abgeschlossen und ich muss sagen: Es hat Spaß gemacht und wir sind alle der Meinung, dass wir gute Arbeit geleistet haben. Der Change gilt auch offiziell als abgeschlossen und andere Abteilungen folgen eventuell. Ich habe nicht, wie vielleicht erwartet, im Anschluss meine Sachen gepackt, sondern habe eine weitere Mission für den Manager angenommen: Das Unternehmen hat zwei neue Standorte aufgebaut. Ich sollte das erste virtuelle Team des Unternehmens coachen, das über drei Standorte verteilt ist. Doch dies soll ein Thema für einen neuen Artikel werden.

Fazit: Best Practices für den Organisationsrebellen

Der Change hat mir sehr viel Spaß gemacht und ich freute mich auf die Folgeaufgabe. Nun leite ich aus meinen Erfahrungen meine Do’s und Dont’s für Organisationsrebellen ab. In erster Linie sollte sich ein Change-Agent eher als Anwalt der Veränderung sehen, also diese immer wieder verteidigen, statt wie ein Priester zu predigen. Auch ist netzwerken wichtig, um die Meinungsführer im Unternehmen mitzunehmen. Weiterhin sollte am Status Quo gearbeitet werden, denn ein klassisch geführtes Unternehmen wird nicht von heute auf morgen Google oder Spotify.

Außerdem ist es speziell am Anfang wichtig, erst einmal zuzuhören und das Vertrauen der Mitarbeiter zu gewinnen. Auch sollten Sie als Rebell nicht eigene Ideen verwirklichen, sondern schauen, was die Unternehmensleitung wirklich erreichen möchte. Sicher muss das dann nicht immer 100 Prozent agil sein. Auch ITIL-Organisationen können agil sein und sind für gewisse Kundenprojekte sehr wichtig. Denken Sie immer daran, dass Sie sich zwischen Tradition und Wandel befinden. Vieles, das Rebellen ändern wollen, ist vielleicht sogar der Garant des Erfolgs der letzten Jahre gewesen.

Kommen wir zu den Dont’s. Wichtig ist, nicht zu polarisieren, sondern eher im Hintergrund zu bleiben. Auch sollten nicht die eigenen Ziele verfolgt werden, wie beispielsweise alles agil machen zu wollen. Klar wollte ich einmal das LeSS Framework ausprobieren, aber das war für unsere Kunden einfach nicht sinnvoll. Das LeSS Framework ist übrigens eine Methode Scrum zu skalieren. Falls Sie mehr zu agiler Skalierung lesen möchten, geht es hier zum Artikel. Ein Change ist auch keine Sache von wenigen Tagen und braucht Zeit. Wir haben ein Jahr in den Change investiert. Weiterhin ist es wichtig, alle Mitarbeiter abzuholen und mitzunehmen, sonst verlieren Sie die Meinungsführer des Unternehmens und es geht Ihnen wie mir, dass man auch einmal aus einem Projekt fliegt. Ein toller Spruch, den ich im Change immer wieder genutzt habe, ist: Gras wächst nicht, wenn man daran zieht. Menschen brauchen Zeit sich langsam an die neue Situation anzupassen – denn der Job bedeutet für alle die Sicherung der Existenz. In der folgenden Abbildung habe ich meine Erkenntnisse zusammengefasst:

organisationsrebellen — Handlungsempfehlungen für den Organisationsrebellen

Genderhinweis: Seit Anfang 2022 achte ich darauf, dass ich immer genderneutrale Formulierungen verwende. Vor 2022 habe ich zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen, Diverse als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.

Rechtschreibung: Ich führe diesem Blog neben dem Job und schreibe viele Artikel in Bahn/Flugzeug oder nach Feierabend. Ich möchte meine Gedanken und Ansätze als Empfehlungen gerne teilen. Es befinden sich oftmals Tippfehler in den Artikeln und ich bitte um Entschuldigung, dass ich nicht alle korrigieren kann. Aber Sie können mir helfen: Sollten Sie Fehler finden, schreiben Sie mich gerne an! Lesen Sie mehr dazu.

Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mir

Sie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne! Sie können dadurch Kunden und Fachkräfte ansprechen.

Ich suche aktuell außerdem Werbepartner für Bannerwerbung für meinen Blog. Sollte es für Sie spannend sein Fachkräfte oder Kunden auf Ihre Seite zu leiten, dann bekommen Sie mehr Informationen hier.

Tipp: Ich vergebe auch über den Blog eine gratis Zertifizierung zum Digital & Agile Practioner!

Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?

Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:

Verwendete Quellen anzeigen