Der aktuelle Sprint neigt sich dem Ende zu. Es ist Reviewtag. Nur noch wenige Stunden bis zur Demonstration der Sprintleistung. In den Teams herrscht rege Hektik. Ein Blick auf die Sprint Backlogs der einzelnen Teams verrät, dass kaum ein Team schon wirklich „fertig“ ist. Auf Nachfrage erhalte ich Antworten wie: Wir sind fast fertig oder zwei Tests laufen noch nicht rund oder eine Doku steht noch aus, die dann noch gereviewt werden muss. Auf den letzten Drücker erfolgt dann noch die Abnahme des Product Owners und mit heißer Nadel bekommt die noch nicht ganz fertige Userstory ihren grünen Haken, als Zeichen dafür, dass sie erledigt (done) ist. Kurzum: Ich beobachte immer wieder das gleiche Phänomen. Die Lieferung des versprochenen (Commitment) Geschäftswerts kommt fast immer in allerletzter Sekunde. In vielleicht fünf (und da greife ich schon hoch) von hundert Sprints sehe ich Entwicklungsteams, die am Tag der Review nichts mehr für die aktuelle Lieferung tun müssen: Es (potential shippable increment) ist getestet (nicht nur unit-getestet), die Funktionalität ist integriert. Grundsätzlich spricht nichts dagegen, wenn eine Userstory, mit heißer Nadel gestrickt, auf den Punkt genau fertig wird. Das spricht auch für das Team. Es hat, wie versprochen, Qualität geliefert und kann gemeinsam einen Erfolg einstreichen. Interessanterweise äußern sich die Teams nahezu einstimmig über die Gründe, warum alles immer auf den letzten Drücker fertig wird: in den ersten Tagen des Sprints wird getrödelt. Man hat gerade einen Sprint hinter sich gebracht und schon soll man wieder Vollgas geben. Das fühlt sich so an, als säße man im Hamsterrad. Darüber hinaus ist man zu Beginn eines Sprints noch nicht so mit der fachlichen Materie vertraut, wie während des Sprintzyklus oder zum Ende hin. Das heißt, dass gerade am Sprintanfang noch viele Dinge unklar sind. Einerseits ist es also verständlich, dass die Teams die ersten Tage im Schongang unterwegs sind und die Arbeitsatmosphäre eher an das sprichwörtliche „Kommst du heut`nicht, kommst du morgen“ erinnert, als an Erich Kästners „Es gibt nichts Gutes, außer man tut es (Anm. d. Verfassers: und zwar am besten sofort).“ Allerdings sinkt mit steigendem Zeitdruck die Qualität der Arbeit und damit auch die Leistungsfähigkeit. Schon vor 100 Jahren wurde das Yerkes-Dodson-Gesetz, das bis heute als allgemein gültig akzeptiert wird, niedergeschrieben. Es besagt, dass „die menschliche Leistung bei einer mittleren Erregung die besten Werte erzielt, bei zu geringer und zu hoher Erregung die schlechtesten. Um die optimale Leistungsfähigkeit ausnutzen zu können, ist eine mittlere Aktivierung und ein wenig Druck, um wach zu werden und in Schwung zu kommen, zu begrüßen. Je stärker der Druck jedoch steigt, desto rapider nimmt die Leitungsfähigkeit ab“ (Kratz, 2011, S. 28). Was kann ein Scrum-Team nun unternehmen, was kann der Einzelne unternehmen, um beiden Seiten der Medaille gerecht zu werden?Gegen AufschieberitisAufgaben wachsen in dem Maße, in dem man sie vor sich herschiebt. Bleiben Dinge unerledigt, dann wächst nicht nur die Liste der Erledigungen, sondern das Unerledigte sitzt uns immer stärker im Nacken und übt einen unangenehmen Druck aus. Deshalb kann ich nur die Empfehlung aussprechen, den großen Frosch zuerst zu vertilgen („Eat the frog“) - jeden Tag. Fangt mit den Sachen an, die am wichtigsten sind und die am meisten Arbeit machen, auch, wenn sie noch so unbeliebt sind. Es wird euch den Druck nehmen. Und macht es nicht allein (nicht selten beobachte ich, dass die Anzahl der Reviews zu Beginn leider sehr gering ist). Geteiltes „Leid“ ist schließlich nur halbes. Und noch was: Eat the frog and reward yourself. Möglicherweise kommt der große Brocken erst mitten im Sprint, weil man beim Planen etwas unterschätzt hat. Auch dann gilt das gleiche Prinzip: 

Der Fehler als Leistung, der Fehler als Chance

Winston Churchill hat mal gesagt: „Perfektion ist Lähmung.“ Und er hat recht damit. Die Hauptursache für Aufschieberitis ist laut Professor Lothar Seiwert, Zeitmanagement-Guru, unser Perfektionismus (vgl. Seiwert, 2009, S. 198): „Wer immer alles perfekt erledigen will, der wird nie fertig und ist somit gezwungen, immer mehr Aufgaben immer länger vor sich herzuschieben. Natürlich wollen wir alle unser Bestes geben. Doch: Muss deshalb immer alles perfekt sein?“ Software-Entwickler neigen ebenso wie Ingenieure zu einem starken Hang zur Perfektion. Es muss alles 100 Prozent vollkommen sein. Alles, was weniger ist als alles, ist definitiv zu wenig. Und genau das führt dazu, dass man den Fokus verliert und nicht mehr unterscheiden kann, ob etwas (überhaupt noch) wirklich wichtig und für eine Lieferung überhaupt essentiell oder gar vonnöten ist (Definition of Done). Hier würde ich mir eine intensivere Kommunikation mit dem Product Owner und seinem Team wünschen. Akzeptanzkiterien auf der Basis der Requirements müssen klar definiert sein und sollten vor allem als Minimalanforderung besprochen werden: Das möchte ich mindestens haben. Wenn ihr das habt, dann gebt Bescheid. Gebt euch untereinander öfter Feedback - insbesondere bei euren Reviews. Hinterfragt euer Handeln! Tun wir noch das Nötigste oder ist es schon mehr, vielleicht schon zu detailliert, zu viel.

Review am Freitag?

Ein von mir äußerst geschätzter Entwickler und Mitglied eines sehr produktiven Scrum-Teams äußerte sich zu der oben diskutierten Problematik dahingehend, dass er sich am Ende eines Sprints zwar zufrieden fühlt, aber er sei auch ausgelaugt und "satt". Ihm würde es helfen, wenn die Review an einem Freitag vonstatten ginge. Man könne so den Sprint auch tatsächlich abschließen. Nach einem erholsamen Wochenende würde dann am Montag das nächste Sprint Planning folgen und man wäre für neue Aufgaben ausgeruhter und bereit. Was denkt ihr? Seht ihr das auch so? Wie sind eure Erfahrungen mit Lieferungen, die auf den letzten Drücker passieren?  LiteraturKratz, Hans-Jürgen (2011). Aufschieben. Nein danke! Tu`s gleich! Die beste Strategie für mehr Lebensqualität. Walhalla. Seiwert, Lothar (2009). Noch mehr Zeit für das Wesentliche. Zeitmanagement neu entdecken. Goldmann.