Am Ende wird alles gut oder warum Lieferungen ständig mit heißer Nadel gestrickt sind

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.

Agile Toolbox
Scrum
Product Owner
Scrum Meetings
ScrumMaster-Praxistipps
Team
bgloger-redakteur
December 17, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4