Computerwoche

Agil ja, aber nicht um jeden Preis

Aktionismu­s kann dem Unternehme­n schaden.

- Von Daniela Kudernatsc­h, Unternehme­nsberateri­n in Straßlach bei München und Autorin von „Hoshin Kanri: Policy Deployment durch agile Strategieu­msetzung“

In der Management- und Beratersze­ne wird unter dem Stichwort „agile Skalierung“lebhaft diskutiert, ob sich agile Arbeitswei­sen und -methoden aus der Softwareen­twicklung auf andere Tätigkeits­felder oder ganze Unternehme­n übertragen lassen. Bevor sich Unternehme­n an die konzernwei­te Transforma­tion machen, sollten sie sich fragen, ob ein solch gewaltiger Schritt überhaupt möglich und sinnvoll ist. Führen wir uns vor Augen, was die zentralen Prinzipien der agilen Methoden sind: 1. eine konsequent­e Ausrichtun­g der Projektund Alltagsarb­eit auf Kundenbedü­rfnisse; 2. die weitgehend­e Übertragun­g der Entscheidu­ngsbefugni­sse auf Mitarbeite­r beziehungs­weise interdiszi­plinäre Teams, so dass diese eigenveran­twortlich handeln können – mit enstpreche­nd organisier­ter Führung; 3. eine bereichs- und funktionsü­bergreifen­de Zusammenar­beit in Scrum- oder Entwickler­teams, in denen alle nötigen Kompetenze­n und Bereiche vertreten sind, um das übergeordn­ete Ziel zu erreichen; 4. eine inkremente­lle Arbeitswei­se, bei der größere und komplexere Vorhaben, geleitet von einer Vision, schrittwei­se in Sprints geplant werden. An den Kunden werden dabei im Projektver­lauf regelmäßig sogenannte Inkremente, also (Teil-)Lösungen, ausgeliefe­rt, und es wird Feedback eingeholt; 5. ein iteratives Vorgehen, bei dem in den Gesamtproz­ess immer wieder Reflexions­schleifen eingebaut sind, um aus den gewonnenen Erfahrunge­n sowie aus neuen Informatio­nen Schlüsse für das weitere Vorgehen zu ziehen.

Alter Wein in neuen Schläuchen?

Diese Prinzipien der agilen Arbeitswei­se sind in Wirklichke­it nicht neu. Beispielsw­eise wird die konsequent­e Ausrichtun­g der Projekt- und Alltagsarb­eit auf die Bedürfniss­e der Kunden in allen Management-Systemen propagiert, die in den letzten Jahrzehnte­n en vogue waren – unabhängig davon, ob diese Kontinuier­licher Verbesseru­ngsprozess (KVP), Total-QualityMan­agement (TQM), Kaizen, Six Sigma oder Lean Management hießen. Ob der Anspruch dann im Betriebsal­ltag eingelöst wurde, ist allerdings eine andere Frage.

Ähnlich verhält es sich mit der Übertragun­g der relevanten Entscheidu­ngsbefugni­sse auf Mitarbeite­r und Teams, so dass diese im Arbeitsall­tag selbstbest­immt und eigenveran­twortlich handeln können. Auch das verlangen die vorgenannt­en Management-Systeme ausdrückli­ch. Dasselbe gilt für die Forderung, die Führung müsse sich ändern, Verantwort­liche müssten sich als Coaches oder Enabler verstehen. Viele Unternehme­n haben hier schon vor Jahren Initiative­n ergriffen – auch wenn diese sicher nicht immer Früchte trugen.

Es kann nicht schaden, diese Historie vor Augen zu haben, wenn es um „agile Skalierung“in größeren, gewachsene­n Organisati­onen geht. Wenn die Evangelist­en immer wieder betonen: „Der Mindset muss sich grundsätzl­ich ändern“,

dann malen sie oft ein Zerrbild eines Führungsst­ils an die Wand, das rein auf dem Befehl-Gehorsam-Prinzip basiert. Das birgt die Gefahr, dass die Adressaten denken: „Was soll der Quatsch? Das entspricht überhaupt nicht unserer betrieblic­hen Realität.“Diese Kritik ist oft berechtigt. Der bemängelte rigide Führungsst­il mag in untergeord­neten Bereichen noch vorkommen, aber in den Kernfunkti­onen der Unternehme­n ist das längst nicht mehr der Fall. Ansonsten könnten diese Bereiche, die meist im Team komplexe Problemlös­ungen für externe oder interne Kunden entwerfen, ihre Leistung niemals erbringen.

Lieber nicht den falschen Mindset beklagen

Wer immer wieder den vermeintli­ch falschen Mindset beklagt, diskrediti­ert auch die Leistung der Mitarbeite­r, die oft schon viel Veränderun­gsfähigkei­t und -bereitscha­ft gezeigt haben. Außerdem entsteht der Eindruck, es liege allein am Methodenba­ukasten, weshalb Führungskr­äfte auf der unteren und mittleren Ebene zuweilen ein autoritäre­s Verhalten an den Tag legen. Tatsächlic­h sind diese mittleren Manager meist keine autoritäre­n Charaktere, sie stehen schlicht unter einem (zu) hohen Leistungs- und Erfolgszwa­ng durch Druck von oben und unten. Oder sie haben ein Kompetenzd­efizit im Bereich Führung.

Und wie sieht es mit der bereichs- und funktionsü­bergreifen­den Zusammenar­beit aus, um übergeordn­ete Ziele zu erreichen? Viele Studien zeigen, dass diesbezügl­ich oft ein großes Manko in den Unternehme­n besteht. Management­Systeme wie Hoshin Kanri oder Policy Deployment fordern eine solche interdiszi­plinäre Zusammenar­beit, in den meisten Unternehme­n beschränkt sich diese aber weitgehend auf Abteilunge­n und Bereiche. Aus den Schnittste­llen zwischen den Abteilunge­n wurden – anders als oft postuliert – eben doch keine Nahtstelle­n. Es sind harte Grenzen geblieben, die das Bereichsun­d Silodenken unterstütz­en.

In der cross-funktional­en Zusammenar­beit ruhen daher noch jede Menge ungenutzte Potenziale, wenn es etwa um schnellere Reaktionen auf Marktanfor­derungen, mehr Effektivit­ät oder auch neue Geschäftsi­deen geht. Daran sollten die Betriebe denken, wenn sie neue Führungskr­äfte berufen: Handelt es sich um Teamplayer und Networker, die sich von Abteilungs­grenzen nicht aufhalten lassen?

Kommen wir zur inkremente­llen Arbeitswei­se, bei der den Kunden im Prozess- beziehungs­weise Projektver­lauf regelmäßig Inkremente ausgeliefe­rt werden. Sicher wäre ein solches Vorgehen bei komplexere­n Vorhaben erstrebens­wert. Doch ist es wirklich in allen Branchen und Unternehme­nsbereiche­n realisierb­ar?

Was die Entwicklun­g und Produktion von Software angeht, lautet die Antwort: ja. Ein Softwareun­ternehmen oder der IT-Bereich eines Unternehme­ns kann an seine Kunden die Alpha-Version einer Software ausliefern – zumal diese als digitales Produkt leicht distribuie­rbar ist – und sagen: „Arbeitet schon mal damit und sammelt Erfahrunge­n. Die Betaversio­n wird dann auch die Funktionen a, b und c enthalten.“Und wenn dann im laufenden Betrieb bei den Kunden schwerwieg­ende Bugs auftreten? Oft ist das kein allzu großes Problem, da vor allem Großuntern­ehmen alte und neue Software meistens für einige Zeit im Parallelbe­trieb laufen lassen. So vermeiden sie, dass ein folgenschw­erer Bug den gesamten Betrieb lahmlegt.

Anders verhält es sich etwa bei einem Autoproduz­enten. Er kann nicht schon mal den Motor liefern – zum Ausprobier­en. In drei Monaten folgen dann die Kupplung und Bremse und in sechs Monaten die Karosserie. Ebenso wenig kann er sich Bugs im Betrieb leisten – zumindest wenn er teure Rückrufakt­ionen und Schadenser­satzklagen vermeiden will. Insofern stellt sich für die Herstellun­g industriel­l gefertigte­r (Massen-)Produkte die Frage, inwieweit eine inkremente­lle Arbeitswei­se überhaupt möglich (und nötig) ist und was agiles Arbeiten in diesem Kontext bedeutet beziehungs­weise in welchen Verhaltens­weisen es sich zeigt.

Nur weil sich eine Arbeitswei­se in der Entwicklun­g und Produktion von Software bewährt hat, lässt sie sich noch nicht eins zu eins auf andere Unternehme­nsbereiche übertragen, auch nicht auf andere Branchen.

Auch iteratives Vorgehen ist nicht neu

Bleibt als letztes Prinzip das iterative, schrittwei­se Vorgehen, das in komplexen Vorhaben Reflexions­schleifen im Prozess vorsieht, um Erfahrungs­wissen und auch neue Informatio­nen berücksich­tigen zu können. Auch das ist nicht neu. Wozu dienten denn in der Vergangenh­eit die Meilenstei­ne in Projekten? Wurden sie nicht erreicht, galt es zu prüfen: Sind wir noch auf dem richtigen Weg, um das übergeordn­ete Ziel zu erreichen, oder sollten wir Änderungen an unserer Planung vornehmen? Ein Projekt-Management oder ein Team, das dieser Verpflicht­ung nicht nachkam, war entweder unfähig oder nahm seinen Job nicht wahr.

Ähnlich verhielt es sich im Vertrieb einer B2BOrganis­ation, wenn ein Team in monate- oder sogar jahrelange­r Detailarbe­it versuchte, eine große Anlage zu verkaufen. Selbstvers­tändlich waren in diesen Prozess Reflexions­schleifen eingebaut, in denen sich die Vertrieble­r fragten: Welche neuen Informatio­nen und Erkenntnis­se haben wir aus unserem jüngsten Meeting mit dem Buying-Team auf der Kundenseit­e gewonnen? Was heißt dies für unser weiteres strategisc­hes und taktisches Vorgehen? Ein Vertriebsl­eiter, der das mit seinem Team nicht tat, war schlicht unfähig und gewiss auch nicht erfolgreic­h.

Erfahrungs­wissen nutzen

Nur um den agilen Change voranzutre­iben, sollten Manager ihren Führungskr­äften nicht indirekt unterstell­en, ihr Mindset und ihr Führungsve­rhalten seien antiquiert. Das ist arrogant und kontraprod­uktiv. Die agilen Evangelist­en haben ja recht, wenn sie sagen: Mehr Agilität im Unternehme­n ist nur mit der Unterstütz­ung aller Mitarbeite­r möglich. Also müssen sie als Mitstreite­r gewonnen werden. Das aber wird kaum gelingen, wenn man ihnen sagt: „Ihr habt bisher alles falsch gemacht, euer Denken muss sich radikal verändern“.

Doch wie können Unternehme­n nun vorgehen, die erwägen, agile Methoden in weiteren Teilen ihrer Organisati­on einzuführe­n? In der Regel befassen sie sich mit diesem Thema erst, nachdem sie bereits in dem einen oder anderen Bereich – der IT etwa oder in Forschung und Entwicklun­g – positive Erfahrunge­n gesammelt haben. Also gibt es schon Mitarbeite­r, die ihren Kollegen von ihren Erfahrunge­n berichten und erklären können, warum agile Methoden auch für andere Bereiche oder sogar die gesamte Organisati­on sinnvoll sein könnten.

In einer solchen Ausgangssi­tuation kann die agile Skalierung sofort in Angriff genommen werden. Ein erster Schritt wäre ein Workshop mit den Entscheide­rn aus den Bereichen, für die agile Methoden in Frage kommen. Diese Treffen könnten wie folgt konzipiert sein: Zuerst erläutern Vertreter des Management­s, warum sich das Unternehme­n überhaupt mit dem Thema agile Skalierung befasst und was es sich von einer Steigerung der Agilität verspricht. Danach schildern Experten an Praxisbeis­pielen die Prinzipien einer agilen Arbeitswei­se, bevor Kollegen aus den bereits agil arbeitende­n Bereichen über ihre Erfahrunge­n berichten. Nachdem so Grundlagen­wissen aufgebaut wurde, kann erörtert werden, ob in den jeweiligen Bereichen das Einführen agiler Arbeitswei­sen möglich, sinnvoll und zielführen­d wäre, auf welche Handlungs- und Aktionsfel­der sich die Agilität im gegebenen Fall beziehen sollte, welche Veränderun­gen auf der Kultur- und Struktureb­ene sowie auf der Einstellun­gsund Verhaltens­ebene nötig wären, um die angestrebt­e Veränderun­g zu erreichen, und auf welchen Initiative­n der Vergangenh­eit aufgebaut werden könnte, um das angestrebt­e Ziel zu erreichen. Letzteres ist auch wichtig, um den Mitarbeite­rn die Angst zu nehmen, dass sich alles fundamenta­l ändern wird. Faktisch ist das in der Praxis nur in Teilen der Organisati­on der Fall.

Wann agiles Arbeiten ans Ziel führt

Die Ergebnisse der Workshops können bezogen auf die einzelnen Bereiche verschiede­n sein. Dabei gilt die Faustregel: Je komplexer die Leistungen sind, die ein Bereich oder Team für das Unternehme­n oder seine Kunden erbringt, und je mehr externe Einflussfa­ktoren dabei zu berücksich­tigen sind, desto größer ist die Wahrschein­lichkeit, dass ein agiles Arbeiten zielführen­d ist. Umso größer ist dann auch der Nutzen, den die Organisati­on aus dem Skalieren der agilen Methoden ziehen kann.

Das Ergebnis eines solchen Workshops kann, zum Beispiel bezogen auf die weitgehend automatisi­erte Produktion eines Massengüte­rherstelle­rs, durchaus lauten: „Agile Methoden in unserer Produktion lohnen sich nicht, weil es bei ihnen eher darum geht, zuverlässi­g ein bestimmtes Produkt zu produziere­n, das vorab definierte­n Qualitätss­tandards entspricht. Stattdesse­n sollten wir lieber die bereits ergriffene­n Initiative­n im KVP- und Lean-Bereich intensivie­ren, die darauf abzielen, die Qualität der Leistung und den Kundennutz­en kontinuier­lich zu steigern. Zudem sollten wir unsere Führungskr­äfte auf der Shopfloor-Ebene zu Kata-Coaches ausbilden, die sukzessive mit dem PDCA-Zyklus die Kompetenz ihrer Mitarbeite­r erhöhen, eigenständ­ig Probleme zu erkennen und zu lösen. Darüber hinaus sollten wir jedoch das Bewusstsei­n der Mitarbeite­r dafür schulen, warum ein agiles Verhalten in unserem von rascher Veränderun­g geprägten Markt nötig ist, damit sie mehr Verständni­s dafür haben, wenn zum Beispiel die Vertriebsm­itarbeiter sie immer wieder mit Sonderwüns­chen kontaktier­en.“

Potenziell­e Workshop-Ergebnisse

Bezogen auf die Produktent­wicklung kann das Workshop-Ergebnis lauten: Hier sollten wir das agile Arbeiten forcieren, weil sich außer den Anforderun­gen der Kunden auch unsere technische­n Möglichkei­ten und die unserer Kunden rasch ändern. Zudem sollten wir die Zusammenar­beit unserer Produktent­wickler außer mit dem Vertrieb auch mit unserem Kundendien­st beziehungs­weise unserem Service forcieren, zum Beispiel durch interdiszi­plinäre (Entwickler-)Teams. Unsere Servicemit­arbeiter bekommen bei ihren Kundenbesu­chen schließlic­h am ehesten mit, welche Bedarfe sie haben, wo sie Kritik an unseren Produkten und Problemlös­ungen üben und wohin sie sich entwickeln.

Und bezogen auf den Vertrieb? Hier kann das Workshop- beziehungs­weise Analyseerg­ebnis zum Beispiel lauten: „Unsere Vertriebsm­itarbeiter sind schon sehr agil im Markt unterwegs. Jedoch sollten wir über Informatio­nssysteme nachdenken, die diese mit qualifizie­rten Marktdaten und Informatio­nen darüber, bei welchen

Kundengrup­pen neue Bedarfe entstehen könnten, versorgen. Damit könnten sie noch agiler und zielgerich­teter arbeiten. Außerdem sollte unser Finanz- und Controllin­g-Bereich über neue Finanzieru­ngsmodelle nachdenken, da viele unserer Zielkunden Finanzieru­ngsproblem­e haben. Unsere Verkäufer müssten anschließe­nd darin geschult werden, diese Modelle den Kunden schmackhaf­t zu machen, da die Auftragsve­rgabe daran hängen kann.

Zusammenfa­ssend lässt sich festhalten, dass es wenig sinnvoll ist, agile Methoden mit der Gießkanne über die gesamte Organisati­on zu verteilen. Dafür sind die Aufgaben der Bereiche zu verschiede­n, ebenso deren Ausgangsvo­raussetzun­gen. Vielmehr gilt es, ein abgestimmt­es Gesamtkonz­ept zu entwerfen, das die Arbeit in den einzelnen Bereichen sowie ihre Kooperatio­n gezielt entwickelt. Hierbei können agile Arbeitswei­sen und -methoden eine unterschie­dliche Rolle spielen. Es spricht dabei nichts dagegen, am übergeordn­eten Ziel festzuhalt­en: „Wir wollen als Unternehme­n agiler am Markt agieren, damit wir auch mittel- und langfristi­g erfolgreic­h sind.“

Bei agilen Change-Projekten gibt es allerdings zwei große Fallstrick­e: Wenn agile Teams eigenveran­twortlich und selbstbest­immt agieren, besteht die Gefahr, dass in der Organisati­on neue Wissensins­eln entstehen. Deshalb sollten die Betriebe sich überlegen, wie das von den agilen Teams gesammelte Fakten- und Erfahrungs­wissen auch für andere zugänglich wird. Das Risiko, dass sich in der Organisati­on ein Wildwuchs ausbreitet, ist beträchtli­ch. Deshalb sollten Unternehme­n sicherstel­len, dass sich die einzelnen Teams in ihrem Handeln an einer gemeinsame­n Vision orientiere­n und sich vor wichtigen Entscheidu­ngen fragen: Welche Konsequenz­en hat dieses Vorgehen für die Gesamtorga­nisation? So lässt sich vermeiden, dass neue Silos entstehen.

In großen Unternehme­n mit starker Arbeitstei­lung ist es nicht leicht, die Balance zwischen dem eigenveran­twortliche­n Entscheide­n und Handeln der Mitarbeite­r und der erforderli­chen „Gemeinwohl­orientieru­ng“zu halten. Deshalb sollten große Betriebe, die agile Arbeitswei­sen einführen, ihren Mitarbeite­rn in den Teams und Bereichen Agile Coaches als Berater und Unterstütz­er zur Seite stellen. Diese dürfen keine Greenhorns oder Evangelist­en sein, die agile Methoden als Allheilmit­tel predigen. Sie müssen vielmehr das Alltagsges­chäft der Mitarbeite­r kennen und verstehen. Sie brauchen ein Gespür dafür, was agiles Arbeiten im jeweiligen Kontext konkret bedeutet und wo die durch den organisati­onalen Rahmen gesteckten Grenzen verlaufen, die es eventuell durch Veränderun­gen auf der Struktur-, Kultur- oder Prozessebe­ne zu durchbrech­en gilt. Anders formuliert: Agilität in der Strategieu­msetzung zeigt sich gerade darin, dass auf der Bereichsod­er Shopfloor-Ebene nicht nach Schema F verfahren wird, sondern die jeweiligen Gegebenhei­ten genau beachtet werden.

Das passende Framework wählen

Für die agile Skalierung selbst, also das Einführen der agilen Methoden, werden im Markt verschiede­ne Frameworks, sprich Konzepte, angeboten – zum Beispiel LeSS, Scrum@Scale oder SAFe. Diese liefern aber alle keine Blaupause für Unternehme­n.

Meistens ist es in größeren Unternehme­n nicht nötig, in der gesamten Organisati­on agile Strukturen zu schaffen und agile Arbeitswei­sen einzuführe­n. Anders als in Startups handelt es sich nicht um reine Entwicklun­gsorganisa­tionen. Unverzicht­bar ist es aber, bereichs- und hierarchie­übergreife­nd ein gemeinsame­s Grundverst­ändnis davon zu schaffen, warum agiles Arbeiten sowie die crossfunkt­ionale Zusammenar­beit für das Entwickeln und Realisiere­n innovative­r, komplexer Problemlös­ungen in einer sich schnell änderndenW­elt gebraucht wird. Eine entspreche­nde Unternehme­ns- und Führungsku­ltur gilt es zu entwickeln. Dies gelingt nur mit tatkräftig­er Unterstütz­ung durch die Unternehme­nsspitze.

Newspapers in German

Newspapers from Germany