Ihre Chefs möchten, dass Sie agil arbeiten, und zwar dalli? Sie selbst haben schon so viel Gutes gehört und wollen jetzt auch mal ran? Zuvor aber haben Sie noch ein paar Fragen? Sie sind nicht allein. Zum Beispiel bin ich kürzlich gefragt worden:
Agilität bedeutet (scheinbar) oft das Aufbrechen von starrer Chronologie in Projekten/Abläufen. Wie vermeidet man „Staus“ an bestimmten Stellen, wenn Person B doch darauf angewiesen ist, dass Personen A und C erst ihren Teil erledigen?
Gegenfrage
Wie vermeiden wir denn in hierarchischen Organisationen Abhängigkeiten und Staus? Eben. Meistens gar nicht. Oder – schlimmer noch – indem ein komplexes, abhängiges Stau-Problem noch komplexer und abhängiger gemacht wird – z.B. durch gestaffelte Abstimmungsrunden.
Da scheint mir die agile Herangehensweise doch zielgerichteter. Zumindest in den meisten Fällen. Vor allem deshalb, weil Agilität ABBAU VON ABHÄNGIGKEITEN als eine der WICHTIGSTEN TEAMAUFGABEN definiert, um die wir uns ALLE (!!!) zu kümmern haben. Während wir in den Command-and-control-Organisationen darauf vertrauen oder hoffen, dass sich „das Management“ oder zumindest irgendwer darum kümmert, z.B. ein schlauer Projektleiter, die Abteilungsleiterrunde oder ein gut durchdachter Projektplan oder so….
Aufbrechen? Nö.
„Aufbrechen“ ist ein hässliches Wort, das mir persönlich nicht gefällt und sogar Angst macht. Und es deutet darauf hin, dass wir die GANZ große Veränderung anstreben – aber mal so richtig grundsätzlich und gründlich! Und tatsächlich geht es ja auch darum, die Abläufe im Großen und Ganzen in den Blick zu nehmen und zu verbessern. Auf dass die Arbeit möglichst gut fließen möge!
Aber eben nicht mit einer einmaligen großen Hauruckaktion, sondern indem wir immer wieder, also permanent die auftauchenden Abhängigkeiten sichtbar machen (sie kommen immer wieder!) und so eben Staus vermeiden. Schritt für Schritt und dauerhaft.
Eine einmalige Aktion bringt erfahrungsgemäß meist wenig. Wir riskieren damit eher den großen Bruch. Im Zweifel geht mehr kaputt als dass es hilft.
Also überstürzen wir nichts
Sondern versuchen erst einmal überhaupt zu verstehen und sichtbar zu machen, was DIE EIGENTLICHEN Probleme sind und die WIRKLICHEN Ursachen für den stockenden Arbeitsfluss.
Die liegen meist nicht (alleine) in einem spezifischen Bereich, sondern an mehreren (!) anderen Stellen im Ablauf. Überstürzte, lokale Maßnahmen sind genau deshalb – erst einmal – zu vermeiden. Insbesondere dann, wenn sie groß sein sollen.
Denn in jenen immer komplexer werdenden Organisationssystemen, in welchen wir heute arbeiten, schütten wir so eher säckeweise Sand ins Getriebe und vergrößern unsere Probleme. Und zwar so, dass sie uns lange, lange, LANGE noch beschäftigen können.
Aus DIESER Erfahrung heraus erkennt Agilität radikal an, dass die Dinge (eher) komplex sind und immer weniger „nur“ kompliziert.
Der Unterschied?
In komplexen Systemen erkennen wir die Ursache-Wirkungs-Zusammenhänge nicht oder nicht gut genug.
Statt durch einzelne, vielleicht auch noch externe Experten einen Masterplan entwerfen zu lassen (z.B. VON ManagerInnen oder BeraterInnen) – was in komplizierten Systemen erfolgreich und zielführend sein kann-, fragen wir deshalb zunächst WAS DAS PROBLEM IST und WELCHE URSACHEN ES DAFÜR GIBT.
Und das tun wir GEMEINSAM („Beschreibung des komplexen Problemsystems“, Multiperspektive).
Wir nehmen das gesamte System in den Blick.
Und wir nehmen auch das gesamte System in die Verantwortung (hands on)! Erst wenn wir uns sicher sind, das PROBLEM MÖGLICHST GUT VERSTANDEN UND BESCHRIEBEN und also auch ECHTE LÖSUNGSANSÄTZE erkannt zu haben, sprechen wir – GEMEINSAM – über die nächsten Schritte.
Die gute alte Lean-Schule also
…die wir jetzt mithilfe der agilen Routinen umsetzen. In Scrum durch Planning – Daily – Review – Retrospective. Das sind übrigens sehr starre, chronologische Abläufe! Ganz ähnlich derer, die wir aus klassischen Organisationsansätzen kennen („Jour Fixe“). Innerhalb derer verhalten wir uns nur anders.
Deshalb brauchen wir anfangs oft Unterstützung durch agile Profis, also interne oder externe agile Coaches, deren Job es VOR ALLEM ist, dem Team in den Arm zu fallen, wenn sie in alte Muster zu verfallen drohen und ansonsten echte Lösungsroutinen anleiten. Also:
Weg vom großen Masterplan (z.B. „aufgenommene“, „modellierte“ und „implementierte“ Prozesse) hin zu eher organischem Wachstum und organisatorischem, gemeinsamem Lernen und zielgerichtetem Handeln.
Enorm wichtig
… ist hierbei, TRANSPARENZ herzustellen und SELBSTORGANISATION zuzulassen. Das ist für Hierarchisten, vor allem den machtorientierten und -geschädigten – also für fast alle von uns: UN-DENK-BAR!!!.
Das ändert aber nichts an der Tatsache, dass Arbeiten auf Augenhöhe, Konfliktfähigkeit, Wertschätzung heute sehr sehr sehr (!) hilfreich ist. (Alles übrigens Dinge, die uns selten bis nie vermittelt werden und denen wir – soziokulturell gesehen – also noch nicht so recht trauen.)
Vor allem die Erkenntnis ist effektiv, dass ALLE das GESAMTE System zu verbessern haben und nicht nur jenen lokalen Spot, an dem sie gerade stehen. Und vor allem geht es nicht (so sehr) darum, die einzelnen Menschen darin zu verbessern: Manage the system, not the people!
Dort, wo das verstanden wird und funktioniert empfinden die Menschen das als ziemlich großen, aber sehr intuitiven und wohltuenden Paradigmenwechsel. Denn sehr viele, wenn nicht sogar die meisten Menschen erleben eben jeden Tag, dass es auf die bisherige Art nicht oder nicht (mehr) gut geht.
Sie freuen sich, wenn durch vernünftige und notwenige Änderungen in der Arbeit der Flow und der Spaß zurückkehrt. Und damit der echte Erfolg.
Weiterlesen?
- Balle, Michael u.a.: The Lean Strategy: Using Lean to Create Competitive Advantage, Unleash Innovation, and Deliver Sustainable Growth.
- Hüther, Gerald; Hauser, Uli: Würde. Was uns stark macht – als Einzelne und als Gesellschaft.
- Rother, Mike: Die Kata des Weltmarktführers. Toyotas Erfolgsmethoden.
- Senge, Peter M.: Die fünfte Disziplin. Kunst und Praxis der lernenden Organisation.
- Sutherland, Jeff: Scrum. The Art of Doing Twice the Work in Half the Time. (Deutsch: Die Scrum-Revolution)