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“.