{"id":2440,"date":"2021-05-18T06:54:17","date_gmt":"2021-05-18T04:54:17","guid":{"rendered":"https:\/\/trellisterium.de\/?p=2440"},"modified":"2022-11-28T14:52:31","modified_gmt":"2022-11-28T12:52:31","slug":"wie-vermeidet-agilitaet-staus-bei-vielen-abhaengigkeiten-in-projekten","status":"publish","type":"post","link":"https:\/\/trellisterium.de\/en\/wie-vermeidet-agilitaet-staus-bei-vielen-abhaengigkeiten-in-projekten\/","title":{"rendered":"How Does Agility Avoid \u201cJams\u201d in Projects With Many Dependencies?"},"content":{"rendered":"

<\/p>\n

\n

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:\u00a0<\/strong><\/p>\n

\n

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?<\/h1>\n

\"\"<\/p>\n

\n
\n

Counter-Question<\/h2>\n

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.<\/p>\n

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).<\/p>\n

\n

Break it Up? Nope.<\/h2>\n

“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!<\/p>\n

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.<\/p>\n

A one-off action often leads to little. We tend to risk the big breakdown, possibly breaking more than it helps.<\/p>\n

\"\"<\/h2>\n
\n

So Let Us Not Rush Into Things<\/h2>\n

First of all, we try to understand and make visible what the REAL problems are and the REAL causes for the stagnant workflow.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\n

Based on this experience, Agile radically acknowledges that things are (rather) complex and less and less “just” complicated.<\/strong><\/p><\/blockquote>\n

\n

The Difference?<\/h2>\n

In complex systems, we do not perceive the cause-effect relationships well enough, or at all.<\/strong><\/p>\n

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.<\/p>\n

And that is what we do in joint work (“description of the complex problem system”).<\/p>\n

\n

We Take the Whole System Into Consideration<\/h2>\n

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.<\/p>\n

\"\"<\/p>\n

\n

The Good Old Lean School<\/h2>\n

…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.
\nThat’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:<\/p>\n

\n

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.<\/strong><\/p><\/blockquote>\n

\n

Enormously Important<\/h2>\n

\"\"<\/p>\n

… 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!!!.<\/p>\n

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).<\/p>\n

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!<\/strong>.<\/p>\n

\n

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. <\/strong>
\nThey are happy that through sensible and necessary changes in their work, the flow and the fun returns.<\/strong><\/p><\/blockquote>\n

\n

\"\"<\/a>Read on?<\/b><\/h2>\n