Einleitung

Eine interessante Regel bei eXtreme Programming (XP) ist die bzgl. des "Nachhaltigen Tempos". Es widerstrebt einem anfangs, das Mittel "mehr Stunden" gerade nicht einzusetzen, wenn es kritisch wird im Projekt. Aber dafür gewinnt man mehr als man scheinbar verliert.

Vielleicht muß man diese Regel wirklich einmal (oder besser öfter) in einem Softwareprojekt angewendet haben, um ihren Wert schätzen zu können.

Warum mir persönlich diese Regel für die Softwareentwicklung wichtig ist, möchte ich hier kurz erklären.

Seitenanfang

Die Regel

Im Original bei Kent Beck ([1]) heißt diese Regel noch "40-Stunden-Woche".

Mittlerweile hat sich der Begriff "Nachhaltiges Tempo" eingebürgert, wobei sich die Bedeutung nicht geändert hat: die Anzahl der (Arbeits-) Stunden pro Woche an sich ist nicht so entscheidend als vielmehr die Frage, welchen Umfang man "unendlich lange" durchstehen kann.

Und das ist der Punkt: wie viele Stunden pro Woche kann ich tatsächlich produktiv arbeiten?

Manche werden antworten "37,5" (merkwürdig), oder "40", oder "45" ... auf jeden Fall gibt es hier keine Norm. Bestimmt sind 50 und mehr Stunden aus meiner Sicht zu viel:

• ich rede hier nicht von Anwesenheit!
• ich rede von konzentrierter und produktiver Arbeit;
• ich rede von 6 und mehr Stunden Pair-Programming pro Tag -- und das IST anstrengend!

Also: es gilt im Projekt-Team festzulegen, bei welcher Belastung das Team immer noch ausreichend Erholung erfährt, um am nächsten Arbeitstag wieder voll leistungsfähig an den Start gehen zu können. Und am übernächsten und am über-übernächsten, usw.; eben über die gesamte Projekt-Dauer hinweg!

Eigentlich sind mir Werte kleiner/gleich 40 Stunden am liebsten; auch eine "kleine" Zahl ist kein Problem (z.B. 20 Stunden), denn ich zahle auch nicht mehr Stunden, bin mir aber sicher, daß ich immer die "volle" Leistung erhalte.

Seitenanfang

Ein Vergleich mit Sportlern

Sie haben sicher schon einmal im Fernsehen (oder live) einen 100m-Sprint gesehen: maximales Tempo, keine Steigerung mehr möglich, die LäuferInnen im Ziel "stark erholungsbedürftig".

Und dann z.B. ein Marathonlauf: das Tempo deutlich langsamer als beim 100m-Sprint, extrem gleichmäßig (gute Läufer haben fast identische 5-km-Splitt-Zeiten), im Ziel wird noch eine Stadion-Runde gelaufen.

Aber so ist das eben mit uns Menschen: man kann nicht beliebig viel Leistung heraus pressen; wir müssen uns eben auch regelmäßig (und nicht zu spät) erholen.

Ein müder Läufer wird zwar auch den Wettkampf bestreiten -- aber eben nur so schnell, wie sein müder Körper es zuläßt.

Und genauso verhält es sich bei der Arbeit in Software-Entwicklungs-Teams: ein Projekt ist eher ein Marathon-Lauf und mehr als ein 100m-Sprint.

Seitenanfang

Das Gegenteil: ein "Hochdruck-Team"

Was wir aber sehr wahrscheinlich als Projekt-Alltag kennen ist:

• 50- bis 60-Stunden-Wochen;
• auch am Wochenende im Büro;
• ein hoher Streß-Pegel;
• ständig das Gefühl, zu viel Arbeit zu haben, hinter Plan zu sein ...
• ach ja: und die Stimmung im Team ist auch nicht so besonders;

Woher kommt das?

In manchen Firmen ist dieses Szenarium einfach zur "Kultur" geworden (siehe dazu auch [2]): alle Projekte laufen unter Hochdruck (d.h. "sie sind besonders wichtig"), haben einen engen Zeitrahmen und sind von vorne herein nur mit hohem Engagement der Beteiligten zu schaffen (d.h. mit vielen Überstunden).

Sie kennen das, oder? Vielleicht vom Erzählen, von Bekannten, von Kollegen, oder gar aus eigener Erfahrung?

Manchmal steckt einfach nur mangelhafte Planung dahinter, manchmal aber auch Manager-Kalkül: "nur so kann gewährleistet werden, daß wenigstens 'das notwendige' erreicht wird".

Aber wie sagte schon Tom DeMarco ([3]): "Ein Kopf unter Druck denkt nicht schneller!".

Seitenanfang

Die Folgen von "Hochdruck"

Die Folgen von "Hochdruck" sind eigentlich bekannt; aber trotzdem kurz:

• "schneller" Start im Projekt;
• im Verlauf des Projektes kommen die Ergebnisse immer langsamer;
• mehr und mehr (Über-) Stunden werden notwendig;
• trotzdem scheint man noch langsamer zu werden;
• die Fehler häufen sich;
• die Krisen häufen sich;
• besonders schlimm: ist man erst bei 50-60 Stunden angelangt erreicht man auch mit 70 Stunden nicht ein Mehr an Ergebnis ([3]);

Übrigens: in einer solchen Umgebung findet man nur schwer Freiwillige für ein nächstes Projekt ...

Seitenanfang

Der Gewinn

Ich beobachte einen sehr geringen Streß-Pegel bei Teams, die explizit mit der Regel "Nachhaltiges Tempo" arbeiten. Die Team-Mitglieder entwickeln selbstständig(!) einen sehr regelmäßigen Rhythmus: wann sie beginnen, wann Schluß ist, wann Pausen gemacht werden ... wie mit Problemen umgegangen wird.

Für mich war es anfangs schwierig zu sehen, daß manchmal die Ergebnisse nicht "rechtzeitig" kommen: man hätte doch leicht mit 2-3 Stunden mehr etwas aufholen können. Aber man gewinnt, wenn man der Versuchung widersteht und es nicht(!) macht: eben dadurch wird der Projekt-Fortschritt kalkulierbar. Schwierigkeiten können sich nicht mehr hinter Mehr-Arbeit "verstecken"; sie werden sofort sichtbar. Und wenn ich ehrlich bin: Mehr-Arbeit und Überstunden hatten oft ihre Ursache in Planungs-Fehlern; d.h. die Software-Entwickler müssen etwas "ausbaden", was sie nicht verursacht haben.

Die Planung: auch die wird positiv beeinflußt. Wenn das Team mit nachhaltigem (=gleichmäßigen) Tempo durch das Projekt marschiert, dann kann ich mit diesem Tempo tatsächlich kalkulieren. Wer sich die "Mühe" macht und einmal die erreichten Story Punkte über die Zeit in ein Diagramm einträgt, der wird in jedem Projekt nahezu eine Gerade sehen; nur die Steigung dieser Geraden ist projektspezifisch.

Seitenanfang

Ausnahmen

Es kann Ausnahmen geben. Aber die Kunst ist, daß es wirklich Ausnahmen bleiben.

• es sollte als Hinweis zum Handeln genommen werden, falls immer am Ende einer Iteration Überstunden "notwendig" sind;
• das gleiche gilt auch für das Ende eines Release: das Tempo muß gleichmäßig verteilt sein;
• hat man Releases in der Produktion beim Kunden im Einsatz, dann kann es durchaus notwendig sein, ein akutes Problem dort sofort zu beheben;

Waren die Planungen für das Release
   fundiert (=Geschwindigkeit korrekt angenommen),
   richtig priorisiert (=die wichtigen Dinge zuerst erledigen, am Ende die weniger wichtigen)
   und offen (=Kunde weiß, daß Funktionen am Ende der Liste ggf. Streich-Kandidaten sind),
dann sollte auch eine Verschiebung von Teilen ins nächste Release kein Problem sein.

Vielleicht hat man ja in diesem Projekt mit einem speziellen Problem zu kämpfen. Wenn dem so ist, dann soll sich dieses neue/junge Problem nicht verstecken können (hinter Mehr-Arbeit) und zu einem Monster wachsen können.

Seitenanfang

Vorsicht Falle

Es gibt da ein paar Fallen, die mir schon aufgefallen sind:

• Kumulative Wochen-Stunden:
  dieses Problem können Sie in Projekten mit Teilzeit-Mitgliedern bekommen: solche Mitglieder sind Ihrem Projekt z.B. für 50% zugeteilt und verbringen auch nicht mehr als z.B. 20 Stunden pro Woche in Ihrem Projekt; aber wie viele Stunden wird noch in anderen Projekten gearbeitet? Achtung: ausgepowert ist man auch in Ihren 20 Stunden, auch wenn der Grund dafür außerhalb dieser 20 Stunden liegt!
• Gruppen-Druck:
  wie bei Sportlern gibt es auch in Projekt-Teams Mitglieder mit unterschiedlicher "Kondition"; gefährlich wird es, wenn man sich fälschlicherweise von den Spitzen-"Sportlern" im Team zu einem zu hohen Tempo mitreißen läßt;

Also aufgepaßt: auch diese Regel muß wie alle anderen mit Gefühl und "Köpfchen" angewendet werden. Und hier ist ganz klar der Team-Coach gefragt!

Seitenanfang

Zusammenfassung

Häufig wird in Projekten bereits zu Beginn der Grundstein für einen Teufels-Kreis gelegt: zu hohes Tempo (=zu viele Stunden), damit erhöhtes Risiko für Fehler, die dann durch weitere zusätzliche Stunden korrigiert werden müssen; usw.

Das Resultat ist eine Verlangsamung im Projekt bis hin zum möglichen Zusammenbruch.

Wer schon einmal eine lange Bergwanderung unternommen hat, der weiß was ich meine: man startet mit einem verhaltenen Tempo, da man sich kennt und weiß, was vor einem liegt; dann wird man ständig von diesen "Sprintern" überholt; nach einer Stunde sieht man sie wieder vor sich; und kurze Zeit später sitzen viele von ihnen am Wegesrand und machen Pause, haben sogar Krämpfe. Viele von denen sieht man an diesem Tag nicht am Gipfel!

Was gibt es schöneres für einen Team-Coach als ein munteres Projekt-Team, das immer leistungsbereit ist, das man eher bremsen muß als "antreiben" und das Ergebnisse in beständiger Regelmäßigkeit produziert.

Das hat nichts mit Behäbigkeit oder "Füße-hoch-legen" zu tun, sondern das ist "Nachhaltiges Tempo"!

Seitenanfang

Verweise

Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und für weiterführende Informationen:

[1]	Kent Beck: eXtreme Programming, Das Manifest; (Addison-Wesley)
[2]	Edward Yourdon: Death March - how to survive Mission Impossible Projects; (Prentice-Hall)
[3]	Tom DeMarco: The Deadline; (Dorset House Publishing)

Seitenanfang