Mein Projektmanager akzeptiert keine Verschleppung in Scrum - ist das normal?

52

Ich arbeite als Entwickler an einer neuen mobilen App für Android und iOS mit einer großen Backend-Komponente. Wir haben an drei Sprints dieses Projekts teilgenommen und verwenden Scrum für alle Zeremonien (Verfeinerung, Planung, Tageszeitungen, Rückblicke usw.).

In zwei der Sprints musste das Team (unbezahlte) Überstunden und Wochenenden leisten, da das Management sehr alarmiert war, dass wir die Sprint-Verpflichtung nicht rechtzeitig erfüllen würden. Alle haben hart gearbeitet, aber einige externe Abhängigkeiten und optimistische Einschätzungen haben uns Mühe gegeben, alle Sprintgeschichten zu realisieren.

Nach meiner Erfahrung ist es etwas normal, dass ein kleiner Prozentsatz der Storys während einiger Sprints nicht abgeschlossen wurde, und diese können im nächsten angepackt werden. Unser Projektmanager sagt jedoch, dass es unsere Schuld ist, als wir die Schätzung selbst vorgenommen haben. Deshalb sollten wir alle Punkte im Sprint vervollständigen.

  1. Ist dies eine akzeptable / übliche Variante von Scrum, die mir nicht bekannt ist?

  2. Wie schlagen Sie vor, dass ich darauf reagieren soll?

MrAn3
quelle
66
Wenn Ihr Arbeitsvertrag unbezahlte Überstunden und Wochenendarbeit vorsieht und Ihre Vorgesetzten dies nach eigenem Ermessen anordnen können, ist es meines Erachtens die beste Vorgehensweise, eine Sicherheitsmarge von mindestens einem Faktor hinzuzufügen von 2 zu jeder Sprintostimation oder um einen anderen Arbeitgeber zu finden.
Doc Brown
59
Nein, dies ist seit der Abschaffung der römischen Galeere keine akzeptable Praxis. Dies ist eine typische Panikattacke eines Projektmanagers, dessen Kompetenz noch weiter ausgebaut werden könnte. Menschen in den Arsch zu treten, wenn man annimmt, dass sie nicht das Beste sind, ohne Schätzungen und die Situation in Frage zu stellen, hilft diesem Chaos nicht. Aber dieses Thema ist viel zu weit gefasst, um hier diskutiert zu werden ...
Christophe
27
Fragen Sie sich, wie die Managementansicht aussehen würde, wenn Sie Ihr Sprint-Engagement im Voraus abgeschlossen hätten. Würde das Team den Rest des Sprints absahnen (einschließlich der Bezahlung)?
Qwerky,
13
Ein Projektmanager ist in Scrum nicht normal. Der Scrum-Leitfaden enthält ausführliche Informationen zu den Rollen: Scrum Master, Product Owner, Scrum Team. Keine PM erwähnt. Tatsächlich haben viele Menschen (einschließlich der meisten Unterzeichner des Agilen Manifests) wiederholt behauptet, dass Projekte die Agilität beeinträchtigen. Sie sind auch der einzige, der entscheidet, dass dies akzeptabel ist. Wenn es für Sie nicht akzeptabel ist, polieren Sie Ihren Lebenslauf und suchen Sie nach einer besseren Firma.
Blueriver,
5
Zwei Dinge: Verpflichtungen werden vom Team und nicht vom Ministerpräsidenten eingegangen, verpflichten Sie sich also zur sofortigen Behebung. Das größere Problem ist jedoch, was passiert, wenn Sie nicht liefern? Was ist die konsequenz In der Regel werden PMs, TPMs, Scrum-Master, Produktbesitzer usw. zur Zusammenarbeit mit dem Team aufgefordert, da sie in der Matrixstruktur, für die sich Agile / SCRUM anbietet, keine wirkliche Autorität über das Team haben. Das kann also nichts anderes sein als ein @, das versucht, seine Karriere auf Kosten anderer voranzutreiben.
RandomUs1r

Antworten:

75

Ein paar Dinge fallen mir auf.

Die Idee des Managements, dass das Team sich zu einer Reihe von Arbeiten verpflichtet, steht im Widerspruch zu den neuesten Versionen des Scrum-Handbuchs. Das Wort "Festschreiben" oder "Festschreiben" wird in der neuesten Version (November 2017) des Scrum-Leitfadens nur zweimal verwendet - einmal bei der Auflistung der Scrum-Werte und einmal, um darauf hinzuweisen, dass "Personen sich persönlich zur Erreichung der Ziele des Scrum-Teams verpflichten ".

Die Idee der Ziele ist Scrum wichtig. Organisationen und Teams haben nicht nur umfassende Ziele, sondern in Scrum hat jeder Sprint ein Sprint-Ziel, das bei Sprint Planning als Zusammenarbeit zwischen dem Product Owner und dem Entwicklungsteam definiert wird. Das Sprint-Ziel wird durch die Implementierung von Elementen aus dem Product Backlog erreicht, es ist jedoch nicht einfach "Beenden dieser Arbeit" und es repräsentiert oft nicht das vollständige Sprint-Backlog. Das heißt, Sie sollten in der Lage sein, das Sprint-Ziel zu erreichen, ohne jedes einzelne Product Backlog-Element, das für den Sprint ausgewählt wurde, oder jedes einzelne Element im Sprint-Backlog zu vervollständigen. Meiner Meinung nach sollte die zur Erreichung des Sprint-Ziels erforderliche Arbeit etwa 60-70% der Kapazität Ihres Teams ausmachen, obwohl Sie für die Kapazität verantwortlich sind. Verschiedene Organisationen werden jedoch unterschiedlich sein, aber das '

Überstunden und Wochenenden sind auch eine Anti-Agile-Softwareentwicklungspraxis. Ein Grundprinzip ist, dass alle Beteiligten in der Lage sind, in einem nachhaltigen Tempo zu arbeiten. Lange Tage und Wochenenden, auch wenn sie bezahlt wurden, sind für ein Team nicht tragbar.

Zu diesem Zeitpunkt gibt es ein paar weitere Schritte. Der Scrum Master des Teams sollte das Management über die Werte und Prinzipien von Scrum und Agile Software Development informieren (wie "Engagement" und "nachhaltiges Tempo"). Das Team sollte an seiner Fähigkeit arbeiten, die Arbeit vorherzusagen und den Umfang mit dem Product Owner zu verhandeln. Das Team sollte auch die Hindernisse identifizieren und darauf hinarbeiten, die zu dieser Situation geführt haben (Beseitigung oder Verringerung der Auswirkungen externer Abhängigkeiten).

Thomas Owens
quelle
2
Tolle Antwort - Sie könnten es sogar verbessern, indem Sie hervorheben oder TL; DR die wichtigsten Punkte: Engagement kann nur frei vom Entwickler selbst ausgehen und Arbeit muss nachhaltig sein
Falco
Wenn Sie Verzögerungen aufgrund der Abhängigkeit von anderen Teams haben, sollte die Zeitspanne, in der Sie gesperrt sind, für Ihr Team sichtbar sein.
luizfzs
2
Ich glaube, sie haben den Wortlaut in "Prognose" geändert. Ähnlich wie bei einer Wettervorhersage kann es falsch sein, es hat ein gewisses Maß an Sicherheit, und die in einem Sprint erstellten Geschichten helfen dem Team, in Zukunft besser abzuschätzen.
George Stocker
1
@GeorgeStocker Ja, das Wort "Prognose" wird in Bezug auf das Sprint-Backlog und bestimmte Arbeitselemente anstelle von "Festschreiben" verwendet. "Commit" und "Commitment" werden jedoch in Bezug auf die Ziele des Teams verwendet.
Thomas Owens
1
und auch ja, 9 Frauen können nicht 1 Baby in 1 Monat machen :)
Michael Durrant
33

Die von Ihnen beschriebene Situation, in der das Management Überstunden benötigt, um alle geplanten Storys fertigzustellen, ist einer der Gründe, warum in der Scrum-Literatur der Begriff "Verpflichtung" nicht mehr verwendet wird. Eine echte Zusage kann nur gegeben werden, wenn alle Ungewissheiten beseitigt sind, einschließlich der Ungewissheit über Abhängigkeiten von Drittanbietern, wie viel Arbeit jeder Gegenstand leistet, wie viel Zeit jeder unter Berücksichtigung der Krankheit zur Verfügung steht usw.

Eine der Grundideen von Scrum ist, dass das Team in einem nachhaltigen Tempo arbeitet, was im Wesentlichen bedeutet, dass normale Stunden ohne Überstunden (bezahlt oder unbezahlt) geleistet werden. Dies bedeutet direkt, dass Sie keine akzeptable Variation von Scrum feststellen.

Was Sie dagegen tun können, hängt von Ihrer Rolle ab.

Wenn Sie ein Entwickler sind, ist das Beste, was Sie tun können

  • (gemeinsam als Entwicklerteam) weigern sich, mehr Arbeit zu leisten, als Sie mit absoluter Sicherheit innerhalb eines Sprints leisten können. Dies wird wahrscheinlich weit weniger sein, als das, was das Management von Ihnen verlangt.
  • Konzentrieren Sie sich weiterhin darauf, die Arbeit zu beenden, anstatt mit neuen Aufgaben zu beginnen. Wenn Sie feststellen, dass einige Arbeiten nicht abgeschlossen werden können, geben Sie dies so früh wie möglich an, damit die Pläne angepasst werden können.

Wenn Sie ein Scrum-Meister sind, können Sie Ihren Wert wirklich unter Beweis stellen, indem Sie das Management über Scrum informieren. Einige Punkte, die mir auffallen:

  • Wie im ersten Absatz erwähnt, gibt das Team während der Sprintplanung keine Zusage, sondern eine Prognose der voraussichtlichen Fertigstellung.
  • Obwohl das Team vermeiden sollte, am Ende eines Sprints unvollendete Arbeit zu haben, ist diese Situation zu Beginn eines Projekts (oder nach einer Änderung in der Zusammensetzung des Teams) fast unvermeidbar. Wie viel Arbeit das Team in einem Sprint realistisch leisten kann, lässt sich nur anhand der historischen Zahlen der letzten Sprints des Teams in dieser Zusammensetzung bestimmen. Zu Beginn des Projekts gibt es solche historischen Figuren einfach nicht. Ein Team, das in den ersten drei Sprints genau das erreicht, was für jeden Sprint geplant ist, ist eher ein Unfall als eine gute Planung. Nach ungefähr 5 Sprints in einem nachhaltigen Tempo gibt es genügend Daten, um eine vernünftige Vorstellung davon zu bekommen, wie viel Arbeit das Team in einem Sprint realistisch beenden kann.
Bart van Ingen Schenau
quelle
Ja, und Ungewissheit wird erst beseitigt, wenn das Projekt abgeschlossen ist :-)
Christophe
3
Die meisten Menschen sind sehr gut in Vorhersagen. Die einzige Ausnahme ist die Zukunft.
Michael Durrant
21

Ihr PM hat nichts mit Ihrem Gedränge zu tun.

Ihr Premierminister hat nichts damit zu tun, Sie um unbezahlte Überstunden zu bitten.

Es liegt auf der Hand, alle Aufgaben so einzuschätzen, dass Sie garantieren können, dass sie rechtzeitig erledigt werden. Dann sollten Sie in der Lage sein, auf die zweite Art in die Kneipe zu gehen, denn wenn Sie eine Aufgabe unterschätzen, umsonst erledigen, bedeutet Überschätzen, dass Sie Zeit ohne Arbeit haben.

gnasher729
quelle
1
"Ihre PM hat nichts mit Ihrem Gedränge zu tun." Bei bestimmten agilen Methoden (z. B. DSDM) ist dies der Fall. Pure Scrum erkennt "Projektmanager" nicht einmal als existierende Rolle.
nick012000
3
Wenn der Arbeitsvertrag besagt, dass es unbezahlte Überstunden geben kann, hat der Premier sicherlich ein Geschäft damit, danach zu fragen. Und wenn das Team früher als erwartet fertig ist, ist das wieder ein "Fehler" des Teams. Es gibt also keinen Grund, danach faul zu werden. Beginnen Sie besser mit der Schätzung für den nächsten Sprint, damit die Schätzungen nicht so weit entfernt sind ). Nicht, dass ich der Art und Weise zustimme, wie das Management damit umgeht, aber Ihre Argumente sind auch nicht zutreffend (außer, dass der PM abhängig von einigen Einschränkungen am Scrum beteiligt ist - als Stakeholder kann er beteiligt sein, nur nicht im Weg er ist derzeit).
Frank Hopkins
Die andere logische Reaktion auf das Festschreiben von Schätzungen besteht darin, die Zeit für die Untersuchung aller Unbekannten einzuplanen, bevor Sie die tatsächliche Aufgabe abschätzen können.
Robin Bennett
Ich habe noch nie an einem Ort gearbeitet, an dem Scrum / Agile auf die gleiche Weise ausgeführt wird, aber in großen Zügen verwalten sie häufig das Budget und das Risiko, auch wenn der PM nicht als bestimmte Rolle anerkannt wird. Die logische Folge davon ist , dass sie unbedingt tun hat ein ureigenes Interesse daran, wie gut / schlecht die Entwicklung gehen wird , und sie können , wenn auch in einer guten Willen Anordnung für unbezahlte Überstunden fragen. Wie dies im Team möglich ist, ist von Geschäft zu Geschäft sehr unterschiedlich. An einigen Stellen sind sie strikt dem Scrum Master überlassen, an anderen beteiligen sie sich am Aufstehen (entgegen der gängigen Praxis).
Robbie Dee
DSDM ist keine agile Methode, es ist ein dampfender Haufen *******, den Manager mögen, weil es ihnen viel gibt Einbeziehung in den Prozess.
gbjbaanb
12

Das hat eine Reihe von Aspekten, aber auf hohem Niveau, ja - der Ministerpräsident wird unbedingt verstehen wollen, warum die geplanten Arbeiten nicht abgeschlossen wurden. Dies sollte jedoch im Nachhinein zur Sprache gebracht (und gelöst) werden. Von der Entwicklerseite gibt es viele Faktoren, die zu Sprintfehlern beitragen können.

Einige Dinge, die Sie möglicherweise berücksichtigen möchten:

Zu viel im Sprint

Wenn Sie regelmäßig zu viel Arbeit verrichten, scheitern Sprints. Die Sprintgeschwindigkeit sollte über die Zeit verfolgt werden, um herauszufinden, wie viele Punkte (oder Tage) optimal sind.

Ressourcenzuweisung

Stellen Sie sicher, dass die Sprint-Planung nicht entwicklungsbedingte Aktivitäten wie Zeremonien, Feiertage, Schulungen, Administrations-, Support- und andere Projekte usw. angemessen berücksichtigt. Es ist einfach nicht praktikabel und wird sofort durchgeführt, wenn automatisch angenommen wird, dass jeder sich jede Minute von jeder Stunde entwickelt, die er physisch im Büro ist Setzen Sie sich von Anfang an auf den Rücken.

Variation schätzen

Sie tun Verfeinerung, aber gibt es bestimmte Arten von Aufgaben, die immer überlaufen? In der Regel sind dies fehlende oder vage Anforderungen. Wenn die Anforderungen streng sind, sollte die Story nicht einmal in den Sprint kommen, es sei denn, sie wurde ausreichend verfeinert oder es wurde ein Spike geplant.

Geschwindigkeit

Wenn die Geschwindigkeit richtig verfolgt wird, sollte die wahre Anzahl der Geschichten klar werden. Das heißt nicht, dass sie immer rechtzeitig erledigt werden, aber es sollte die Dinge viel einfacher machen.

Guter Wille

Bei jedem Projekt ist der gute Wille begrenzt. Wenn Sie ständig außerhalb der Arbeitszeiten arbeiten, um zu liefern, leidet die Moral und die Entwickler werden ausbrennen - dies ist ein Fehler im Projektmanagement . Stellen Sie, wie bereits ausgeführt, sicher, dass bei der Sprint-Planung nur eine realistische Anzahl von Storys geplant wird, wobei Geschwindigkeit und Spitzen verwendet werden, um Sie dabei zu unterstützen.

Spikes

Wenn ein Gegenstand schlecht veredelt oder einfach nur wollig ist, haben Sie keine Angst, einen Dorn einzusetzen, um eine bessere Schätzung für spätere Sprints zu erhalten. Ja, manche Leute sind nur schlecht in der Einschätzung, aber meistens sind die vollständigen Fakten zu diesem Zeitpunkt noch nicht bekannt. Im Idealfall sollte dies in der Verfeinerung abgedeckt oder früh von der PO aufgenommen worden sein, aber manchmal können sie in einen Sprint durchrutschen. Entwickler sollten diese hart zurückschieben, da diese leicht einen Sprint torpedieren können, der ansonsten gut läuft.

Robbie Dee
quelle
2
Ich bin mir nicht sicher, ob "Push back from the PM" das nützlichste Bild ist. Das gesamte Team sollte seinen Prozess verbessern wollen - dafür ist die Retrospektive gedacht - und all die Probleme, die Sie identifiziert haben, sollten als Teil dieser Diskussion in Betracht gezogen werden, aber ich denke, es ist am nützlichsten, darüber nachzudenken "Wie kann das Team sicherstellen, dass die Schätzungen der Sprintziele in Zukunft nützlicher sind?" eher als ein PM, der das Team zurückdrängt, weil es seine Aufgaben nicht erfüllt.
Zach Lipton
1
Ich glaube, du kommst dem Problem auf den Grund. Der Premierminister muss dies unbedingt zur Sprache bringen, um zu verstehen, warum das Projekt zu spät ist, aber der Hauptgrund wird sein, dass Schätzungen aus irgendeinem Grund falsch waren. (und der Hauptgrund dafür wäre, dass PM keine hohen Schätzungen mochte!)
Ewan
Für mich ist dies eindeutig die bisher beste Antwort. +1
angryITguy
Wie wäre es, wenn wir "Pushback" (was einen potenziell antagonistischen Ansatz impliziert) als "Fragen" bezeichnen, die mir neutraler und effektiver erscheinen?
Michael Durrant
1
@MichaelDurrant et al. Fair genug - Ich habe den Wortlaut des ersten Absatzes geändert.
Robbie Dee
10

Nein, dies ist aus einem sehr wichtigen Grund keine anerkannte Form von Agile : Wenn Sie sich dazu verpflichten, alles zu liefern , tun Sie nicht Agile, sondern Waterfall - und wenn Sie glauben, Sie tun stattdessen Agile Wahrscheinlich machst du Waterfall schlecht . Ich bin sicher, Sie haben gehört, die alte Säge "gut, schnell, billig, wählen Sie zwei", oder? Bei der Softwareentwicklung heißt es eher: "Alle Funktionen werden pünktlich und im Rahmen des Budgets bereitgestellt. Wählen Sie die erste oder die anderen beiden aus." Der Wasserfall nimmt den ersten und der Agile den zweiten.

Wenn Sie agil sein wollen, müssen Sie flexibel genug sein, um Stories aus dem Sprint zu entfernen, die Sie nicht rechtzeitig abschließen können. Eine Möglichkeit, dies zu tun, besteht darin, Ihren Product Owner zu bitten, die Storys mithilfe der MoSCoW-Priorisierung zu bewerten. Dies würde bedeuten, dass nicht mehr als 60% der Storys (nach Gesamtpunktzahl der Storys) als Muss-Haves ausgewählt werden, die abgeschlossen werden sollen, 20% als Sollten-Haves, die Sie bis zum Abschluss des Projekts abschließen sollten, und das Minimum Viable Product wird veröffentlicht, 20% als Könnte abgeschlossen sein, wenn Sie die Zeit haben, und alles, was außerhalb des Geltungsbereichs der aktuellen Version liegt, wird nicht ausgeführt. Es ist auch wichtig zu beachten, dass die Must Haves in Kombination genug Fleisch haben sollten, um das Minimum Viable Product zu schaffen, ohne dass Gegenstände aus den anderen Kategorien hinzugefügt werden müssen.

Die Entscheidung, ob Elemente aus dem Sprint-Backlog gelöscht werden sollen oder nicht, liegt in der Verantwortung des Product Owner, nachdem dies vom Team angefordert wurde. Alle Elemente, die aus dem Sprint-Backlog gelöscht werden, werden vom Product Owner bewertet vollständig aus dem Projekt entfernt oder an einer angemessenen Position im Projekt-Backlog abgelegt werden.

In diesem Fall schätze ich, dass Ihr Product Owner Ihr Projektmanager ist, oder? Es wäre seine Aufgabe, zu bestimmen, welche Aufgaben fallen gelassen werden sollen, daher sollte er Sie nicht für übermäßiges Engagement beschuldigen, da es seine Aufgabe wäre, die Aufgaben fallen zu lassen, um dies zu kompensieren, und es scheint, dass er dies nicht tut.

nick012000
quelle
Überall, wo ich jemals Scrum gesehen habe, seinen Wasserfall.
gbjbaanb
6

Er hat Recht, dass es keine Verschleppung zwischen den Sprints geben sollte. Scrum-Teams, die eine Verschleppung zwischen Sprints haben, sind ein Anti-Pattern und nicht etwas, das Canonical Scrum als gültiges Ergebnis akzeptiert.

Aber sein Ansatz ist nicht gut.

Während eines Sprints sollte das Team ständig die geleistete Arbeit überwachen und sicherstellen, dass die Sprintplanung für die Fertigstellung ausgewählter Storys eingehalten wird. Wenn das Team feststellt, dass es nicht alle Storys beenden kann, sollte es sich mit PO treffen und eine Story auswählen, die aus dem Sprint entfernt werden soll. Auf diese Weise hört jeder auf, an der Geschichte zu arbeiten, und konzentriert sich darauf, die verbleibenden Geschichten fertigzustellen. Denken Sie daran: Es ist immer besser, eine Geschichte vollständig zu beenden, als zwei Geschichten zur Hälfte fertig zu haben.

Die Probleme externer Abhängigkeiten und ungenauer Schätzungen sind genau der Grund, warum es Retrospektiven gibt. Während Retro sollte das Team diese Probleme reflektieren und identifizieren. Das Team sollte dann Lösungen für diese Probleme finden und implementieren. Schätzungen können präziser gemacht werden, indem man das System und die einfache Erfahrung besser kennt. Externe Abhängigkeiten sind schwieriger, aber nicht unmöglich zu beheben.

Ihr PM ( was macht überhaupt ein PM in einem Scrum-Team? ) Sollte vom Scrum-Master nicht dazu gezwungen werden, alle Storys zu beenden. Wenn er Beschwerden hat, sollte er sie stattdessen für die Rückschau aufbewahren. Und noch besser, sollte ein Teil der Lösung der Probleme sein, die verhinderten, dass die Geschichten pünktlich beendet wurden.

Euphorisch
quelle
Ich bin mit dem Kommentar "Kein gültiges Ergebnis" nicht einverstanden. Obwohl dies kein wünschenswertes Ergebnis ist, sollten Scrum-Teams erkennen, dass es durchaus sinnvoll ist, einige Storys von Zeit zu Zeit nicht zu Ende zu bringen. Es sollte sicherlich kein normales Ergebnis sein, wenn Sie nicht mehr als eine Geschichte fertigstellen, zeigt dies, dass Sie etwas falsch gemacht haben, aber zu sagen, dass es nie ein gültiges Ergebnis ist, ist meiner Meinung nach ein bisschen stark. Ich hätte lieber Teams, die ein bisschen zu viel Arbeit als zu wenig auswählen.
Bryan Oakley
5

Ist dies eine akzeptable / übliche Variante von Scrum, die mir nicht bekannt ist?

Nein . Es ist völlig falsch. Ich könnte vielleicht mit bezahlten Überstunden sympathisieren , wenn die PO den Fehler begeht, die Schätzungen vor dem Ende des Sprints als Fakten anzugeben, aber unbezahlte Überstunden sind völlig lächerlich und lassen mich so schnell wie möglich nach einem anderen Job suchen.

Wie schlagen Sie vor, dass ich dagegen vorgehen soll?

Nach meiner Erfahrung hören Leute, die so viel auf der Schiene sind, nicht auf logische Argumente. Der einzige Weg für sie zu sehen, wie kaputt es ist, ist Show , nicht sagen. Wenn Sie also das nächste Mal eine Schätzung vornehmen und sich verpflichten, verpflichten Sie sich zu einem möglichst geringen Betrag . Verpflichte dich, ein kleines Ticket bis zum Ende des Sprints zu beenden. Eine, die du an einem Tag machen könntest. Sehen Sie, wie Ihre Uhr reagiert. Starten Sie dann eine Diskussion darüber, wofür das System verwendet wird und wofür das System verwendet werden sollte .

nvoigt
quelle
upvoted, obwohl die unbezahlte Überzeitperspektive angemessen sein kann, wenn der Vertrag auf diese Weise formuliert wird (und der allgemeine Lohn berücksichtigt dies, dh überdurchschnittlich - oder es gibt andere Vorteile).
Frank Hopkins
4

Wenn wir zu Beginn des Projekts die Geschwindigkeit des Teams festlegen, wählen wir im Allgemeinen eine konservative (niedrigere als übliche) Zahl, da es sich um ein neues Team handelt. Es würde ein wenig Zeit in Anspruch nehmen, bis sich das Team zurechtfindet , sich gegenseitig verstehen, die funktionalen und NFR-Anforderungen verstehen usw. Grundsätzlich optimieren wir nach den ersten Sprints die Teamgeschwindigkeit und offensichtlich wird sich die Geschwindigkeit erst ab diesem Punkt verbessern.

Es macht keinen Sinn, zu Beginn eine höhere Geschwindigkeit zu wählen und das Team zu strecken, um dies zu erreichen.

Eine weitere Sache ist, dass in einem einmaligen Szenario, in dem eine Lieferzusage nicht zu übersehen ist, die Projektmanager möglicherweise Druck auf das Team ausüben, weil sie sich dehnen, spät arbeiten und an den Wochenenden arbeiten. Aber das muss dann als Ausnahme und nicht als Arbeitsnorm betrachtet werden. Wenn Sie so arbeiten, kann dies kurzfristig die Geschwindigkeit erhöhen, langfristig jedoch kontraproduktiv sein, da dies zu Problemen mit der Codequalität, Problemen mit dem Ausbrennen des Teams, unglücklichem Team mit geringer Motivation usw. führen kann.

Rajesh Nair
quelle
1
Nett! +1. Bei der Gefahr des Haarspaltens "entscheidet" man nicht über eine Geschwindigkeit, es ist nur etwas, was beim Waschen nach einer Reihe von Sprints herauskommt, aber ja, mit Sprint 0 (oder wie auch immer Sie es nummerieren) - Sie stapeln das Brett mit so vielen Geschichten, wie Sie glauben, sind erreichbar.
Robbie Dee
2

Häufig gestellte Fragen zum Engagement

Ist dieses Verhalten normal?

Ich bin mir nicht sicher.

Ist es überraschend

Nein. Manche Leute werden immer "Verpflichtung" verstehen, was bedeutet, dass alles in der Verpflichtung abgeschlossen werden muss .

Ist das eine gute Idee?

Nein. Agile Entwicklung hat Nachhaltigkeit als zentrales Thema: Arbeiten Sie nur so viel / lang / hart, wie Sie auf unbestimmte Zeit tun können. Das ist meistens eine vernünftige Idee. (Wenn Ihr Management dies nicht akzeptiert, sollte es seine Organisation nicht als agil bezeichnen.)

Was sollen wir machen?

  • Erklären Sie, dass der Sprint-Inhalt auf einer Schätzung basiert . "Schätzen" bedeutet, dass es nur manchmal richtig ist - und normalerweise falsch. Wenn es falsch ist, ist es manchmal zu niedrig und manchmal zu hoch.
  • Erklären Sie, dass es viel einfacher ist, das Schätzverhalten zu ändern als die Arbeitsgeschwindigkeit.
  • Erklären Sie, dass das Team, wenn es für zu hohe Schätzungen bestraft wird, nur niedrigere Schätzungen vornimmt und das Management auf diese Weise viel mehr Fortschritte verliert, als wenn es gelegentlich einen Teil des Inhalts von einem Sprint zum nächsten pusht.

Das Schöne ist: Ihr Projektmanager kennt all diese Dinge bereits und erkennt sie als richtig. Nur kurzfristig mag man es vorziehen, sie zu ignorieren.

Lutz Prechelt
quelle
2

Ich stimme Ihrem Management-Team nicht zu. Sie hätten dich nicht dazu bringen sollen, Überstunden zu machen, um den Sprint zu beenden.

Die Idee, dass Zusagen nicht möglich sind, stammt jedoch aus einem Missverständnis der Softwareentwicklung. Ich habe viele Teams gesehen, die versucht haben, die Storys, die sie in einem Sprint beenden können, anhand der Anzahl der Story-Punkte vorherzusagen, die sie in früheren Sprints abgeschlossen haben. Wenn das möglich wäre, wäre die Softwareentwicklung linear, dh wenn ich zwei Stunden arbeite, bekomme ich doppelt so viel Arbeit wie in einer Stunde.

Softwareentwicklung ist kreativ und daher nicht linear. Es ist eine bessere Praxis für das Team, dem Management zu sagen, was es im Sprint tun kann, und diese Geschichten dann zu übermitteln. Wenn Sie Ihre Verpflichtungen konsequent nicht einhalten, hatten Sie entweder von Anfang an keine Vorstellung vom Umfang der Geschichte, oder Sie werden von Ihrem Produktbesitzer unter Druck gesetzt, mehr zu übernehmen.

Im ersten Fall müssen Sie sicherstellen, dass Sie den Umfang der Geschichte verstehen, bevor Sie sich bereit erklären, sie anzunehmen. Wenn es das letztere ist, haben Sie ein Kulturproblem und es gibt wenig, was getan werden kann.

John Douma
quelle