Durchführung im Betrieb

Mit der Skalierung agilen Arbeitens ‒ also der Ausweitung der agilen Arbeitsweise auf weitere Betriebsbereiche ‒ ist in der Regel die Erwartung verbunden, dass sich die positiven Erfahrungen in den bislang agil arbeitenden Bereichen 1:1 auf weitere Betriebsbereiche übertragen lassen. Leider ist das meistens nicht der Fall, weil die Komplexität und Eigendynamik der Organisation unterschätzt wird. Daher zeigt die Erfahrung: Nehmen Sie den Change-Prozess bei der Skalierung ernst, damit Risiken durch Überforderung vermieden werden!

Die folgenden Handlungsempfehlungen zielen darauf ab, Betriebe für ihren Schritt zum nächsten Level zu sensibilisieren und ihnen Hilfestellungen zu dessen Vorbereitung und Entwicklung zu geben.

Betriebe, die bereits in (Pilot-)Bereichen positive Erfahrungen mit agilem Arbeiten gemacht haben, wollen diese Erfahrungen auf weitere Betriebsbereiche erweitern. Typische Szenarien für eine Ausweitung agilen Arbeitens werden nachfolgend vorgestellt.

Als allgemeine Prinzipien für gesundheitsgerechte Change- Prozesse sind folgende Empfehlungen auch für solche Betriebe interessant, die gerade erst mit dem agilen Arbeiten anfangen wollen (vgl. Workshop "Gesunder Einführungsprozess").

Adressaten einbeziehen!
Diejenigen, die zukünftig agil arbeiten sollen, und die für sie verantwortlichen Führungspersonen müssen frühzeitig über die anstehenden Veränderungen informiert werden. Besser noch: Sie sollen sich aktiv in der Rolle als Vor-Ort-Experten maßgeblich an der Konzeptentwicklung und Umsetzung des Change-Prozesses beteiligen.

Skalierung agilen Arbeitens als tiefgreifenden Change-Prozess angehen!
Zusammenarbeit, Arbeitsmethodik, Führung und Organisationskultur werden sich verändern – und das nicht unbedingt auf die gleiche Weise, wie es bei den Pilotprojekten zum agilen Arbeiten der Fall war. Im Pilotprojekt war "Ausnahmezustand", alle wussten, dass Neuland betreten wird, und es gab gute Chancen auf eine hohe Aufmerksamkeit des Managements. Beim Ausrollen ist das plötzlich anders – der Pionier- oder Heldenmodus wird dysfunktional.

Überforderung vermeiden, Zeit und Ressourcen zum Lernen geben!
Bei allen Beteiligten entsteht durch die Umstellung der Arbeitsweise auf „agil“ Lern- und Entwicklungsbedarf – auf methodischer, fachlicher und psychologischer Ebene. Dieser Entwicklungsbedarf muss ernst genommen werden: Stellen Sie die nötigen Ressourcen bereit! Neben der Mobilisierung von interner und externer Expertise zu Training, Coaching und Teamentwicklung bedeutet das vor allem, den Mitarbeitenden ausreichend Lernzeit zur Verfügung zu stellen, um mit den Veränderungen zurechtzukommen.

Gesundheit und Arbeitszufriedenheit explizit zu einem der Ziele für die Einführung agilen Arbeitens machen!
Agiles Arbeiten kann zu einer gesundheitsförderlichen Arbeitsform werden: Das hohe Maß an Partizipation, Kooperation, Teamarbeit, systematischer Reflexion und Prozessverbesserung („inspect and adapt“) bietet Ressourcen für gesundes Arbeiten. Diese kommen allerdings nur zum Tragen, wenn gleichzeitig gesundheitliche Risiken erkannt und vermieden werden. Anderenfalls besteht die Gefahr der Überforderung durch

• fehlende Erfahrung, Einarbeitung und Qualifizierung für die jeweilige Agil-Rolle,
• Selbstüberschätzung und Festhalten an Best-Case-Annahmen,
• fehlendes Risikomanagement,
• interessierte Selbstgefährdung durch fehlende Abgrenzungskompetenz.

Gesundheit und Arbeitszufriedenheit als Effekte von agilem Arbeiten ergeben sich also nicht von selbst, sondern nur dann, wenn sie als eigener Wert gesehen und berücksichtigt werden.

Weiterführende Informationen zu gesundheitlichen Chancen und Risiken agiler Arbeit finden Sie im Abschnitt "Agiles Arbeiten gesund gestalten".

Konflikte und widersprüchliche Anforderungen als agil-typische Belastungfaktoren wahrnehmen!
Einige Konflikte, die aus nicht-agilen Projekten und Prozessen bereits gut bekannt sind, spitzen sich beim agilen Arbeiten weiter zu: Zum einen werden Ziel- und Ressourcenkonflikte im Spannungsfeld von Kosten-, Termin- und Qualitätszielen durch agiles Arbeiten nicht automatisch ausgeräumt, zum anderen bestehen mögliche Interessensunterschiede zwischen Projekt- und Prozessakteuren weiterhin fort. Solche Konflikte, die ansonsten womöglich unter der Oberfläche bleiben würden, werden durch das agile Arbeiten Tag für Tag (z.B. beim Daily Meeting) spürbar und alle werden damit konfrontiert – auch das gehört zu den Grundprinzipien agilen Arbeitens.

Darüber hinaus stellt das Finden von Lösungswegen zum Umgang mit diesen Widersprüchen und Konflikten eine Aufgabe dar, die sich im Idealfall für alle Beteiligten stellt. Deshalb bedeutet „Gesunder Change“ bei der Einführung und Skalierung von agilem Arbeiten unter anderem die systematische Berücksichtigung von Standards zur Früherkennung und zur konstruktiven, lösungsorientierten Bearbeitung von Konflikten und widersprüchlichen Anforderungen.

Typische Szenarien

Immer wieder ist von Organisationen zu hören, die erfolgreich praktizierte agile Arbeitsweisen und Organisationsformen über weitere Bereiche hinweg „ansteckend“ machen wollen. „Wir wollen das nächste Level erreichen!“, heißt es dann. Fünf Szenarien können hier unterschieden werden:

1. Vom agilen Pilotprojekt zum großflächigen agilen Arbeiten („Ausrollen“)
   Solange Tätigkeit, Aufgabenstruktur und Umfeld der Bereiche, auf die agiles Arbeiten ausgerollt werden soll, dem Pilotbereich gleichen, können Schritte durchgeführt werden, wie sie bereits beschrieben wurden. Komplexer wird es dagegen in den folgenden Szenarien.

2. Übertragung des agilen Arbeitens auf Bereiche und Tätigkeiten, die sich kulturell voneinander unterscheiden
   Die agilen Rollen, die häufig IT-typisch vorgeprägt sind, können nicht ohne weiteres 1:1 auf andere Aufgabenklassen angewandt werden. Hier müssen Antworten auf die Frage gefunden werden, wie die Anpassung dieser IT-typischen agilen Rollen und Artefakte auf weitere Arbeitsbereiche und Leistungsspektren gelingen kann. Drei Teilaspekte verdeutlichen, welche „Übersetzungsarbeit“ es dazu braucht:

   1. Die Logik des iterativen Entwickelns kann nicht direkt von virtualisierten Produkten auf physische Produkte umgesetzt werden: Was würde „lauffähiges Produkt“ (als "Zwischenergebnis" in einem IT-Projekt, z.B. bei der Entwicklung einer Software) beispielsweise bei der Entwicklung eines elektromechanischen Produkts oder der Entwicklung einer Dienstleistung bedeuten?
   2. Welche eigene Arbeits- und Qualitätskultur ist im Nicht-IT-Bereich zu berücksichtigen?
   3. Wie passen die agilen Rituale und Artefakte zu den im IT-fernen Arbeitsbereich gewachsenen Interaktions- und Kommunikationsformen?

3. Vom agilen Arbeiten in Projekten zum agilen Arbeiten in Prozessen
   Agiles Arbeiten als „Methodologie“ eignet sich insbesondere für Aufgaben, die ein hohes Maß an Volatilität und Offenheit (in Bezug auf Anforderungen, erforderliche Arbeitsweisen, Teilaufgaben etc.) mit sich bringen. Das sind häufiger Charakteristika von Projekten als von Prozessen. Prozesse zeichnen sich im Gegensatz zu Projekten dadurch aus, dass sie wiederholbare Vorgänge mit festem Ablauf beschreiben. Im Gegensatz zu Projekten können Prozesse zwar kompliziert sein, sie sind in der Regel aber weniger komplex. Die Anforderungen bei der Durchführung von Prozessen sind meistens stabiler und die Aufgaben stärker vorhersehbar.

   Beispielsweise ist die Lohnbuchhaltung ein Prozess mit wiederkehrenden, gleichartigen Aufgaben: Hier können agile Methodologien ihre Stärke nicht ausspielen, weil in der Regel keine neuartigen und herausfordernden Aufgaben vorkommen und die Anforderungen der (internen) Kundinnen und Kunden sowie Stakeholder in der Regel gleich bleiben. Anders sieht das beispielsweise bei einem Projekt wie der Umstellung des Vergütungssystems auf leistungsabhängige Vergütung aus. Ein solches Projekt ist prinzipiell ergebnisoffen und abhängig von vielen Stakeholdern im Betrieb (Personalwesen, Interessenvertretung, Top- Management, Rechnungswesen etc). Hier sind viele Aspekte der Entwicklungsaufgabe offen und variabel, weshalb eine agile Vorgehensweise durchaus sinnvoll sein könnte.

   Insgesamt ist daher zu klären, ob und wie agiles Arbeiten bei Routineaufgaben funktionieren soll und welchen Nutzen es bringt. Wahrscheinlich ist das Einführen einzelner Elemente agilen Arbeitens (z.B. regelmäßige Meetings) gewinnbringender als eine Komplettübernahme agiler Rollen, Rituale und Artefakte, die über das eigentliche Ziel hinausschießen würde.

4. Vom agilen Arbeiten in Projekten und in Geschäftsprozessen zum agilen Arbeiten im Gesamtunternehmen („agile Organisation“)
   Einen Schritt weiter gehen Ansätze, die aus dem ursprünglich auf Tätigkeiten und Aufgaben bezogenen agilen Arbeiten ein agiles Organisationsmodell ableiten wollen. Hier stehen Betriebe vor einer beachtlichen Herausforderung: Agile Werte und Prinzipien wurden in einem eng abgegrenzten, auf Entwicklungs-Teams bezogenen kulturellen Umfeld entwickelt. Die Übertragung dieser Werte und Prinzipien auf eine gesamte Organisation ist keineswegs trivial, sondern bedarf einer guten Vorbereitung und Begleitung.

5. Die „Total Transformation“, in der komplette Bereiche und Prozesse auf einen Schlag umorganisiert werden
   Schließlich gibt es die Ansätze und Real-Experimente, in denen komplette Organisationen auf agiles Arbeiten umstellen. Dies birgt ganz besondere Herausforderungen. Neben der Übertragung von Projekten auf Prozesse (vgl. Punkt 3) sind alle Mitarbeitenden, Führungskräfte und die Unternehmensleitung gefordert, sich mit ihren neuen Aufgaben, neuen Methoden und ihrer neuen Rolle auseinanderzusetzen. Gelingt dies nicht umfassend, kann das dazu führen, dass die neuen agilen Strukturen nur teilweise umgesetzt und die herkömmlichen hierarchischen Strukturen parallel weitergelebt werden. Konflikte, die sich aus der Koexistenz von agilen und nicht-agilen Betriebsbereichen ergeben, sind typische Risiken bei groß angelegten Veränderungsprojekten, die zur Rollenüberforderung bei den Beschäftigten führen können.

   Wenn eine derartig umfassende Reorganisation abgeschlossen ist, liegen darin jedoch auch Chancen: Bei vielen agil arbeitenden Teams wird als Belastungsquelle das fehlende Mindset in den höheren Hierarchieebenen und die Widersprüchlichkeit unterschiedlicher parallel existierender Steuerungslogiken genannt. Bei der totalen agilen Transformation, die von allen Teilen des Managements getragen wird, sollte diese Belastung nicht bzw. weniger stark ausgeprägt sein.

Fallstricke und Erfolgsfaktoren

Neben den dargestellten Szenarien können bei der Weiterentwicklung bzw. Ausweitung des agilen Arbeitens – so wie bei allen Themen, die mit organisationalen Veränderungsprozessen einhergehen – typische (Schein-)Argumentationen auftreten, mit denen anstehende Veränderungen abgeblockt werden sollen. Im Folgenden soll für diese Fallstricke sensibilisiert werden, damit durch vorbeugendes Handeln gegengesteuert werden kann. Die Sichtweisen derjenigen Interessensgruppen, die den Status quo beibehalten möchten, sollten aufgegriffen werden, damit sich niemand übergangen fühlt.

Top-down-Entscheidungen laden zur Passivität ein
Top-down-Entscheidungen zur Einführung bzw. Ausweitung agilen Arbeitens auf weitere Betriebsbereiche bergen das Risiko, dass sie nicht sensibel sind für die jeweilige Ausgangslage in den zu transformierenden Teams/Bereichen. Darüber hinaus werden dabei die Erfahrungen der Beschäftigten bei den anstehenden Veränderungen nicht einbezogen. Ein solches Vorgehen führt dazu, dass die Bereitschaft, sich mit der Transformation zu identifizieren, schwindet. Weder die gesundheitsförderlichen noch die effektivitätsbezogenen Effekte agilen Arbeitens kommen so zum Tragen.

„Not invented here!“
Allein die Tatsache, dass eine neue Arbeitsweise von außen an ein (noch) nicht agil arbeitendes Team herangetragen wird, lässt die Attraktivität der anstehenden Veränderung schwinden. Eigenentwicklungen werden in der Regel bevorzugt. Die Mitglieder des zu transformierenden Teams sollten partizipativ an der Einführung agilen Arbeitens in ihrem Bereich beteiligt werden, damit das Ergebnis ihr „eigenes“ wird („sense of ownership“).

AGABU
Eine Killerphrase gegenüber jeglicher Form ideengetriebener Veränderung lautet: „Ist doch alles ganz anders bei uns!“, kurz: AGABU. Unterschiede zwischen den Pilotbereichen des agilen Arbeitens und dem eigenen Bereich, der transformiert werden soll, werden überbetont und Ähnlichkeiten unter den Tisch fallen gelassen, damit alles so bleiben kann, wie es ist. Hintergrund dieser Phrase ist eine tatsächliche Gefahr, Standards ein für alle Mal festschreiben zu wollen.

One size fits all
Hierbei handelt es sich um das Gegenteil zur AGABU-Phrase. Werden Standards im agilen Arbeiten derart starr interpretiert, dass niemand aus dem zu transformierenden Team sich vorstellen kann, wie „das, was die dort im Pilotbereich gemacht haben, hier bei uns gehen soll“, ist die Einführung agilen Arbeitens tatsächlich in Gefahr. Als Beispiel kann das gängige Missverständnis dienen, Scrum sei eine festgeschriebene Handlungsanweisung, bei der die immer gleichen Methoden (z.B. bei der Bearbeitung einer Retrospektive) eingesetzt werden müssen. Dabei wird übersehen, dass Standards im agilen Arbeiten bewusst offen und „stabil-flexibel“ formuliert sind, damit die jeweils passenden Methoden auf die Situation im Betrieb/im Team hin ausgewählt bzw. zugeschnitten werden können.

Paradoxerweise führt das starre Festhalten an Standards häufig zum Aufweichen ebendieser. Beispielsweise wenn das Sprint-Ziel für unveränderlich erklärt wird, wenn hinzutretende Aufgaben die Personalkapazität „auffressen“, dann werden über kurz oder lang Ergebnisse vorgetäuscht, und die Zusatzaufgaben werden mit halber Kraft bearbeitet. Oder aber, wenn agile Rituale sinnentleert durchgeführt werden, während de facto nicht-agile Verhaltensmuster die Arbeit bestimmen, beispielsweise wenn Teamentscheidungen nicht durch das Team sondern durch die Führungskraft getroffen werden.