Scrum und Motivation

Question

Wie kann man das Entwicklungsteam davon abhalten, seine Zahlen aufzubessern, wenn es um die Erstellung von Aufgabenzeiten geht? Wie sollen sie motiviert werden, ihre Arbeit zu erledigen, wenn es keine echten Fristen gibt und sie nur an ihrer Geschwindigkeit gemessen werden?

Erledigen Sie den Auftrag innerhalb dieser Frist

gegen

Erledigen Sie den Auftrag, wenn wir den Umfang und die Qualität verringern oder die Ressourcen erhöhen.

Answer 1

Die Grundlage der meisten agilen Methoden ist Vertrauen . Wenn Sie Ihrem Team nicht trauen, warum haben Sie es dann überhaupt eingestellt? Wenn Sie der Meinung sind, dass sie der Aufgabe nicht gewachsen sind, ist es besser, das Projekt nicht zu beginnen, da es mit ziemlicher Sicherheit zum Scheitern verurteilt ist - entweder, weil Sie Recht haben und das Team ein Haufen unfähiger Entwickler ist, oder weil Sie sich irren, aber Ihr mangelndes Vertrauen und Ihre übermäßige Kontrolle das Team ersticken und ihr Engagement und ihren Enthusiasmus tatsächlich zunichte machen.

OTOH, wenn Sie sicher sind, dass Sie die besten verfügbaren Mitarbeiter eingestellt haben und dass sie talentiert und motiviert sind, ist es am besten, ihnen eine gute Herausforderung zu geben, sie arbeiten zu lassen und zu versuchen, alle Hindernisse aus dem Weg zu räumen.

Meiner Erfahrung nach sind die meisten Entwickler zu Beginn begeistert und motiviert, Produkte zu entwickeln, auf die sie stolz sein können. Doch unmögliche Fristen, unrealistische Erwartungen, zu viel Bürokratie, überkontrollierendes Management - und nicht zuletzt, Qualitätsminderung - kann diese Motivation schnell zunichte machen.

Der Sinn agiler Methoden besteht darin, dass die Entwickler die richtigen Leute sind, um die Kosten für eine bestimmte Funktion zu kennen bzw. zu schätzen. Wenn das Management darauf besteht, die Kosten zu schätzen ambos Wenn man die Ressourcen, den Umfang und die Zeit, die für das Projekt vorgesehen sind, nicht berücksichtigt, führt dies fast immer zu einer Katastrophe. Wenn man den Entwicklern hingegen Vertrauen und Verantwortung überträgt, werden sie der Aufgabe in der Regel auch gerecht. In Scrum arbeitet das Team gemeinsam die Schätzungen aus und kämpft mit Problemen, die während des Sprints auftauchen. In einem guten Projekt wachsen die Teammitglieder schnell mit dem Team zusammen und fühlen sich persönlich für das Projekt verantwortlich. Das kann so weit gehen, dass man die Mitglieder, die nicht so schnell vorankommen, zu Ergebnissen anspornt, anstatt das Team zurückzuziehen.

Answer 2

Meiner Erfahrung nach polstern die Entwickler die Zahlen aus Unsicherheit auf. Sind die Geschäftsanforderungen Ihrer Produktverantwortlichen klar? Sind die Geschichten klein genug, um sie zu schätzen?

Ihre 2 Entscheidungen zeigen mir, dass Sie ein grundlegendes Missverständnis von Scrum haben. Das Versprechen von Scrum besteht nicht darin, das gleiche Ergebnis zu erzielen, nur schneller. Es ist die Fähigkeit, schnell zu iterieren, auf Feedback zu reagieren und den Kurs zu ändern. Die Grundlage von Scrum ist das sich selbst verwaltende Team. Wenn Sie keine Teams haben, denen Sie vertrauen, ist Scrum wahrscheinlich nicht für Ihr Unternehmen geeignet.

Wie Péter in seiner Antwort sagte, ist die Motivation des Teams entscheidend, und der schnellste Weg, sie zu zerstören, ist, sie zu untergraben. Wenn das Team das Gefühl hat, dass die Geschäftsleitung es nicht unterstützt oder nicht an es glaubt, hat es keinen Grund, aggressive Schätzungen abzugeben, und wird einfach seinen eigenen Hintern schützen. Es ist Ihre Aufgabe als Manager, ihnen zum Erfolg zu verhelfen.

Answer 3

Darüber hinaus fördert die agile Methodik die Verantwortung der Peers. Es sollte nicht nur eine Person für die Schätzung von Elementen zuständig sein. Machen Sie es zu einer Gruppensache und stellen Sie sicher, dass (fast) jeder der Schätzung zustimmt. Wenn Ihr gesamtes Team gegen Sie konspiriert, um die Schätzungen aufzubessern, haben Sie viel mehr Probleme, als Sie denken.

Außerdem gibt es bei der traditionellen Wasserfall-/BDUF-Methode (Big Design Up Front) viele Möglichkeiten, Schätzungen aufzubessern und Ausreden zu finden. Ich würde sagen, dass Scrum mit den täglichen Scrum-Meetings mehr dazu beiträgt, dies einzudämmen, als es zu fördern.

Answer 4

Ich habe vor einiger Zeit einen Blogbeitrag über Anti-Muster bei der Schätzung geschrieben. Es ist eine lustige Lektüre, aber leider sind alle Muster Dinge, die ich entweder schon gesehen oder von Kollegen gehört habe. Bei unserem aktuellen Projekt haben wir etwa 3 von ihnen durchlaufen; ich glaube nicht, dass es irgendein Team schafft, sie alle vollständig zu vermeiden!

http://lizkeogh.com/2009/11/30/estimation-anti-patterns/

Informieren Sie sich auch über Systemdenken, Spieltheorie und perverse Anreize. Wenn die Entwickler die Kostenvoranschläge aufbessern, dann deshalb, weil das Umfeld, in dem sie arbeiten, sie dazu ermutigt. Eine Änderung dieses Umfelds wird ihnen helfen.

Answer 5

Hier gibt es bereits gute Antworten. Wenn Sie davon ausgehen, dass die Entwickler Sie betrügen, indem sie Stunden angeben, die sie nicht gearbeitet haben (sondern mit dem Spielen eines MMORPGs verbracht haben), warum arbeiten Sie dann überhaupt mit ihnen zusammen? Und wenn Sie ihnen vertrauen, warum glauben Sie, dass sie "mogeln"?

Übrigens ist es völlig normal, dass Teams, die neu in Scrum sind, sich zunächst überschätzen (und Elemente aus dem Sprint fallen lassen müssen), dann - nachdem sie sich so verbrannt haben - unterschätzen, um zu vermeiden, dass ihnen das noch einmal passiert. Dann wird sich, wie andere schon gesagt haben, die Teamgeschwindigkeit einpendeln und die Leute werden ein besseres Verständnis dafür haben, wie viel sie innerhalb eines Sprints tun können.

Noch ein Tipp, was Sie tun können: Stellen Sie die Arbeitszeiten nicht in Frage, versuchen Sie nicht, sie zu "managen", indem Sie ihnen sagen, wie viel Zeit sie für dieses oder jenes brauchen. Fragen Sie sie stattdessen wie sie wollen dies oder jenes erreichen, welche Lösungen die sie nutzen wollen und warum? Es ist ziemlich üblich, dass gute Geeks dazu neigen, zu viel zu entwickeln - wenn die Dinge viel größer aussehen, als Sie erwartet haben, gibt es hier wahrscheinlich ein Missverständnis darüber, was gebaut werden soll, das geklärt werden muss.