Insbesondere mit dem Scrum-Commitment gibt es immer wieder Diskussionen über die ungeliebten Überstunden. Muss das Team Überstunden schieben, um sein Commitment zu halten? Diese Diskussion will ich hier aber gar nicht führen – vielleicht später. Bei der Diskussion um Überstunden habe ich häufig das Gefühl, dass es sich in der agilen Welt um eine heilige Kuh handelt. Überstunden sind ein No-Go und fertig. Tatsächlich glaube ich, dass wir uns mit dieser Haltung einer Option berauben, die man in der passenden Situation durchaus in Betracht ziehen sollte.
Und genau zu so einer Situation habe ich ein Praxisbeispiel. Wir haben vor einiger Zeit ein Projekt angenommen, in dem wir eine Webanwendung für eine Versicherung entwickeln sollten. Für das Projekt hatten wir 2,5 Monate Zeit und die Deadline war ebenso hart wie sportlich. Und da der Termin so eng war, haben wir gemeinsam im Team beschlossen, dass jeder von Beginn an soviele Überstunden macht, wie er selbst verantworten kann. Wir haben alle eine ganze Weile Überstunden geschoben. Die Menge hat aber über die Zeit abgenommen, weil wir immer sicherer wurden, dass wir den Termin halten können. Letztlich haben wir den Termin auch gehalten und es wurde eines der produktivsten und befriedigsten Projekte, an dem ich bisher beteiligt war – und das bei wirklich konsequentem TDD, sehr hoher Testabdeckung und sehr gut strukturiertem Code.
Bei der Retrospektive haben alle Teammitglieder die Überstunden-Maßnahme begrüßt. Sie wurde in einer “Jo, wir schaffen das”-Atmosphäre geboren (im Gegensatz zur sonst üblichen “Wir arbeiten soviel wir können, damit wir hinterher keinen Anschiss kriegen”-Atmosphäre). Es war also “Play to win”.
Zur Klarstellung: Ich rede hier nicht von Überstunden, die irgend jemand anordnet. Ich rede davon, dass das Team Überstunden bewusst und gewollt über einen kurzen und verantwortbaren Zeitraum einsetzt.
Tagged: eXtremeProgramming, Scrum
