Wollen Scrum-Sprints so schnell wie möglich arbeiten?

21

Ich habe kürzlich ein Interview mit einigen Unternehmen geführt, die Agile und Scrum anbieten, um genau zu sein, und es gibt einige Dinge, die mir nicht so agil erscheinen. Ich nehme einen Fall, der mich gerade besonders interessiert, den von Scrum-Sprints.

Ein bestimmter Projektmanager, mit dem ich gesprochen habe (ja, sagte ich, Projektmanager), erklärte stolz, dass die Leute in ihrem Team verstehen, dass man nicht nach Hause geht, wenn die Arbeitszeiten vorbei sind Sie gehen nach Hause, wenn die Arbeit erledigt ist, egal wie viel es kostet. Was ich zwischen den Zeilen gelesen habe, ist, dass wir so viele Features wie möglich in einen Sprint packen und Überstunden machen, um dies zu ermöglichen.

Jetzt habe ich Agile noch nicht gemacht (arbeitete mit Finanz- und Regierungsinstitutionen zusammen, die Wasserfälle noch immer bevorzugen), aber ich verstehe Folgendes:

  • Sprint in Scrum ist der Name für die generische Iteration in Agile.
  • Das Team sollte in einem nachhaltigen Tempo arbeiten und versuchen, langfristige Überstunden zu vermeiden, da dies nur Auswirkungen auf die kurze Zeit hat und die Auswirkungen durch die Probleme, die sie in der langen Zeit haben, in den Schatten gestellt werden.

Stimmen meine Aussagen? Und sollte ich die Präsentation des Managers als rote Fahne sehen?

JohnDoDo
quelle
Keine wirkliche Erfahrung mit Agile, aber soweit ich weiß, sollte Ihre Sprint-Arbeitsbelastung mit der Dauer Ihres Sprints abgeglichen werden. Entweder unterschätzen die Entwickler ihre Arbeitsbelastung, oder der Manager gibt ihnen nur Arbeit, ohne nach ihrem Feedback zur Arbeitsbelastung zu fragen . In diesem Fall wahrscheinlich das letztere. - Korrigieren Sie mich, wenn ich mich irre
Andreas
4
@ Gnat Ich denke, die Fragen sind zu unterschiedlich
Andreas
27
"... du gehst nicht nach Hause, wenn die Arbeitszeit vorbei ist, du gehst nach Hause, wenn die Arbeit erledigt ist, egal wie viel es kostet ...". Rennen wie der Wind. Sie ist eine Idiotin.
6.
Ich habe dafür gestimmt, diese Frage erneut zu eröffnen. Die Frage des vorgeschlagenen Duplikats ist-agil-das-neue-Mikromanagement hat mit dieser Frage gemein, dass der Manager etwas "scrum" nennt und der Fragesteller wissen möchte, ob dies wirklich scrum ist. Bei dieser Frage geht es um "Überstunden", bei der vorgeschlagenen um "es ist nicht erlaubt, mit anderen Entwicklern zu sprechen".
k3b
"... dass du nicht nach Hause fährst, wenn die Arbeitszeit vorbei ist, sondern nach Hause fährst, wenn die Arbeit erledigt ist, egal wie viel es kostet", scheint ein direkter Konflikt mit dem Schlüsselbegriff des nachhaltigen Tempos zu sein - ich würde arbeite dort, wenn ich essen auf den tisch legen müsste. HST, wenn dies von Zeit zu Zeit auftritt, habe ich kein Problem damit. Manchmal gibt es trotz aller Anstrengungen eine Krise, und der Kunde steht an erster Stelle. Aber sie lässt es so klingen, als ob es regelmäßig vorkommt und dass es bewundernswert ist. Was es bedeutet ist, dass sie keine Ursache dafür haben, zu verstehen, warum es auftritt, und das zugrunde liegende Problem zu beheben.
Don Branson

Antworten:

27

Sie müssen nicht lange suchen, um festzustellen, dass diese Praktiken den Prinzipien von Agile zuwiderlaufen. Eines der Prinzipien des Agilen Manifests lautet:

Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

Vor ein paar Jahren hat Scrum eine subtile, aber wichtige Änderung vorgenommen . Anstelle von Teams , die sich zu der Arbeit verpflichten, die erreicht werden kann, prognostizieren sie, was sie für möglich halten.

Die Änderung ist auf Missbrauch zurückzuführen, der sich sehr nach der von Ihnen beschriebenen Einstellung anhört, erst nach Hause zu gehen. In der Entwicklung gibt es viele Faktoren, auf die sich die Teams nicht festlegen können. Um die Wetteranalogie zu verwenden, können Sie nicht festlegen, dass es morgen regnen wird.

So beantworten Sie Ihre Fragen direkt:

  • Ja, Sprint ist der Name für eine Iteration in Scrum. Sehen Sie diese Antwort für den Unterschied
  • ja, teams sollten in einem nachhaltigen tempo arbeiten. Die einzige Gewissheit von Überstunden ist , dass es wird die Teams der Produktivität langfristig zu reduzieren.
  • Ja, es ist eine rote Fahne!
Dave Hillier
quelle
23

Ja, Sie haben Recht, und wenn mir gesagt würde, was Ihnen gesagt wurde, würde ich so schnell wie möglich von dort weglaufen. Sie benutzen Agile nur als Ausrede. Klingt nach dem klassischen Todesmarsch.

Miki Watts
quelle
3
Hätte ein Todesmarsch nicht typischerweise ein Ende? Dieses Projekt klingt wie eine ewige Hölle, wenn sie Sprint für Sprint so arbeiten.
DXM
5
Nein, in einem Todesmarsch gibt es immer "wir müssen nur auf die nächste Version pushen, dann können wir Fehler umgestalten und beheben! Ups, wir haben dem Kunden die nächste Version in zwei Monaten versprochen, müssen nur auf die nächste Version pushen Ausführung!" und so weiter, Sie bekommen die Idee.
Miki Watts
2
@DXM es hat ein Ende, wenn jeder kündigt oder entlassen wird. Death March-Projekte können Jahre dauern.
Dogweather
3
@DXM Todesmärsche enden, wenn Sie sterben.
Dave Hillier
hmm, ich schätze, ich habe meine eigenen Erfahrungen dort projiziert. Irgendwie sind in meinen Augen schlecht verwaltete Projekte eine Kombination aus Todesmarsch und monatelanger Unentschlossenheit darüber, wohin sie als nächstes gehen sollen. Am längsten saß unser Team mit leerem Rückstand fast 8 Monate auf den Daumen. Dann hätten wir 4-6 Monate Zeit für eine Veröffentlichung mit der Aussage "Wir haben einen jährlichen Veröffentlichungszyklus"
DXM
11

Es gibt einen Schlüssel, der dies akzeptabel machen kann: Das Team akzeptiert den Umfang des Sprints.

In Scrum erhalten Teams nicht nur Aufgaben zugewiesen. Der Product Owner verhandelt mit dem Team, um Produktarbeit und technische (Schulden-) Arbeit zu priorisieren. Der Projektmanager, der Product Owner und das Team verhandeln dann darüber, was in einen Sprint hineingezogen wird und welchen Umfang diese Arbeit hat.

In dieser Welt sagt das Team im Wesentlichen: "Wir können X-Arbeit erledigen, testen und diese Iteration versenden". Daher würde ich erwarten, dass ein Team gelegentlich Überstunden macht, um diese Verpflichtungen zu erfüllen.

Das heißt, so viele Orte beeinträchtigen die Agilität - und so wenige Teamleiter können effektiv mit Leuten verhandeln, die normalerweise ihre Chefs sind ... Ich würde dies als große rote Fahne ansehen.

Telastyn
quelle
8
„gelegentlich Überstunden diese (zu erfüllen falsch eingeschätzt ) Verpflichtungen“ => machen falsche Schätzungen in eine Gewohnheit
gnat
1
@gnat - pssh. Die Schätzungen sind manchmal hoch. Die Schätzungen sind manchmal niedrig. Wenn Unterschätzung zum Trend wird, ist das sicherlich ein Problem. Aber das ist vor allem der Grund, warum es Iterationen gibt: um die Schätzung zu verfeinern.
Telastyn
8
Das Programmieren von Sweatshirts akzeptiert im Allgemeinen keine Verhandlungen von Arbeitern.
maple_shaft
1
@gnat: Wenn Sie als Team feststellen, dass Sie die Arbeit gewöhnlich unterschätzen, sollten Sie im nächsten Sprint weniger Arbeit leisten.
Bart van Ingen Schenau
Wenn Managementziele darin bestehen, unabhängig von den Arbeitszeitbeschränkungen (und die Erfahrung zeigt, dass dies in den allermeisten Fällen zutrifft), so viel Arbeit wie möglich zu erledigen, und die Ziele der Mitarbeiter darin bestehen, die meiste Arbeit zu erledigen, ohne die bezahlte Arbeit zu überschreiten Stunden (ich gebe zu, dass einige Manager dies als optimistisch einstufen). Unabhängig vom inhärenten Fehler bei der Schätzung wird die Planung immer zu> = Arbeitsstunden tendieren. Die logische Erweiterung besteht darin, dass die Ziele der Mitarbeiter zu unterschätzen sind. @BartvanIngenSchenau so entwickelt sich diese gewohnheit natürlich.
Steven Evers
1

Scrum wird in Sprints aufgeteilt, in denen Sie eine Reihe von Aufgaben abschätzen, die in der Dauer dieses Sprints erledigt werden müssen (normalerweise 2 Wochen, aber ich habe zwischen 1 Tag und 4 Wochen gesehen). Ich denke, dies schafft einen Anreiz, Aufgaben falsch einzuschätzen. POs (Product Owner) wünschen sich niedrige Schätzungen, um ein hohes Engagement pro Sprint zu erzielen. Das Team wird große Schätzungen vornehmen, um schöne Burndown-Charts für die PMs zu erstellen. Dies ist natürlich ein Hinweis auf eine beschissene Organisation. Sie möchten wirklich genaue Schätzungen erhalten und keine Angst haben, entweder zu kurz zu kommen und die Storys auf den nächsten Sprint zu übertragen oder früh fertig zu werden und zusätzliche Aufgaben aus dem Rückstand zu ziehen. Ich denke, der Begriff "Sprint" schafft dieses Bild von Menschen, die schneller arbeiten.

jiggy
quelle
1
mit der Ausnahme, dass die Bestellung keinen Anteil am Schätzungsprozess haben sollte. Wenn sie agil wären, wären die Teams allein dafür verantwortlich, Schätzungen zu erstellen, und basierend auf den Schätzungen des Teams kann PO nur die Prioritäten des Auftragsbestands ändern.
DXM
2
"Das Team wird große Schätzungen anstellen, um schöne Burndown-Charts für die PMs zu erstellen.": Dies ist einer der Gründe, warum ich denke, dass dieser gesamte Mechanismus fehlerhaft ist. Ich denke, ein Manager kann von einem Team, dem er vertraut, eine viel bessere Leistung erzielen, als wenn er ein Team dazu zwingt, Schätzungen vorzulegen, die in die Diagramme eingehen.
Giorgio
Das Team sollte, wie ich bereits sagte, einen Anreiz haben, Schätzungen vorzunehmen. Wenn der PO derjenige ist, der bezahlt, kann er Druck ausüben, aggressiver zu schätzen. Im Hintergrund arbeite ich in der Beratung, so dass das Scrum-Team meine Mitarbeiter sind, während der PO in der Regel extern ist und unseren überhöhten Rechnungsbetrag zahlt :)
jiggy
@Giorgio Ein nicht vertrauenswürdiges Team kann immer Schätzungen aufzeichnen und die Situation verschlimmern. Aber ein vertrauenswürdiges Team, auch von Experten, kann lernen, besser zu schätzen. Aus diesem Grund werden die Schätzungen vorgenommen und dann mit der tatsächlichen Arbeit verglichen, um zu versuchen, ihre Schätzfähigkeit zu verbessern. Der Mechanismus ist nicht fehlerhaft, ein Team zu haben, das ein System nutzt, ist das Problem und wird das Problem sein, unabhängig vom Managementsystem.
Chris
1

Nein: Scrum Sprints sind eine Zeitbox, nicht mehr und nicht weniger. Zu Beginn des Sprints / der Iteration gibt das Team eine Schätzung der Anzahl der Story-Punkte, von denen es glaubt, dass sie erreicht werden können, basierend auf Dingen wie früherer Leistung, Verfügbarkeit, bevorstehenden Ereignissen, offenen Hindernissen usw. Anschließend verhandeln sie mit dem Produktbesitzer darüber, welche User Stories in den Sprint einfließen. Das ist (oder war? Siehe andere Antwort) die Verpflichtung, die das Team dem Produktbesitzer gibt.

Wenn sich während der Entwicklung herausstellt, dass die Voraussagen nicht stimmen (es handelt sich immerhin um Softwareentwicklung) und das Risiko besteht, dass das Team die Verpflichtung nicht einhält, informieren sie den Product Owner, dass das Risiko besteht, dass eine oder mehrere Storys vorliegen nicht abgeschlossen sein.

Und das ist gut so. Sicher, es fühlt sich schlecht an, am Ende des Sprints zuzugeben, dass der Sprint fehlgeschlagen ist, aber es ist keine Niederlage, es ist eine Chance für Verbesserungen. Denn am Ende des Sprints / Starts des neuen Sprints können Sie eine Sprint-Retrospektive durchführen. Als Erstes werden Sie gefragt, warum wir diesen Sprint nicht bestanden haben und was Sie tun müssen, um ihn nicht erneut zu bestreiten ? '. Eine Möglichkeit wäre, weniger Engagement zu zeigen (= weniger Story Points aufnehmen).

tl; dr: Nachhaltiges Tempo. Bei Scrum geht es um Trittfrequenz, was das Team von Sprint zu Sprint unbegrenzt mithalten kann. Überstunden machen ist nicht; Das Team wird überarbeitet, die Arbeit wird schlampig, die Mitglieder melden sich krank oder kündigen ganz und dann haben Sie ein größeres Problem als ein fehlgeschlagener Sprint.

Cthulhu
quelle
0

Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

Aus dem Agile Manifest

Überstunden zu machen, klingt für mich nicht nachhaltig.

Trotzdem sehe ich kein Problem darin, dass eine Frühlingsverpflichtung eine starke ist (wenn das Team so arbeiten möchte), und Überstunden zu leisten, wenn Sie Schätzungen überbeanspruchen oder vermasseln, ist ein guter Anreiz, das Schätzen oder Kommunizieren zu verbessern Erwartungen an PO.

ptyx
quelle
0

Ein bestimmter Projektmanager, mit dem ich gesprochen habe (ja, sagte ich, Projektmanager), erklärte stolz, dass die Leute in ihrem Team verstehen, dass man nicht nach Hause geht, wenn die Arbeitszeiten vorbei sind Sie gehen nach Hause, wenn die Arbeit erledigt ist, egal wie viel es kostet. Was ich zwischen den Zeilen gelesen habe, ist, dass wir so viele Features wie möglich in einen Sprint packen und Überstunden machen, um dies zu ermöglichen.

Das ist kein Scrum. Die vorgeschlagene Arbeitsbelastung für eine Timebox basiert auf der Teamgeschwindigkeit und nicht auf der Wunschliste des Managers. Sie versuchen einfach, Sie zu täuschen und zu glauben, dass endlose Überstunden "agil" sind, was nicht der Fall ist. Das Team wird effizienter, wenn es ungestört und konzentriert arbeitet, aber Scrum ist kein Zauberstab für endlose Effizienzsteigerungen.

Entweder hat der Manager ein leichtes Missverständnis von Agile, oder (wahrscheinlicher) er denkt, dass Entwickler so dumm sind. Auf der anderen Seite, wenn das Team den Sprint immer wieder annimmt und weiß, dass es Überstunden machen muss, sind sie vielleicht wirklich dumm und verdienen es nicht besser?

Ich denke, du kennst die Antwort ... ;-)

JensG
quelle