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?

Your bosses want you to work more Agile? You yourself have heard so many good things and now you want to try it too? But first you have a few questions? You are not alone. I, for instance, have recently been asked:

Agility (apparently) often means breaking up rigid chronology in projects/processes. How do you avoid „traffic jams“ at certain points, when person B is dependent on persons A and C doing their part first?

Counter-Question

How do we avoid dependencies and congestion in hierarchical organizations? Exactly. Most of the time, not at all. Or – worse – by making a complex, dependent problem of congestion even more complex and dependent – e.g. through scaled rounds of approval.

In this respect, it seems to me that the Agile approach is more targeted. At least in most cases. Especially because Agile defines the reduction of dependencies as one of the most important team tasks that we all (!) have to take care of. Whereas in command-and-control organizations we trust or hope that „management“ will take care of it (e.g. the department head meeting or a well-thought-out project plan).

Break it Up? Nope.

„To break up“ is an ugly word that I personally dislike and worry about. And it indicates that we are aiming for the WHOLE BIG change – really fundamental and thorough! And indeed, it is about looking at the processes on the whole and improving them. So that the work may flow as smoothly as possible!

However, this is not done in a one-off, big, sudden action, but by making the emerging interdependencies visible again and again, i.e. permanently (they always come back!) and thus avoiding traffic jams. Step by step and permanently.

A one-off action often leads to little. We tend to risk the big breakdown, possibly breaking more than it helps.

So Let Us Not Rush Into Things

First of all, we try to understand and make visible what the REAL problems are and the REAL causes for the stagnant workflow.

These are usually not found (solely) in one specific area, but in several (!) other places in the process. This is exactly why hasty, local measures should be avoided – for the time being. Especially if they are to be large.

For in the increasingly complex organizational systems in which we work today, we tend to pour bags of sand into the gears and increase our problems. In such a way that they can keep us busy for a long, long, long time.

Based on this experience, Agile radically acknowledges that things are (rather) complex and less and less „just“ complicated.

The Difference?

In complex systems, we do not perceive the cause-effect relationships well enough, or at all.

Instead of having individual, perhaps even external experts (e.g. managers or consultants) draw up a master plan – which can be successful and purposeful in complicated systems – we therefore first ask WHAT THE PROBLEM IS and WHAT THE CAUSES ARE.

And that is what we do in joint work („description of the complex problem system“).

We Take the Whole System Into Consideration

And we also take the whole system into account (hands-on)! Only when we are sure that we have UNDERSTOOD AND DESCRIBED THE PROBLEM AS WELL AS POSSIBLE and have thus also identified REAL SOLUTIONS, do we talk – TOGETHER – about the next steps.

The Good Old Lean School

…which we are now implementing with the help of Agile routines. In Scrum through Planning – Daily – Review – Retrospective. By the way, these are very rigid, chronological processes! Very similar to those we know from classical organizational concepts („Jour Fixe“). Within them, we just behave differently.
That’s why we often need support from agile professionals at the beginning, i.e. internal or external agile coaches, whose job it is FIRST and foremost to prevent the team from relapsing into old patterns. And otherwise to guide real solution routines. So:

Move away from the big master plan (e.g. „recorded“, „modelled“ and „implemented“ processes) to more organic growth and organisational, shared learning and purposeful action.

Enormously Important

… here is to establish TRANSPARENCY and allow SELF-ORGANISATION. For hierarchists, especially the power-oriented and power-affected – in other words, for almost all of us: UNTHINKABLE!!!.

But that doesn’t change the fact that working at eye level, the ability to deal with conflict and appreciation is very very very (!) helpful today. (By the way, these are all things that are rarely if ever taught to us and which – from a sociocultural point of view – we, therefore, don’t really trust yet).

Most of all, it is effective to realize that EVERYONE has to improve the WHOLE system and not just that local spot where they are standing at the moment. And above all, it is not (so much) about improving individual people in the system: Manage the system, not the people!.

Where this is both understood and working, people find it a pretty large but very intuitive and beneficial paradigm shift. Because a lot of if not most people experience every day that things don’t work or don’t work (any more) the way they used to.
They are happy that through sensible and necessary changes in their work, the flow and the fun returns.

Wie vermeidet Agilität „Staus“ in Projekten mit vielen Abhängigkeiten?How Does Agility Avoid “Jams” in Projects With Many Dependencies?