Hybride Agilität in Großunternehmen |
Von der Notwendigkeit des Entlernens
| Zeitschrift | Industrie 4.0 Management |
| Ausgabe | 35. Jahrgang, 2019, Ausgabe 2, Seite 27-30 |
| Open Access | https://doi.org/10.30844/I40M_19-2_S27-30 |
| Literatur | Teilen | Zitieren | Download |
Abstract
Keywords
Artikel
Der Wunsch nach effektiven sowie flexiblen Strukturen in Organisationen ist alt. Bereits Alvin W. Gouldner wusste in den 1950er Jahren, dass das Verhältnis von Regeln und Akteuren die Funktionalität von Strukturen bestimmten. Für ihn waren Strukturen dann besonders befähigend, wenn organisationale Regeln sowohl von Managern als auch von den Mitarbeitern gleichermaßen akzeptiert und befolgt werden. Folgerichtig nannte Gouldner diesen Typus representative bureaucracy. Daneben kannte er aber auch den Typus der punishment-centered bureaucracy, die auf der legitimen Autorität Vorgesetzter beruht, Sanktionen gegenüber Mitarbeitern auszuüben, wenn sie die autoritär gesetzten Regeln nicht einhalten.
Viele Großunternehmen leiden aber unter dem, was Gouldner als mock bureaucracy bezeichnete. In einer mock bureaucracy werden bestimmte Regeln durchgängig ignoriert. Als Beispiel nannte Gouldner seinerzeit die Anti-Raucher-Gesetze in den USA, die in vielen Firmen sowohl von Managern als auch von Mitarbeitern nicht befolgt wurden [1-3].
Warum agiles Arbeiten in großen Unternehmen?
Viele Großunternehmen haben im Bereich der Technischen Entwicklung stark ausdifferenzierte Produktentstehungsprozesse. Freilich erfordern die komplexen Anforderungen in der industriellen Entwicklung ein hohes Maß an Qualitätssicherung. Diese in Teilen von außen angetragenen Anforderungen ziehen schwer veränderbare Strukturen nach sich.
In den bis zu fünf Jahre dauernden Entwicklungsplänen werden Meilensteine integriert, deren Erreichen jeweils mit einer detaillierten Dokumentation verbunden ist. Manche dieser Regeln sind indessen so feingliedrig und bedürfen eines solchen hohen Verwaltungsaufwands, dass Mitarbeiter Gefahr laufen, mehr Zeit für die Dokumentation als die eigentliche Entwicklungsarbeit aufzubringen. Folglich stehen Mitglieder solcher Organisationen vor der Entscheidung, sich entweder regelkonform zu verhalten oder die Regeln bewusst zu ignorieren. Entscheiden sie sich für Ersteres, ist das häufig eine Entscheidung gegen das zu entwickelnde Produkt, da wichtige Zeit für die Entwicklung nicht mehr aufgebracht werden kann.
Viele der Mitarbeiter von Entwicklungsabteilungen entscheiden sich eher für den zweiten Weg, d. h., sie stellen eigene, informelle Regeln auf, welche die Entwicklungsarbeit unterstützen, anstatt sie zu behindern. Treten durch die strikte Einhaltung der Produktentstehungsprozesse Verzögerungen in der eigentlichen Entwicklungsarbeit auf, werden häufig sog. Task-Forces ins Leben gerufen. In ihnen sollen Mitarbeiter konzentriert in kürzester Zeit diese Entwicklungsarbeit nachholen – besonders wenn der nächste Meilenstein kommt. Task-Forces zeichnen sich dadurch aus, dass Regeln von ihren Mitgliedern selbst organisiert und bestehende Hierarchien zugunsten einer schnellen Entwicklungsarbeit aufgehoben werden [3].
Funktionierte dieses informelle Vorgehen bisher, um Meilensteine von Produktentstehungsprozessen zu erreichen, treibt ein volatileres Marktumfeld größere Unternehmen dazu, grundsätzlich die Organisation ihrer Entwicklungsabteilungen zu überdenken. Denn: Neben den genannten Vorteilen sind die Task-Forces häufig hektisch und wenig nachhaltig, da nach der Überwindung des Problems die Task-Force-Einsätze beendet werden und ihre Mitglieder wieder in den alten Arbeitsmodus zurückkehren müssen. Daher ist es der Wunsch vieler Großunternehmen, eine Organisationsform zu finden, die die vorteilhaften Aspekte der Task-Forces (wenig Hierarchien, schnelles und unbürokratisches Handeln) durchgängig und nicht nur in Krisensituationen gewährleistet.
Dabei stoßen einige der DAX-Unternehmen auf das Konzept der Agilität, das aus der IT-Szene stammt und bisher eher in kleinen Start-ups bzw. jungen Unternehmen der Gründerszene zu finden war [4]. Agilität ist ein breit besetzter Begriff, der auch als „Buzzword“ oder „flottierender Signifikant“ bezeichnet wird. Demnach finden ständig Deutungskämpfe statt, was unter diesem Begriff zu verstehen ist [5, 6]. Dieser Beitrag behandelt die agile Methode Scrum, da sie im untersuchten Fall implementiert wurde.
Hybride Formen agilen Arbeitens oder: Konfektion oder Maßschneiderei?
Hat sich ein großes Unternehmen entschieden, agile Projekte in seinem Unternehmen einzuführen, stellen sich Manager und Mitarbeiter häufig die Frage, wie im eigenen Entwicklungsbereich eigentlich agile Methoden umgesetzt werden sollen. Ursprünglich wurde das Grundkonzept, das Agile Manifest (2001), für die IT-Branche aufgestellt. Die dort universell formulierten Werte wie „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“, „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“ oder „Reagieren auf Veränderung mehr als das Befolgen eines Plans“ zu schätzen [9], scheinen im ersten Moment auch auf die Entwicklung von klassischen Produkten zu passen.
Kommt es zur Implementierung agiler Methoden (bspw. Scrum, Kanban oder Design-Thinking [7]), gibt es zwei Philosophien der Umsetzung, die als Konfektionsschneiderei und Maßschneiderei bezeichnet werden können. Bei der Konfektionsschneiderei sollen die Projektmitglieder sich so eng wie möglich an den in Praxishandbüchern beschriebenen Regeln orientieren. Bei diesem Ansatz wird davon ausgegangen, dass sowohl die Rollen in einer agilen Methode wie Scrum (Scrum-Master, Product-Owner und Entwicklungsteams), als auch die ausdifferenzierte Meeting-Landschaft (Daily, DailyPlus, Plannings, Reviews und Retroperspektiven) so konzipiert sind, dass sie eine universelle Wirkung in der menschlichen Zusammenarbeit haben – unabhängig von bereits vorhandenen Strukturen oder dem zu entwickelnden Produkt.
Die Regeln, die Rollen, Meetings und Teams determinieren, scheinen universell anwendbar, da sie auf den allgemein formulierten Werten des Agilen Manifests beruhen. Der Ansatz der Konfektionsschneiderei findet sich (noch) bei vielen Beratungen zur Einführung agiler Methoden bzw. in deren Beratungshandbüchern [9]. Häufig wird dort von einer „agilen Zielorganisation“ [9] gesprochen, die schließlich exakt den vorgegebenen Elementen agiler Methoden entsprechen muss.
Daneben finden sich hybride Ansätze, die hier Maßschneiderei genannt werden sollen. Anstatt darauf zu drängen, eine Methode exakt nach Vorgabe von Praxishandbüchern umzusetzen, werden bei der Implementierung der Methode in bestehende Organisationseinheiten Abweichungen als selbstverständlich, wenn nicht sogar notwendig gesehen. Die Methode muss sich dem Charakter des Unternehmens, also den bestehenden Strukturen und dem zu entwickelnden Produkt, anpassen können. Die Entwicklung eines Flugzeugs unterscheidet sich dieser Auffassung nach wesentlich von der Entwicklung einer Software. Dieser Umstand sollte sich auch bei der Einführung agiler Methoden wiederfinden. Kurz: Es bedarf hybrider Agilität.
Da agile Methoden auf dem Konzept der simple rules beruhen, gibt es Freiräume, die durch die Mitarbeiter gefüllt werden können. So werden bspw. in den Planning-Meetings die Ziele für die jeweiligen (Arbeits-)Sprints (meist mehrwöchige Takte) vom Product-Owner vorgegeben. Wie die Sprintziele erreicht werden, können die Entwicklungsteams jedoch selbst organisieren. Ebenso steht den Entwicklungsteams frei, ihre Teamstruktur selbst aufzustellen. In diesen Freiräumen findet häufig ein Adaptionsprozess statt, bei dem Mitarbeiter eigene Regeln entwerfen, die sie selbst befähigen, effektiv zu arbeiten. Durch ihren informellen Charakter sind diese selbstentworfenen Regelwerke flexibler und können sich daher auch Veränderungen in der Entwicklungsarbeit schneller annehmen [11, 12].
Ein DAX-Unternehmen als Case
In einem zweijährigen Forschungsprojekt in einem DAX-Unternehmen wurde die Implementierung agiler Projekte im Bereich der Technischen Entwicklung untersucht. Die Technische Entwicklung dieses DAX-Unternehmens ist an sich sehr stark reguliert. Zwar wurde die Entwicklung schon vor Einführung der agilen Methode in einzelnen Projekten abgewickelt, die Strukturen dieser herkömmlichen Projekte waren jedoch – gleichsam wie die Linienorganisation des DAX-Unternehmens – stark hierarchisiert und unterlagen ausdifferenzierten Produktentstehungsprozessen.
Entscheidungen über kleinste Entwicklungsschritte mussten über mehrere Hierarchieebenen aus dem Projekt in die Linie getragen werden, was zeitraubend war und häufig zu Kommunikationsverlusten führte. Die Leitung dieser Technischen Entwicklung beschloss angesichts solcher Pro-bleme, agile Pilotprojekte zu starten. Bei einem dieser Projekte wurde die Methode Scrum eingeführt. Die 120 Projektmitglieder sollten es schaffen, innerhalb von 18 Monaten ein innovatives Produkt zu entwickeln – also in nicht einmal der Hälfte der dafür üblicherweise vorgesehenen Zeit.
Scrum wurde von der Leitung der Technischen Entwicklung und der Leitung Personal und Weiterbildung nach Vorbild eines Praktikerhandbuchs aufgesetzt; die Leitungen folgten damit bewusst dem Konzept der Konfektionsschneiderei. Als Rollen wurden Product-Owner (PO) und Scrum-Master (SM) geschaffen. Beide Projektverantwortlichen führten zudem eine differenzierte Meeting-Landschaft nach Scrum ein. Dazu gehörten: Daily Meetings in den einzelnen Entwicklungsteams, DailyPlus-Meetings (für die PO und SM sowie Abgeordneten aus den Teams), Plannings (zur Festlegung der Ziele) am Anfang und Reviews (zur Feststellung der Ergebnisse) am Ende eines Sprints sowie regelmäßige Retroperspektiven. Die elf Entwicklungsteams entstanden dagegen durch Selbstorganisation der Projektmitglieder. Ferner gab es auch Regelrunden, die der konventionellen Entwicklungsarbeit entstammten und trotz Anwendung der Scrum-Methode abgehalten wurden.
Entlernen als notwendige Kompetenz zur Einführung hybrider Agilitätsmethoden in großen Unternehmen
Was passierte bei der Umsetzung der neuen Scrum-Methode? Es fanden auffällige Lern- und Entlernprozesse statt, die schließlich eine maßgeschneiderte hybride Scrum-Methode ermöglichten – obwohl die ursprüngliche Intention der Projektleiter vorsah, Scrum exakt nach dem Praktikerhandbuch einer Beratungsfirma umszusetzen. Während Lernprozesse in Organisationen sowohl für Praktiker als auch für Wissenschaftler bekannte Phänomene sind, blieben Entlernprozesse im agilen Arbeiten bisher noch weitgehend unbeleuchtet [11-16].
Wurden Entlernprozesse einst noch als einfacher Teilschritt des Lernprozesses in Organisationen verstanden, so veränderte sich vor einigen Jahren der Blick: Entlernen wird u. a. als isolierter Vorgang bewussten Vergessens begriffen [15]. Dieses neue Verständnis ist hilfreich, um auch die Prozesse der organisatorischen Maßschneiderei zu verstehen; bspw. wenn agile Methoden in bestehende Strukturen eingesetzt werden. In dem untersuchten Fall wurden folgende wichtige Entlernprozesse beobachtet:
In Selbstorganisation haben die Projektteilnehmer einige der Scrum-Regeln verdrängt oder variiert. Besonders stark wurde die Meeting-Landschaft durch die Mitarbeiter umgestaltet. Wurden Daily Meetings zu Beginn, wie vorgegeben, noch täglich begangen, so halbierte sich diese Regelmäßigkeit bereits nach einem halben Jahr der Projektlaufzeit. Am Ende des Projekts wurden nur noch dienstags und mittwochs verbindliche Daily Meetings abgehalten. Die Entscheidung, die Anzahl der Daily Meetings zu reduzieren, trafen die Projektmitarbeiter selbst.
Die Funktionalität der Daily Meetings, die Teammitarbeiter über den aktuellen Stand der einzelnen Entwicklungsprozesse zu informieren, wurde durch Verringerung dieser Regelrunden nicht eingeschränkt. Die Mitarbeiter schufen sich jene Dichte an morgendlichen Meetings, die für sie passend war. Ein starres Beibehalten der Methode, wie sie aus der Praxisliteratur bekannt war, hätten die Projektmitglieder nach eigener Aussage als Belastung empfunden.
Ein Hauptargument war, dass in einem technischen Entwicklungsumfeld nicht genügend Veränderungen erfolgen würden, um das Daily Meeting täglich mit neuen Informationen zu füllen. Neben der Veränderung der vorgegebenen Meetings kam es zu einer Wiederbelebung bekannter Regeln aus dem konventionellen Arbeiten. Da die Daily Meetings nur für den Informationsaustausch, aber nicht für die Lösung der angesprochenen Probleme zugeschnitten waren, bedienten die Projektmitglieder sich aus dem bekannten Repertoire konventioneller Regeln.
So wurden Regelrunden wie die sog. „Dringlichkeitsblattrunden“ in das agile Projekt seitens der Mitarbeiter wiedereingeführt. In den „Dringlichkeitsblattrunden“ wurden die aktuellen Entwicklungsschritte der einzelnen Teams mit Ampelfarben gekennzeichnet. Entwicklungsschritte, bei denen massive Probleme auftreten, wurden folglich mit Rot gekennzeichnet; unproblematische Entwicklungseinheiten mit Grün und die mit leichten Problemen mit Gelb.
Neben der Variation von Meetings gab es auch die Veränderung von Rollen, so bspw. die des Teamabgeordneten. Zu Beginn des agilen Projekts wurde den Teams vom Scrum-Master aufgetragen, sog. Teamabgeordnete in die DailyPlus-Meetings zu senden, in denen der Product-Owner und der Scrum-Master saßen, um sich regelmäßig mehrmals die Woche über den Stand des Gesamtprojekts zu informieren. Die einzelnen Teams sollten Teamabgeordnete stellen, um den Stand der eigenen Teamarbeit in diesem Meeting mitzuteilen und Probleme rechtzeitig zu adressieren. Ursprünglich war es seitens des Scrum-Master vorgesehen, dass die Teammitglieder in dieser Rolle rotierten, d. h. jedes Teammitglied sollte für eine bestimmte Zeit regelmäßig Teamabgeordneter im DailyPlus-Meeting sein.
Bereits nach kurzer Projektlaufzeit zeigte sich jedoch, dass das Rotationsprinzip von den Teams nicht angenommen wurde. Die Rolle des Teamabgeordneten nahmen stets dieselben Personen ein. Dieser ging nicht nur in die DailyPlus-Meetings, sondern übernahm auch Mini-Management-Aufgaben im eigenen Team: So wurde aus dem Teamabgeordneten ein Teamsprecher. Die Teamsprecher-Rolle glich in vielen der Aufgaben dem Gruppenleiter in konventionellen Entwicklungsprojekten.
Zusammengefasst fanden Entlernprozesse in diesem Fall als bewusste kollektive Entscheidungen statt. Die Projektteilnehmer haben bestimmte agile Regeln, die von den Projektleitern auferlegt wurden, im Konsens beseitigt. Selbstorganisation ist demnach nicht nur ein Verfahren, um Regeln zu schaffen, sondern auch um unpassende Regeln zu eliminieren. Erst durch dieses – selbstorganisierte – bewusste Vergessen wurde die Maßschneiderei einer hybriden agilen Scrum-Methode ermöglicht; obwohl eigentlich eine Anwendung der Methode Scrum im Sinne der Konfektionsschneiderei von der Projektleitung vorgesehen war.
Agile Projekte als Filter guter Regeln
Wie sich in dieser Fallstudie zeigt, betreffen Entlernprozesse die im Rahmen der Scrum-Methode neu eingeführten Regeln. So paradox es klingt: Für die maßgeschneiderte Anpassung von agilen Methoden in Großunternehmen müssen nicht alte Regeln aus dem traditionellen Arbeiten, sondern erst neu gelernte Regeln einer agilen Methode entlernt werden (können). Die entlernten Regeln wurden nicht schlicht vergessen, sondern bewusst durch andere Regeln ersetzt, die dem konventionellen Arbeiten entstammten. Unter diesen Umständen konnte das Produkt tatsächlich innerhalb von 18 Monaten entwickelt werden.
Doch wo verläuft die Entscheidungslinie, welche der bekannten Regeln aus dem konventionellen Arbeiten von den Projektmitarbeitern wiederbelebt werden und welche nicht? Die Antwort scheint simpel, aber überzeugend: Es sind eben die Regeln, die bereits im traditionellen Arbeiten als hilfreich empfunden wurden. Diese Erkenntnis scheint die These zu stützen, dass technisches Entwickeln in Großunternehmen auf bestimmte funktionale Regeln angewiesen ist (bspw. aufgrund von Qualitätssicherung) ist und diese Regeln nicht vollständig durch neue Regeln einer agilen Methode ersetzt werden können.
Damit fungieren agile Projekte als Filter guter Regeln, wenn Projektmitgliedern der nötige Raum für Selbstorganisation gewährt wird. Ist das nun ein Rückfall in das konventionelle Projektmanagement und damit ein Scheitern des agilen Arbeitens? Nein, es ist eher eine dritte, hybride Form, die sich in diesem Projekt herausgebildet hat. Denn: Die Vorstellung, dass bekannte Regeln (Meetings, Rollen) völlig identisch kopiert werden, führt an dieser Stelle in die Irre.
Vielmehr finden beim Kopieren einiger konventionellen Regeln Veränderungen statt, die auf den ersten Blick marginal aussehen, aber schließlich den besonderen Effekt der „Maßschneiderei“ bei der Einführung agiler Arbeitsmethoden ausmachen: Eine representative bureaucracy im Sinne Gouldners könnte auf diesem Wege Realität werden. Schlüsselwörter: Agilität, Scrum, Selbstorganisation, Technische Entwicklungsarbeit, DAX-Unternehmen
Literatur
[1] Gouldner, A. W.: Patterns of Industrial Bureaucracy. New York 1954.[2] Burawoy, M.: The Written and Repressed in Gouldner’s Industrial Sociology. In: Theory and Society, 11 (1982) 6, S. 831-851.
[3] Adler, P. S.; Borys, B.: Two Types of Bureaucracy: Enabling and Coercive. In: Administrative Science Quarterly 41 (1996) 1, S. 61-69.
[4] Conforto, E. C.: Can Agile Project Management Be Adopted by Industries Other than Software Development?. In: Project Management Journal (2014) June/July, S. 21-34.
[5] Frost, J.: Immer noch – Prozessmanagement als Kernkompetenz. In: Sulzberger, M.; Zaugg, R.J. (Hrsg.): Management Wissen. Wiesbaden 2018.
[6] Ortmann, G.: Flottierende Signifikanten: Über Wörter wie lean, smart und agile. In: Organisationsentwicklung 2 (2017), S. 128.
[7] Brandes, U.; Gemmer, P.; Koschek, H.; Schültken, L.: Management Y. Agile, Scrum, Design Thinking & Co.: So gelingt der Wandel zur attraktiven und zukunftsfähigen Organisation. Frankfurt/New York 2014.
[8] Davis, J.: Optimal Structure, Market Dynamics, and the Strategy of Simple Rules. In: Administrative Science Quarterly 54 (2009), S. 413-452.
[9] Foegen, M. et al.: Der ultimative Scrum Guide 2.0. Hannover 2017.
[10] Beck, K.: Manifest für agile Softwareentwicklung. URL: http://agilemanifesto.org/ iso/de/manifesto.html, Abrufdatum 16.10.2018.
[11] Ktata, O.; Lévesque, G.: Agile Development: Issues and Avenues Requiring a Substantial Enhancement of the Business Perspective in Large Projects. In: ACM International Conference Proceeding Series, 2009, S. 59-66.
[12] Bass, J. M.: How Product Owner Teams Scale Agile Methods to Large Distributed Enterprises. In: Empirical Software Engineering 20 (2015), S. 1437-1464.
[13] Martin de Holan, P.: Managing Organizational Forgetting. In: MIT Sloan Management Inquiry 45 (2004) 2, S. 45-51.
[14] Martin de Holan, P.: Agency in Voluntary Organizational Forgetting. In: Journal of Management Inquiry 20 (2011) 3, S. 317-322.
[15] Tsang. E. W. K.; Zahra, S. A.: Organizational Unlearning. In: Human Relations 61 (2008) 10, S. 1435-1462.
[16] Starbuck, W. H.: Organizational Learning and Unlearning. In: The Learning Organization 24 (2017) 1, S. 30-38.
Ihre Downloads
Das könnte Sie auch interessieren
