Um es kurz zu machen, wir bauen ein Produkt und ich habe das Scrum-Framework für das Produktmanagement eingeführt und dann implementiert. Es hat sehr gut funktioniert und mein Team hat großartige Arbeit geleistet.
Das Problem, das ich jetzt habe, ist, dass der Hauptbeteiligte allmählich so hungrig nach Funktionen wird, dass die Qualität der Ergebnisse durch eine erhöhte Anzahl von Elementen im Sprint beeinträchtigt wird.
Jedes Mal, wenn wir einen guten Job machen, dh den Sprint erreichen, fragt der Stakeholder in der folgenden Woche nach weiteren Features. Er ist der Meinung, dass wir in der folgenden Woche mehr Arbeit erledigen können, weil wir den Sprint erreicht haben.
(Im Moment möchte er 3 Features pro Woche geliefert bekommen)
Das muss mein Team dann mit einer höheren Velocity ausgleichen. Irgendwann ist es an einem Punkt angelangt, an dem wir in einem Sprint mit der Küchenspüle konfrontiert wurden und von denen erwartet wird, dass sie im Vergleich zu früheren Sprints die dreifache Menge an Funktionen liefern. Aufgrund der erhöhten Geschwindigkeit bedeutet dies auch, dass mehr Fehler von Funktionen auftauchen, die in die Produktion überstürzt werden.
Ich bin jetzt in einer Situation, in der wir mit unseren Sprints ins Hintertreffen geraten, und meine Kollegen sich darüber beschweren, dass die Arbeitsbelastung zu hoch ist. Ich bekomme auch viel mehr Ärger von den Beteiligten, weil ich nicht alle versprochenen Arbeiten erledigt habe. Bei unserem nächsten Teammeeting denke ich darüber nach, mit meinem Stakeholder und dem Entwicklerteam darüber zu sprechen, ist das eine gute Idee?
Wie kann ich damit umgehen?
Eigentlich muss ich David Espina teilweise widersprechen. In Scrum ist es wichtig zu verstehen, wem welcher Teil des Prozesses gehört.
Indem Sie den PO (oder, schlimmer noch, einen Stakeholder) vorgeben lassen, was es zu einem Sprint macht, verringern Sie die Effektivität des Teams und setzen die Qualität Ihrer Arbeit aufs Spiel, wie Sie bereits in Ihrem Beitrag angemerkt haben. Das soll nicht heißen, dass der ScrumMaster oder Product Owner das Team nicht ermutigen kann, mehr zu übernehmen oder es sogar zu einem aggressiven Sprint Commit zu führen, aber niemand außer dem Team kann ein Element in das Sprint Backlog schreiben.
An Ihrer Stelle würde ich mir etwas Zeit nehmen, um Stakeholdern und POs zu erklären, hey, schauen Sie sich an, wie viel mehr wir mit Scrum erledigen – Sie können nicht in jedem Sprint ein Wunder erwarten. Die Geschwindigkeit wird im Allgemeinen zunehmen, aber manchmal auch abnehmen (ob das Team beispielsweise eine schlechte Schätzung macht oder etwas eine „schwere“ 8 anstelle einer „leichten“ 8 ist). Ich würde ihnen sagen, dass wir das lassen müssen Das Entwicklungsteam tut, was es am besten kann, und vertraut darauf, dass das Team so viel wie möglich für einen Sprint einsetzt, ohne die Qualität der bereitgestellten Funktionen zu gefährden.
Ich bin mir nicht ganz sicher, wer Ihr Team vorantreibt. Sie oder der Stakeholder?
1: Offensichtlich muss jedes Team ständig ermutigt und herausgefordert werden, um mehr zu erreichen und produktiver zu werden.
2: Offensichtlich sind Fristen unabhängig davon, was Scrum sagt, wichtig, wenn Sie bezahlt werden möchten.
Aber! Das Entwicklerteam sollte die Aufgaben im Rückstandsprotokoll schätzen, und die Geschwindigkeit aus dem vorherigen Sprint sollte Ihnen eine Schätzung darüber geben, wie viele Aufgaben im nächsten Sprint enthalten sind.
Wenn das Team unter Druck gesetzt wird, niedrigere Schätzungen vorzunehmen, ändert dies nicht die geleistete Arbeit, sondern nur die Geschwindigkeitszahl.
Wenn der Stakeholder mit mehr Features und vielleicht weniger Tests oder weniger Details zu jedem Feature zufrieden ist, dann ist das seine Entscheidung und sollte sich in den Geschichten widerspiegeln. Wir alle wissen, dass die letzten 10 % einer Geschichte normalerweise 90 % der Zeit in Anspruch nehmen.
Wenn Sie oder der Stakeholder das Team direkt unter Druck setzen, härter oder schneller zu arbeiten oder länger zu arbeiten, ist dies nur eine Frage des Managements, ob Sie der Meinung sind, dass sie nachlassen oder nicht.
Ihr Scrum Master sollte das Team jedoch vor dieser Art von direkter Interaktion mit dem Stakeholder schützen.
Die Messlatte höher zu legen ist eine gute Sache. Sie sollten sich dahinter stellen und weiter auf mehr drängen. Das Hinzufügen von Herausforderungen zu einem Team führt dazu, dass das Team herausfindet, wie es diese Herausforderungen bewältigen kann, und oft schafft ein sehr pessimistisches Team, das vorhersagt, dass es nicht machbar ist, es. Irgendwie passen sich Teams an und innovieren.
Sie mindern auch Dinge wie das Parkinson-Gesetz und das Studentensyndrom, wenn Sie ständig ein Team herausfordern, das glaubt, dass „es nicht geht“.
Und ich stimme zu, dass dies nicht ohne Kosten und Risiko ist. Sie müssen diese Dinge überwachen und die Teammoral, Probleme mit der Fehlerdichte, Beschwerden von Stakeholdern, wenn ihre Erwartungen nicht erfüllt werden, usw. beobachten. Ich denke jedoch, dass Sie überrascht wären, wie viele dieser Kosten und Risiken nicht wirklich eintreten, wenn Sie darüber nachdenken Sie würden.
Es ist interessant, Werte und Stakeholder-Erwartungen zu planen. Planen Sie 2 Funktionen ein und erreichen Sie diese in einem bestimmten Zeitraum. Planen Sie für 4 und erhalten Sie 3 im gleichen Zeitraum. Als erstes hast du ein Ziel erreicht. Beim zweiten hast du dein Ziel verfehlt. Aber was ist eigentlich besser?
BEARBEITEN: Zum Kommentar von @ bobo2000: Ich würde erwarten, dass es einen Punkt mit abnehmenden Renditen geben würde. Nach meinen Beobachtungen liegt dieser Punkt weiter entfernt, als viele glauben oder vorhersagen. Wenn Sie jedoch glauben, dass Sie an diesem Punkt angelangt sind, müssen Sie sich wirklich damit anfreunden, Ihrem Kunden „Nein“ zu sagen. Wenn Sie sich entscheiden, Ja zu der Herausforderung zu sagen, müssen Sie die Risiken, die Sie sehen, auf sehr formelle und laute Weise eskalieren, z. B. ist es sehr wahrscheinlich, dass wir in diesem Sprint nicht alle Ziele erreichen, oder wir sehen wahrscheinlich einen Anstieg Sev 1 und 2 Defekte gehen herum. Irgendwann müssen Sie damit beginnen, das Gespräch zu kontrollieren. Ihr Kunde wird drängen und drängen, weil er es aus der Sicht der „Maximierung des Nutzens für jeden ausgegebenen Dollar“ betrachtet. Sagen Sie nein und eskalieren Sie das Risiko. Das gehört zu deinem Job als PM! Viel Glück.
@Rubberduck: Erhöhte Fehler und versäumte Fristen können bedeuten, dass Sie die Kapazität erreicht haben, wenn Sie genügend Beobachtungen haben, um normale Ursachen auszuschließen. Andernfalls haben Sie möglicherweise ein falsches Positiv. Beide werden durch viele stochastische Treiber wahrscheinlichkeitsgetrieben. Die Zunahme von Defekten allein sagt nicht viel aus. Wenn eine Fehlerquote von 10 % erwartet wurde, haben sie eine Leistung von beispielsweise 4 % erzielt und steigen dann auf 6 %. Deutet dies auf eine Überkapazität hin?
Und Ihr Kommentar zu Vertrauen und Prozess ist genau mein Punkt. Wenn ein Team seine Kapazität verbessern kann, indem es seine Verfahren verbessert, dann war es von Anfang an nicht in der Kapazität.
Teams können sich durch Innovation an Herausforderungen anpassen. Wenn Sie keine Herausforderung erzwingen, werden Teams nicht innovativ sein oder sich anpassen. Tatsächlich bauen sie ... Parkinson ab!
MeisterPJ
Jeff Lindsey