Führt die Einschränkung des Engagements in Scrum zu Selbstzufriedenheit?

In meiner Organisation beenden Scrum-Teams fast nie alle ihre Geschichten zu 100%. Ich schlug vor, dass wir uns bei jedem Sprint auf weniger Geschichten festlegen, aber der F & E-Manager sagt, wenn wir das tun, werden die Leute die Arbeit immer noch nicht abschließen, sondern nur weniger davon, was die Entwicklung verlangsamt. Er sagt, dass hier ein Studentensyndrom am Werk ist.

Wie sehen Sie das?

Ihr Manager muss verstehen, dass das Studentensyndrom / Parkinson-Gesetz zu einem erheblich größeren Problem wird, wenn keine Hoffnung mehr besteht, Ziele zu erreichen. Plötzlich ist die Zeit, die für die Erledigung einer Aufgabe zur Verfügung steht, unendlich. Wie ein alter Kollege von mir sagte: "Fristen sind nur Dinge, die hier vergehen. Wir vermissen sie, sie werden zurückgezogen, wir vermissen sie wieder."

Und das war in erster Linie eine Folge unangemessener Fristen. Diese Leute waren von Natur aus nicht faul, sie sahen nur keine Hoffnung, ein Ziel zu treffen, und keine Konsequenz, es nicht zu treffen. Warum sollten sie sich also Sorgen machen?

Mein Punkt ist, dass Ihr Manager durchaus Recht haben könnte. Aber er muss verstehen, dass er das Problem schafft.

Wenn ein Team die Sprintplanung gut macht, beginnt es als Team zu arbeiten, um seine Fristen einzuhalten. Jede Person zieht nicht ihr Gewicht, sie scheitert als Team. Wenn dies kontinuierlich geschieht, kümmert sich das Team um diese Person.

Es besteht die Möglichkeit, dass Sie die Geschwindigkeit zu stark verringern und weniger erreichen, als Sie möglicherweise haben. Aber du wirst es geschafft haben. Die Gefühle im Team werden positiv sein. Jemand wird wahrscheinlich sagen: "Ehrlich gesagt, ich denke, wir können im nächsten Sprint noch ein paar Punkte mehr erreichen."

Schließlich finden Sie Ihren Gleichgewichtspunkt und können den Arbeitsaufwand, den Sie in einer Iteration tatsächlich erzielen können, richtig vorhersagen.

Wen interessiert das? Sollte der Produktbesitzer nicht fragen, wo der Rest meiner Funktionen ist?

Möglicherweise müssen Sie die Länge Ihrer Sprints begrenzen. Auf diese Weise muss mehr Fortschritt zusammen mit dem Weg gezeigt werden. Verwenden Sie das Feedback, was getan wird, um zu bestimmen, wie viel in nachfolgenden Sprints erreicht werden kann.

Sie können keinen festen Zeitrahmen für ein Projekt und keine feste Liste von Geschäften / Funktionen haben, ohne genügend Ressourcen zuzuweisen. Wenn es ein festes Fälligkeitsdatum gibt, werden möglicherweise nicht alle Geschichten fertig. Sie möchten einige Geschichten ausschneiden? Welche? Können Sie das am Anfang wirklich feststellen? Wenn Sie die richtigen Prioritäten setzen, erhält der Product Owner hoffentlich das Wichtigste. Es ist schließlich ihre Priorität.

Der Manager spielt Gedankenspiele. Wenn Sie ein Kind sind, das einen Hund möchte, fragen Sie nach einem Pony.

In meiner Organisation beenden Scrum-Teams fast nie alle ihre Geschichten zu 100%. Ich schlug vor, dass wir uns bei jedem Sprint auf weniger Geschichten festlegen, aber der F & E-Manager sagt, wenn wir das tun, werden die Leute die Arbeit immer noch nicht abschließen, sondern nur weniger davon, was die Entwicklung verlangsamt. Er sagt, dass hier ein Studentensyndrom am Werk ist.

Aufgrund meiner begrenzten Erfahrung mit [was für] Agile posiert, bin ich nicht überrascht. Alles, was ich über Agile gelesen habe, deutet darauf hin, dass jeder viel besser organisiert sein muss als bei anderen Entwicklungstechniken, aber wie Sie sehe ich wenig oder gar keine Beweise dafür.

Das Schätzen von Story Points ist keine exakte Wissenschaft, insbesondere in "topaktuellen" Bereichen wie F & E. Es könnte leicht sein , dass Ihre Entwickler sind mis schätzen ihre Story Points (IME, in der Regel über ihre eigenen Fähigkeiten -estimating) oder es könnte sein , dass es einige „Ziel“ ist Anzahl der Punkte , dass sie in jedem Sprint (IMHO zu produzieren soll sind , eine völlig fehlerhafte Art zu verwalten, die mich zu ...) bringt.

Ihr Manager muss dies untersuchen und herausfinden, was nicht funktioniert. Es liegt in ihrer Verantwortung, Dinge an die Kunden zu liefern (oder sollte es auch sein), und so ist ihr "Hals auf dem Block", wenn die Benutzer anfangen, sich zu beschweren.
[Zynismus] Natürlich wird es nicht so sein, denn sie haben alle notwendigen Schulungen / Fähigkeiten, um sicherzustellen, dass keine der Schuld bei ihnen bleibt. [/Zynismus]

Und ihre Mitarbeiter zu beleidigen, sie mit irgendeiner Art von "Syndrom" zu brandmarken, ist niemals akzeptables Verhalten - es zeigt nur das mangelnde Engagement des Managements für das Team und ihren Wunsch, sich davon zu "distanzieren".

Die Entwicklung wird in beiden Fällen verlangsamt, aber die Arbeit langsam und gewissenhafter zu erledigen (dh tatsächlich Dinge zum Laufen zu bringen) ist weitaus besser, als einfach überhaupt nichts zu liefern.