Die 40-Stunden-Woche

… oder „Warum sind meine Core-Bibliotheken so schlecht?“

Eine von der agilen Bewegung empfohlene Praktik ist die Einhaltung der 40-Stunden-Woche. Wird beispielsweise im Team Scrum eingesetzt, soll beim Planen eines Sprints darauf geachtet werden, dass die Zielvorgaben vom Team in seiner Regelarbeitszeit und damit ohne Überstunden erfüllt werden können.

Das klingt zunächst nur wie ein Vorteil für die Angestellten. So möchte der Arbeitgeber doch so viele Funktionen wie nur möglich implementiert haben. Und wenn die Zeit knapp wird möchte er erst recht nicht hören, dass das Release verschoben werden muss.

Warum sollte er also entgegen dem betriebswirtschaftlich offensichtlichen Standpunkt die Mitarbeiter nicht „darum bitten“, Überstunden zu machen?

Ken Schwaber erklärt in seinem Google Tech Talk mit dem Thema „Scrum“ weshalb es unbedingt vermieden werden sollte, dass das Team überlastet ist und Überstunden machen muss.

Arbeitet ein Entwickler nur 8 Stunden am Tag an seiner Aufgabe, so ist es laut Schwaber möglich, sich in dieser Zeit auf die Arbeit zu konzentrieren und gute Arbeit zu leisten.

Meist sollen sich laut Schwaber Entwickler auch nach der Arbeit in Gedanken mit den ihnen gestellten Problemen befassen und finden gelegentlich dadurch Lösungen für Probleme, auf die sie in der Arbeitszeit nicht gekommen wären.

Arbeit, die über die Regelarbeitszeit hinaus geht, bringt den Software-Entwickler an einen Punkt der Erschöpfung, der zum einen seine Konzentrationsfähigkeit schwächt und zum anderen seinen Wunsch stärkt, nach der Arbeit „abzuschalten“. Dies bedeutet in der Regel, dass versucht wird, von den Themen der Arbeit Distanz zu halten. Dadurch wird nicht mehr reflektiert, was an diesem Tag gearbeitet wurde.

Ordnet der Vorgesetzte an, dass Release Dates gehalten und dafür wenn nötig Überstunden gemacht werden müssen, ist die übliche Reaktion von Software-Entwicklern, zu versuchen, durch Erhöhung der Geschwindigkeit Überstunden zu vermeiden.

Genau das Erhöhen der Entwicklungsgeschwindigkeit kann jedoch nicht ohne weitere Verluste geschehen:

• Bei der Konzipierung der Systeme werden schnelle Entscheidungen getroffen
• Oft werden dabei die Lösungen gewählt, die am einfachsten zu implementieren sind
• Diese Lösungen sind in der Regel unflexibler
• Gründliches Testen oder Unit-Tests werden vernachlässigt
• Code Reviews werden nicht gemacht
• Der Code wird nicht durch Refactoring wieder in einen wartbaren Zustand gebracht

All diese Faktoren sind der Grund, weshalb kontinuierlicher Druck im Team dazu führt, dass Komponenten mit der Zeit immer schwerer zu warten werden.

Wenn schnellere Entwicklung und Überstunden vom Team akzeptiert werden und dadurch Release Dates gehalten werden können, wird der Vorgesetzte beim nächsten Mal wieder vom Team erwarten, dass es diese Geschwindigkeit liefern kann.

Jedoch dann steht dem Team eine Software zur Verfügung, die eine Codebasis hat, mit der wesentlich schwerer und langsamer entwickelt werden kann.

Mit der Zeit entstehen Bereiche in der Software, die nahezu unwartbar sind und von denen die Entwickler am Liebsten die Finger lassen. Das sind oft die Core-Bibliotheken, die Klassen im System, die am häufigsten modifiert wurden.

Es ist also wichtig zu erkennen, dass bei der Software-Entwicklung eine Erhöhung der Entwicklungsgeschwindigkeit und ein Erzwingen von Überstunden nicht wie bei anderen Professionen mit der Zeit wieder ausgeglichen wird. Vielmehr handelt es sich hier um einen Kreislauf, der die Situation ständig verschlimmert.

Es wird klar, dass es keine Verlust-Situation für das Management sein kann, wenn sie das Release zugunsten der 40-h-Woche verschieben, denn dann kann in kontinuierlicher Qualität entwickelt werden. Und schließlich soll meistens die Software mehr als zwei Quartale weiterentwickelt werden.