{"id":3386,"date":"2021-09-16T11:59:57","date_gmt":"2021-09-16T09:59:57","guid":{"rendered":"https:\/\/trellisterium.de\/?p=3386"},"modified":"2022-11-28T15:31:39","modified_gmt":"2022-11-28T13:31:39","slug":"und-laeufts-oder-agilitaet-ist-nur-was-fuer-projekte","status":"publish","type":"post","link":"https:\/\/trellisterium.de\/en\/und-laeufts-oder-agilitaet-ist-nur-was-fuer-projekte\/","title":{"rendered":"How’s things? Or: “Agile only works for projects.”"},"content":{"rendered":"

<\/p>\n

\n

Companies organized in an agile way seem to be ahead of the game today. So, why haven’t we all already been organized in this way?<\/strong><\/p>\n

\n

<\/p>\n

\"\"<\/div>\n
<\/div>\n
<\/div>\n
<\/div>\n
\n

Recently, on a conference, I talked<\/h1>\n

to a friendly attendee. Agile, she said, appealed to her personally, she found it interesting and helpful. But for her and her department’s job, she regretted, agile approaches were out of the question.<\/p>\n

\n

After all, in her department, it’s all about routinely processing rather uniform tasks. She would very much welcome agility for projects in which she is also partly involved, but not for her department’s routines.<\/p>\n<\/div>\n

\n

While I am certainly often confronted with the misconception<\/h2>\n

that Agile was invented for projects, I confess that I am always a bit clueless. What should I do? Should I argue?<\/p>\n

Should I say that it is precisely the patterns of thought and action that are not regularly reviewed, precisely the entrenched, unconscious routines, that get teams, departments and entire companies into trouble. In general. Especially nowadays. They turn out to be a threat to them.<\/p>\n

Because they make you feel safe when you are not.<\/strong>.<\/p>\n

\n

It is precisely these routines that open up huge opportunities for competitors.<\/h2>\n

So should I say that Agile is particularly effective and important with routines? Because Agile teams are all about asking themselves again and again whether they are still doing the right thing, whether they are still good enough, in other words: whether the routines are still right?<\/p>\n

Should I be doing this?<\/p>\n

\n

Better not. Who wants to be preached to?<\/h2>\n

After all, we all have the right to find our own way and make our own experiences (including the sometimes adventurous missteps it takes).<\/p>\n

So I held back this time again. Even though it was hard for me this time. Again. (It gets easier each time).<\/p>\n

\"\"<\/p>\n

\n

Any Agile working framework<\/h2>\n

be it Lean Startup, Design Thinking, DevOps, Kanban, Scrum, etc., follows the same basic empirical, experience-based organizing principle (and the same value creation philosophy): in manageable steps, recurring, and focused on a big goal:<\/p>\n

    \n
  1. plan<\/li>\n
  2. do<\/li>\n
  3. check (study)<\/li>\n
  4. adapt.\/1\/<\/li>\n<\/ol>\n

    Accurately speaking, this is the universal, evolutionary principle of learning and surviving that each of us has known since the first moment of our lives – at least since we first touched the very hot hotplate.<\/strong><\/p>\n

    \n

    Agile consistently transfers this learning principle<\/h2>\n

    to the organization of collaborative tasks. Each agile working framework does this in its own way, with certain emphases and with certain goals.<\/p>\n

    What they all have in common, however – and here they differ fundamentally from those prevailing hierarchical structures and organizational principles that emerged in the machine and production age of the last century – is that all working frameworks prioritize the collaborative element as a basic condition.<\/p>\n

    And this is not because Agilists are better people (which has yet to be proven) or because, say, this kind of collaboration feels better (which has already been proven). <\/strong><\/p>\n

    But simply because today, in the dawned service age, it is all about optimizing value. Which means pecuniary and\/or other profit. (“Maximum outcome, minimum waste.”).<\/p><\/blockquote>\n

    And for this it simply needs different approaches than the ones around.<\/p>\n

    \"\"<\/p>\n

    \n

    Agile, therefore, always and consistently turns as many people as possible<\/h2>\n

    to participants. May it be managers, staff or any kind of stakeholder, first and foremost of course the customers. (We are talking about taking part in decision making, value creation, taking over responsibility, motivation etc.).<\/p>\n

    For this purpose, they are given a structural framework (financial, organizational, thematic, creative, visionary, etc.). In an self-organized way they repeatedly (respectfully and on an equal level) exchange information (feedback) about the what, the how, the current status and the next concrete steps in certain rhythms.<\/p>\n

    As a consequence, results are gradually developed in an organizationally maximally fast, flexible and seemingly incidentally appreciative and motivating way, which satisfy everyone as much as possible.<\/p>\n

    (And if this does not succeed, undesirable developments can be corrected relatively easily and quickly).<\/p>\n

    \n

    However, although each of us know this learning principle by heart<\/h2>\n

    although each of us today has a very large expertise in how to organize well,\/3\/ although the successes and advantages of agile companies are visible and tangible for all of us today, and although, on the other hand, things are increasingly not going quite so smoothly for us, slower, more complicated, more inflexible, more self-centered, more annoying, more conflictual, etc., so despite all this, we find it difficult to take the obvious, the agile step.<\/p>\n

    Why? <\/strong><\/p>\n

    \"\"<\/p>\n

    \n

    For me, it is because<\/h2>\n

    we are (as so many times) victims of an all-too-human pattern of behavior:\/4\/ Despite many warnings and existing rational insight, we still lack (for us) good, convincing motivational reasons, we lack the real, our own urgency to break away from the existing but expiring organizational success model of the last century.<\/strong><\/p>\n

    What is tough enough for each of us individually doesn’t get any easier in groups. (“It’ll work out.”, “It’s all worked out well so far!”, “It’ll be fine.”)\/4\/<\/strong><\/p><\/blockquote>\n

    \n

    The successful model called for<\/h2>\n

    striving for structural and routine stability. That`s what the circumstances of the time demanded.<\/p>\n

    So they relied on division of labor (silos) and on management (“command and control”), on maximally efficient, routinized and standardized processes (“best practice”), on the expertise and strength of the individual (“specialism”, “it’s up to you!”) and on extrinsic motivators (bonuses, existential fear, compulsion).<\/strong><\/p><\/blockquote>\n

    \n

    \"\"Until the turn of the millennium, this worked just fine economically<\/h2>\n

    (ecologically, it probably looks different) and was therefore also very desirable for a long time.<\/p>\n

    Today, however, this form of corporate management is developing not at all slowly into a relatively large structural risk that can (and happily does) pose an existential threat to organizations as a whole<\/strong><\/p><\/blockquote>\n

    Because unlike back then, today we are dealing with much more unsteady times and changed environments. Complexity and rapidity are just two challenges for organizations here, albeit particularly large.<\/p>\n

    However, a multitude of other issues can be effortlessly added here, which are developing at a similarly rapid to radical pace:<\/p>\n