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 Aufschieberitis

Aufgaben 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?

 

 

Literatur


Kratz, 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.

Avatar of David Holzer
Er kann keine Ikea-Schränke zusammenbauen. Wenn er ein Bild aufhängt, endet das in einem loriotschen Chaos. Aber wenn er Menschen durch neue Situationen führen muss, ist David gelassen und fokussiert. Dort wo andere an die Grenzen ihrer Belastbarkeit stoßen, vermittelt er Ruhe und Orientierung, kann aber als guter „Leser“ von Stimmungen genauso spontan motivieren.
  • Urs Enzler

    Unsere Sprints sind 2 Wochen lang und beginnen immer an einem Mittwoch. Am Dienstagnachmittag sind Coding Dojo (2h), Review (1h) und Retrospektive (1.5h), am Mittwoch Sprint Planning (3h). (X) = time box

    Wir hatten früher das Sprintende am Freitag. Sprintende unter der Woche empfinden wir wesentlich angenehmer da so am Freitag keine Meetings sind und es den Teammitgliedern mehr Freiheit gibt auch mal früher ins Wochenende zu gehen. Ebenfalls war die Motivation am Freitagnachmittag in einer Sitzung zu hocken wesentlich kleiner.

    Bei uns wird auch am ersten Tag des Sprints nicht getrödelt. 2 Wochen sind zu kurz dafür und da Sprint nicht am Montag beginnt sind auch die Wochenendauswirkungen ;-) nicht zu spüren. Wir haben einen sehr guten Product Owner, so dass wir beim Sprintstart immer sehr motiviert sind.
    Wir zwängen auch nichts in den Sprint rein. Lieber korrekt im nächsten Sprint (technical debt).

    Ebenfalls investieren wir Zeit in das Backlog Grooming, so dass beim Sprintstart nur technische Fragen offen sind und keine Business-relevanten. Wir nehmen ausschliesslich Stories in den Sprint auf, welche genügend vorbereitet sind und vom Team verstanden sind (Ausnahmen natürlich möglich, aber selten).

    • David

      Hallo Urs,

      das hört sich ja nach einem richtig tollen Modell an – erfolgreich und für die Entwickler (also die Qualität) sehr gut. Ist das so? Klingt nach einem hohem Qualitätsbewusstsein mit Freude am Tun für alle Beteiligten

  • http://twitter.com/ArminSchubert Armin Schubert

    Hallo

    Wir haben 3 Wochen Sprint und eine Woche Orga, in denen die Kollegen sich was aus dem KANBAN Stapel nehmen. Damit “stören” wir die Sprintentwicklung nicht durch Planning, Estimation, diese finden alle in der Orga Woche statt.

    Ich hoffe, dass damit auch ein Kontextwechsel für die Entwickler möglich ist und neue Ideen spriessen können. Und diese kleinen Kanban – Themen, die nicht in den Sprintkontext passen, aber dennoch erledigt werden müssen, werden auch bearbeitet.

    Unser Team hat entschieden einen “Review-Koordinator” zu benennen, der sich um die Sammlung der vorzustellende Weiterentwicklungen kümmert und dadurch kommt sehr viel Struktur in die letzten Tage.

    • David

      Und? Wie geht es euch damit? Tut diese Woche “Orga” gut? Bekommt man so den nötigen Abstand?

      Ist das Phänomen der heißen Nadel dadurch fremd(er)?

      • http://twitter.com/ArminSchubert Armin Schubert

        Ich sehe hier, dass die Kollegen “an was anderes denken”. Aber diese Woche ist halt chronisch voll mit Meetings (Planning 1+2, etc) aber es ist eben bewusst kein Sprint.
        Diese 3+1 Mechanik gibt auch einen schönen Rhythmus fuer den Rest des Unternehmens so dass auch die Schnittstellen im Monatsrhythmus planen können.

  • http://twitter.com/MartinDomig Martin Domig

    Für mich ist die folgende Aussage ein Teil des eigentlichen Problemes:

    “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.”

    Ein Sprint ist fertig, danach beginnt sofort der nächste Sprint. Ich kenne diese Situation als Entwickler, und bin damit nicht glücklich – denn es kann auf Dauer nicht funktionieren.
    Ein Sportler kann auch nicht ewig sprinten. Wenn er das tut wird er vom Sprinter zum Dauerläufer, und der läuft nunmal langsamer als ein Sprinter. Einen ganz ähnlichen Effekt habe ich in der Software-Entwicklung erlebt: das dauernde Hetzen von einem Sprint in den nächsten, vom einen Release ins nächste führt dazu, dass man langsamer wird, das ganze Team verliert an Velocity. Dann ist am Ende eines Sprints auch irgendwann keine Energie mehr da, die eigene Defintion of Done durchzubeissen.

    • David

      Hallo Martin, das kann ich echt gut nachvollziehen. Und nun? Was kann man dagegen tun? Könntest du dir vorstellen, eine Art Pause zwischen dem Sprinten zu haben (z.B. nach jedem zweiten Sprint eine Woche Zeit für andere Themen oder Refactoring oder oder)? Denkst du das so etwas realisierbar wäre oder läuft es auf ein perpetuum mobile raus?

  • Pingback: Agile is limit » Warum Scrum nicht effizienter ist

  • Matthias Frey

    Bei uns ist Review allermeist am Donnerstag vormittags, die Retrospektiven am Nachmittag. Freitag ist “Slack-Day”, Planning dann am Montag drauf.