Warum borisgloger?

Die 10 häufigsten Fragen unsere Kund:innen hat Boris Gloger für Sie beantwortet.

Boris Gloger beantwortet die 10 häufigsten Fragen an das Unternehmen.

1. Welche konkrete Beispiele habt ihr, bei denen ihr Kund:innen mit schwierigen Herausforderungen geholfen habt?

Created with Sketch.

Wir zeigen Unternehmen seit 2009, wie sie mithilfe von agilen Managementframeworks ihre Projekte zuverlässiger und schneller entwickeln. Darum ging es immer und mein erstes Buch heißt genau aus diesem Grund: Scrum – Produkte zuverlässig und schnell entwickeln.

Egal, ob es Kund:innen aus dem E-Commerce, dem Handel, dem Automobilbau, der Finanzbranche, der Werbebranche, der Medizintechnik oder aus dem Bereich der NGOs sind – es sind viele Projekte und Teams zustande gekommen. Wir haben geholfen, Massenspektroskope, Vakuumventile, Flugsimulatoren, Notrufzentralen, E-Commerce-Shops, Webplattformen, Versicherungsprodukte und Kommunikationssysteme zu entwickeln. Verwaltungs- und HR-Prozesse wurden mit agilen Mitteln beschleunigt und große SAP-Implementierungen mit Hilfe von agilen Frameworks verbessert.


Dabei wurden Visionsworkshops, Teambuildingmaßnahmen, mehrere hundert Trainings, sicherlich an die 10.000 Meetings und hunderte von Führungskräfteteams begleitet. Tausende Menschen sind durch unsere Trainings und Einführungskurse mit den agilen Methoden vertraut gemacht worden. Allein die Anzahl an Taskboards, die wir im Laufe der Jahre mit unseren Teams entwickelt haben, vorzustellen – kilometerlang wäre die Aneinanderreihung der vielen physischen und virtuellen Boards.  

Wir haben mit großen DAX-Konzernen und kleinen Unternehmen, mit internationalen Mittelständlern und Medizintechnik-Start-ups in Großbritannien zusammengearbeitet. Wir arbeiteten mit Teams im In- und Ausland, mit Projektteams, die auf vier Ebenen, vier Gebäuden aber auch auf vier internationale Standorte verteilt waren, in Projekten mit mehr als 250 Personen sowie mit kleinen Teams aus 3 Personen. Mit Vorständinnen und Vorständen, Lehrerinnen und Lehrern, Wissenschaftlerinnen und Wissenschaftlern sowie natürlich auch Softwareentwicklerinnen und Softwareentwicklern.

Damit Sie sich ein wenig vorstellen können, worum es bei diesen Engagements ging – hier so anonymisiert wie möglich, denn die meisten Unternehmen sind sehr verschwiegen – einige Beispiele: Wo wir die Freigaben haben und die eine oder andere Fallstudie geschrieben haben, findet sich der Hinweis auf die Fallstudie.

Herausforderungen und Beispiele für unser Engagement

Der Projektmanager eines großen IT-Projekts rief an und erklärte mir, er wolle wissen, ob man mit Hilfe von Scrum 180 Entwickler:innen dazu bringen könnte, in 9 Monaten ein Produkt im Umfang von circa 100 Millionen Euro zu liefern. Wir konnten - 3 Monate später waren 180 Entwickler:innen in 18 Teams organisiert, alle 4 Wochen wurde Software geliefert, der Marketingvorstand war zufrieden und die Software ging 10 Sprints zu 4 Wochen live.


Der Programmleiter eines Entwicklungsteams, das eines der ganz großen internationalen Web-Portale für einen Kunden entwickelte, wusste nicht weiter. Die Synchronisation seiner mehr als 160 Entwickler:innen funktionierte nicht mehr. Die Abstimmungen mit dem Kunden und auch untereinander funktionierte nicht. Statt neue Funktionalitäten zu liefern, wurde mehr und mehr Bug-Fixing betrieben. Eine Lösung war eines der ersten Big-Room-Plannings, die es weltweit gab (Nannte man damals noch nicht so – ich nannte es Massensprint-Planning.) Wir hatten alle User Stories an der Wand und ich erfand die Synchronisation der Teams während des Sprint Plannings. Es war irre – funktionierte, und wurde später der Blue-Print für alle großen Implementierungen. Wir unterstützen hier auch mit Trainings und on-the-job-Coaching, machten die Taskbaords besser, coachten die ScrumMaster – doch entscheidend war: Nach nur 4 Wochen lieferten die Entwickler:innen wieder wesentlich mehr Funktionalität.

Ein Abteilungsleiter zuständig für die Betreuung eines großen SAP-Systems – alle Kundendaten, alle Verträge, alle Leistungen wurden mit diesem System geliefert, wollte höhere Transparenz und bessere Qualität und natürlich wissen, ob zuverlässiger geliefert werden konnte. 6 Monate später entwickelten 200 Entwickler:innen agil und lieferten die Projekte in einem Drittel der Zeit mit weniger Defects als sonst und dank automatisierter Testverfahren war die Qualität um Längen besser.

Viva Con Agua veranstaltet jedes Jahr die Millentor Gallery. Sie machen das großartig doch der Stress vor dem Festival ist immens, alles hängt an wenigen Personen, danach brauchen alle immer eine größere Pause. Wir unterstützten das 5-köpfige Team, entwickelten neue Kommunikationsprozesse, etablierten ein neues Management und Lieferkultur und die Mitarbeiter:innen, deren Zahl dann um das Festival herum auf 150 anwachst, wurden durch klare Prozesse und hohe Transparenz gesteuert. Die Geschäftsführerin war sogar durch einen Unfall in den letzten 10 Tagen vor Eröffnung nicht in der Lage, da zu sein. Es machte einen Unterschied, doch ihre Mannschaft kam so gut klar, dass sie sich um ihre Genesung kümmern konnte.

In einem Produktionsbetrieb zeigte sich, dass die Produktionsmitarbeiter:innen einen Weg brauchten, um offensichtliche Fehler während der Montage untereinander zu kommunizieren. Wir entwickelten mit der IT vor Ort, also fast in der Montagehalle, ein Kommunikationssystem iterativ und inkrementell und konnten so das Problem in wenigen Tagen prototypisch und dann in wenigen Wochen produktionsreif lösen. Ein Projekt das normalerweise sicher Jahre auf sich hätte warten lassen.

Ein Kunde wollte wissen: Wie können wir IT-Unternehmen bei der Rekrutierung und Integration (weiblicher) ausländischer Fachkräfte unterstützen? Also aus Übersee, Afrika, Asien, Südamerika. Wir setzten ein cross-funktionales Team aus Young Professionals aus vielen Ländern in einer remote Arbeitsumgebung zusammen und moderierten mit ihnen einen Innovationsprozess. Nach 6 Wochen konnte das Team viele Möglichkeiten vorweisen, die alle ausprobiert worden waren. Dieses Verfahren wurde von unseren Schwester-Unternehmen unter Leitung der Co-Founderin Andrea Kuhfuss ausführlich in diesem Buch “Agile Innovation Sprint” beschrieben, das Ergebnis dieses Projekts lässt sich hier nachlesen.  

Bei der KfW Entwicklungsbank stießen die herkömmlichen Arbeitsmethoden an ihre Grenzen. Als Lösung entwickelte wir mit dem Umsetzungsteam „Front-to-end“ (FRED) ein neues Zusammenarbeitsmodell (ZAM), das auf 4 klar definierten Prinzipien basiert.  Wir setzten das gemeinsam mit den Kolleg:innen um, schulten Mitarbeiter:innen in agilen Methoden und begleiteten die Teams praktisch. In 9 Monaten nahmen rund 500 der 800 Angestellte an mindestens einer Schulung teil, 40 Team-Coachings wurden durchgeführt und etwa 10 Treffen von „Communities of Practice“ organisiert. Zudem bildete FRED mit den externen Berater:innen und der neuen Abteilung für Innovation ein Transformationsteam, um Hindernisse zu identifizieren und die zukünftige Ausrichtung der Transformation voranzutreiben. Mehr dazu

In unserem Projekt mit der Raiffeisen Bankengruppe Österreich haben wir die Umstellung auf eine digitale und kund:innen-orientierte Bankstruktur unterstützt. Ziel war es, die Bank mit ihrer traditionellen regionalen Verankerung digital zu transformieren, basierend auf der Vision „regional.digital.überall“. Durch die Implementierung eines Microservice-Architekturkonzepts und intensives Rollencoaching gelang es uns, agile Prozesse zu etablieren. Dies beinhaltete auch das Shadowing-Konzept zur Wissensintegration und regelmäßige Review Events für kundenorientierte Produktentwicklungen. Innerhalb eines Jahres formten wir 15 Scrum-Teams und bildeten interne Agile Coaches aus. Die Transformation manifestierte sich im Launch der Onlinebanking-Lösung „Mein ELBA“ 2017, ein direktes Ergebnis unserer agilen Methoden. Mehr dazu

Von April 2021 bis Mai 2022 unterstützte borisgloger die Webasto Group, einem internationalen Automobilzulieferer mit über 15.700 Angestellt:innen weltweit, bei der Einführung eines agilen Arbeitsmodells für die Produktentwicklung. Ziel war es, die Reaktionsfähigkeit und Effizienz der Entwicklungsstandorte zu verbessern. Mit unserer Beratung entwickelte Webasto iterativ ein maßgeschneidertes und anpassbares agiles Modell, das „Webasto AHEAD Framework“. Dieses Rahmenwerk wurde auf einer theoretischen Grundlage aufgebaut und während der Pilotphase durch praktische Erfahrungen stetig optimiert. Das Modell ermöglicht es Webasto, zukünftige Anpassungen eigenständig vorzunehmen und kontinuierlich weiterzuentwickeln. Mehr dazu

65 Entwickler:innen – damals in einem der bedeutenden deutschen Start-ups – lieferten nichts mehr. Alle arbeiteten viel, waren engagiert, doch die Features tröpfelten nur noch, die Releases waren unvorhersehbar und alle waren gestresst. Der damalige CTO rief mich an und fragte, was man machen könnte. Ich fragte ihn: „Wie mutig bist du? Wollen wir alle auf einmal umstellen?“ Das hatte damals noch niemand gemacht. Normalerweise ging man bedächtig vor: Erst ein Pilot-Team, dann das nächste und so weiter. Wir vereinbarten das genaue Gegenteil: alle Teams auf einmal. Wenn wir als Consulting-Team in 14 Tagen kämen, wäre die Organisation bereit und hätte die entsprechende Infrastruktur. So war es: Wir trainierten die Teams und alle Beteiligten einen Tag lang und starteten. 3 Sprints später – nach 6 Wochen – waren alle von Scrum überzeugt, denn die Tester:innen waren nun Teil des Teams, die Marketing-Fachleute waren glücklich, denn ihre Ideen wurden umgesetzt und das Beste: Die Funktionen, die gezeigt wurden, waren qualitativ so hoch, dass es keine Nacharbeiten mehr brauchte. Nur kurze Zeit später konnte diese Firma ohne unsere Unterstützung weitermachen.

Eine Abteilung aus 150 Menschen, die unter anderem die Software für eine sehr kritische neue Infrastruktur schrieben, bekam ihr wichtigstes Projekt nicht fertig. Es war bereits einige Jahre zu spät. Obwohl Teile des Produktes schon bei Kund:innen  liefen, erzeugte das sogar mehr Stress, denn nun kamen die Anforderungen der Kund:innen, die gerne Änderungen an dem Produkt hätten. Nach einigen Workshops wurde klar: Wir müssen die Abteilung völlig neu aufstellen. Wie wir das gemacht haben: Wir haben die Teams selbst in einem Workshop, der 45 Minuten dauerte, gebeten, sich auf die entsprechenden Bereiche wie Wartung, neues Produkt und Unterstützung der anderen aufzuteilen. Nach 45 Minuten hatten sich alle aus dem Bereich selbst zugeordnet und wir konnten fokussiert loslegen. Alles, was ich getan hatte, war das Prinzip Law of Two Feet aus der Open Space Technologie anzuwenden.

Fazit

Das sind aus hunderten Projekten und tausenden Problemen, die wir als Consultants lösen konnten, nur eine Handvoll Beispiele.

Agile Frameworks unterstützen uns, die Herausforderungen unserer Kundinnen und Kunden zu lösen, doch sie selbst lösen die Probleme nicht. Es ist die Kunst unserer Consultant-Teams, dabei zu unterstützen, sich zu fokussieren, das Richtige zu liefern und die vielen Probleme zu lösen, die sie hindern, ihre Arbeit effektiv zu machen. Wir haben viel gesehen und bringen unsere Erfahrung gerne ein, und damit gehen wir über das reine Vermitteln von Fertigkeiten, wie das Durchführen von Meetings, hinaus.

Gerne sprechen wir über Möglichkeiten persönlich und finden gemeinsam mit Ihnen die Lösung auch für Ihre Herausforderung. Eine Patentlösung gibt es dabei in der Regel nicht, doch wunderbare Handlungsprinzipien, die wir in den oben genannten Projekten angewendet haben.

2. Wie viel kostet eine Beratung und ist sie wirklich rentabel?

Created with Sketch.

Die lapidare Antwort von Berater:innen ist es häufig: Es kommt darauf an. Ganz häufig wird dann das Problem auf denPreis der Tagessätze reduziert. Das ergibt dann zwar einen ersten Richtwert, doch in Wahrheit sagt das noch nichts zu den Kosten, die auf eine Organisation zukommen werden, wenn sie sich entscheiden ein Team oder eine Abteilung agil begleiten zu lassen.

Der Tagessatz sagt noch nichts darüber aus, was das Projekt am Ende kosten wird, denn es hängt sehr von dem ab, was bei dieser speziellen Implementierung tatsächlich gebraucht wird.

Aufbau der Leistungen in einem Angebot

Doch natürlich kann und muss man diese Frage spätestens beim Erstellen eines Angebots beantworten und konkretisieren. Um hier einmal eine Einschätzung zu geben, schauen wir uns doch einfach den Aufbau der Leistungen eines Angebots an.  

1. Auftragsklärung: bei größeren Projekten meist ein Workshop

2. Bestandsaufnahme: ein bis mehrere Workshops

3. Training aller Beteiligten in der jeweiligen Methodik: z.B. ein ScrumMaster Training oder ein agile Intro-Training, ein- bis zweitägiges Training

4. Betreuung eines Teams über den Zeitraum von 6 Wochen

  • Hier kann es aber auch schnell dazu führen, dass bereits 2 oder 3 Teams betreut werden sollen.
  • Hier könnten viele Trainings-Elemente hinzukommen.
  • Hier kann es auch dazu kommen, dass noch weitere Skills zugekauft werden müssen.


5. Kommunikation der Ergebnisse in das Unternehmen durch einen Bericht oder eine kontinuierliche Kommunikationsbegleitung.

6. Arbeit mit den Führungskräften, um auch hier eine Veränderung zu erreichen


7. Reporting/Dokumentation der Maßnahmen

8. Einen Lessons-Learned- und einen Next Step Workshop am Ende der ersten 6 Wochen.

9. Dazu kommen dann noch weitere Gespräche und Abstimmungsmeetings bei Bedarf

Wer sich die obigen Themen durchliest und nur kurz überschlägt, wie viel Aufwand in diesen Arbeiten steckt und kurz überlegt, welche Skills die Menschen, die all das durchführen sollen, benötigen, wird uns sicher zustimmen - das braucht Erfahrung und Ausbildung in mehr als agilem Management.

Das führt uns zu der Antwort, warum eine qualitative agile Implementierung tatsächlich nicht zum Discount-Preis zu bekommen ist.

Consultants, die das alles durchführen können, brauchen:

1. Skills im Führen von Teams und großen Projekt-Organisationen,

2. die Kompetenz effektive Meetings, Trainings und Workshops durchzuführen,

3. die Fähigkeit innerhalb von Teams und mit dem Rest der Organisation eine vertrauensvolle Zusammenarbeit aufzubauen,

4. das Wissen, wie man dieLieferfähigkeit erhöht und technische Schulden abbaut und

5. ein hohes Maß an Problemlösungskompetenz

Wir setzen dafür Mitarbeiter:innen ein, die wir nicht nur auf interne Ausbildungen geschickt haben, sondern auch zu externen Coaching- und Facilitation-Ausbildungen, die die verschiedenen agilen Managementformate nicht nur kennen, sondern diese auch trainieren können und die einschlägige Kollaboration-Tools wie Slack, MS-Teams, Zoom, Miro, Jira, Asana uvm. beherrschen sowie wissen, wie sie Sachverhalte visuell für die Teams aufbereiten können.

Daher kommt es vor, dass wir, um unseren Qualitätsstandard halten zu können, für die Betreuung eines einzigen Teams über den Zeitraum von 6 Wochen zwischen 40.000,- und 50.000,- Euro verrechnen müssen. Damit liegen wir nicht an oberster Stelle der Skala für Beratungsleistungen für diesen Umfang, bieten unsere Leistungen aber auch nicht zu einem Diskontpreis an.

Um nun ein wenig konkreter zu werden

Lasst uns schauen, wie diese Zahl zustande kommt.  In der ersten Zeit der Zusammenarbeit, den ersten 3 Sprints(1 Sprint à 2 Wochen), setzen wir auf eine Vollzeitbetreuung des oder der Teams durch einen ScrumMaster oder Agile Coach, also 4-5 Tage über einen Zeitraum von 6 Wochen für eine:n Berater:in.

Damit stellen wir auf operativer Ebene die Einführung des agilen Arbeitsmodells langfristig und erfolgreich sicher. Parallel dazu findet in der Regel die Zusammenarbeit mit dem Transformation Team oder dem Management auf strategischer Ebene statt, damit hier der Rahmen derOrganisation so angepasst und zur Verfügung gestellt werden kann, um agiles Arbeiten überhaupt erst nachhaltig möglich zu machen. Hier kommt einer unserer Transformation Coaches zum Einsatz, der ein bis zweimal wöchentlich mit dem Transformationteam des Kunden arbeitet.

Nach dieser intensiven ersten Phase schauen wir: Wie weit ist das Team? Können wir die Zusammenarbeit ein wenig zurückfahren? Wenn dem so ist, wird die Begleitung auf ca. 2 Tage / Woche über die nächsten 3 Sprints reduziert.

Bei einem unserer Kunden haben wir wochenlang in vielen Workshops zuerst mit den 8 Führungskräften gearbeitet – um hier eine einheitliche Linie zu erreichen, und dann wurden anschließend mit den 150 Mitarbeiter:innen in weiteren Workshops gearbeitet. Dieser Prozess zog sich über mehrere Monate.

Rechnet sich das für Unternehmen?

Wir denken schon. So haben wir u.a. bei einem unserer Kundenprojekte 3 unserer Consultants innerhalb von nur 3Monaten  nicht nur  Planungsaufwände von 400 Personentagen pro Halbjahr eingespart, sondern die Projektdurchlaufzeiten einer Organisation mit 200 Mitarbeiter:innen konnte im Schnitt, bei gleichzeitiger Qualitätserhöhung und Liefertreue, gedrittelt werden.

Eine Investition in die Performance eines Teams kann auf den ersten Blick sehr hoch sein – daher ist es uns so wichtig, dass unsere Kund:innen wissen, was sie sich erwarten und wir den Business Case für die Veränderung berechnen.

3. Was sind die Hauptunterschiede zwischen klassischen Beratungen und borisgloger?

Created with Sketch.

Diese Frage können wir nur aus unserer Sicht beantworten, und daher bitte ich an dieser Stelle schon um Entschuldigung, dass wir hier sicherlich nicht hundertprozentig objektiv sind.

Von starren Strukturen zu dynamischer Flexibilität: Der Paradigmenwechsel in der Unternehmensberatung

Als jemand, der in den späten 1990er Jahren erlebt hat, wie klassische Beratungen arbeiteten und feststellte, dass die eigentliche Veränderung von den beratenen Menschen selbst gemacht werden musste – viele Konzepte zwar auf der PowerPoint-Folie gut aussahen, jedoch an der Lebenswirklichkeit der Menschen in Unternehmen vorbeigingen, wollte ich mit borisgloger eine Beratung aufbauen, die nicht nur konzipiert, sondern vor allem umsetzt.

Wir sind Macher. Für uns ist das noch immer der Kernunterschied zwischen der klassischen Beratung und unserem Verständnis einer agilen Managementberatung.

Dieser Unterschied basiert auf der tiefen Einsicht, dass nur die Kund:innen-Systeme ihre Herausforderungen selbst lösen können, doch ihre eigenen Prozesse, die aus einer anderen Zeit, dem industriellen Paradigma stammen, stehen ihnen dabei im Weg.

Gleichzeitig ist uns im Laufe der vielen Jahre der Beratung aufgefallen, dass sich Kund:innen-Systeme nicht wandeln, weil es

  1. kein klares Bild davon gibt, wohin die Reise geht – es gibt noch immer zu wenig Erfahrung, wie eine moderne Organisation aussehen kann, und
  2. es zweitens an Know-how fehlt, neue Wege zu gehen. Es mangelt schlicht an dem Know-how, mit den neuen Tools (Test Driven Development, Cloud, Microservice-Architektur, MS Teams, Miro) zu arbeiten. Sehr gut zu beobachten ist dies gerade wieder an der Angst vor General AI. Diese kommt nicht daher, dass man wüsste, wie Chat GPT und Co. funktionieren, sondern die Menschen in den Unternehmen wissen schlicht noch nicht, wie dieses neue Tool nutzbringend eingesetzt werden kann. Ein wunderbarer Vortrag, wie KI zum Kollegen wird, findet sich hier


Wir verstehen den Job einer agilen Unternehmensberatung darin, genau diese beiden Aspekte zu kombinieren. Die Veränderung im Unternehmen muss einerseits dabei unterstützen, die Organisation wieder arbeitsfähig zu machen, und andererseits den Menschen die Angst nehmen, die Veränderung mitzugehen.

Der traditionelle Ansatz: Eine Welt voller Pläne und Prognosen

Klassische Beratung hat ihre Wurzeln in einer Welt, die Stabilität und Vorhersehbarkeit hochschätzt. Hier werden Probleme durch detaillierte Analysen identifiziert, die zu umfassenden Lösungen und langfristigen Strategien führen. Diese Lösungen, oft in dicken Berichtsbänden dokumentiert, folgen einem strikten Plan, der auf Effizienz und Kontrolle ausgelegt ist.

Viele Unternehmen bezahlen die Berater:innen dafür, ihnen Wissen über die Konkurrenz zu geben – jeder kennt die berühmte Strategie von Unternehmensberatungen, die erklären, es gäbe einen sogenannten Benchmark, an dem man sich orientieren müsste. Diese Analysen lassen sie sich dann gut bezahlen.

Dann wird eine Strategie erstellt, die genau erklären soll, wie das zu Erreichende erreicht werden soll.

All das folgt der klassischen Idee, eine Organisation wäre ein Uhrwerk, das man dadurch verändert, indem man neue Zahnräder einsetzt und die Menschen durch neue Prozesse mobilisiert.  


Der Prozess ist hierarchisch und top-down orientiert, und nach einer Entscheidung, wie sich die Organisation zu ändern habe, wird dann gefordert, dass die anderen so arbeiten sollen. Der Erfolg wird durch das strikte Einhalten von Budgets und Zeitplänen sowie durch das Erreichen spezifischer, vorab definierter Ziele gemessen.

Dieses Vorgehen hat funktioniert – natürlich, wenn alle Unternehmen im Grunde das Gleiche tun, kann man sich an der Konkurrenz orientieren und versuchen, ein wenig besser, das zu machen, was die anderen auch tun.

Die Unternehmensberatungen, die dieses Weltbild stützen, funktionieren dann im Inneren genau wie ihre Kund:innen: selbst hierarchisch und die unteren Chargen werden zu den Ausführenden der Senior-Consultants.

Die agile Revolution: Flexibilität und Iteration als Schlüssel zum Erfolg

Im Gegensatz dazu steht die agile Beratung, die eine Organisation als ein System aus Kommunikation – begreift. In der es also keine Chance gibt, einfach wie ein:e Mechaniker:in einzugreifen. Vielmehr muss das System sich selbst verändern – das geschieht durch eine iterative, inkrementelle Vorgehensweise.  


Natürlich muss auch hier erst einmal eine Analyse getätigt werden – das Problem muss verstanden werden. Hier geht es aber um eine Sicht auf die eigene Fähigkeit. Wir schauen also nicht, ob die anderen besser sind, sondern ob die eigene Organisation erreicht, was sie sich vorgenommen hat – und zeigen der Organisation, wie sie sich selbst diese neuen Ziele setzen kann.

Hier hat sich  

  • einerseits bewährt in Anlehnungen an Design Thinking vorzugehen. Möglichst viele Menschen werden involviert, um sowohl das Problem zu verstehen (Discovery) als auch bereits hier alle zu beteiligen, die später die Veränderung mitgestalten sollen.


Das kann  

  • Ergänzt werden oder ersetzt werden in dem man eine Befragung in Form eines Business Agility Vital Checks durchführt. Diese Analyse ist sehr schnell und kosteneffektiv für Organisationen, die zunächst ein Gespür für die Probleme in der Organisaton entwickeln wollen. Er ist ähnlich aufgebaut wie ein Persönlichkeitstest.  


Nach der Analyse geht es aber nicht darum, umfassende Pläne zu entwickeln, sondern die Probleme so schnell und effektiv wie möglich sofort zu lösen, die gerade verhindern, dass die eigenen Ziele der Organisation erreicht werden. Wir setzen auf kurzzyklische Sprints, die es der Organisation ermöglichen, schnell auf externe Einflüsse zu reagieren und ihre Strategien entsprechend anzupassen. Hier steht nicht der umfassende Plan im Vordergrund, sondern die Fähigkeit zur Anpassung und kontinuierlichen Verbesserung.


Das geht nur miteinander – und so ist die Veränderung und das Veränderungsmanagement bereits Teil des Plans. Wer iterativ und inkrementell seine Veränderung durchführt, wird diese Fähigkeit auch nutzen, um die eigenen Produkte zu entwickeln.

Wir verändern also die Organisation dadurch, dass die Organisation etwas Neues auf eine andere Art liefert.  

Wenn die Fähigkeit der Organisation wächst und genau das gekonnt wird, ist die Organisation anders als zuvor und der Change war erfolgreich.

Die Rolle der Mitarbeitenden: Vom Befehlsempfänger:in zu Gestalter:in

Anders ausgedrückt – der wesentliche Unterschied in der Beratung liegt in der Einbindung der Mitarbeitenden. Während klassische Beratungsprojekte oft eine klare Trennung zwischen Berater:innen und dem Klient:innen-Team aufweisen, fördert die agile Beratung eine kollaborative Kultur bereits während des Veränderungsprozesses. Hier sind alle Beteiligten aktiv in den Entscheidungsprozess eingebunden, was nicht nur die Akzeptanz der Veränderungen erhöht, sondern auch die Qualität der Ergebnisse verbessert.  

Teams werden befähigt, selbstorganisiert zu handeln und direkt an der Entwicklung von Lösungen mitzuwirken. Das Prinzip dahinter ist nicht das theoretische Überzeugen, sondern das aktive Machen, um zu neuen Einsichten zu kommen. Erst wer erlebt hat, wie schnell Projekte geliefert werden können, wenn man weniger gleichzeitig tut und dann am Ende sogar insgesamt mehr liefert, obwohl man weniger arbeitet, versteht es. Nonaka nannte das implizites Lernen – die Idee, dass neues Wissen durch Machen statt durch Überlegen und Planen entsteht. Wir nannten das mal: „Doing as a way of thinking“ und wir stehen mit unserem Slogan: Wollen.Machen.Können. genau dafür ein.

Umgang mit Veränderungen: Eine Frage der Perspektive

Ein weiterer fundamentaler Unterschied ist der Umgang mit Veränderungen. In der klassischen Beratung werden Veränderungen oft als Risiko gesehen, das es zu minimieren gilt. Hier fallen viele Manager:innen gerne auf die schönen Bilder (den Blue Prints) der klassischen Unternehmensberater:innen herein. Wir werden oft gefragt, wie unser Standardmodell aussieht, und wenn wir dann entgegnen: „Es gibt kein Standardmodell, weil jedes Unternehmen anders ist“, sind viele unserer Kund:innen mit der Antwort nicht zufrieden. Ja – es fällt uns tatsächlich schwer, einen Blueprint zu liefern.  


Daher haben sich unsere Consultants die Mühe gemacht und mit ihrem Buch „Agile Transformationen – abseits vom Happy Path“ versucht zu zeigen, dass Unternehmen, die sich agil verändern wollen, sich auf einige Turbulenzen einstellen müssen.


Und wir haben ein eigenes Skalierungsmodell entwickelt – eines das gar keines ist, sondern nur aufzeigt, wo eine Organisation etwas ändern könnte und möglicherweise auch sollte.


Diese Turbulenzen sind jedoch die Chance. Denn Veränderungen ohne tatsächliches Hinsehen und das gemeinsame Arbeiten an dem Ziel, eine echte Integration des Neuen in das Unternehmen zu bringen, gehen vorbei. Agile Beratung – auch die unsere – hingegen begreift Veränderung als Chance. Die iterative Natur des agilen Prozesses bedeutet, dass wir Veränderungen erwarten, sie sogar begrüßen und als Teil des natürlichen Projektflusses sehen. Widerstand ist hier immer eine Information darauf, dass in der zu beratenden Organisation noch etwas nicht gekonnt wird.

Widerstand ist also immer eine Information – die Art des Systems aufzuzeigen: „Achtung – hier gibt es etwas zu beachten.“ Dieser Ansatz lässt dann miteinander die nächsten Schritte gestalten. Siehe dazu auch diesen Text unseres Kollegen  

Persönliche Erfahrungen und die Kunst der agilen Beratung

Aus meiner persönlichen Erfahrung heraus sehe ich, dass die Kunst der agilen Beratung weit über das bloße Anwenden von Methoden hinausgeht. Ja – natürlich müssen neue Kenntnisse erworben und durch Einüben gefestigt werden. Doch es geht darum, eine kontinuierlich lernende Organisation zu etablieren. Das Beobachten der Entwicklung einer Kultur des Gelingens, der Offenheit, des kontinuierlichen Lernens und der gemeinsamen Verantwortung ist dabei wunderbar. Es ist wunderbar zu sehen, wie jede:r Einzelne im Unternehmen nicht nur Teil des Prozesses ist, sondern aktiv an der Gestaltung der Zukunft mitwirkt und damit auch die Zukunftsfähigkeit der eigenen Profession sichert.

Zum Abschluss

Die Entscheidung zwischen klassischer und agiler Beratung sollte nicht leichtfertig getroffen werden. Es kann sein, dass auf der einen Seite die Veränderung hin zu neuen Arbeitsweisen durch die agile Beratung – wie der unseren – getätigt werden sollte, doch die inhaltlichen Skills, eine neue Form zu arbeiten (z.B. 3D-Druck oder neue Technologien), eine fachliche Beratung ganz klassischer Art sein können.  

Doch wir wissen heute, dass jede Änderung der Technologie in Unternehmen immer auch eine soziale Komponente hat. Neue Technologien werden erst dann wirksam und effektiv, wenn alte Arten des Arbeitens bzw. Verhaltens ebenfalls geändert werden. Genau das kann aber nur mit den Menschen passieren, nicht gegen sie oder für sie.


In persönlichen Gesprächen mit unseren Kund:innen erkunden wir stets, welcher Ansatz der geeignetste ist, um die spezifischen Herausforderungen zu meistern. Es gibt keine Patentlösung – aber es gibt bewährte Prinzipien und eine tiefe Erfahrungsbasis, die wir nutzen, um gemeinsam mit Ihnen nicht nur Probleme zu lösen, sondern auch neue Möglichkeiten zu erschließen.

4. Wie viel bringt die Investition? Was ist der Business Case dahinter?

Created with Sketch.

„Was bringt uns das?“ – Das ist nicht nur eine berechtigte, sondern vor allem die wirklich wichtige Frage, bevor ein Unternehmen ein agiles Projekt startet. Denn eines ist offensichtlich, wenn Sie eine:n Berater:in wie uns einkaufen, um Sie dabei zu unterstützen, ein Projekt oder einen Unternehmensbereich mit Hilfe agiler Managementframeworks und neuen Arbeitsweisen fit zu bekommen, denn unsere Beratungsleistung kostet Geld.

Trainings und Workshops für die Mitarbeiter:innen, Updates der technischen Infrastruktur, damit effizienter und reibungsloser miteinander gearbeitet werden kann, Modularisierung der Produktarchitektur – das alles kostet Zeit und Geld – und was wäre, wenn sich diese Beratungsleistung und das Umstellen der Infrastruktur, der Ausbau der Skill der Mitarbeiter:innen sehr schnell amortisieren würde? In einigen Fällen in wenigen Wochen, manchmal sogar bereits in 90 min.

Effizienzsteigerung und Kostensenkung durch agile Transformation  

Wir waren gebeten worden, während eines agilen Trainings-Workshops mit dem Team an einem realen offenen Fall zu arbeiten. Ein Projekt, dass seit 3! Jahren nicht abgeschlossen werden konnte. Der Abschlussbericht fehlte; hatte noch eine Millionen Euro ausstehen.

Nach dem Vormittag, bei dem wir die grundsätzlichen agilen Arbeitsweisen erläuterten, nutzten wir dann 90 min, um dieses Projekt mit Hilfe von Flash-Working anzugehen. 90 min später, war dem Team nicht nur klar, was zu tun ist, sie hatten es getan. Das Geld kam zurück. Rentable Investition – wir denken schon.  

Doch auch Kosten können reduziert werden. Das Ziel jeder agilen Arbeitsweise ist, die Zusammenarbeit in und zwischen den Teams in einer Organisation so zu gestalten, dass unnötiger Prozessballast – „Waste“ – abgeworfen werden kann. Bereits dieser Schritt wirkt sich auf die Kosten aus. Wartzeiten werden reduziert und Lagerhaltung wird abgebaut, weil es nicht zu Stehzeiten kommt.

All das kann gemessen werden und hier kommt der entscheidende Punkt jedes agilen Implementierungsprojektes:

Welches Problem will ich verbessern.  

Bei StudiVZ war das Problem, dass die Software nicht mehr auslieferungsfähig war. Statt ständig neue Funktionalitäten den Anwender:innen anzubieten und damit genau wie Facebook attraktiv zu bleiben, lieferten die Entwickler:innen aus den altbekannten Problemen der Software-Entwicklung weniger. Nach nur 6 Wochen konnte dieses Problem eliminiert werden.

Bei Salesforce.com kam es 2005 zu exakt dem gleichen Problem. Immer mehr Entwickler:innen lieferten in immer längeren Zeiträumen. 2006 kam es dann zu einer der ersten agilen Transformationen – das Resultat: die Lieferfähigkeit wuchs exponentiell - zu einer der schnellsten in der Industrie. Siehe dazu u. a dieses Slidedeck

Beide Unternehmen konnten ihr Problem in Zahlen ausdrücken: Tage bis zum nächsten Release; diese wuchsen ohne agiles Arbeiten und sanken rapide mit agilem Arbeiten.

Wir empfehlen immer unseren Kund:innen ihre existierenden KPIs als Fiberkurve zu sehen. Was ist derzeit wichtig? Absatz, Profitabilität, Time-To-Market, Kund:innen-Zufriedenheit:  Diese KPIs müssen durch die Implementierung agiler Arbeitsweise besser werden.

Wie findet man diese relevanten KPIs?

Mit den Expert:innen des Kund:innen-Systems gehen wir eine Reihe von Fragen durch, die sowohl auf die Effizienz als auch die Effektivität abzielen. Diese Fragen sind bewusst einfach gehalten: Das Ziel ist nicht, centgenaue Beträge zu berechnen, sondern ein Gespür für finanzielle Auswirkungen zu entwickeln.

Wir fragten einmal einen Geschäftsführer, wie viel Geld sie verlieren, wenn das Produkt, dass wir gerade hier im Team entwickelten, nur einen einzigen Monat später auf der Messe stehen wird, weil wir hier jetzt einen Monat für die Entscheidung brauchen, um 100.000 oder 140.000 Euro auszugeben – und deshalb das Team nicht weiterkommt. Er sagt: Jeder Monat später hat zur Folge, dass wir mindestens eine:n Kund:in für die Laufzeit von 10 Jahren verlieren, also circa 10 Millionen Euro Umsatz-Verlust.

Diese Einschätzung reicht oft, um zu rechtfertigen, Aktionen im Unternehmen zu setzen.

Ähnliche Fragen wie bei dem Beispiel sind

  • Welche Effekte können wir erzielen, wenn sich die Kolleg:innen aus dem Bereich fokussieren und in einem Team an einer Sache arbeiten können?
  • Welche Mehrkosten lassen sich vermeiden, wenn fehlgeleitete Entwicklungen früher erkannt werden. Wie viel weniger Aufwand braucht die Erledigung von Aufgaben, wenn für einen schnellen und reibungslosen Austausch die Crossfunktionalität im Team erhöht wird?
  • Welche Beschleunigung wäre möglich, wenn die aktuellen Hindernisse systematisch aus dem Weg geräumt und damit abgebaut werden?
  • Wie viel Zeit kann im Management gespart werden, wenn die Reporting-Aufwände drastisch reduziert bzw. abgeschafft werden?
  • Wie viele schneller kann ein Team sein, wenn es Entscheidungen selbst trifft?
  • Wie viel mehr Umsatz könnte das Unternehmen generieren, wenn es seine Produkte und Dienstleistungen früher am Markt platzieren kann?
  • Wie stark kann die Kundenzufriedenheit steigen, wenn Produkte und Dienstleistungen eher den Erwartungen und Bedürfnissen der Kund:innen und Anwender:innen entsprechen?


Stellt man den Ergebnissen dieser Einsparungs-Schätzungen die möglichen Kosten der agilen Implementierung entgegen, kann man zumindest einen ersten Indikator dafür sehen, ob sich die Investitionen rechnen. 

Achtung: Wenige KPIs – Fokus auch hier

Unsere Empfehlung ist: Fokussieren Sie sich auf maximal vier Themen, die sie zur Maßzahl ihrer Verbesserungen machen wollen. Finden Sie dazu ein bis maximal 2 Werte, die sie messen wollen – und es sollten Messwerte sein, die sie sehr leicht, am besten automatisiert messen können.

Beispiel 1: Großprojekt - mehr Effizienz durch Reduzierung von Zeitfressern


Ausgangssituation

In einem großen Projekt mit mehr als 1.000 Mitarbeiter:innen gab es erhebliche Planungsaufwände: Abstimmungen wurden durchgeführt, ständig musste koordiniert und umgeplant werden. Ein gigantischer Zeitfresser. "Wir kommen nicht mehr zum eigentlichen Arbeiten" sind O-Töne, die in solchen Projekten fallen.

Lösung

Wir haben uns nun auf ein 3-monatiges Planning Intervall geeinigt, dass alle Lead- und Koordinations-Funktionen (> 100) an 2 Tagen vor Ort zusammenbringt, um die jeweils nächsten Monate zu planen. Das reduziert die Planungsaufwände enorm. Lässt sich nur schlecht im Voraus planen, da so gut wie nie Planungsaufwände getrackt werden. Hier lässt sich schwer messen, ob aus “Wir kommen nicht mehr zum eigentlichen Arbeiten!”, ein “Jetzt arbeiten wir effektiver und zielgerichtet”, wird.

Beispiel 2: IT-Unternehmen – schnellere Produktentwicklung 

Ausgangslage

Die Auftragslage ist verzwickt, da erstens der Kunde das Produkt schnell sehen will und durch erste Verzögerungen stark verunsichert ist, ob das Entwicklungsteam überhaupt liefern kann, was er versprochen hat.

Lösung

Wir haben 2 Development Teams aus der bestehenden R&D Organisation (ca. 70pax) geschnitten, haben diese mit Product Ownern und ScrumMastern ausgestattet und haben dann in Iterationen losgelegt. Unser Ziel war innerhalb von 8 Iterationen (16 Wochen) einen erstes lauffähiges Produktinkremente zu implementieren und so das Vertrauen in den Kunden zurückzugewinnen.

Alle waren verblüfft, dass tatsächlich so schnell geliefert wurde. Neben der Einführung von Scrum, dem Erzeugen von Fokus und der vollen Management Aufmerksamkeit war ein wichtiger Erfolgsfaktor, dass wir die Arbeit sparen konnten, ein finales Architekturdesign zu machen, sondern grobe Annahmen einschlugen, diese ausprobierten und dann iterativ weiterentwickeln. Das sparte im Vergleich zu klassischem Vorgehen Wochen.


Beispiel 3: Deutsche Bahn - Effizienz in der Generierung von Fördermitteln

Ausgangssituation

Der Rhein-Ruhr-Express (RRX) ist eines der wichtigsten Schieneninfrastrukturprojekte der Deutschen Bahn. Auf der Strecke Köln-Düsseldorf-Duisburg-Dortmund werden zusätzliche Kapazitäten geschaffen, dazu war bis Ende 2019 die bessere Anbindung von 6 „Außenästen“ – den Zulaufstrecken zur Hauptlinie – notwendig. Für den Umbau von 52 Bahnhöfen musste der Regionalbereich West der DB Station&Service AG Fördermittel beantragen. Hier sind klare Prozesse einzuhalten, um die sogenannten Zuwendungsbescheide zu erhalten. Intern und extern müssen dabei viele Schnittstellen überwunden werden. Änderungen müssen beim Fördergeber angezeigt und die ursprünglichen Anträge überarbeitet werden. So beginnt der Prozess von Neuem, bis es den aktualisierten Zuwendungsbescheid gibt; oder es gibt Rückfragen, in deren Beantwortung wieder mehrere Abteilungen involviert sind. Ohne Visualisierung und klare Abstimmung sind solche Projektsituationen für Ineffizienz prädestiniert.


Lösung

Um die Übersicht über alle 52 Teilprojekte zu wahren und den Prozess zu beschleunigen, visualisierte das zuständige Team den Ablauf der Antragstellung auf einem 4 mal 2 Meter großen Projektboard, geclustert nach den sechs Außenästen.  Am Morgen jedes Arbeitstages wurde innerhalb von 15 fokussierten Minuten der Status aller Projekte besprochen. Für Themen, an deren Lösung mehrere Expert:innen mitwirken mussten, hat sich die Umwandlung von Meetings in crossfunktionale Arbeitstreffen bewährt, an deren Ende weißer Rauch aufsteigen, also ein Ergebnis stehen muss. Das heißt: Alle für ein Thema notwendigen Personen arbeiten so lange in einem Raum zusammen, bis sämtliche Fragen gelöst sind.  Sollte es offene Punkte geben, committen sich die Beteiligten an Ort und Stelle zu einem weiteren Termin.

Das Ergebnis konnte sich sehen lassen:  

  • Die Zahl der erhaltenen Bescheide stieg von 3 im Jahr 2017 auf 35 im Jahr 2018.  
  • Der Überblick über alle Projekte machte es auch einfacher, Kapazitäten umzuschichten. 
  • Die Arbeitszufriedenheit ist deutlich gestiegen, da die Aufgabenverteilung klarer ist und Fortschritte am Board sichtbar werden.
  • Dass Mitgestalten und Ideen einbringen, hat viele junge Bewerber:innen angezogen.
  • Das agile Arbeiten wurde auch auf andere Programme ausgeweitet, zum Beispiel auf die Schlussverwendungsnachweise für den Fördergeber (das war das obige Beispiel: 1 Millionen in 90 min).  


Beispiel 4: Webasto - eigenes Arbeitsmodell für die Produktentwicklung

Ausgangssituation

Seit Jahrzehnten produziert der Erstausstatter Webasto erfolgreich Lösungen für die Automobilindustrie. Angesichts steigender Dynamik und neuer Trends im Automobilmarkt startete die Unternehmensgruppe ihre maßgeschneiderte agile Transformation mit dem Ziel: weg von der Projektorganisation hin zur kundenorientierten Produktorganisation. Es sollte ein effektives Zusammenarbeitsmodell für die Entwicklungsstandorte identifiziert werden, um die interne Expertise von Webasto stärker zu mobilisieren und so schneller auf die Marktdynamik zu reagieren
 

Lösung

Es wurde den Produktverantwortlichen genug Orientierung gegeben, um geeignete Teams aufzubauen und den Produktteams größtmögliche Gestaltungsfreiheit bieten, um effektiv arbeiten zu können. 4 Zielaspekte, die für Webasto wichtig waren wurden identifiziert. Das Framework sollte den Fokus aller Tätigkeiten an der Wertschöpfung ausrichten, die Reaktionsfähigkeit der Organisation unterstützen, selbstverantwortliche und selbstorganisierte Zusammenarbeit auf Augenhöhe ermöglichen und Lösungen statt Prozesse in den Vordergrund stellen.  

Ergebnis

  • Die ersten Erfolge zeigten sich in der Zusammenarbeit: Durch die neue Teamzusammensetzung können die Teammitglieder fokussierter arbeiten und sich besser einbringen.  
  • Den Fokus halten zu können bedeutet, Transaktionskosten zu sparen, weil die Teammitglieder nicht mehr ständig zwischen verschiedenen Kontexten wechseln müssen.
  • Reportings brauchen weniger Vorbereitungszeit und in der Entwicklung werden Kompatibilitätsfragen so früh geklärt, dass in der Integration kaum noch Hindernisse auftreten.  
  • Insgesamt hat die crossfunktionale Zusammenarbeit die Wartezeiten deutlich reduziert, weil Fragen schneller geklärt und Aufgaben dadurch rascher weiterbearbeitet werden können.

Mehr dazu

Beispiel 5: Millentor Festival – Eventorganisation mit kleinem Team und großer Wirkung

Ausgangslage

Viva Con Agua Arts veranstaltet jedes Jahr das Millentor Festival. Kunst und Musik im Stadion. Fünf Mitarbeiterinnen stemmen das dort und das mit mehreren hundert freiwilligen Helfer:innen. Jedes Jahr musste dieses Team im Anschluss erst einmal ein paar Wochen Urlaub nach diesem Kraftakt machen. Es ist jedes Mal sehr stressig.


Lösung

Wir boten unsere Unterstützung für diesen caritativen Zweck pro bono an. Unsere Consulting Team half dem Team einige Stunden pro Woche. Das Ergebnis war eine völlig entspannte Veranstaltung des Festes und sogar der Wegfall wichtiger Schlüsselpersonen vor dem Event stellt keine echte Herausforderung da.

Die Top 10 der Verbesserungen

Bei einem Blogbeitrag wie diesem, wo also der tatsächliche Versuch unternommen wird, die Rentabilität der Einführung von agilen Arbeitsweisen vorzustellen, gibt es das Problem, dass Kund:innen diese Dinge nicht gerne veröffentlichen. Die beiden obigen Beispiele sind da eine echte Ausnahme.

Doch aus unserer Erfahrung gibt es 10 Aspekte, die sich immer wieder zeigen – egal ob in der Hardware-Entwicklung, in der Software-Entwicklung, beim Veranstalten von Festivals oder beim Arbeiten mit Schüler:innen:

  1. Effektiver Kommunikation zwischen den Abteilungen und das bedeutet oft eine drastische Beschleunigung von Prozessen.
  2. Fehlerbearbeitung und Nacharbeiten werden dramatisch reduziert.
  3. Projekte werden deutlich schneller abgearbeitet.  
  4. Lagerstände. Im Hardware- und Produktionsbereich sinken die Lagerstände deutlich.
  5. Die Kund:innen-Zufriedenheit steigt.
  6. Die Mitarbeiter:innen-Zufriedenheit steigt deutlich.
  7. Der Durchsatz von Projekten in Unternehmen steigt sprunghaft an
  8. Die Mitarbeiter:innen nehmen die Führung unterstützend an und erkennen, wie wirksam diese sein kann.
  9. Produkte werden deutlich enger am Kund:innen-Nutzen entlang gebaut. Die entwickelten Funktionalitäten treffen den Bedarf
  10. Die Zuverlässigkeit wird positiv wahrgenommen und das gegenseitige Vertrauen steigt.

Alles in allem sparen sich die Unternehmen durch die Einführung von agilen Arbeitsmethoden hohe Kosten und erzielen eine wesentlich höhere Produktivität - wie wir immer wieder selbst erleben konnten.  

Die Antwort auf die Frage: “Was bringt es?” Ist also immer mit der Gegenfrage verbunden: Was soll es bringen? Wie messen wir das? Und dann legen wir los und messen nach kurzer Zeit, ob wir unser Ziel erreichen?

5. Welche Vorteile bietet es uns, wenn wir borisgloger beauftragen, anstatt die Transformation mit Internen voranzutreiben?

Created with Sketch.

Die agilen Evangelisten der ersten Stunde, u.a. ich selbst, hatten den Vorteil und den Nachteil, dass wir keine externen Consultants einkaufen konnten, die uns gezeigt hätten, wie agiles Arbeiten funktioniert. Ich habe zwar Ken Schwaber 2004 nach Wien zu meinem ersten Scrum-Team geholt, und ihn mit meinen 5 Entwickler:innen sprechen lassen, doch das war in dem Sinne keine Beratung, wie sie heute existiert.

Dann, wenige Monate später rief mich die Software Entwicklungsabteilung der damaligen Web.de an. Andreas Schliep, der damalige Teamleiter der Software Entwicklung und heutige Co-Founder der Beratungsfirma  “Das Scrum Team”. Er bat mich, ihnen dabei zu helfen, Scrum auszuprobieren; sie hatten schon, so wie ich damals begonnen und gemeinsam begannen wir zu lernen, wie agiles Arbeiten geht.  

Auch heute gibt es das Phänomen, dass Menschen in ihren Organisationen beginnen, mit Scrum und anderen Management-Frameworks selbst zu experimentieren und einige haben sogar das große Glück, dass sie selbst bereits in anderen Unternehmen profunde Erfahrungen sammeln konnten. Gerade habe ich mit einer Art Head of Innovation in einer großen Firma gesprochen, der selbst im eigenen Haus als Berater und Moderator agiert, um die agilen Prinzipien in die Organisation zu tragen.  Also ja – es ist möglich die agile Transformation aus sich heraus zu beginnen.

Und – dieser Ansatz ist langsamer

Oft ist hier keine bewusste Entscheidung der Geschäftsleitung, sich für eine veränderte Arbeitsweise einzusetzen, vorhanden. Das heißt viele Aktivitäten finden im Verborgenen oder geduldet statt.

Ein großer Konzern hatte 50 Projekte, in den agiles Vorgehen ausprobiert wurde, ohne dass die Hauptabteilungsleiter etwas davon wussten. Erst als wir die Führungskräfteworkshops mit ihnen so gestalteten, dass diese Projekte dort aufschienen, begann das Verständnis, weshalb diese Themen erfolgreich waren.

Die aus unserer Sicht offensichtlichen Vorteile, sich an eine:n Berater:in zu wenden, sind

  • Es gibt schon eine Bereitschaft zur Veränderung, wenn externe Berater:innen engagiert werden. Allerdings oft nur bei dem, der den Auftrag erteilt. Hier ist dann oft die Kompetenz der BeraterInnen gefragt, Teams und Führungskräfte zu motivieren, ein neues Vorgehen auszuprobieren, um selbst feststellen zu können, wie nützlich dieses neue Arbeiten ist. Bei – heute würde man Transformation sagen – der IT in einem Energiekonzern, war durch unser Hinzuziehen von vorne herein auch klar, es gab eine Erwartungshaltung und damit auch die Aufmerksamkeit des Managements für diese Aktion. Diese Entscheidung war dann auch hilfreich, wenn es darum ging, mit den externen Dienstleister:innen ins Gespräch zu kommen. Hier wurde dann deutlich, dass ab sofort unter anderen Voraussetzungen gearbeitet werden sollte.


  • Der aus meiner Sicht zweite wesentliche Faktor ist das Know-how und die Erfahrung, die Kund:innen durch externe Beratung einkaufen. Web.de hatte mich wegen meiner Erfahrung eingekauft. Auch das ist heute noch so – wir werden wegen unserer mittlerweile sehr weitreichenden Erfahrung eingekauft. Unsere Berater:innen haben viel, sehr viel gesehen. Unterschiedliche Branchen, unterschiedliche Herausforderungen unterschiedliche Kulturen und viele unterschiedliche Teams, Software und Hardware-Projekte. Eine unserer Berater:innen bringt sogar NGO Know-how mit und kann zeigen, wie man Agile in Arts macht. Ja – es kann den Glücksfall geben, dass eine Organisation sich jemanden eingestellt hat, der auch das alles gesehen hat (und zum Beispiel ein Ex-Mitarbeiter:in von borisgloger eingestellt hat), doch in der Regel ist das nicht so. Wir machen noch immer die Erfahrung, es fehlt einfach das Know-how – eine Zertifizierung macht noch keinen guten Coach oder Consultant.


  • Der dritte Punkt: Der agile Hub wird mitgekauft. Einen agile Hub, also eine interne Beratung aufzubauen, die aus 5 bis 10 Consultants besteht, die alle dann innerhalb der Organisation wiederum die Teams betreuen soll, ist wünschenswert, doch das dauert seine Zeit. Viel Zeit und Energie wird benötigt, dass dieses Team selbst erst einmal starten kann. (Einige unsere Beratungsaufträge bestanden darin, genau diese Teams aufzubauen und das verlangsamte dann die Transformation in anderen Bereichen). Doch - natürlich ist das auf längere Sicht der richtige Weg. Wer aber die Gunst der Stunde nutzen will, der braucht die Geschwindigkeit von erfahrenen aufeinander eingespielter Teammitglieder, die nur ein Ziel haben, die Kund:innen zufriedenzustellen und die nicht innerhalb ihrer eigenen Reihen darüber nachdenken müssen, wer jetzt wohl beim Chef besser ankommt, um die eigene Karriere zu fördern. Daran anschließt auch die Tatsache, dass selbst ein großes Projektteam, dass wir stellen können, noch immer nicht alles gesehen hat, doch die übrigen Consultants bei borisgloger können jederzeit unterstützen. Sei es ganz profan bei Urlaubsvertretungen, die Kund:innen-Teams werden dann nicht allein gelassen, sondern weiter effektiv geführt oder durch die Chance, dass unsere Kolleg:innen jederzeit auf die Unterstützung (inhaltlich wie auch moralisch) von unseren Kolleg:innen zählen können.


Das ist vielleicht der entscheidende Nachteil des Versuchs intern die Veränderung durchzuführen.  

Change ist harte Arbeit, oft mit sehr viel Leidenschaft begonnen, ist es doch so, dass es unweigerlich auch mal zu einer Frustration kommt. Vergeblich versucht man ein Team oder eine Führungskraft zu überzeugen, oder hat sich vielleicht sogar mit der eigenen Führungskraft heftig gestritten – wohin geht diese Person dann? Zu einem Kollegen? Das vergiftet die Atmosphäre noch mehr, zur nächsten Führungskraft - in vielen Organisation ein Tabu. Schnell ist dann das Gefühl der Ohnmacht überwältigend und der interne Consultant verlässt frustriert das Unternehmen (habe ich sehr oft gesehen.)

  • Der vierte Grund, der für das Arbeiten mit externen Consultants spricht, ist die Objektivität und die Durchsetzungsfähigkeit. Ich habe borisgloger u.a. deshalb gegründet, weil ich einen sicheren Hafen für unsere Consultants bieten wollte. Sie sollten in der Lage sein, offen und ehrlich ihre Meinung Kund:innen gegenüber zu äußern. Sie sollten aufzeigen können, was der Fall ist und die Fakten darstellen – ohne Angst haben zu müssen, diese objektivierten Erkenntnisse könnten der Karriere schaden. Ein externer Consultant sieht die Dinge noch so wie sie sind. Die berühmte Geschichte vom “Des Kaisers neue Kleider” illustriert das – ein Consultant ist so naiv, politikfrei und offen die Parafunktionalitäten einer Organisation ansprechen zu können. Er/sie weiß nicht, dass man es hier so macht, weil man es immer so macht. Er/sie weiß auch nicht, was nicht geht, und tut es einfach – und oft zeigt das den internen Kolleg:innen, was alles gehen könnte.  So hat ein Kollege einmal eine Wand-Vitrine abgeschraubt, weil er Platz für ein Whiteboard und Taskboard brauchte. Er wusste nicht, dass man dafür eine Erlaubnis vom Facility Management benötigt, die er nie bekommen hätte. Als das bekannt wurde, gab es schon einen Aufschrei, doch da das Team effektiver wurde, verhalte dieser Schrei und die Organisation konnte damit leben, dass dieses Möbelstück nicht gebraucht wurde.


Doch wie oben schon erwähnt, oft gibt es in Organisationen 2024 bereits Menschen, die mit agilen Methoden arbeiten, oder davon zumindest in ihrem Studium gehört haben.

Die wahre Kunst des externen Beraters liegt darin, gut mit anderen externen, aber vor allem mit den internen Consultants und Mitarbeiter:innen zusammenarbeiten.

Hier geht es nicht nur um das voneinander lernen. Interne Mitarbeiter:innen können sich manchmal mehr Zeit nehmen oder sie können noch mit weiteren Argumenten die Veränderung untermauern. So hat einmal die interne Organisationsentwicklung einer Bank begonnen, selbst mit agilen Methoden zu arbeiten; angestoßen von den Erfahrungen durch unsere Kolleg:innen und genau dieses Beispiel hat dann Schule gemacht und wieder andere Teams überzeugt.  

Und manchmal, wie bei einem großen Konzern erlebt, ist es so, dass die externen Consultants Dinge sagen dürfen, die dann gehört werden – und sich die Internen wundern. Denn der Externe hat mehr oder weniger genau das Gleiche gesagt, wie vorher die Internen. Eine agile Transformation, eine agile Projektbetreuung, das Einführen von Design Thinking in einer Produktentwicklungsabteilung geht nur mit unseren Kund:innen.
 

Gute Berater:innen sind dabei nicht nur Führer:innen, sondern auch Sherpas, sie zeigen, wie gute Hauslehrer:innen oder Personaltrainer:innen nicht nur wie es geht, sondern unterstützen auch das Machen. Denn es geht nicht ums Wissen, wie es geht, sondern darum es zu tun – und dieses Tun, ins Können unserer Kund:innen-Organisationen zu überführen.

Berater:innen - wie wir - sind den Weg schon öfter gegangen  

und kennen die Fallstricke und möglichen Schlaglöcher auf dem Weg der Veränderung. Für unsere Kund:innen diese zusammengetragen haben Christoph Schmiedinger und Carsten Rasche in ihrem Buch Agile Transformationen abseits vom Happy Path, und ich selbst zeige in Scrum Think BIG, was man alle berücksichtigen muss, wenn man mehr als ein kleines Projektteam agilisieren will.  

Für mehr Informationen, was einen bei agilen Implementierungen erwartet, empfehle ich zum Abschluss noch die vielen Case Studies und Whitepaper – kostenlos und frei verfügbar auf unsere Website.

6. Was wäre der konkrete erste Schritt nach einer Kontaktaufnahme mit borisgloger?

Created with Sketch.

Auftragsklärung und Zieldefinition

Die wichtigste Frage, die wir zu Anfang unseren Kunde:innen  stellen, ist das Wozu? Wozu soll denn die Veränderung gut sein. Agilität ist kein Selbstzweck. In der Regel haben Kund:innen einen ganz speziellen Bedarf.

Das könnte sein:

1. Projekte sollen schneller fertig und im Budget geliefert werden – Einer unserer Kunden hatte beispielsweise Projektdurchlaufzeiten von über 2 Jahren für IT-Projekte. Das konnten wir auf wenige Wochen reduzieren.

2. Produktiondurchläufe sollen kürzer werden. So gab es einen Kunden, der seine Produktionszeit von der Idee bis zum Verkauf an der Kasse von 18 Monaten mit uns auf 6 Monate reduzieren konnte.

3. Die Zusammenarbeit von Teams untereinander aber auch miteinander funktioniert nicht optimal. Einem unserer Consultants gelang es, ein sich streitendes Team in nur wenigen Tagen zum Liefern zu bringen.

4. Die Kund:innen sind in zu vielen Projekten gleichzeitig involviert und der Fokus geht verloren. Mit agilem Portfoliomanagement gelang es bei einem großen Automobilzulieferer, die Profitabilität zu erhöhen. Mehr dazu in unserer Case Study.

5. Strategien bleiben in der Schublade liegen, doch können nicht implementiert werden. Mit unserer Auffassung von OKRs konnte das Top-Management in der gesamten Organisation Klarheit zu den nächsten Schritten schaffen und die Mitarbeiter:innen motivieren.

Es würde zu weit führen diese Liste zu vervollständigen. Doch es wird deutlich, es geht immer um ein Business-Problem, das durch die Veränderung - also eine Transformation - gelöst werden soll.

Diese Auftragsklärung wird ergänzt durch die Zieldefinition. Wie messen wir am Ende, ob wir das Ziel gemeinsam mit dem Kunden erreicht haben? Wie findet auch der Kunde heraus, ob die Transformation erfolgreich war. Hier geht es um harte Fakten: Wir wollen ganz konkret die Durchlaufzeit reduzieren, weniger Fehler im System haben oder die Mitarbeiter:innen-Zufriedenheit steigern. Jetzt mehr erfahren in unserer Case Study!


Bestandsaufnahme

Ist dieses einmal eingegrenzt, kommt es in der Regel zu einer Bestandsaufnahme. Wir setzen dazu bei größeren Projekten 3 bis 5 Tage an: Heute ist es oft so, dass bereits agile Konzepte in den Unternehmen angewandt werden. Oft gibt es nicht nur erste Erfahrungen, sondern sogar schon ausgewiesene Expertise.

Jetzt geht es darum, ein gemeinsames Bild zu erarbeiten, wo die Verbesserungen stattfinden sollen. Reden wir zum Beispiel “nur” von einem Team, in dem agiles Arbeiten zum Standard werden soll, kann die Bestandsaufnahme auch nach 4 bis 6h abgeschlossen sein. Nach dem Workshop wissen alle, was in den nächsten 6 Wochen zu tun ist, um dieses Teams effektiver arbeiten zu lassen.

Wir arbeiten bei dieser Analyse gerne mit unserem Modell der 6 Dimensionen der Veränderungen.

Wir unterscheiden, ob die Maßnahmen einzahlen müssen auf:

1. Steuerung des Unternehmens und Leadership, aka Führungskräfte-Verhalten: Stichwort agiles Leadership und agile Strategie-Entwicklung

2. Das Managen von Projekten, Produktionsabläufen oder dem Organisieren eines Teams oder einer Abteilung: agile Management-Frameworks

3. Wie aus Produktideen, Produkte werden: Wie kann kund:innen-fokussiert das Produkt, der Service so gebaut werden, dass es dem Kund:innen-Nutzen dient?

4. Gibt es Know-How Themen: Stichwort – an welchen Stellen benötigt die Kund:innen-Organisation neues Know-How in der Art und Weise wie State-of-the-art gearbeitet wird, auch das kann sehr unterschiedlich sein. Oft fehlt es zum Beispiel daran zu wissen, wie man mit modernen Entwicklungstools arbeitet. Thema derzeit ist KI und DevOps.

5. Das Thema Infrastruktur: Haben wir die richtige Technologie? Ist unsere Kommunikations- und Infrastruktur in der Lage schnell und kostengünstig zu liefern?

6. Wie ist unsere Organisation aufgestellt, wie gut passt unsere organisationale Struktur zu den Anforderungen der Kund:innen und welche Implikation hat das auf unsere Kunden:innen.

Maßnahmen: das Transition-Backlog

Nach dieser Bestandsaufnahme sprechen wir mit unseren Kund:innen die daraus entstehenden Handlungsempfehlungen durch und erstellen eine Art Veränderungs-Roadmap, das wir Transition-Backlog nennen. Wir vereinbaren dann gemeinsam mit den Kund:innen, welche Maßnahmen davon in welche Reihenfolge durchgeführt werden sollten. Nur Kund:innen können diesen Weg bestimmen, nur sie wissen, was für die Organisation vorstellbar und verkraftbar bei der Veränderung ist.

Betrifft die Veränderungen mehr als ein Team oder ein Projekt, wird bei diesen nun größeren Veränderungsvorhaben ein sogenanntes Transformation Team eingeführt und dann unterstützen wir von borisgloger dieses Team bei den Maßnahmen.

Es kann aber auch sein, dass der nächste Schritt der Aufbau genau eines Pilot-Teams ist, und hier unterstützen wir das Team, um das Projekt erfolgreich zu liefern. Hier besteht oftmals unsere Leistung darin, das bestehende Projektteam entweder selbst zu leiten, indem wir die Führungskraft für das Projekt stellen oder die Führungskraft des Kundensystems befähigen, dieses Projekt mit agilen Methoden zum Erfolg zu führen.

Weitere Informationen dazu, wie eine Veränderung bis hin zur Transformation ablaufen kann und zu welchen Herausforderungen es dabei kommen kann, findet sich in dem Buch "Agile Transformation" von Christoph Schmiedinger und Carsten Rasche.

7. Warum sollten wir mit borisgloger arbeiten?

Created with Sketch.

Kund:innen fragen uns häufig: Was macht unsere Beratung besonders? Warum passen wir vielleicht besser zu Ihnen als unsere Kolleg:innen aus anderen Beratungen? Und wie erkennen Sie, dass wir nicht zu Ihnen passen?

Zunächst, wir sind keine klassische Unternehmensberatung, und wir kommen auch nicht aus dem klassischen Projektmanagement. Wir sind keine klassische Organisationsberatung und auch keine systemischen Coaches.

Und doch beraten wir sie bei der Ausarbeitung und Implementierung neuer Strategien. Wir unterstützen Ihre Projekte, in dem wir Ihre Liefertreue erhöhen und die gelieferte Qualität verbessern. Wir verändern dabei möglicherweise Ihre Organisation, um Ihre Prozesse besser auf die Kund:innen-Bedürfnisse abzustimmen. Das alles mit Ihnen gemeinsam, d.h. wir gehen mit Ihnen den Weg, anstatt Ihnen nur zu sagen, was Sie zu tun haben. Genau darin liegt unsere Stärke. Uns reicht es nicht die Diagnose zu finden und das Rezept auszustellen – wir sind bei jedem einzelnen Schritt an Ihrer Seite.

Das geht nur, weil wir - neben fundiertem theoretischem Wissen - nicht nur wissen, wie man die Veränderung umsetzt, sondern wir haben auch die kommunikativen Skills bei unseren Consultants trainiert, damit diese Ihnen bei der Durchführung ihrer Initiativen helfen können. Wir nutzen all unsere Kenntnisse zur Unterstützung, um Menschen in Organisationen dabei zu begleiten, mit agilen Methoden erfolgreich zu sein.  

Vor allem aber leben wir das Prinzip "Eat Your Own Dog Food". Wir selbst nutzen alle agilen Management-Methoden, alle Coaching- und Kommunikationstechniken, um unsere eigene Beratung zu steuern.

Wir sind daher auch keine Unternehmensberatung, die nach Außen agiles Mindset verkauft, aber in sich hierarchisch ist, oder die einmal klassisches Projekt-Management beraten hat und dann auf den agilen Zug aufspringt.  

Wir leben, was wir beraten

Im Gegensatz zu vielen anderen Unternehmensberatungen begreifen wir agiles Arbeiten nicht als add-on, sondern leben die agilen Prinzipien als essenzielle Haltung. Wir verkaufen nicht Scrum oder andere agilen Managementframeworks als Methode, sondern unsere Berater:innen denken, ja wir leben in unserer eigenen Organisation agil. Wir stellen unsere Teams divers zusammen, wir nutzen OKRs und Scrum selbst. Wir führen Retrospektiven durch, arbeiten selbst mit Taskboards und haben unsere Organisation so dicht am organistorischen Ideal aufgebaut, wie es uns bisher möglich war. Geht es noch besser, sicher.

Wir übernehmen Verantwortung für den Erfolg

Der zweite entscheidende Unterschied: Wir sehen zwar die Welt unserer Kunden durch die agile Brille, doch wir wollen damit die Themen unsere Kunden lösen. Wir verpflichten uns für den Erfolg der Kund:innen. Es geht uns nicht darum Scrum, SAFe oder OKRs einzuführen, um diese Methoden zu leben.

Wir wollen mit diesen Managementframeworks die Zusammenarbeit von Mitarbeiter:innen effektivieren und ihren Führungskräften Werkzeuge an die Hand geben, mit denen sie ihre Arbeit schneller und effektiver erledigen können. Sich zu verpflichten, unser Commitment, heißt nicht, dass wir mit dem Kunden dessen Ziele erreichen – auch wir sind schon gescheitert, zum Glück nur sehr selten gelingt es nicht, die versprochene Wirkung zu erlangen.

Wir haben unsere Organisation selbst agil aufgebaut

Und sagen Ihnen ehrlich unsere Meinung. Unsere Berater:innen entscheiden selbst, mit wem sie arbeiten wollen. Wir haben unsere Finanzen transparent für alle aufgestellt. Wir leben Nähe und wir leben Augenhöhe. Daher können bei uns auch auf den ersten Blick sehr junge Berater:innen bereits nach wenigen Wochen ehrlich ihren Kunden gegenüber sagen, sie verstehen, wie neues Arbeiten funktioniert, weil sie es erlebt haben. Ihre Beratungskompetenz ist nicht angelesen, sondern sie fühlen und begreifen, wie viel produktiver agile Arbeitsmethoden sind.

Es gibt andere Beratungen, die auf den ersten Blick auch den ScrumMaster stellen, doch wir machen oft die Erfahrung, dass diese Kolleg:innen (im Geiste) leider nie erfahren haben, was echter Respekt bedeutet und deshalb oft nicht für ihre Teams einstehen. In ihrer Not bleiben sie auf der sicheren Seite, denn sie dürfen wegen ihrer Chefs eben nicht den Kunden ehrlich sagen, was jetzt notwendig wäre.  

Wir bestärken unsere Berater:innen umgekehrt genau das zu tun: Wir legen die Fakten auf den Tisch – auch auf die Gefahr hin, dass unsere Kunden uns dann den Laufpass geben. Zum Glück passiert das nicht oft, obwohl wir auch anstrengend für unsere Kunden sind.

Denn ja – wir machen dabei auch Fehler

Die nichts mit dem offenen Ansprechen von Dysfunktionalitäten zu tun haben. So haben wir einen wunderbaren Kunden, dessen interne Kultur so fremdartig für uns war, dass wir zu Anfang in jedes nur erdenkliche Fettnäpfchen gestolpert sind. Wir haben uns wohl in deren Augen benommen wie der sprichwörtliche Elefant im Porzellanladen. 

Es war uns tatsächlich peinlich und erst als wir dann das offene Gespräch suchten und es uns gelang unsere kulturellen Unterschiede anzusprechen und offen zuzugeben, dass wir uns zu unserem Unverständnis bekannten – genau da begann unsere Zusammenarbeit. Wir konnten die Unterschiedlichkeit als Quelle der Veränderung sehen. Der Kunde wusste das besser als wir, denn genau deshalb hatte er sich für uns entschieden. Dieses Annähern dauerte mehrere Monate – und wir können uns nur bedanken, dass der Kunde uns ausgehalten hat.  

So schwer dieser Weg war und so dankbar wir für das Verständnis des Kunden noch immer sind - die Kundenorganisation hätte uns nicht ausgehalten, wenn wir nicht von Anfang an doch einen Mehrwert geliefert hätten. Wir bekamen trotz unserer Fehler gleichzeitig wunderbares Feedback, da wir die Teams des Kunden bei ihrer Arbeit produktiv und professionell unterstützen konnten.

Wir visualisieren - ständig  

Jeder der bisher Beratungsleistungen von borisgloger in Anspruch nahm, war zu Anfang erstaunt, dass wir ständig zeichnen und Bilder malen. Das ging vor der vielen Remote-Arbeiten sehr gut, wenn man Flipcharts im Raum hatte. Heute müssen wir dazu auf das Skizzieren mit dem iPad zurückgreifen. Ja – wir glauben fest daran, dass es wesentlich ist, die Dinge zu zeigen, statt sie zu erklären.

Wir leben das visuelle Management und zeigen mit manchmal nicht so schönen Strichen sowie einfachen Kästen und manchmal mit wunderschönen Grafiken Sachverhalte auf. Nein – wir haben nicht die Ressourcen, wie die großen Unternehmensberatungen über Nacht eine:n Grafiker:in damit zu beauftragen. Unsere Berater:innen zeichnen on-the-fly, was sie denken, um Teams und Führungskräfte adhoc Sachverhalte zu verdeutlichen.

Wir lassen unsere Berater:innen nicht allein  

Wer eine:n Berater:in von uns in sein Unternehmen holt, bekommt die geballte Ladung borisgloger. Wir leben ein Prinzip, das aus der Open Source Bewegung bekannt ist: Wenn jemand etwas nicht weiß, dann befragt er/sie das gesamte Unternehmen und hat in der Regel innerhalb weniger Minuten die Unterstützung, die er oder sie benötigt. Das kommt unseren Kund:innen zugute, die so von der Kreativität vieler profitiert.

Content und Gemeinschaft  

Neben all dem, was sie von unseren Berater:innen erwarten dürfen, profitieren unsere Kund:innen von unserem Wunsch Sie immer wieder mit anderen Inhalten zu unterstützen.

Wir bieten unseren Kund:innen Webinare an, wir schreiben Case Studies und Whitepaper und wir bringen unsere Kund:innen in den Austausch mit anderen Firmen, die sich auf die agile Reise gemacht haben.  

Können wir es noch besser machen? Sicher. Sind wir mit unserem Drive und unsere Motivation oft eine Zumutung für Kund:innen-Organisationen? Ja! Doch wir stehen dafür, dass wir unseren Kunden zuhören und mit Ihnen durch dick und dünn gehen.

8. Welche Rolle spielt Training?

Created with Sketch.

Wir werden häufig gefragt, ob die Unternehmen alle Mitarbeiter:innen in agilen Methoden schulen sollten? Unsere Antwort ist immer – ja alle. Am besten vom Vorstand bis Servicemitarbeiter:in. Sicher – die Trainings müssen entsprechend auf die jeweiligen Arbeitsbereiche und Positionen im Unternehmen abgestimmt sein. Doch wissen, worum es bei agilem Arbeiten, bei New Work und visuellen Management geht, sollten alle.

Widerstand ist eine Funktion von Nicht-Können?

Wir vertreten die Auffassung, dass der Widerstand gegen ein neues Verhalten, gegen eine neue Form des Arbeitens fast immer damit zusammenhängt, dass Menschen nicht wissen, was auf sie zukommt. Sie kennen sich im Neuen nicht aus. Sie wissen nicht, was von ihnen erwartet wird und sie fühlen sich unwohl, weil sie es noch nicht selbst umsetzen können. Und machen wir uns nichts vor: Unternehmen sind keine geschützten Räume, in denen man als Mitarbeiter:in etwas einfach mal ausprobieren kann oder zugeben kann, dass man sich noch nicht zutraut das Neue umzusetzen.

Und de facto haben die meisten Menschen keine profunden Kenntnisse darüber, wie agiles Arbeiten funktioniert. Wir sind fast alle klassisch sozialisiert worden und unsere Vorbilder sind es auch.  

Fast niemand hat in der Schule, im Kindergarten oder während der Ausbildung gelernt, was agiles Management ist. Erst jetzt arbeiten Consultants mit einigen wenigen Grundschüler:innen und bringen ihnen bei, wie man mit Aufgabenboards als Schüler:in auch selbstorganisiert lernen kann. Siehe Scrum4Schools.  

Die meisten Menschen in den Unternehmen haben noch nie etwas von Scrum und Kanban, SAFe und OKRs gehört. Dazu kommt noch, dass – sollte der eine oder andere bereits von Kolleg:innen und Freund:innen etwas dazu erfahren haben, die unterschiedlichsten Vorstellungen existieren – jeder versteht unter New Work und agilem Denken derzeit etwas anderes. Dazu braucht man nur mal auf Linked:in ein wenig zu recherchieren.  

Wie sollten die Trainings für alle Mitarbeiter:innen aussehen?

Wie finde ich mich im Dschungel der Trainingsangebote zurecht. Mache ich ein agiles Training oder eine Scrum Master Zertifizierung? Soll ich lieber zu Product Owner Schulung oder zum SAFe Training gehen? Welche Trainings für Führungskräfte oder Teams soll ich für meine Firma einkaufen? 

Die Antwort ist heute nicht mehr so einfach, wie vor 20 Jahren zu beantworten, weil es so viele unterschiedliche Anwendungsgebiete und Spezialisierungen gibt.

Zunächst schauen wir uns doch mal die verschiedenen Fragestellungen an, die ich mit einem Training lösen will.

  1. Allgemeine Information – Jede:r Mitarbeiter:in sollte wissen, was agiles Management ist und welche Unterschiede es gibt.
  2. Ein Team oder eine Abteilung möchte mit agilen Methoden arbeiten.
  3. Ein Projektteam soll agil arbeiten.
  4. Ein großes, sehr großes Projekt soll agile arbeiten.
  5. Die Führungskräfte der Organisation sollen verstehen, was agiles Management bedeutet und gegebenenfalls auch agiles Führen.


Die allgemeine Information

Es lohnt sich jede:n Mitarbeiter:in in ein agiles Info-Training zu schicken. Diese Trainingsformate heißen im Allgemeinen Agile 101 oder Agile Intro Workshops. Sie sind oft zwischen 3h bis 6h lang. Sie informieren über die Rollen und das Prozessmodell und zeigen oft schon einmal wichtige Ideen wie das Taskboard oder die Retrospektive.  

Die ScrumMaster Trainings: ein Team möchte mit Scrum arbeiten


Diese Formate waren für die Personen gedacht, die Scrum in das Unternehmen bringen wollten. Für Teamleiter:innen und Projektmanager:innen, die ihr Projekt ab sofort mit Scrum durchführen wollen. In zwei Tagen bekommt diese Person ein umfassendes Bild darüber, was Scrum wirklich macht und wie man es implementiert. Wie man Probleme im Team löst und wie die einzelnen Meetingformate und Begriffe zu verstehen sind. Das Ziel dieses Trainings ist Scrum anwenden zu können und es dem eigenen Team erklären zu können.

Dieselbe Variante des Trainings gibt es für alle gängigen Management-Frameworks also für OKRs, Kanban, Design Thinking und Scrum.

Eine Variante dieses Trainings gibt es für die Product Owner, hier wird detailliert erklärt, wie sich die Rolle des Product Owner auswirkt, mit welchen Tools dieser das Stakeholder-Management durchführen kann und wie er zum Beispiel eine Vision für das Team erarbeitet.

Wenn ein ganzes Projekt-Team mit Scrum arbeiten soll

Die Führung dieses Teams sollte ein ScrumMaster Training haben und entweder dann das Team selbst ein bis zwei Tage trainieren oder sich von einem Dienstleister:in dieses Team-Training einkaufen. Alle Mitarbeiter:innen des Teams müssen nach 1 bis 2 Tagen in der Lage sein zu verstehen, warum sie jetzt so arbeiten sollen. Gute Didaktik hilft und auch dieses Investment ist notwendig – ob mit einem Externen gestafft oder intern ist zweitrangig.

Das große, sehr großes Projekt soll agile arbeiten

Wieder gilt: Alle Führungskräfte, Teamleiter:innen sollten das Framework trainiert haben, dass sie dort nutzen. Egal ob es MyScaled Agile, LeSS, SAFe oder ein anderer Skalierungsframework ist. Die Personen, die exponierte Rollen haben, sollten alle das gleiche Verständnis haben.  

Wir bieten für diesen Fall das My Scaled Agile Training an oder auch die entsprechenden SAFe Trainings.  

Dann muss der Rest des Projektteams ebenfalls wieder 1 bis 2 Tage in dem gesamten Modell ausgebildet werden.  

Die Führungskräfte der Organisation, allen voran der Vorstand oder die Geschäftsleitung, brauchen ebenfalls ein Training

Hier gibt es verschiedenste Formate:

  1. Oft beginnt es mit einem Vortrag und die Führungskräfte bekommene einen ersten Einblick
  2. Effektiver ist es, die Führungskräfte 1 bis 2 Tage intensiv mit agilen Führungstechniken zu konfrontieren. Das kann ein Agiles Leadership Training sein, oder auch ein Scrum Master- oder Product Owner Training sein.
  3. Doch diese Trainings müssen durch 2 weitere Trainings vervollkommnet werden:
    • Einem Training in der Art des von uns entwickelten Selbstorganisation braucht Führungs-Training. Also der intensiven Auseinandersetzung mit mir und den neuen Möglichkeiten der Führung aus einer agilen Haltung heraus.  
    • Ein Training, dass sich Zeit nimmt Elemente aus dem Lean Management zu erklären. Flow, Work in Progress Limits und ähnliche Tools. Das ist notwendig, weil Führungskräfte verstehen müssen, dass sie es in der Hand haben, ob ihre Organisation produktiver wird oder eben nicht.


Neben diesen klassischen Methodentrainings ist es dann notwendig auch Fähigkeiten zu Leadership, Teamcoaching, Facilitation und Change Management zu erwerben.

Hier ist meine Empfehlung auch in diesem Fall auf Anbieter:innen zuzugreifen, die aus dem agilen Beratungsumfeld kommen. Agile Leadership Skills und agiles Change Management sind beispielsweise doch anders von ihrer Grundhaltung als die traditionellen Ansätze. Es mag sich das eine oder andere Mal nur um eine Nuance handeln, doch diese ist am Ende entscheidend bei der Anwendung und dem Erfolg.

9. Wer sind die Top 10 agilen Unternehmensberatungen?

Created with Sketch.

Wer heute auf eine Konferenz wie die Agile 2025 in den USA, die Manage Agile in Berlin oder eine andere Veranstaltung geht, um sich darüber zu informieren, welche agile Unternehmensberatungen ihm oder ihr denn bei der Einführung von agilen Management Frameworks wie Scrum, Kanban, Design Thinking helfen soll oder beim agilen Skalieren mit SAFe, My Scaled Agile oder LeSS unterstützen soll, wird schier überwältigt von der Zahl der Anbieter:innen. Der Markt wird noch unübersichtlicher, weil es daneben auch noch zig Kleinst-Unternehmen mit wenigen Mitarbeiter:innen gibt, oft sogar sind es tatsächlich Ein-Personen Unternehmen, die gemeinsam mit Kolleg:innen aus ihrem Netzwerk auftreten.  

An dieser Stelle ist es auch uns nicht möglich einen kompletten Überblick über den Markt im deutschsprachigen Raum zu geben, doch wir starten hier mal den Versuch die aus unserer Sicht sechs kompetentesten Unternehmen aufzuzeigen und ihnen kurz vorzustellen.

Sie werden auf dieser Liste nicht die großen Unternehmensberatungen finden, die auch agile Transformationsberatungen anbieten. Cap Gemini, Accenture,  PWC, Bearing Point und McKinsey, Bain, Boston Consulting Group - sie alle bieten natürlich auch Beratungen in diesem Feld an. Ihnen werden wir einmal einen eigenen Beitrag widmen.


1. Das Scrum Team

Fangen wir mit einer kleinen sehr spezialisierten Beratung an. Das Scrum Team. Gegründet von Andreas Schliep und Peter Beck. Sie wären meine erste Empfehlung, wenn es darum geht, Trainings zum Certified ScrumMaster, Certified Product Owner oder auch die weiteren Zertifkats-Trainings, die die Scrum Alliance anbietet einzukaufen.

Sie gehören zu den erfahrensten Scrum-Trainern der ersten Stunde. Sind bestens in das Netzwerk der agilen Szene und der Scrum Alliance eingebunden und kennen viele Probleme bei Unternehmen. Ihre Kurse sind hochaktuell und ihre Kund:innen sind in Deutschland und der Schweiz.

2. Wibas

Die Nr. 2 auf der Liste wäre die Wibas. Wibas, schon vor einem viertel Jahrhundert von Claudia Raak, Jörg Battenfeld und Malte Foegen gegründet, versteht sich als agile Management-Beratung. Sie ist anders als das Scrum Team nicht auf Scrum, sondern methodisch auf SAFe spezialisiert – nutzt diese Trainings allerdings, um agile Transformationen anzubieten. Dazu gibt es von ihnen auch ein Buch.  

Sie bieten ebenfalls sehr gut Scrum Trainings, haben sich daneben aber in den letzten Jahren mehr auf die Skalierungsframeworks allen voran SAFe spezialisiert. Sie bieten darüber hinaus auch die anderen agilen Management-Frameworks an. Sie haben im Darmstadt eine wunderbare Location, in denen sie ihre Trainings geben. Ihre Beratungen rund um SAFe und agile Transformationen gehören sicher zu dem besten, was der deutsche Markt zu bieten hat.

3. IT Agile

Wer im norddeutschen Raum nach einem agilen Training zu Scrum, Kanban oder SAFe sucht, der kommt natürlich nicht an der IT Agile aus Hamburg vorbei. Sie stehen nur auf Platz drei, weil ihr Angebot für meinen Geschmack unübersichtlich geworden ist.

Wer sich über UNFIX oder ihr eigenes agiles Führungsangebot informieren will, wird dort genauso fündig, wie jemand der die Zertifizierung der Scrum Alliance oder der Scrum.org findet. Doch das ist ihre Stärke - sie gehören, weil sie auch schon länger als 2 Dekaden im agilen Markt zu den erfahrensten Berater:innen, wenn es darum geht Teams und Organisationen in agilem Management und Mindset zu beraten.  

4. Kegon AG  

Die Kegon AG in Wiesbaden war eine der ersten Beratungen in Deutschland, die sich auf den Scaled Agile Framework spezialisiert hatte. Sie bieten Trainings und Beratung rund um den  SAFe-Framework an. Wer sich über diese Variante der Skalierung von Unternehmensprozessen informieren will, der ist sicher gut beraten bei der KEGON einmal vorbeizuschauen. KEGON hat ein sehr großes Netzwerk, da sie sich von Anfang an als Netzwerkorganisation gesehen haben.  

5. Improuve

Eine weitere agile Unternehmensberatung der ersten Stunde ist Improuve in München. Sie bieten neben den Certified Scrum Trainings wie Certified ScrumMaster so wie die anderen genannten auch die Professional Scrum Trainings der Scrum.org und die Flight Level Training der Flight Level Academy sowie Kanban und SAFe Trainings. Sie verstehen sich als Beratung auf Augenhöhe und gehören sicherlich zu den leiseren Unternehmensberatungen im Markt, doch man trifft sie auf vielen Konferenzen.

6. Agile Heroes

Last but not least auf dieser Liste sind die Agile Heroes aus Frankfurt. Sie haben mit Abstand die beste Website und die beste Social Media Präsenz. Ihre Stärke sind die Scrum Professional Trainings der Scrum.org, aber auch agile Prince oder sogar Scrum in Gründung.

Aber ihr absoluter  Schwerpunkte sind online Schulungen, die sie wesentlich aggressiver anbieten als die oben genannten – die alle ebenfalls online Angebote haben. Ihr zweites Standbein ist die Beratung, von agilen Transformationen bis agiler Strategieberatung bekommt man bei ihnen ebenfalls das gesamte Portfolio.  

Fortsetzung folgt

Diese Aufzählung kann Ihnen die Arbeit nicht abnehmen, selbst das für Sie richtige Unternehmen zu finden. Und sie ist wie gesagt noch lange nicht vollständig. Um es spannend zu machen ... diese Liste wird fortgesetzt.  In einem weiteren Post werden wir u.a. die HR Pioneers und andere wie die Emendare kurz vorstellen. Lasst uns wissen, wer unbedingt auch erwähnt werden muss.

10.Warum macht ihr eigentlich kein SAFe?

Created with Sketch.

Um diese Frage zu beantworten, muss ich ein wenig weiter ausholen. Mein erster Versuch ein Buch über Skalierung von Scrum zu schreiben war ein Desaster. Ich schrieb mich in eine Schreibblockade. Es ging nicht! Monatelange probierte ich unterschiedliche Zugänge zu dem Thema aus, verfasste Gliederungen, schrieb meine ersten Zeilen und blieb stecken. Dann viel es mir wieder ein. Es war fast als würde ein Film in meinem Inneren ablaufen: Recife, 2008.  Ein großer Saal. Eine Software Entwicklungskonferenz. Auf der Bühne spricht Jan Bosch. Ein Star in der Software-Architektur-Szene. Seine These: Große Projekte skalieren nicht über den Prozess, sondern nur über die Architektur. Jeder Versuch ein großes Projekt mit Hilfe von Prozessen im Griff zu halten, muss am Ende scheitern, weil die Abstimmungsaufwände zu groß werden, führte er weiter aus. Das passte zu meinen Erfahrungen. Ich hatte bis dahin bereits mehrere Male großes Entwicklungsprojekte mit 60 Personen, 180 und 250 Personen auf Scrum umgestellt. Ja, es war möglich, aber es war so extrem anstrengend. Es gab irre viele Abstimmungsmeetings und die Taskboards wurden länger und länger, das längste war 7 Meter lang.
 

Und Bosch erklärte uns ja nur, was in Sillicon Valley bei Amazon und Intuit in Sacheng große Projekte passierte. Das war die Zeit als die Idee die Microservice Architektur nicht nur erfunden, sondern implementiert wurde. Sein Ansatz versprach die Lösung, denn ich hatte es selbst erlebt – es war möglich 180 Entwickler:innen gleichzeitig an einem Projekt arbeiten zu lassen und die vielen Abhängigkeiten mit Hilfe von Taskboard zu managen. Auch konnte man das Sprint Planning so gestalten, dass die 180 Entwickler:innen am Ende eines Tages tatsächlich wussten, was sie entwickeln wollten. Ich hatte die Idee von Bas Voode, nimm einen großen Raum und setze alle 180 Personen dort hinein, umgesetzt und lauffähig gemacht (heute heißt das Big Room Planning). Doch es war so unendlich mühsam, laut und chaotisch. Aber auf Dauer war das keine Lösung. Es kostete ja irrsinnig viel Geld. 180 Entwickler:innen zum Tagessatz von 800 Euro ... ich sagte dazu immer: “Und gerade wurde wieder ein Porsche 911 verbrannt.” Diesen gigantischen viel zu teuren Overhead muss man sich erst einmal leisten können.

Ich bin immer noch der gleichen Meinung: Kund:innen beauftragen zwar unsere Consultants dafür diese Big Room Meetings zu veranstalten, doch effektiv ist das nicht. Wir können das Big Room Meeting effektiv machen, doch dieser Ansatz ist grundsätzlich falsch.  

Warum? Dafür gibt es zwei Gründe:  

  1. Der erste ist die Vorstellung, die auch noch immer durch das alte Bild von Ken Schwaber mit dem Backlog auf der linken Seite, den beiden Kreisen in der Mitte und dem Produktinkrement auf der rechten Seite, verbreitet wird. Die Vorstellung, die Entwicklungsteams arbeiten Anforderungen eines Product Owners oder der Kund:innen ab.  Gerade großes Entwicklungsorganisationen, die Auftragsentwicklung machen, nutzen SAFe deshalb, weil sie sich so aufstellen – genau diese Idee zu bedienen. Da werden in diesen Meetings die Release Trains besprochen – damit diese dann beauftragt werden können. Hier wird völlig die berechtigte Kritik aus der Lean Community, dass Scrum und SAFe in Batches abarbeiten, statt in einem kontinuierlichen Flow liefert, ignoriert. Wenn man 3 Monate vorausplant, ist man eben auch nicht mehr in der Lage adhoc auf die Kund:inen-Bedürfnisse zu reagieren.  
  2. Der zweite Fehler ist die Architektur des Produktes nicht so zu entwickeln, dass Teams End2End liefern können.


Aber ich verliere mich schon im Detail. Die Änderung der Architektur war also die Lösung des Skalierungsproblems. Jedes Team ist dabei für einen oder mehrere Services zuständig. Ein Service gehört aber immer nur einem Team. Das führt dazu, eine Organisation aus unabhängigen Teams aufzustellen und die ersten Bilder dazu, wurden dann von Spotify erläutert und das Spotify-Modell entstand.

Gleichzeitig muss ein weiteres Problem gelöst werden. Wenn unterschiedliche Services zusammen interagieren müssen, die alle für sich gekappselt sind, doch voneinander wissen, dann müssen diese Services miteinander kommunizieren. Es braucht eine Infrastruktur, die diese Kommunikation ermöglicht. Unsere Laptops haben alle ein Betriebssystem, dass die Hardware-Infrastruktur (Gehäuse, Bildschirm, Tastatur, Stromversorgung, Chips) so abstrahiert, damit darauf die Applikationen, die Services laufen können. Das skalierte System aus zig-Tausend Services (Word, Excel, Safari, Powerpoint bestehen selbst wieder aus 1000den Services) funktioniert, weil unabhängige Einheiten durch das Betriebssystem in die Lage versetzt werden, miteinander zu kommunizieren.  Die Architektur war also nur die eine Bedingung, es brauchte auch die zweite Voraussetzung, eine neue Art der Infrastruktur. Auf die Produktentwicklung umgemünzt hieß, dass wir müssen bei großen Projekten nicht nur in Microservices denken, wir brauchen auch noch die Tools und Prozesse – das Betriebssystem, in Form von Infrastruktur, damit die Teams gemeinsam liefern können.  

Am besten werden durch das Betriebssystem dann auch noch die meisten Prozessschritte automatisiert. Hier ist das Continuos Deployment und das automatisierte Testen zunächst erst einmal nur die Eintrittskarte. Es kann noch viel mehr automatisiert werden, wenn man sich damit auskennt. (Übrigens steckt hier natürlich der erste entscheidende Anwendungsfall für GEN-AI; jeder Wissensarbeiter wird in die Lage versetzt, seinen Job zumindest in Teilen zu automatisieren.  

Jedem der diese obigen Tatsachen akzeptiert und damit seine Prämissen ändert - kann nicht mehr daran glauben, dass Skalierungsmodelle die Lösung der Probleme großer Projekte sind. Egal ob Nexus, SAFe, LeSS oder die anderen Skalierungsframeworks, sie alle hatten 1. noch immer das falsche Ausgangsszenario und 2. verkannten die Tatsache, dass Skalieren über Prozesse viel zu teuer wird.  

Der dritte Schritt war dann eine Folgerung aus einer Beobachtung. Die meisten Organisationen konnten weder mit der Idee der emergenten Architektur noch mit Microservices, weder mit Test Driven Development oder Automatisierung, ja die meisten Organisationen scheitern noch daran, dass die kollaborativen Tools wie Miro oder MS Teams nicht in ihrem vollen Umfang genutzt werden – es fehlt an den Skills. Es nützt nichts, das Obige zu wissen, wenn es die Organisation, d.h. die Menschen in den Organisationen, nicht denken können, weil sie die Skills nicht haben.

Ein Modell, dass erklären will, wie man ein wirklich großes Produkt baut, musste dann also auch den Faktor Skill berücksichtigen. Diese Tatsache wird im Übrigen ebenfalls nicht in den bekannten Frameworks wie SAFe angesprochen – und ich rede nicht von agilen Skills. Es geht um den Skill, seine Arbeit anders als im klassischen Kontext zu machen. Allein das Beispiel Automatisierung oder KI heute zeigt, was hier gemeint ist.  

Um diesen Artikel hier nicht zu sprengen: Es gab noch drei weiteren Aspekte:


  1. Wer ein Produkt erfinden will, muss das heute mit agilen Methoden user-zentriert machen, nutzt hier also Design Thinking als agile Produktentwicklungsmethode,
  2. braucht einen agilen Management-Framework, um Teams und Organisationen zu führen Scrum 3.0 und OKRs und er  
  3. braucht ein agiles Führungsverständnis, um eine Kultur des Gelingens zu implementieren. (Wer diese 6 Schritte genauer verstehen will, dem sei mein Buch Scrum Think B!G, unsere MyScaled Agile Framework, und unser 6 D – Assessement empfohlen.)  


Diese 6 Level haben wir hier einmal dargestellt.  


Soweit zu Genese der Überlegungen, warum Skalieren selbst etwas völlig anders ist, als es in den Skalierungsframeworks erklärt wird. Nur – dann, wenn all diese Faktoren miteinander betrachtet werden, kann eine Organisation tatsächlich agile, also user-zentriert und hocheffektiv liefern. Alles andere führt zu Bürokratie und gigantischen Kosten.  

Wer unbedingt SAFe machen will, der muss eine große Organisation haben und viel sehr viel Geld in die Hand nehmen können. Die Aufwände, nur SAFe zu managen, weil es nur um Prozesse geht, sind sehr hoch – und man muss auch noch eine Lizenz dafür zahlen, wenn man es benuten will. Absurd – ist es doch u.a. in meinem Buch Scrum Think B!G beschrieben, wie Skalierung prozessual gemanaged wird.  

Aber hier geht es nicht darum SAFe schlecht zu machen, sondern zu zeigen, dass es auch anders geht. Wir haben selbst darüber nachgedacht, wie wir Organisationen unterstützen können, wenn sie noch nicht ideal aufgestellt sind. Wenn sie noch keine Teams haben, die End2End liefern können, wenn die Architektur noch nicht passt, wenn es noch keine ausreichende Automatisierung gibt und auch noch der/die Anwender:in viel zu wenig befragt wird – unsere Lösung für unsere Kund:innen ist der MyScaled Agile Ansatz.  

Basierend auf dem obigen sechs Punkten und dem korrespondierenden 6D Assessment – entwickeln wir einen strategischen Implementierungspfad mit unseren Kund:innen. Ja – wir haben dabei auch unseren Blue Print im Kopf, doch dieser kann auf vier Prinzipien reduziert werden: ‍

  1. Ermögliche es, Teams End2End Verantwortung zu übernehmen – Loose loose Coupling von Teams und Microservices! ‍
  2. Automatisiere so viel wie möglich – z.B. DevOps Automationen!
  3. Denke immer von Kund:in her – user centricity!
  4. Stelle die Organisation als Netzwerk auf und gestalte Führung entsprechend!


Um dorthin zu gelangen ist es häufig so, dass Organisationen Zwischenstadien benötigen und zunächst den ein oder anderen Vorläufer zu einer netzwerkartigen Struktur eingehen müssen. Das ist völlig ok – solange es gelingt, systematisch die Organisation auf die Kund:innen auszurichten und damit zukunftsfähig zu halten. Wer mehr dazu wissen will – schaut einfach mal hier: Agile Skalierung

Machen wir also SAFe? – Wir würden selbst keine SAFe Implementierung empfehlen, doch wenn Kund:innen unsere Expertise in ihrem SAFe Projekt benötigen, um dann SAFe zu implementieren, lassen wir unsere Kund:innen natürlich nicht allein. Die Hoffnung bleibt, dass wir mit unserer Expertise im SAFe Kontext die der Agilität zugrundeliegenden Prinzipien doch am Ende für unsere Kunde:innen nutzbar machen können.