Archiv für den Monat Mai 2017

Ein Denken in digitalen und virtuellen Zusammenhängen ist notwendig

Veröffentlicht am von
Kommentar

In den zurückliegenden zwanzig Jahren der Digitalisierung und Virtualisierung der Arbeitswelten waren Betriebsräte, Vertrauensleute, Personalräte und Gewerkschaften in der Regel davon ausgegangen, dass die Ansätze zur sozialen Gestaltung der Arbeit vor allem den betrieblichen Organisationsabläufen folgten. Das Hervorbringen materieller Produkte sowie die Bereitstellung von Dienstleistungen verstärkten ein Denken von betriebsrätlichem Handeln, das vor allem die Beziehungen von Mensch zu Mensch und die Mensch-Maschine-Relation betonte. Diesen beiden Ebenen galten vordringlich die Interventionen zugunsten einer weiteren Humanisierung der Arbeitswelt.

Mit der enormen Zunahme der Quantitäten von Software, Hardware, Plattformen und Netzen sowie weiteren Einflussfaktoren ist eine neue zusätzliche Qualität entstanden, die ein erweitertes Handeln erfordert. In dem Maße, wie mehr und mehr Arbeitsinhalte und Organisationsbedingungen im virtuellen Raum verankert sind, verschieben sich Räume und die Möglichkeiten sozialer Gestaltung dorthin.

Neben das Denken in Organisationszusammenhängen, in Mensch-zu-Mensch-Beziehungen sowie Mensch-Maschine-Verknüpfungen tritt nun notwendigerweise ein Denken in digitalen und virtuellen Zusammenhängen sowie in Netzinfrastrukturen. Dieser Denkansatz gewann und gewinnt rasant an Gewicht. Es ist deutlich zu erkennen, dass das Verstehen einer 4.0-Arbeitswelt auf der Basis „autonomer Software-Systeme“ (ASS) eher dann gelingt, wenn gewerkschaftliches Handeln vom Denken in digitalen und virtuellen Handlungsräumen (Transaktionen) geprägt wird. Mit anderen Worten: Es genügt nicht, von außen auf bzw. in die virtuellen Räume zu blicken. Es gilt nun vermehrt, aus dem Inneren der virtuellen Transaktionsräume den Wandel des Virtuellen zu verfolgen.

Ist es für uns vorstellbar, dass die Zukunft der Arbeit nicht mit dem Netz, nicht entlang des Netzes sondern vor allem im Netz entschieden wird? Wenn diese Annahme zutrifft, müssten Gewerkschaften ihre Kompetenz und Gestaltungskraft im Netz weiter ausbauen. Damit wären nicht Websites gemeint sondern fokussierte soziale Transaktionskompetenzen im Umfeld von ASS.

Kontrovers: „Altes“ und „neues“ Wissen?

Veröffentlicht am von
Kommentar

Im Hinblick auf die notwendige Gestaltung von „Arbeit 4.0“ zeigen sich in den gewerkschaftlichen Diskussionen und Diskursen zunehmende Ungleichzeitigkeiten von Erfahrungen und Wissen. So manch kompetenter Kollege, der schon die Kontroversen um die Einführung von Gruppenarbeit und die Debatte um die Implementierung von Steuerungssoftware im Werkzeugmaschinenbau Ende der achtziger und in den neunziger Jahren leidenschaftlich mitgestaltete, steht der Wirkmächtigkeit „autonomer Software-Systeme“ (ASS) eher zurückhaltend gegenüber.

Das mühsam errungene Technikleitbild einer „menschenzentrierten“ Gestaltung von damals wirkt beim ersten Hinsehen mit den schrittweise beginnenden Realitäten von ASS-Anwendungen unverträglich. „Selbst lernende“ Software erscheint so als vermeintlich diametraler Gegensatz zur „menschenzentrierten Technikgestaltung“.

Doch die beiden Perspektiven sind durchaus positiv und synergetisch verbindbar. Wenn es in der aktuellen Debatte um die tatsächlichen 4.0-Arbeitswelten mit ASS-Nutzungen gelingen würde, die Frage („Wer ist im Verhältnis von Mensch und ASS wessen Assistent?“) im Sinne des Menschen zu beantworten und die Rolle von ASS auf Assistenzfunktionen grundsätzlich auszurichten, gingen beide Perspektiven produktiv zusammen.

Deshalb sollte die aufgebrochene Kontroverse zwischen vermeintlich „altem“ und „neuem“ Wissen kreativ weitergeführt werden. Es lohnt sich.

Die zwei Gesichter der agilen Scrum-Methode

Veröffentlicht am von
Kommentar

Seit mehr als eineinhalb Jahrzehnten wandert ein neues Modell der Arbeitszeitorganisation durch die Entwicklerabteilungen der großen und mittelständischen IT-Unternehmen. Entwicklerteams sollen selbstverantwortlich handeln, sollen sich selbst organisieren, sollen hierarchiefreie hohe Qualität auf kurzen Wegen erbringen. Das Zauberwort heißt „Agilität“. Seit dem „Agile Manifesto“ des Jahres 2001 (http://agilemanifesto.org/iso/de/manifesto.html) entfaltet sich dieses Prinzip in verschiedenen Erscheinungsformen und Methoden. Eine davon nennt sich „Scrum“. Eine schlanke Organisation für schnelle gute Arbeit, könnte man meinen.

Doch Scrum hat mindestens zwei Gesichter. Auf der einen Seite verspricht Scrum die Aufwertung und Wertschätzung der Team-Idee. Scrum-Teams handeln methodisch ähnlich wie teilautonome Gruppen in der Fertigung. Sie agieren horizontal, ergebnisorientiert und möglichst zeitautonom. Im Idealfall würde nicht das Management die Vorgaben („Sprints“) machen sondern das Team für sich selbst. Moderierend wird ein/e vorübergehend gewählte/r Scrum-Master/in aktiv. Wer einmal in einem Scrum-Team war, betrachtet die Methode als Schritt in die richtige Richtung. Ein solches Team will dies auch dem Betriebsrat beibringen.

Doch das Prinzip „Scrum“ krankt immer wieder an einer unzureichenden und einseitigen Umsetzung. Die vom Team angestrebte höhere Arbeitszufriedenheit wird verfehlt, wenn die Zielperspektiven der Scrum-Umsetzung falsch gewählt werden. Gelingt es Team und Betriebsrat, die Realisierung an den Begriffen Stärkung von Qualität und Kreativität sowie an nachhaltigen Arbeitsformen auszurichten, hat Scrum eine gute Chance, dem Unternehmen samt Beschäftigten positiv dienlich zu sein.

Wird der agilen Methode aber einseitig ein purer Effizienzgedanke mit kurzen Zeitrhythmen unterlegt, kehren sich die Vorteile um. Die Belastungen überwiegen bei weitem die Entlastungen. Stresssymptome, psychische Belastungen, Konzentrations- und Schlafprobleme verringern die von der Geschäftsleitung erhofften Produktivitätsgewinne.

Die Daily Scrum-Meetings führen die Teammitglieder in eine weitreichende Transparenz der Teamleistungen und des individuellen Leistungsvermögens. In der Praxis zeigt sich jedoch, dass die radikale Transparenz nicht mit einem Anwachsen des Vertrauens in die Führungskompetenz der Unternehmensleitung verbunden ist. Im Gegenteil: Unzureichende Scrum-Zielsetzungen erzeugen einen Vertrauensschwund. Hinzu kommt die Praxiserfahrung, dass nicht das Team die Arbeitsmenge und die Geschwindigkeit vorgibt, sondern Management und Kunden. Der Zeitdruck nimmt zu. Scrum verkehrt sich in ein rein Takt gebendes System. Wenn einzelne Personen in mehreren Scrum-Teams arbeiten oder wenn verschiedene Scrum-Teams auf Grund von Auftragsinhalten miteinander verschränkt sind, sinkt die Zeitautonomie rapide.

Die Arbeit verliert so ihren ganzheitlichen Charakter. Gestaltungsspielräume und Zeitsouveränitäten schwinden. Teams empfinden sich vermehrt als eine Art Fließbandarbeiter der IT-Entwicklung. Im Zentrum steht nicht mehr der Mensch sondern der Takt.

Die Praxiserfahrungen aus unterschiedlichen Unternehmen zeigen, dass eine gute Scrum-Umsetzung zumeist an zwei Herausforderungen scheitert: Wenn, erstens, die Rolle der Führung keine Führung ist, sondern nur kurzatmige Leitung, dann verringert sich die Entscheidungsautonomie der Teams erheblich. Wenn, zweitens, Scrum nicht auf der grundsätzlichen Zeitautonomie der Teams basiert, wandelt sich die agile Methode zu einem Faktor der inneren Instabilität. Scrum wird so nicht nachhaltig.

Vor diesem Hintergrund kommt einem Betriebsrat bei der Einführung von Scrum eine zentrale Rolle zu. Er muss qualifizierte Zielbestimmungen durchsetzen und die Bedingungen der Arbeit klären. Erforderlich ist eine Betriebsvereinbarung die unter anderem den Paragrafen 111 des Betriebsverfassungsgesetzes (Betriebsänderung: Einführung neuer Arbeitsmethoden) sowie Paragraf 5 des Arbeitsschutzgesetzes (Beurteilung der Arbeitsbedingungen) aufgreifen sollte. Betriebsräte sollten sich vorab schulen lassen. Die Methode Scrum benötigt starke Betriebsräte, die sozial gestalten und die Chancen der Agilität vor möglichen Belastungen schützen. Die Lösung der Belastungsproblematik wird zum Schlüsselkriterium für eine gute Scrum-Umsetzung. – Übrigens: Manchmal heiß Scrum auch „SWARM“.