Was Menschen in die Erschöpfung treibt
Was Menschen in die Erschöpfung treibt
Psychische Erkrankungen sind der dritthäufigste Grund für Krankschreibungen. Bei einem Kongress in Berlin werden derzeit die Auswirkungen der extremen Beschleunigung auf die Psyche diskutiert. Von A. Braun und R. Kölbel.
You're viewing a single thread.
Das Hauptproblem ist hier meiner Meinung nach, dass die Schlagzahl der Kommunikation sich drastisch erhöht hat, aber die Arbeit selbst nach wie vor immernoch wie in den 80ern durchgeführt wird.
Ein populäres Beispiel hier sind Meetings. Die Tendenz, dort viele regelmäßige Termine mit vielen unnötigen Teilnehmern zu veranlassen, ist für mich Ausdruck eines Wunsches nach Kontrolle, aber eigentlich erzeugt man nur Stress. In den meisten Projekten ist man eh permanent dabei, miteinander zu kommunizieren, also braucht es keine "Abstimmungsmeetings" oder ähnliches mit 15 Teilnehmern, das ist völliger Schwachsinn.
In der Informatik (ich weiß, da sind ja auch viele von euch) gibt es darüber hinaus diverse agile Frameworks wie SCRUM, die aus meiner Sicht nur noch zum Übel beitragen. Sie vernichten die persönliche Assoziation der Entwickler mit ihrem Werk, indem Aufgaben absurd klein geschnitten werden, um sie zu generalisieren und damit auch jeden Funken von Stolz und Identifikation mit dem eigenen Werk. Dazu kommt dann eine nie endenwollende Welle von Retro-Pre-Refinement-Standup-Meetings, die dann auch noch effektiv den letzten Keim der Freude an der Arbeit um die Ecke bringt.
Nee, entweder wir reduzieren die Geschwindigkeit oder hören auf, uns selbst auf den Sack zu gehen, aber beides geht eben nicht auf Dauer.
Das "auf den Sack gehen" kommt doch auch aus der Geschwindigkeit. Beispiel Vertrieb. Wenn früher die Bestellung per Brief kam, dann galt die genau so. Also hat der Kunde sich vorher genau überlegt, was er haben will, und das dann auch so bestellt.
Heute gibt es dann 20 Mails mit kurzfristigen Änderungswünschen, weil die Bestellung unbedingt schon heute raus musste, aber dann die Hälfte nicht gepasst hat, was im Laufe des Tages festgestellt wird.
Und natürlich will der Kunde dann, dass alles schon bearbeitet ist, damit die Bestellung unbedingt heute bearbeitet wird. Dann antwortet man nach der 20. Änderung, ob sie es sich nicht nochmal in Ruhe überlegen wollen, weil das immer noch nicht pass. Man kann das aber natürlich auch so liefern. Dann wird die superwichtige Bestellung die unbedingt heute noch durch muss plötzlich ein Thema, von dem man die nächsten zwei Wochen nichts mehr hört.
Ich bin ja schon etwas älter und daher kann ich dir leider sagen, dass das so nicht stimmt. Kunden sind durchaus in der Lage eine Bestellung per Post zu versenden und dann per Telefon noch Änderungen reinzuschicken. Oder mehrere Bestelländerungen per Fax zu einer telefonischen Bestellung aufzugeben. Ich bin mir sogar sicher, dass schon zu römischen Zeiten Pferdekuriere mit Bestelländerungen zu Olivenölamphoren oder Gladiatorenzubehör unterwegs waren
Ich würde nicht sagen, dass Geschwindigkeit hier die einzige Ursache ist, aber natürlich ein Katalysator. Ich definierte das "auf den Sack" gehen als nicht-zeitgemäße Herangehensweise innerhalb einer Prozessstruktur, die ganz offensichtlich im Wandel ist, während man selbst aber nicht darüber nachdenkt, wie man sein eigenes Kommunikations- und Handlungsportfolio entsprechend anpasst. Beispiel waren daher die Meetings mit sinnlosen Teilnehmern in sinnloser Taktung, die wohl von so ziemlich allen in dieser Form als kontraproduktiv wahrgenommen werden. Man macht das aber trotzdem, weil war ja immer so.
Scrum ist nur eine Methode, nicht das Problem. Wie die Gesichtserkennung ist es nur eine Technik, deren Implementierung schlecht oder Anwendung häufig zweckentfremdet wird.
Ich höre und lese oft, dass Scrum ein totaler overhead ist. Dann fehlt aber häufig ein guter Scrum Master, der sich um die Prozesse und Moderation kümmert. Häufig wird die Methode auch nur vom (mittleren) Management "reingekippt" nach dem Motto, "dann sind wir agiler", was aber NICHT bedeutet, man kann einfach mal so was in die Entwicklung kippen. Und dann - wenn richtig eingeführt - deckt Scrum sehr häufig Missstände auf, die vorher diffus nicht greifbar waren. Genau dann braucht es auch jemanden, der diese aufnimmt und für die nötige Veränderung sorgt. Bedingt aber auch, dass das entsprechende Management für diese Veränderung bereit sein muss.
Richtig angewandt kann Scrum mega gut sein und die Entwicklungsumgebung und die Menschen darin schützen. Man muss es aber auch wirklich wollen. Und dazu gehört zu verstehen, wann Scrum überhaupt sinnvoll ist (und v.a. welches Problem es lösen soll) und wann nicht.
ich möchte dir wirklich nicht zu nahe treten und eigentlich sollten wir diese Diskussion vielleicht an anderer Stelle führen, daher kürze ich etwas ab, aber deine Argumentation erinnert mich etwas an die Legitimation des Sozialismus. Der war nämlich auf dem Papier auch immer schon eine tolle Idee. in der Realität bin ich seit 20 Jahren in diesem Beruf, länger, als man hierzulande überhaupt Begriffe wie Scrum weitläufig kennt. Ich behaupte mit vollster Überzeugung, dass ich noch nie gesehen habe, wie etwas gutes aus dieser Methode entsteht, das sowohl wirtschaftlich ist als auch Kernprobleme wie Crunchzeiten minimiert. Das Gegenteil ist für mich der Fall.
Wir arbeiten in meiner Firma ohne festes Framework, nehmen uns das, was wir brauchen, fokussieren uns bewusst auf individuelle Stärken und Schwächen, anstatt zu generalisieren. Das führt derzeit noch zu einer effektiven Mitarbeiterfluktuation von exakt 0, da sich meiner Einschätzung nach die Menschen gut aufgehoben und wertgeschätzt fühlen, da sie sich in so gut wie alle Prozesse des Betriebs einbringen können.
Das geht nicht in Betrieben mit vielen hunderten an Mitarbeitern, ist schon klar. Scrum aber auch nicht.
Ich gebe aber auch zu: ich bin Hardliner, was das angeht. Jedes Atom meiner physischen Existenz lehnt Scrum aufgrund eigener Erfahrungen entscheidend ab. Deswegen nochmal die Bitte, dass du dich nicht angegangen fühlst von mir.