Sie möchten oder sollen agil arbeiten? Jetzt stellen sich Ihnen noch ein paar Fragen? Sie sind nicht allein. Deshalb, also aufgrund der weiterhin großen Nachfrage, ein weiterer Teil einer Serie, in der ich einige der nachvollziehbaren Fragen zu beantworten versuche./1/ Wie immer tappe ich dabei voller Absicht in die Beraterfalle./2/
 |
| Bild vom Autor |
Was genau versteht man unter "agilem Arbeiten"?
Ja, gut. Das ist eine wichtige Frage. Und ein Evergreen. Fragen Sie zehn Menschen, und Sie bekommen 15 Antworten. Hier dann die sechszehnte, also MEINE Antwort:
Agiles Arbeiten bedeutet, sich als Team, Abteilung, Bereich und Unternehmen in relativ kurzen regelmäßigen und gleichbleibenden (!) Abständen zusammenzufinden (Takt: 1 bis 4 Wochen), um immer wieder zu überprüfen, ob man noch auf dem richtigen Weg ist oder irgendetwas angepasst werden sollte.
Wir machen das also GEMEINSAM und selbstorganisiert, also nicht irgendwie angeleitet durch irgendeine Art Management. Wir agieren dabei auf ECHTER Augenhöhe, allerdings NICHT hierarchiefrei, sondern unserer jeweiligen Verantworungen, Job und Rolle entsprechend. Wir reden uns also nicht gegenseitig rein. Sondern jeder erledigt seinen resp. ihren Job. Und wir lassen auch die jeweilig anderen ihren Job machen.
Heißt umgekehrt auch: Wir fordern es auch ein, dass das Management die Richtung vorgibt uns sich kümmert, dass der Rahmen stimmt. Umgekehrt müssen, sollen die Fachleute dann den Job erledigen ohne dass ihnen dann gesagt wird, wie. UND eben auch ohne, dass man ihnen zumutet, uninformierte Businessentscheidungen treffen zu müssen.
In anderen Worten: Wir denken, sprechen und tun - wir ARBEITEN - also in FUNKTIONALEN Strukturen und eben nicht (mehr) in DYSFUNKTIONALEN. (Wir erkennen also radikal an, dass wir alle in einem Boot sitzen, wo jeder SEINEN Job zu erledingen hat. Kein gegenseitiges Abschieben von Verantwortung mehr!)
Das alles tun wir ALLE IMMER mit radikalem Kunden- bzw. Marktfokus. Denn NUR dort entscheidet sich heute der Geschäftserfolg.
Wir sorgen also dafür, dass wir ECHTE Probleme lösen und das auch tun können. Und zwar vornehmlich die DES KUNDEN. Und nicht etwa hauptsächlich unsere eigenen Probleme oder jene, die wir für relevant halten. (Um der großen Gefahr zu begegnen, am Kunden/Markt vorbei zu arbeiten.)
Um das tun zu können, achten wir darauf, ECHTE Arbeit tun, also überwiegend an Kundenprojekten zu arbeiten. Und wir tun alles dafür, dass wir das auch tun KÖNNEN. Indem wir z.B. so wenig Zeit und Energie wie möglich in sinnlosen und auch sinnlos langen Besprechungen verplempern, die ja doch oft nur Statusgedöns sind (erkennbar z.B. daran, dass Menschen nicht pünktlich erscheinen und so zeigen, dass "man" es sich leisten kann, andere warten zu lassen und somit das Geld mit vollen Händen zum Fenster rauschmeißen zu können.)
 |
| Zeichung vom Autor |
Außerdem fragen wir uns regelmäßig GEMEINSAM, wo wir auf dem Weg zum Ziel stehen. Das machen wir, indem wir uns die folgenden zwei Fragen stellen - und übrigens auch beantworten (!):
1. Wie zufrieden ist der Kunde bzw. der Markt mit unserer Arbeit?
2. Was können wir tun, um uns für die nächste Zeit besser zu organisieren und zusammenzuarbeiten?
Zur ersten Frage nach der Qualität der Arbeit: Wie können wir unser Produkt, unseren Service, unsere Arbeit verbessern?
Passt unsere Arbeits-QUALITÄT? Ist der Kunde mit uns und unserer Arbeit im Detail zufrieden? Ist der/sind die Kunden mit unserem Output in den letzten Wochen samt seiner Qualität zufrieden? Was ist anzupassen? Wo können/müssen wir die nächsten Wochen besser werden, um die Kundenerwartungen noch besser zu erfüllen? Wo wollen wir selbst die eigenen Planungen verbessern, um unsere Qualitätsvorstellungen besser zu erfüllen?
 |
| Zeichnung vom Autor |
- Was wir an der Qualität unserer Produkte und Services verbessern und also einplanen sollten.
- Was dem Kunden bzw. dem Markt generell wichtig ist.
- Wie wir unsere Planung und unsere Arbeitsqualität verbessern können.
 |
| Zeichnung vom Autor |
Der größte Vorteil agiler Formen der Zusammenarbeit ist, dass sie institutionalisieren, was in in der DNA von Hochleistungsorganisationen, also z.B. Lean Organisiationen festgeschrieben ist: Routinemäßig und IMMER zu überprüfen, was in der Zusammenarbeit anzupassen bzw. zu verbessern ist, um sich den stets wandelnden Begebenheiten anzupassen und Kunden zufrieden zu stellen.
Also: Was ist in der letzten Zeit gut gelaufen, was weniger? Was davon ist besonders wichtig? Was ist die WIRKLICHE Ursache? Welche effektive, machbare Maßnahme hilft uns, besser zu werden? Und das, ohne das ganz große Wir-machen-jetzt-ALLES-anders-und-diesmal-aber-richtig-Change-Rad zu drehen?
Ständig wird so die Planung und die Struktur in kleinen Schritten, also auf machbare (!) Weise den neuen Realitäten angepasst. So
- werden wir als Organisation flexibel. Denn indem wir in Abständen von ein bis vier Wochen so agieren, versetzen wir uns alle in die Lage, zu reagieren und sogar zu agieren. Und zwar zu einem Zeitpunkt, wo das noch gut geht. (Im Gegensatz z.B. zu Top-Down Jahresplanungszyklen. Oder zu Situationen, wo die Probleme schon so groß oder verworren sind, dass sie überbordend erscheinen.)
- lernen wir als Organisation. Und wenn wir es gut anstellen sogar gemeinsam mit dem Kunden. Vor allem lernen wir, was dem Kunden wichtig ist und wie wir ihn zufriedenstellen können.
- bauen wir Vertrauen und Selbstvertrauen auf.
- bauen wir nach und nach organisatorische Schulden und vor allem: Dysfunktionaliäten ab (Wechsel- und Verzugskosten, ständiges Beschäftigen mit sich selbst, Fingerpointing, kostspielige, nervige, gesundheitsschädliche Machtspielchen und/oder Egoismen).
- wird (wieder) möglich, sich in die Organisation wertschöpfend einzubringen.
- kann der Spaß an der Arbeit bzw. der Selbstverwirklichung wiederkehren.
- steigert sich der Profit und die Wirtschaftlichkeit (alleine schon dadurch, dass wir uns mehr und mehr auf die Arbeit konzentrieren und unnötiges Status- und Business-Theater schlicht und einfach: weglassen).
 | ||
DAS also verstehe ICH grundsätzlich unter agilem Arbeiten. (Wer wissen möchte, wie das im Detail funktioniert bzw. funktionieren kann, lese sich die paar Seiten Scrum-Guide durch, den es kostenlos zum Download gibt.
Wichtig, weil oft missverstanden: Agilität ist KEINE Methode oder "Tool". Auch wenn manche agile Arbeitsrahmen sehr viel Methodisches und Prozesshaftes an sich haben. Und auch wenn Agilität in den letzten Jahren von Bertungsfirmen als methodisches Produkt verkauft wird.
Die Zusammenarbeit agil zu organisieren bedeutet, mit einer bestimmten Haltung, auf bestimmte Art und Weise und mit bestimmten Fokus auf die Wertschöpfung Geschäfte zu betreiben und sich entsprechende Strukturen zu geben - und vor allem auch, auf gewisse statusorientierte, machthierarchische Strukturen radikal zu verzichten.
 |
| Zeichnung vom Autor |
Weiterlesen?
- Anderson, David J.: Die Essenz von Kanban – kompakt.
- Anderson, David J.; Reinertsen, Donald G: Kanban. Successful Evolutionary Change for Your Technology Business.
- Sutherland, Jeff: Scrum. The Art of Doing Twice the Work in Half the Time, New York, 2014. (Deutsch: Die Scrum-Revolution)
- Schwaber, Ken; Sutherland, Jeff: Scrum Guide
Welche Formen des agilen Arbeitens gibt es?
Agilität ist mehr eine Haltung als eine bestimmte Form des Arbeitens (s.o.). Trotzdem gibt es hilfreicherweise ein paar weit verbreitete, konkrete Arbeitsrahmen, die alle Menschen anleiten, die damit beginnen wollen, agil zu arbeiten.
Alle agilen Arbeitsrahmen fokussieren inhaltlich auf etwas anderes. Neudesign und Markteinführung von Produkten, Arbeiten an Projekten, reibungsloses Implementieren von neuen Features, Organisieren und Abarbeiten von gleichbleibenden und auch gleichförmigeren Service-Aufgaben.
Alle diese Arbeitsrahmen teilen dieselbe, oben angerissene agile Philosophie. Diese wird oft mit dem so genannten Deming-Kreis beschrieben: Planning - Doing - Checking - Adjusting. Bei ganzheitlicher Betrachtung der gesamten Wertschöpfung und deren Entstehung. Und bei maximalem Kunden- bzw. Marktfokus.
Außerdem geht es jedem Arbeitsrahmen zunächst um die Arbeit von EINZELNEN Teams. Um zu verstehen, wie Agilität innerhalb eines Teams grundsätzlich vorgeht, ist es also sinnvoll, sich mit den Details von einem dieser Arbeitsrahmen zu beschäftigen (Wenn Sie sich fragen, mit welchem, starten Sie mit Scrum, da können Sie nichts falsch machen!)
Wen jedoch darüber hinaus interessiert, wie man größere Projekte oder Unternehmungen agil organisieren kann, dem reicht das vielleicht nicht. Natürlich sollten Sie zunächst verstehen, wie Agilität grundsätzlich, also im Kleineren funktioniert, bevor Sie sich der Frage zuwenden, wie sie in größeren Kontexten funktionieren kann. Hierfür könnten Sie sich mit "Nexus" und "Scrum@Scale" beginnen zu beschäftigen (beide sind von den Scrum-Erfindern entworfene Arbeitsrahmen für größere Teams bzw. Unternehmen.).
SAFe und LeSS sind in diesem Zusammenhang auch noch zu erwähnen. Wer sich jedoch mit diesen beiden, naja, teil-agilen Hierarchie- und Prozessmonstern zu beschäftigen beginnt, wird schnell die Agilität vermissen und sich zurecht fragen, was denn nun genau der Unterschied zu den gestaffelten Prozess- und Ablaufstrukturen der Statushierarchien ist, von denen man sich ja gerade wegbewegen möchte.
Für sachdienliche Hinweise in dieser Hinsicht wäre ich sehr dankbar. Denn ich weiß das auch nicht.
 |
| Zeichnung vom Autor |
Weiterlesen?
- Anderson, David J.: Die Essenz von Kanban – kompakt.
- Anderson, David J.; Reinertsen, Donald G: Kanban. Successful Evolutionary Change for Your Technology Business.
- Nexus-Guide
- Scrum@Scale Guide
- Sutherland, Jeff: Scrum. The Art of Doing Twice the Work in Half the Time, New York, 2014. (Deutsch: Die Scrum-Revolution)
- Schwaber, Ken; Sutherland, Jeff: Scrum Guide
Ist agiles Arbeiten nicht immer noch nur ein "Theoriegespinst" oder eine Methode für IT-Abteilungen, die sich in einer kompletten Organisation nie wirklich umsetzen lassen wird?
Ja, Agilität, so wie wir sie heute verstehen, hat seinen Ursprung in der IT. EIGENTLICH ist die Idee der organisationalen Agilität aber schon viel älter, siehe hierzu Jans letzten Post.
Dass ausgerechnet die IT die agile Idee aufgriff, ist kein Zufall. Es liegt daran, dass ihre Systeme, Phänomene und Geschäftsmodelle spätestens um die Jahrtausendwende so komplex geworden und mit den klassischen Geschäftsmodellen immer mehr verwoben waren, dass sie auf Teufel komm raus nicht (mehr) wie komplizierte Maschinen funktionieren und sich entsprechend managen lassen wollten.
Das war streng genommen zwar schon immer so, nur jetzt konnte man diese Tatsache bei bestem Willen nicht mehr ignorieren oder kaschieren.
Planungsansätze, die auf der Idee relativ einfacher Ursache-Wirkungs-Beziehungen aufbauten und für die Massenproduktion des 20. Jahrhunderts erfunden worden waren, also z.B. der viel zitierte Wasserfall, funktonierten jetzt selbst mit maximalem Zwang, Selbstbetrug oder Betrug nicht mehr. (Ein gutes Beispiel dafür dürfte das inzwischen schon wieder in Vergessenheit geratene Jahr 2000-Problem sein.)
Zudem wurden die Geschäftsmodelle in der damaligen aufstrebenden digitalen Welt immer abhängiger von IT-Services. Die wurden bis dahin mehr oder minder als unterstützende Hausmeisterdienstleistungen gesehen. Sie sorgten lediglich dafür, dass die anderen, vermeintlich wertschöpfenden Firmenabteilungen arbeiten und ihre Geschäftsmodelle gewinnbringend realisiseren konnten. Mehr war von der IT nicht zu erwarten.
Ab der Mitte der 90er Jahre jedoch begann der rapide digitale Trend, mit der Folge, dass sich das Verhältnis mehr und mehr umkehrte: Nun waren es plötzlich die IT-Lösungen, die die Treiber der wertschöpfenden Geschäftsmodelle waren, ja, diese erst möglich machten. Unter immer stärkeren Fokus auf den Einzelnutzen der Konsumenten.
Alle Unternehmensbereiche, alle Produkte und Services, ALLE Geschäftsmodelle waren plötzlich zu 100 Prozent von einer reibungslosen, kreativen, funktionierenden liefernden IT abhängig. In jedem Bereich. In jedem Industriezweig.
Organisatorisch bedeutete das, dass sich IT und restliche Abteilungen - konkret und praktisch und eben NICHT theoretisch - untrennbar miteinander verwoben. Denn nur so konnte man die immer komplexer gewordenen Anforderungen der Organisation, der Kunden und des Marktes erfüllen.
 |
| Zeichnung vom Autor |
Das ist die Welt, in der wir heuten leben: Wir arbeiten in ultra-komplexen, IT-basierten Organisationen. Um ultra-komplexe Marktprobleme und Situationen zu lösen. Und zwar mit unseren ultra-komplexen Produkten und Services.
Im Gegensatz zu Kompliziertheit bringt Komplexität es mit sich, dass wir nicht genau wissen oder vorhersagen können, was passieren wird, wenn wir diesen oder jenen Schritt tun. Nicht der noch so beste einzelne Experte oder auch Expertengremium kann das. Also müssen wir uns ständig vortasten und anpassen. Und zwar nicht als Einzelne, sondern als Team, Abteilung, Unternehmung, Firmen-Kunden-System.
Die IT war schon vor dreißig Jahren in dieser komplexen Situation. Sie hat damals (auch eher unfreiwillig) damit begonnen, nach einer organisatorischen Lösung für dieses Problem zu finden und im Zuge dessen agile Wege für sich adaptiert. Anders hätte sie mit dieser ultra-Komplexität nicht mehr umgehen können.
Und das NICHT THEORETISCH, sondern ganz PRAKTISCH.
Agilität war und ist also alles andere als ein Theoriegespinst. Es ist ein praktischer Ansatz, um die Arbeit erledigen zu können. Und zwar in der Qualität, die Kunden erwarten und auch erwarten dürfen.
Und weil IT und andere Geschäftsbreiche inzwischen untrennbar miteinander verbunden und voneinander abhängig sind, ist Agilität längst kein Ansatz mehr, der nur für die IT hilfreich und (überlebens-) wichtig ist. Wir kommen alle nicht mehr um Agilität herum.
Je schneller wir diese Zusammenhänge erkennen, und je schneller wir Agilität zulassen, desto besser wird es sein.
|
| Zeichnung vom Autor |
Weiterlesen?
- Laloux, Frederic: Reinventing Organizations. A Guide to Creating Organizations. Inspired by the Next Stage of Human Consciousness.
- Wohland, Gerhard; Wiemeyer, Matthias: Denkwerkzeuge der Höchstleister. Warum dynamikrobuste Unternehmen Marktdruck erzeugen.
- Snowden, Dave: Cynefin – Weaving Sense-Making Into the Fabric of Our World.
- Snowden, David J.; Boone, Mary E.: A Leader’s Framework for Decision Making. Harvard Business Review, November 2017.
Wie kombiniert man das eigene agile Arbeiten mit nicht-agilem Arbeiten? Wie kann man mit externen Partnern agil arbeiten, die noch nicht "soweit sind"? Wie schafft man es mit internationalen Partnern agil zu arbeiten?
Diese Frage wird häufig gestellt. Vielleicht erklärt sich das mit unserem sehr prozesshaften Verständnis von Arbeit und also auch Agilität. Das verleitet zur Annahme, dass Unternehmen wie Maschinen funktionieren, in denen Zahnräder ineinander greifen. Wenn also unser Zahnrad mit bestimmten agilen Prozessen und Methoden funktioniert, müssen diejenigen, mit denen wir zusammen arbeiten, die anderen Zahnräder, ähnlich arbeiten, damit das funktionieren kann.
Tatsächlich, je nach Arbeitsrahmen, gibt es auch in der Agilität einiges, was prozesshaft wirkt und auch relativ strikt einzuhalten ist (mutmaßlich): Rollen, Events, Artefakte, Takte...
Und das macht auch Sinn. Je nach Situation mal mehr, mal weniger.
Und doch ist immer - und gerade in der Zusammenarbeit mit anderen, vielleicht sogar externen Kooperationspartnern - wirklich wichtig, sich daran zu erinnern, dass wir keine Zahnräder sind. Als Organisation sind wir auch keine Maschine. Viel eher sind wir ein Organismus, der anders und eben nicht maschinenhaft funktioniert und agiert.
 |
| Zeichnung vom Autor |
DAS ist das organisatorische Anliegen der Agilität: Unternehmen (wieder) eher wie Organismen funktionieren zu lassen statt als Maschine. Die zentralen Elemente der Agilität sind deshalb:
- Fokus immer auf die Wertschöpfung, die wir zum Überleben brauchen, also auf den (schnellen) Kundennutzen (zufriedenstellend Liefern! Rechnung schreiben!).
- Lernen und Anpassen: Immer wieder Planen, Tun, Auswerten, Anpassen. Gemeinsam, in einem festen Takt.
DAS ist Agilität. Ich sehe keinen Grund, wieso das mit anderen Zahnrädern a/k/a KollegInnen, externen PartnerInnen oder Teams, die sich keinem agilen Arbeitsrahmen verschrieben haben, nicht zu organisieren sein soll.
Welches ist der erste Schritt in agile Arbeitsformen, den ich alleine, und welcher, den ich mit anderen gehe?
Zwei Tipps, die ich Ihnen dazu geben kann:
 |
| Zeichnung vom Autor |
Erstens: Für Sie persönlich: Machen Sie sich klar, dass AGILITÄT EIN TEAMSPORT ist. Sie kommen selbst mit dem umfassendsten agilen Wissen und Fähigkeiten alleine nicht weit.
Deshalb bzw. trotzdem: Wenn Sie alleine einen Schritt gehen möchten, machen Sie sich schlau darüber, was Agilität ist, will, bedeutet.
Die beste Grundsatzlektüre, die ich dazu kenne, ist (ich wiederhole mich, ich weiß): Der Scrum-Guide. Der erklärt Ihnen das Spiel, die Mannschaftsaufstellung und die grundsätzliche Taktiken - um im Bild des Teamsports zu bleiben.
Dann aber sollten Sie schnellstmöglich anfangen, mit Ihren TeamkollegInnen zu beraten, wie Sie sich GEMEINSAM agiler organisieren können. Kommen wir deshalb zu:
Zweitens: Starten Sie, indem Sie gemeinsam regelmäßig eine Retrospektive machen: Mit Ihrem Team (das beinhaltet am besten auch die Team- oder Abteilungsleitung oder sogar das Management!). Ein bis zwei Stunden. Mindestens im Takt von vierzehn Tagen, maximal vier Wochen. Immer und immer wieder. Keine Unterbrechung!
Stellen Sie sich dabei offen und ehrlich die folgenden Fragen:
- Was ist SEIT DER LETZTEN RÜCKSCHAU organisatorisch gut gelaufen? Was weniger?
- Was lernen wir daraus generell? Was lernen wir daraus FÜR DIE NÄCHSTEN WOCHEN?
- Welche machbare Maßnahme fällt uns für die nächsten Wochen ein, die uns ein bisschen besser macht?
Bei der regelmäßigen Retrospektive fällt schnell auf, wie Sie sich als Team verbessern können, was Ihnen noch fehlt und welche methodischen Hilfsmittel Ihnen aus der agilen (oder sonsteiner) Welt helfen können.
Wichtig: Wenn Ihr Team eine gewissen Reife hat - damit ist gemeint, dass die meisten schon erkannt haben, dass es wie bisher nicht weitergehen KANN -, dann sind Sie damit nicht erst auf dem Weg, agiler zu WERDEN. Dann SIND sie es schon.
 |
| Zeichnung vom Autor |
Natürlich können Sie auch MitstreiterInnen finden und dafür trommeln, in einem größeren Schritt gleich einen agilen Arbeitsrahmen wie Scrum oder Kanban einzuführen.
Das hat allerdings jeweils größere Vor- und Nachteile. Einer der Vorteile: Sie beschäftigen sich ALS TEAM relativ schnell und intensiv mit der methodischen Umsetzung der Agilität. Das kann Ihnen u.U. helfen, die Handgriffe schnell zu lernen und schnell auf agil umzusteigen. Dann nämlich, wenn die meisten von Ihnen das als sinnvollen Schritt sehen.
Der Nachteil: Sie haben mit allem Positiven und Negativen zu rechnen, was Sie aus anderen Veränderungsinititativen kennen. Und das sind eben oft nicht nur Jubelschreie, sondern meist auch die (im Grunde vernünftige) generelle Frage: "Was soll denn das jetzt? Haben wir nicht Wichtigeres zu tun?"
Selbst wenn Ihre Antwort generell "Nein." heißt bzw. gerade dann wird die anschließende Diskussion Ihr Ziel verzögern, mittels Agilität schnell Probleme zu lösen.
Warum nicht also einfach damit anfangen - ohne viel Gedöns und am besten so, dass alle davon profitieren? Sollte das nicht klappen, können Sie ja immer noch die größere Change-Initiative ausrufen.
|
| Zeichnung vom Autor |
Weiterlesen?
- Anderson, David J.; Reinertsen, Donald G: Kanban. Successful Evolutionary Change for Your Technology Business.
- Appelo, Jurgen: How to Change the World.
- Laloux, Frederic: Reinventing Organizations. A Guide to Creating Organizations. Inspired by the Next Stage of Human Consciousness.
- Rodehack, Edgar: Die acht Schritte eines Sprintübergangs.
- Sutherland, Jeff: Scrum. The Art of Doing Twice the Work in Half the Time, New York, 2014. (Deutsch: Die Scrum-Revolution)
- Schwaber, Ken; Sutherland, Jeff: Scrum Guide
- Wohland, Gerhard; Wiemeyer, Matthias: Denkwerkzeuge der Höchstleister. Warum dynamikrobuste Unternehmen Marktdruck erzeugen.
Das größte Problem ist oft die mittlere Führungsebene: Wie nehme ich die mit, wenn das Thema "abteilungsübergreifende Teams" angegangen werden soll? Wie und wo fängt man an? Sollte man das Organigramm ändern?
Ja. Beziehungsweis Jein.
Klar ist: Macht sich eine Organisation auf, wirklich agil zu arbeiten, wird das Auswirkungen auf das Organigramm haben. Denn das ist ja genau, was erreicht werden soll. Durch das Arbeiten in interdisziplinären Teams machen wir uns flexibler, schneller, marktnäher. Und auch rentabler.
Das liegt daran, dass die auf mächtige Entscheider(kreise) ausgerichteten gestaffelten Entscheidungskaskaden in den Macht- und Statushierarchien bzw. in den ultra-arbeitsteiligen (silogetriebenen) Organisationen aufwändiger, langsamer und deshalb teuerer sind als die Vorgänge beim agilen Wettbewerber. Der ist einfach kundennäher, schneller und nicht nur günstiger, sondern viel rentabler.
Und dadurch attraktiver für Kunden, Investoren und Mitarbeitende. Unabhängig, wie viel Sinn die Beschleunigung unseres Lebens wirklich macht: Wer hat in unserer Welt der Zehn-Minuten-Lieferdienste noch Verständnis dafür, länger als nötig warten zu müssen? Wir wundern und ärgern uns ja selbst, ja, es macht uns buchstäblich krank, dass wir in unseren endlosen, zähen, langeweiligen und überflüssigen Jour Fixen nichts voranbringen und so lange brauchen, um wichtige Entscheidungen zu fällen. Warum braucht der Projektleiter, das Management, der Lenkungsausschuss nur so lange für Entscheidungen? Wann können wir endlich weitermachen?
Bei all dem vergessen wir allerdings gerne, dass das, was uns heute - zurecht! - als ein entscheidender Wettbewerbsnachteil erscheint, in Zeiten effizienter Kostenführerschaft DER ENTSCHEIDENDE Vorteil war. Die hierarchische Form von Organisation und Entscheidungsfindung hat Firmen also bis vor kurzem SEHR ERFOLGREICH gemacht (und tut es in gewissen Bereichen auch noch heute).
Für diesen Erfolg sorg(t)en zu einem nicht unerheblichen Teil vor allem jene Führungskräfte im mittleren Management, die heute oft und wenig schmeichelhaft als Bremser, ja sogar als Lehmschicht diskreditiert wird.
Sie werden manchmal zurecht, oft aber auch unfairerweise dafür kritisiert, dass Sie ihren Job gewissenhaft erledigen. Auch wenn das heute natürlich immer öfter ein Problem darstellt: Ihre Aufgabe ist, dafür zu sorgen, dass der Betrieb stabil, effizient und auch ohne große Veränderungen läuft. Alles, was das System verändert, haben sie sorgfältig zu prüfen und nur in absolut sicheren Schritten zuzulassen.
Heute brauchen wir jedoch mehr und schnellere Flexibilität. Die Organisation ist umzubauen, jeder hat ein bisschen etwas anderes zu tun. Genau dazu will Agilität beitragen.
 |
| Zeichnung vom Autor |
Für einen agilen Wandel, ist deshalb wichtig, Menschen im mittleren Management wertschätzend gegenüberzutreten und anzuerkennen, welch wichtige Rolle sie bisher gespielt haben und welche Verdienste sie bislang für die Unternehmung gleistet haben.
Und zwar auch dann, wenn das manchmal schwerfällt. Schließlich erledigen ManagerInnen in hierarchisches Command-and-Control-Organisationen auch heute noch oft ihren Job mit sehr rigiden Methoden, die sie oft als wandlungsunfähige Betonköpfe erscheinen lässst.
Zudem fehlt leider auch der persönliche Grund. Denn mittlere ManagerInnen, selbst jene, die die Notwendigkeit des Wandels erkennen, finden sich in einem persönlichen Dilemma wieder: Wenn Managementaufgaben von selbstorganisierten Teams weitestgehend übernommen werden: Wo bleibe ich in diesem Spiel?
Im agilen Wandel haben sie also persönlich und strukturell eine sehr schwierige, vielleicht sogar die schwierigste Position. Sie haben mit am meisten Verantwortung (dafür, dass der Laden weiter läuft). Außerdem haben sie persönlich (mutmaßlich) am meisten zu verlieren, nämlich Einfluss, Geld, Status. Und das alles, ohne dass sie viel dafür können.
Das ist miteinzubeziehen in die Frage, wie "man" das mittlere Management in einem agilen Wandel "mitnehmen kann".
 |
| Zeichnung vom Autor |
Und für einen erfolgreichen organisatorischen Wandel brauchen wir solche Menschen. Gerade die KollegInnen des mittlern Managements! Nicht nur aufgrund ihrer besonderen Erfahrung und Markt- und Fachkenntnisse. Sondern auch, um die agile Idee mit Energie in die Organisation zu tragen und sie dort zu verankern.
Schaffen Sie dazu Runden, Foren und Treffpunkte, wo Management, mittleres Management und Mitarbeitende aus dem Teams die Notwendigkeit für die organisatorischen Umstellungen diskutieren und aushandeln können, wie der konkret aussieht und umgesetzt wird:
Wer macht am besten was, wann und wie? Vor allem auch: Wozu? Wer findet wo ihren/seinen neuen Platz? Wer ist wo am besten eingesetzt - mit ihrem/seinem Wissen, Erfahrung, Motivation?
 |
| Zeichnung vom Autor |
"Take it to the team!" Machen Sie allgemein klar, dass es keine Alternative zum Umbau hin zu einer agileren Organistation gibt. Binden Sie so viele Menschen Ihrer Organisation wie möglich mit ein. Vor allem aber das mittlere Mangement!
Mit anderen Worten: Lassen Sie alle Experten der eigenen Arbeit über ihre eigene (agilere) Struktur entscheiden. Jede Wette: Damit nehmen sie die meisten Menschen in Ihrer Organisation mit. Dadurch schreibt sich das Organigrammn fast von allein.
Weiterlesen?
- Appelo, Jurgen: How to Change the World.
- Appelo, Jurgen: Managing for Happiness. Übungen, Werkzeuge und Praktiken, um jedes Team zu motivieren.
- Balle, Michael u.a.: The Lean Strategy: Using Lean to Create Competitive Advantage, Unleash Innovation, and Deliver Sustainable Growth.
- Byrne, Art: The Lean Turnaround.
- Laloux, Frederic: Reinventing Organizations. A Guide to Creating Organizations. Inspired by the Next Stage of Human Consciousness.
- Ōno, Taiichi: Workplace Management.
- Rosa, Hartmut: Beschleunigung. Die Veränderung der Zeitstrukturen in der Moderne.
- Senge, Peter M.: Die fünfte Disziplin. Kunst und Praxis der lernenden Organisation.
- Simon, Fritz B.: Einführung in die systemische Organisationstheorie.
- Wohland, Gerhard; Wiemeyer, Matthias: Denkwerkzeuge der Höchstleister. Warum dynamikrobuste Unternehmen Marktdruck erzeugen.
Alle Teamworkblog-Posts von Edgar Rodehack.
Edgars eigener Blog: www.trellisterium.de
Edgars Podcast: trellisterium.podbean.com
Edgar Rodehack ist Teamwork-Enthusiast mit einem Faible für agile Formen der Zusammenarbeit. Da trifft es sich natürlich gut, dass er das beruflich macht. Er ist Organisationsberater, Business und Agile Coach, Teamentwickler und Moderator. Außerdem ist er ein Mensch mit Frau und drei Kindern, der viel Spaß am Musikmachen, Schreiben und Lesen hat. Mehr über ihn: www.rodehack.de
Anmerkungen
- /1/ Rodehack, Edgar: Agil arbeiten! Noch Fragen?. Blogpost-Serie auf www.teamworkblog.de vom 29. April 2019
- /2/ Siehe hierzu: Rodehack, Edgar: Gibt es agile Organisationsberatung? Blogpost auf www.teamworkblog.de vom 18.6.2018
Kommentare
Kommentar veröffentlichen