Akkordarbeit (und warum sie in der IT nicht funktioniert)

Bild: Pixabay/Selenajain - Lizenz

Der Artikel Büroarbeit wird zur Akkordarbeit aus der Süddeutschen Zeitung ist in den letzten Tagen recht intensiv in meiner Timeline diskutiert worden. Der Titel ist selbsterklärend und das Thema nicht falsch, die Kombination von Detailkontrolle und Akkordarbeit sollte man kritisch sehen und nur vorsichtig einsetzen. Problematisch wird dieser Artikel dadurch, dass er agile Softwareentwicklungs-Methoden in diesen bedenklichen Trend mit einschließt. Er versucht zwar zu differenzieren (und ist damit schon einen Schritt weiter als der Spiegel letztes Jahr), rutscht aber immer wieder in die Haltung zurück, dass überschaubare Aufgaben und transparenter Arbeitsfortschritt etwas schlechtes sind.

Ohne den Text komplett aufdröseln zu wollen (sein Verfasser Alexander Hagelüken hat darin auch Zutreffendes aufgeschrieben) möchte ich mich auf den zuletzt genannten Punkt konzentrieren, da ich glaube, dass er auf einer falschen Annahme beruht. Auf der nämlich, dass es überhaupt möglich ist Arbeitsprozesse in der Software-Entwicklung so zu zerlegen und kontrollierbar zu machen, dass Akkordarbeit durchführbar wird. Nach über 10 Jahren in dieser Branche bezweifele ich das sehr.

Zunächst ist die grundlegende Eingangsvoraussetzung nicht gegeben: um Arbeit in fest definierte Arbeitspakete zu zerlegen und diese zu verteilen müsste man bereits im voraus wissen welche Arbeit in der nächsten Zeit anfällt. Um das wiederum zu wissen müsste man sie schon mindestens einmal durchgeführt haben, um irgendeinen Anhaltspunkt für Schätzungen und Optimierungen zu haben. In der Fabrikproduktion geht das, man kann auf diesem Weg die Herstellung eines Autos immer effizienter machen. In der Softwareproduktion ist das entweder sinnlos oder unmöglich: wenn das neue und das alte Produkt genau gleich sind übernimmt man einfach mit Copy & Paste den gesamten Code, wenn sie nicht gleich sind bringen die Erfahrungen der Vergangenheit nur vage Anhaltspunkte. Man baut dann einen Prototypen, mit allen damit verbundenen Unwägbarkeiten.

Das bedeutet natürlich nicht, dass Firmen nicht trotzdem versuchen würden Akkordarbeit einzuführen. Die Arbeit wird im voraus in Pakete verteilt, ihnen wird eine Zeitschätzung angehängt und sie werden auf die Mitarbeiter verteilt. Entweder erweist sich die Schätzung dann schnell als unrealistisch oder es zeigt sich, dass weitere Arbeiten zu erledigen sind die am Anfang nicht bedacht wurden. Die übliche Reaktion darauf ist, dass die Mitarbeiter zu Überstunden angetrieben werden um den Zeitplan zu halten. Die reagieren ebenfalls, indem sie dort Arbeit einsparen wo der Vorgesetzte es nicht sehen kann. Es wird weniger in Clean Code, saubere Architektur und gründliches Testen investiert, kleinere Defects werden nicht gemeldet, auszubauende Komponenten werden nicht entfernt sondern nur auskommentiert. Natürlich führt das in der Zukunft zu Mehrarbeit, wodurch insgesamt der Effekt entsteht, dass höherer Arbeitsdruck die Leistungsfähigkeit nicht etwa steigert sondern sogar senkt.

In fast allen Software entwicklenden Unternehmen in denen ich bisher gewesen bin galt Akkordarbeit aufgrund dieses Phänomens als etwas kontraproduktives. Selbst wenn das Management sie gerne gehabt hätte war jedem klar, dass sie in der Realität nicht umsetzbar sein würde. Und an der Stelle wurden die in kurzen Abschnitten präsentierte Zwischenergebnisse, die für agiles Arbeiten unverzichtbar sind, auch wieder unproblematisch: natürlich kam regelmässig die Frage auf ob das nicht schneller gehen würde, ohne den dazu notwendigen Hebel ließ sich dieser Fortschritt aber nicht erzwingen. Um den Bogen zurück zum Beginn zu schlagen: ja, Akkordarbeit in Büros ist ein Problem. Aber: nein, Akkordarbeit in der (agilen) Softwareentwicklung ist keines.

Das alles heisst übrigens nicht, dass man in agilen Methoden nicht mit Deadlines planen kann. Dafür gibt es andere Ansätze, die aber ein Thema für sich sind.