Verteiltes Team und Überstunden – Zwei heikle Themen für Scrum

Stefan Roock hat in seinem Blog zwei heikle (da umstrittene) Themen aufgegriffen. Viele Scrum-Abhängige ;-) bekommen schon bei einem der Themen graue Haare; Stefan hat zu beiden  interessante Posts geschrieben.

Überstunden

Mehrarbeit wird in der Agile Community stets als etwas schlechtes angesehen. Das Team soll keine Überstunden leisten (“sustainable pace”). Manchmal wirkt dies etwas absonderlich, wenn man als Projektleiter selbst Überstunden leistet, vor dem Team kommt, nach dem Team geht und dann auch nicht das geliefert bekommt, was man eigentlich im Projekt braucht (Argumentation: “Haben keine Zeit / zu wenig Leute / …”). Dies führt zu noch mehr Überstunden, da Diskussionen mit Kunden anstehen oder Notlösungen erdacht/geplant/umgesetzt werden müssen. Natürlich ist dies letztendlich eine Frage der Priorisierung, d.h. vom Top-Management. Es bleibt aber der fahle Beigeschmack, dass manche sehr engagiert arbeiten, anderer – anscheinend – im Modus “Dienst nach Vorschrift” verweilen.

Stefan beschreibt in seinem Blog ein Projekt, in dem das Team Überstunden geleistet hat, um die sehr enge Zeitplanung zu halten. Wichtig dabei: Das Team für sich selbst die Entscheidung getroffen, bewusst und sehr früh Überstunden zu leisten.

Weg von einem “covering my ass” zu einem “winning team” eben.

Hierzu muss das Team natürlich entsprechend motiviert sein (gewinnen muss sich lohnen). Das Engagement muss ausreichend belohnt werden. Wahrscheinlich der entscheidende Knackpunkt bei den meisten Teams bzw. beim Management.

Weitere Links zu dem Thema:

 

Verteiltes Team

In einem anderen Artikel beschreibt er ein stark verteiltes Team und wie dieses erfolgreich Scrum Sprints durchführen konnte. Sehr lesenswert: 13 Leute, 5 Firmen, 3 Standorte. Unmöglich! Oder?

Verteilte agile Entwicklung ist sicherlich eines der wichtigsten Themen in nächster Zeit, da letztendlich jedes größere Projekt auch immer mit einem verteilten Team arbeiten wird.

“All large scale development is distributed development”

… wenn ich mich nicht irre aus “Scaling Software Agility” von Dean Leffingwell – ein sehr empfehlenswertes Buch!

3 thoughts on “Verteiltes Team und Überstunden – Zwei heikle Themen für Scrum

  1. Zum Thema Überstunden:
    In manchen Branchen wird es niemals ganz ohne Überstunden abgehen. Immer dann, wenn recht kurzfristig gesetzliche Änderungen umgesetzt werden müssen. Also die Arbeit sehr ungleich über’s Jahr verteilt ist.
    Wichtig ist m. E. dann:
    - Arbeit, die in Überstunden geleistet wurde, darf keinesfalls dazu führen, dass mit der dann erhöhten Velocity in die nächste Planung gegangen wird.
    - Wenn nicht in Scrum gearbeitet würde, hätten die Entwickler normalerweise in den nächsten Wochen Zeit, die Überstunden wieder abzubauen.
    Scrum verhindert solche Verschnaufpausen. Deshalb ist ja ein Sprint nach dem anderen in der Softwareentwicklung genau so ungesund wie im Sport. Zumindest ein teilweiser Ausgleich der Überstunden sollte aber mit eingeplant werden, sonst hat man irgendwann Entwickler die einfach keine Überstunden mehr machen können. Auch dann, wenn es für den Fortbestand des Betriebs sehr geboten wäre.

    • Die Berechnung der Velocity ist schnell ein richtiges Politikum:
      Einmal werden externe Einflussfaktoren einbezogen, ein anderes Mal nicht. Steht das Team schlecht da, dann werden die Sizes bei den Schätzungen erhöht – und dann mehr Storypoints pro Sprint abgearbeitet als zuvor. Mal wird Supportleistung (ja, das gibt es ;-)) in einem dunklen Puffer versteckt – das andere Mal explizit ausgewiesen.

      Zu den Arbeitszeiten:
      Ich bin der Meinung, dass hier eine gute Arbeitszeitregelung hilft. Diese erlaubt dann problemlos in einer Periode etwas mehr zu arbeiten und in einer anderen die Mehrarbeit wieder abzubummeln. Damit gibt es Flexibilität ohne erhebliche Mehrkosten (was bei echten Überstunden der Fall sein kann).

      Diesem Ansatz steht Scrum nicht im Weg! Wenn beispielsweise Urlaubstage in die Planung der Velocity (dere Grundlage die Team-Verfügbarkeit sein sollte!!!!) einfliessen, dann können auch freie Ausgleichstage einbezogen werden. Nicht Scrum ist schuld sondern die Arbeitszeitregelung bzw. das Management, welches wohl mehr Entwicklungskapazität benötigt als vorhanden ist.

  2. “Das Team soll keine Überstunden leisten (“sustainable pace”)”

    Das ist doch genau der Punkt. Das Team macht keine Überstunden aus Rücksicht auf den Projekterfolg. Denn wir wissen alle, wohin Überstunden führen: Übermüdung, steigende Fehlerzahl, sinkende Motivation, steigende Kosten, Verzögerung.

    Knackpunkt ist, dass einfach falsch priorisiert wurde und daher der Termin nicht eingehalten wird. Ob dem Kunden fälschlicherweise zuviel versprochene wurde oder zu viel verkauft wurde ist dabei nebensächlich. :)

Comments are closed.