Ist eine starke Geschwindigkeitssteigerung in einer Scrum-Umgebung realistisch?

89

Mein Manager hat in letzter Zeit wirklich versucht, Geschwindigkeit als Ziel und Maß für die Produktivität zu verwenden. Wir arbeiten derzeit mit einer Durchschnittsgeschwindigkeit von 50 Story Points. Mein Manager möchte, dass wir ihn um 40% auf 70 Story Points erhöhen (ohne Erhöhung der Teammitglieder). Wenn wir diese Steigerung nicht erreichen, möchte er, dass wir eine vollständige Aufschlüsselung liefern und erklären, warum.

Die ganze Idee, die Teamleistung an der Geschwindigkeit zu messen und als Ziel zu verwenden, scheint mir falsch, aber ich finde es schwierig zu erklären, warum. Irgendeine Hilfe? Warum ist dies nicht der richtige Weg, um die Produktivität zu messen und Anreize zu setzen?

P2l
quelle
19
Beeindruckend. Der Manager versteht entweder nicht, was Geschwindigkeit ist, oder er glaubt, dass das Team nachlässt. oder beides. Bei der nächsten Planungssitzung sollten Sie sich auf 70 Punkte festlegen und sich vom Team über die Ausfallrisiken informieren lassen
Steven A. Lowe,
25
Es scheint eine so dumme Bitte zu sein, dass ich Sie bitten möchte, ihn zu fragen, warum er dies für möglich hält. Wenn Sie bereits 100% geben, erwartet er, dass Sie 140% geben? Was ist, wenn Sie nur 40% länger sprinten?
Jonathan Rich
20
Die Geschwindigkeit soll ein Maß dafür sein, wie schnell Sie Dinge erledigen können. Wenn Ihre Geschwindigkeits- und Story-Punkte überhaupt genau sind, bedeutet dies, dass Sie nicht den gesamten Rückstand bis zum Stichtag fertigstellen können. Das Vernünftigste ist, die Realität zu akzeptieren und entweder Dinge aus dem Rückstand herauszuschneiden oder Prioritäten zu setzen, damit das, was Sie tun, das wichtigere ist. Oder Sie können die Frist auf etwas Realistisches ändern.
Michael Shaw
45
Bitten Sie ihn um eine Gehaltserhöhung von 40%, wenn Sie diese Ziele erreichen. Erhöhen Sie dann Ihre Schätzungen, damit Sie die Erhöhung um 40% erhalten.
Mattnz
18
Ist das nicht eher so, als würde man einen Marathonläufer bitten, den Marathon plötzlich in 1h25m anstatt in 2h zu laufen?
Scroog1

Antworten:

158

Nun, es ist ganz einfach, die Geschwindigkeit um 40% zu erhöhen - fügen Sie einfach 40% mehr Punkte zu all Ihren Schätzungen hinzu und erledigen Sie die gleiche Menge an Arbeit.

In Anbetracht dessen sollte es offensichtlich sein, warum die Verwendung von Geschwindigkeit als Ziel falsch ist, sondern lediglich zu überhöhten Schätzungen anregt.

Eine weniger glatte Antwort ist, dass Ihre Schätzung bereits davon ausgeht, dass Sie so schnell wie möglich fahren, während Sie alles richtig machen. Die einzige Möglichkeit, die Produktivität um 40% zu steigern, besteht darin, entweder Überstunden zu leisten oder nicht alles richtig zu machen. Beides beschleunigt die Dinge kurzfristig, verlangsamt sie aber langfristig. Und die Langzeit in diesem Fall ist nicht sehr lang, ein Monat nach außen. Die optimale langfristige Strategie besteht darin, niemals schneller als in Ihrem nachhaltigen Tempo voranzukommen.

Peopleware spricht eloquent über die Probleme, Programmierer zu höherer Produktivität zu zwingen, und ist ein häufig zitierter Klassiker. Aber im Allgemeinen wird es nicht einfach sein, die Meinung eines Managers zu ändern, der den Weg einschlägt, den Sie gehen. Ihr Projekt ist möglicherweise in Schwierigkeiten - dies ist sicherlich eine rote Fahne.

bA
quelle
28
Ich bin der festen Überzeugung, dass es kein "schnelles und schmutziges" gibt. "Dirty" macht mich immer langsam - auch kurzfristig.
Doc Brown
1
@Paul - ich fand es gut. Die darin enthaltenen Ratschläge können jedoch meist nur von Managern befolgt werden, und diejenigen, die davon profitieren könnten, werden sie wahrscheinlich nicht lesen. Auch wird das Lesen nicht unbedingt das Verhalten ändern.
PSR
2
Und wenn Sie zustimmen und die Geschwindigkeit wirklich um 40% steigern, wird es für andere so aussehen, als ob Sie und Ihr Team nicht in Bestform gearbeitet haben. Die professionelle Art, damit umzugehen, ist eine klare Antwort: "Nein, geht nicht." Eine weitere Referenz zum Buch: "The Clean Coder" von Robert C. Martin.
Pablosaraiva
1
"Ihre Schätzung geht bereits davon aus, dass Sie so schnell wie möglich fahren, während Sie alles richtig machen." Dies ist wahrscheinlich eine falsche Annahme. Wir können uns immer weiter verbessern und optimieren. Die Teams sollten niemals davon ausgehen, dass ihre stabile Geschwindigkeit anzeigt, dass sie nicht besser werden können. Sie müssen jedoch ihren gesamten Prozess systematisch betrachten und nach geringfügigen Prozessverbesserungen suchen.
Curtis Reed
53

Wie die Kommentare gezeigt haben, ist die Anfrage offensichtlich falsch, wie sie gestellt wurde. Aber es ist nicht wirklich falsch, die Produktivität ständig verbessern zu wollen. In der Regel streben Manager dies an (und werden bewertet).

Manager sind jedoch stets bemüht, die Leistung zu verbessern, und bei Scrum und Agile geht es vor allem darum, anpassungsfähig zu sein. Während Geschwindigkeit ein Maß für Ihr aktuelles nachhaltiges Tempo ist, sollten Sie sich nicht auf Ihren Lorbeeren zurücklehnen. Scrum hat einen Ort zum Bewerten und Ändern dessen, was in Ihrem Prozess funktioniert und was nicht: die Retrospektive. Wenn Sie dies ausnutzen und Ihren Prozess anpassen, sollte die Produktivität (und möglicherweise die Geschwindigkeit) steigen.

Suchen Sie (in Ihren Rückblicken) nach Möglichkeiten, um als Team produktiver zu werden? Gibt es irgendetwas in Ihren Sprints, das regelmäßig einen unverhältnismäßigen Aufwand verursacht? Kann es angesprochen werden? Es wird Ihnen wahrscheinlich keine 40% ige Steigerung bringen, aber 5-10% sind ein Anfang, nicht wahr? Bei jedem Sprint sollten Sie nach Engpässen suchen und diese beheben. Möglicherweise nähern Sie sich dem Ziel, das er Ihnen gesetzt hat.

Matthew Flynn
quelle
7
+1: Dies ist ein guter Weg, um es dem Manager zu beschreiben. Sie können die Geschwindigkeit nicht künstlich erhöhen, aber Sie können nach jedem Sprint zurückblicken und lernen, was Sie tun können, um beim nächsten Sprint effizienter zu werden.
Kevin
3
Es besteht die Wahrscheinlichkeit, dass Sie durch das Entfernen des Verwaltungsaufwands (erzwungene Besprechungen, Ausfüllen von Formularen usw.) diese 5-10% leicht erreichen. Aber wie kann man ihn überzeugen?
AviD
2
Ich denke, Ihre Antwort ist ein Missverständnis der Geschwindigkeit. Es ist keine absolute Metrik, sondern ein Durchschnitt über die Laufzeit des Projekts. Was mehr ist, sind Geschwindigkeitspunkte selbst keine geleistete Arbeit, sondern grobe Maßeinheiten für die Komplexität. Sie sind auch Durchschnittswerte selbst, und eine Niedrigpunktaufgabe kann mehr Zeit als eine Hochpunktaufgabe erfordern. Es erscheint ein wenig bedeutungslos, nach "mehr" zu fragen, und stellt ein grundlegendes Missverständnis dar. Der Manager fordert grundsätzlich eine feste Frist.
Ricardo Gladwell
3
@RicardoGladwell - Als ich sagte "die Anfrage ist offensichtlich falsch", gab ich zu, dass dies ein falsches Verständnis dafür ist, wie Story Points funktionieren. Ich habe lediglich vorgeschlagen, dass der Manager wirklich eine Verbesserung der Produktivität für das Team wünscht, und Scrum bietet ein Mittel, um dies zu erreichen. Außerdem gibt es unterschiedliche Einstellungen zu den Story Points - Komplexität ist eine der häufigsten. Die meisten Teams, mit denen ich zusammengearbeitet habe, haben dafür gesorgt, dass sie in gewissem Maße mit der Anstrengung übereinstimmen. Eine einfache Aufgabe mit viel Quantität gilt nicht mehr als einfach.
Matthew Flynn
1
Sie erwähnen zwar, dass eine Geschwindigkeitssteigerung von "5-10% ist ein Anfang", aber dies scheint das Missverständnis des Managers darüber zu teilen, was "zunehmende Geschwindigkeit" bedeutet, das ich skizziert habe.
Ricardo Gladwell
26

TL; DR

Velocity ist sehr nützlich für die Schätzung von Zeitplänen oder die Generierung von Planungswerten und kann auch eine sinnvolle Detektivkontrolle für die Beurteilung von Prozessengpässen oder Änderungen der Teamkapazität sein. Es ist jedoch kein gültiges Maß für die Produktivität.

Wenn Geschwindigkeit mit Managementzielen verwechselt wird

"Geschwindigkeit" ist ein Bereich, der die durchschnittliche Kapazität eines Teams über einen historischen Zeitraum angibt. Hierbei handelt es sich um eine statistische Analyse der Leistung in der Vergangenheit, mit deren Hilfe probabilistische Schätzungen der zukünftigen Arbeitslastkapazität oder Zykluszeiten erstellt werden können. Dies steht in krassem Gegensatz zu einem "Planungsziel", bei dem es sich um ein Führungsziel handelt, das einen Zeitplan oder ein Ziel für Planungszwecke festlegt.

Erfahrene agile Projektmanager wissen, dass es wichtig ist, mit der richtigen Geschwindigkeit zu bestimmen, ob ein Team die nachhaltige Fähigkeit besitzt, vom Management festgelegte Planungsziele zu erreichen. Manchmal lautet die Antwort ja und alle sind glücklich. Manchmal ist die Antwort nein, an welchem Punkt die eisernen Dreieck Kräfte Geschäftsentscheidungen über Umfang, Kosten, Zeit und Qualität.

Bewerten Sie Ihre politischen Optionen

Wir haben eine Durchschnittsgeschwindigkeit von 50 Story-Punkten ... Ich wurde gebeten, diese um 40% auf 70 Story-Punkte zu erhöhen (ohne Erhöhung der Teammitglieder).

Unter der Annahme, dass Ihre Schätzpraktiken solide sind und Ihre Geschwindigkeit einigermaßen stabil ist, wird Ihr Manager keine Freude daran haben, den Schätzmaßstab anzupassen oder Verwaltungsziele festzulegen, die nicht auf der historischen Leistung basieren. Wie Sie richtig hervorheben, handelt es sich grundsätzlich um ein Kapazitätsproblem .

Das Kapazitätslimit hängt möglicherweise von der Anzahl der Personen in Ihrem Team ab, oder es kann eine Einschränkung Ihrer organisatorischen Prozesse sein. Wenn Sie mehr Leute hinzufügen, erhöht sich natürlich auch nicht immer die tatsächliche Projektkapazität. Weitere Informationen zu diesem häufigen Missverständnis finden Sie im Brooks'schen Gesetz .

Das Problem, mit dem Sie konfrontiert sind, ist politisch. Nach dem Tonfall Ihres Beitrags scheint es, als wolle Ihr Manager eine Produktivitätssteigerung sehen, ohne die zugrunde liegende Kapazität des Teams tatsächlich zu ändern. Die Lösungen sind daher auch politischer und größtenteils pädagogischer Natur.

Wenn Sie ein Scrum-Shop sind, bitten Sie Ihren Scrum-Master, dieses Problem über die entsprechenden Framework-Kanäle zu beheben. Rückstandsbereinigung und Sprint-Rückblicke sind häufig die idealen Inspektions- und Anpassungsmöglichkeiten für dieses spezielle Problem.

Wenn Sie kein Scrum-Shop sind, müssen Sie entscheiden, wie Sie Ihre Anliegen in Ihrem Unternehmen richtig ansprechen können. Wenn Sie gute Beziehungen zu Ihrem Vorgesetzten haben, können Sie ihm sogar eine Kopie von Agile Estimating and Planning leihen, die Sie beide beim Mittagessen besprechen können.

Wenn alles andere fehlschlägt, bereiten Sie sich auf einen Todesmarsch vor, indem Sie Ihren Lebenslauf auffrischen und Ihr Bestes geben, bis das Projekt zum Erliegen kommt. 68% der IT-Projekte schlagen fehl ; Wenn die Managementziele nicht auf organisatorischer Basis festgelegt sind, gehören Sie wahrscheinlich dazu.

CodeGnome
quelle
Qualität ist keine Anpassungsvariable: Deshalb sprechen wir vom Eisendreieck, nicht vom Eisenquadrat. Mit anderen Worten, wenn jemand versucht, die "Qualität" zu verringern, kann dies zu Verzögerungen (längeren Lieferungen), zum Umfang (Funktionen funktionieren nicht und werden daher nicht realisiert) und zu Ressourcen (Entwickler sind frustriert und gehen) führen. Nette Antwort neben diesem winzigen Punkt.
kriss
1
@kriss Qualität kann in der Tat ein Teil des Dreiecks sein. Es wird manchmal als Teil des "Umfangs" betrachtet, oder in einigen Dreiecken ist es ein tatsächlicher Eckpunkt, der anzeigt, dass es eine primäre Einschränkung ist. Sehen Sie sich das blaue Dreieck im PMBOK Star als konkretes Beispiel oder die Entwicklung des Projektbeschränkungsmodells für einige Details zu diesem Problem an. Bitte bringen Sie dies auf PMSE für mehr.
CodeGnome
Dies ist eine Diskussion, die ich bereits mit anderen Agilisten geführt habe. Zusammenfassend kann man nicht sagen, dass PMBOK eine gültige Agile-Ressource ist. Es entstand mit dem Wasserfallmodell und ist orthogonal zu agil. Es ist größtenteils kompatibel, aber es gibt immer noch einige Probleme. Qualität als Anpassungsvariable zu betrachten, ist eine davon. Aus meiner Sicht (und ich bin nicht allein) unter Verwendung von Quality als Anpassungsvariable wird der gesamte Agile-Prozess unterbrochen. Aber es sollte eine Frage für sich sein.
kriss
Frage hier gepostet pm.stackexchange.com/questions/11489/…
kriss
21

Ich verstehe nicht, welche Rolle Ihr Manager im Scrum-Team hat? Ist er ein Trainer? Ist er ein Produktbesitzer?

Wenn er wie ein Trainer oder so im Team ist (er arbeitet an einer Entwicklungsaufgabe), können Sie ihn fragen, warum er seine eigene Produktivität unterbewertet, weil es den Anschein hat, dass dies bei anderen Teammitgliedern nicht der Fall war. Wenn er glaubt, dass er mit jeder Iteration 30 Story Points mehr annehmen kann, sollte er es zeigen.

Wahrscheinlicher: Er ist außerhalb des Teams, vielleicht der Product Owner? Wenn ja, sollte er verstehen, wie man so eine dumme Bitte stellt, hat er einfach die Beweglichkeit gestoppt.

Eine Grundregel ist, dass der Product Owner das Ziel festlegt, während das Team festlegt, was in einer Iteration getan werden kann. Andernfalls entsteht der klassische und bekannte Eisenkreis: Ressourcen, Geschwindigkeit, Merkmale. Wähle zwei aus! Sie können nicht drei auf einmal auswählen (und denken Sie daran: Qualität ist keine Anpassungsvariable. Wenn Sie versuchen, Ecken durch schlechte Qualität zu schneiden, wird die Situation noch schlimmer).

Wenn er das aktuelle Ziel nicht ändern möchte, kann eine Produktivitätssteigerung von 40% erreicht werden, indem mehr Mitarbeiter für das Team eingestellt werden. Vielleicht in ein Training für einige Teammitglieder investieren? Teams können auch durch kontinuierliche Verbesserung an Geschwindigkeit gewinnen, aber sicher nicht durch willkürliche Entscheidung.

Der Versuch, die Geschwindigkeit eines Teams zu ändern, ist wie der Versuch, die Größe eines Raums zu ändern. Es kann getan werden, aber im Grunde müssen Sie den Raum ändern.

Haben Sie keinen Scrum Master oder andere Leute mit Grundkenntnissen über Scrum, die ihm das erklären könnten?

kriss
quelle
15

In diesem Fall hat der Manager die falsche Richtung eingeschlagen, nachdem er vom Team eine ehrliche und glaubwürdige Schätzung erhalten hat. Der Manager soll sich an den Stakeholder wenden und ihm mitteilen, dass seine Anforderungen nicht in der gewünschten Zeit erfüllt werden können. Der Manager / Analyst sollte dann priorisieren, welche der Funktionen enthalten sein MÜSSEN, und die anderen, die warten können (wenn auch nur ein paar Wochen). Wenn der Stakeholder unvernünftig ist, müssen möglicherweise höhere Manager einbezogen werden, was im Allgemeinen eine Herausforderung darstellt und eine ganze Reihe weiterer Diskussionen erfordert.

Wenn ich in den Schuhen würde ich mit einem detaillierten Fall kommen, warum das Projekt IST so lange dauern würde als geschätzt. Versuchen Sie auch, Artikel mit geringer Rückgabe zu identifizieren. Suchen Sie die Elemente, die nicht viel Wert hinzufügen und einen erheblichen Programmieraufwand erfordern, und machen Sie sich dafür stark, diese aus dem Sprint zu entfernen. Überlegen Sie sich auch einen iterativen Ansatz, der "X" am "Y" -Datum liefert, und stellen Sie sicher, dass er machbar ist. Überlegen Sie sich dann eine Folge-Iteration, mit der sie die verbleibenden Elemente erhalten.

Grundsätzlich muss jemand dem Stakeholder mitteilen, was er zum Stichtag erwarten kann und dass die Mehrheit seiner Anforderungen darin enthalten ist. und dass sie in der folgenden Version die restlichen Elemente haben werden. Wenn der Kunde so unvernünftig ist, muss das obere Management einbezogen werden, und der Manager sollte in der Lage sein, dies zu erreichen.

Wenn der Kunde jedoch zu viel versprochen hat und bis jetzt noch niemand etwas gesagt hat, wird es ein harter Kampf. Dies ist leider keine ungewöhnliche Situation.

Hanzolo
quelle
1
"Ehrliche und treue Einschätzung" kann das Problem sein.
JeffO
@JeffO - Könnte sein, das ist der Grund, warum ich empfohlen habe, die Schätzungen zu begründen. Wenn sie versuchen, dies zu tun, werden sie entweder feststellen, dass sie ihre Schätzungen aufgeblasen haben oder dass sie wirklich nicht über die Kapazität verfügen
hanzolo
9

Es hört sich so an, als stünden Sie vor zwei Problemen.

Der Teil der Geschwindigkeitsmessung, der Sie stört, ist wahrscheinlich, dass die Messung die Kosten sind . Was Sie wirklich verbessern möchten, ist der Wert . Leider ist das Messen des Werts von Software bekanntermaßen schwierig und subjektiv. Dennoch kann auch eine unvollständige und subjektive Metrik nützlich sein. Es könnte sein, dass das eigentliche Problem nicht darin besteht, dass Ihr Team mehr Code schreiben muss, sondern dass die Geschichten wertvoller sein müssen.

Das andere Problem ist, dass Ihr Manager basierend auf Ihrem Konto eine Produktivitätssteigerung von 40% erwartet hat. In Ihrer Frage wurde der Kontext dieser Anfrage nicht angegeben. Es könnte ein gutmütiger Wunsch sein, dass sich Ihr Team verbessert. Oder es könnte ein nicht so subtiler Hinweis darauf sein, dass Ihr Manager der Meinung ist, dass Ihr Team unterdurchschnittliche Leistungen erbringt.

Bearbeiten: Basierend auf Ihrem Kommentar sieht die Situation schlecht aus. Es hört sich so an, als ob Ihr Unternehmen die Grundlagen dafür legt, dass Sie und Ihr Team (möglicherweise auch Ihr Manager) entlassen werden. Ich schlage vor, dass Sie sich nach einem anderen Job umsehen.

Aaron Kurtzhals
quelle
3
Leider war es eine ernsthafte Anfrage, die so formuliert ist, dass ich keinen Grund sehe, warum Sie dies nicht erreichen können (aber ich werde Ihnen nicht sagen, wie!). Die Implikation ist also, dass er nicht glaubt, dass sie hart genug arbeiten oder nicht so kompetent sind, wie sie sein sollten. Es wurde dann schlimmer, als ich im Urlaub war und der Product Owner dem Team sagte, dass es ernsthafte Auswirkungen geben würde, wenn sie es nicht erreichen würden. So habe ich jetzt auch ein sehr besorgtes Team (von dem ich wirklich glaube, dass es ein tolles Team ist), um das ich mich auch sorgen muss.
P2l
4
+1 für "Raus aus dem Ausweichen". Manchmal ist es der einzige Weg (je weniger, desto besser).
Michael
9

Entlasse ihn. Das heißt, gehen Sie über den Kopf und erklären Sie, dass er das Vertrauen seines Teams verloren hat, und erklären Sie, dass er für das Geschäft keinen Wert hat. Erklären Sie, dass Manager mit dieser Inkompetenz viel einfacher zu ersetzen sind als das unten stehende Team.

Es gibt keinen guten Grund, sich mit einem solchen Manager abzufinden, aber das sollte nicht automatisch bedeuten, dass die Entwickler zurücktreten sollten. Mit dem Geschäft stimmt nicht unbedingt etwas nicht, nur mit dieser einen Person. Beheben Sie das Problem.

Machen Sie klar, dass dies kein verzeihbarer Fehler ist, um ein Schweigen des oberen Managements zu verhindern. Es zeigt an, dass der verantwortliche Manager kein Verständnis für das Team hat, das er leitet. Das eignet sich weder zur Festsetzung, noch besteht auf dem derzeitigen Arbeitsmarkt ein Bedarf. Manager sind wie Sporttrainer hervorragend austauschbar. Besitzer feuern keine Teams.

Nun könnte dies wie eine Strategie aussehen, die nach hinten losgehen kann. Bedenken Sie jedoch, dass Sie ohnehin schon in einer Verlustposition sind, wenn das obere Management mit Ihrem Manager zusammentrifft. Wenn Sie also nur die Situationen berücksichtigen, in denen Sie noch nicht in dieser Verlustposition sind, ist das Ergebnis wahrscheinlich weitaus positiver. Das eigentliche Risiko besteht darin, dass das obere Management nur das gesamte Team einschließlich des Managers entlässt. Nur Sie können dieses Risiko einschätzen. Anscheinend ist Ihre Ausgabe erwünscht, sonst würden sie nicht mehr verlangen, aber zu welchem ​​Preis?

MSalters
quelle
5
Mit anderen Worten, heben Sie Ihre Hände in die Luft, jammern Sie und werfen Sie einen Anfall. Diese Einstellung löst niemals Probleme. Es gibt viel bessere Möglichkeiten, mit der Situation umzugehen.
MrFox
Nein. Jammern oder Anfälle sind dramatische Handlungen. Das kann ignoriert werden. Was ich vorschlage, ist ein Ultimatum. Entweder geht dieser Manager oder das Team geht. Kein Drama, nur kalte Geschäftslogik. Er ist nicht fit für den Job, und es ist die Aufgabe des oberen Managements, darauf zu reagieren. Ihre bevorzugte Option ist es jedoch, die Situation zu ignorieren, wenn Sie dies zulassen. Deshalb müssen Sie diese Wahl aufheben.
MSalters
@ Nathanhayfield Typisch? Ich denke, das Team würde sich aus einer Reihe von Persönlichkeiten und Menschen zusammensetzen. Faulen sollte individuell keine pauschale Anfrage an das Team gerichtet werden.
James Khoury
1
@MSalters Es gibt viele Leute in verschiedenen Geschäftsbereichen, die bestimmte Dinge nicht verstehen. Der richtige Ansatz besteht darin, Konflikte abzumildern und alle Beteiligten zu erziehen. Vielleicht versteht dieser Manager Agile nicht, aber er hat möglicherweise andere einlösende Eigenschaften (die viel wichtiger sein könnten). Als Profi sollten Sie aus jeder Situation das Beste machen und mit jeder Art von Persönlichkeit arbeiten - denn das ist langfristig tatsächlich konstruktiv und hilfreich. Das zu tun, was Sie vorschlagen, lässt sich nicht skalieren.
MrFox
3
@ MrFox: Direkte Manager sollten die Planung verstehen. Tatsächlich sind sie die Schicht, die am unmittelbarsten dafür verantwortlich ist. Die Teammitglieder sollen Fachexperten sein, und das übergeordnete Management ist weiter von der Aktion entfernt. Also dieser Manager, in einer Position , wo er ist , Behauptungen über Zeitpläne zu machen, beweist , dass er nicht versteht , was vielleicht Aufgabe seiner wichtigsten ist. Wenn der Arbeitsmarkt eng war, könnte es schwierig sein, einen besseren Manager zu finden. Aber heute kannst du jemanden finden, der besser ist.
MSalters
6

Ich habe die Erfahrung gemacht, dass es sehr, sehr schwierig war, die tatsächliche Geschwindigkeit eines Teams zu erhöhen , da weder das Team noch die Problemdomäne oder der Technologie-Stack geändert wurden.

Wo ich Zuwächse erzielen konnte, war es eine Frage von:

  • technische Schulden bereinigen; Sicherstellen, dass alles in der richtigen (nicht unbedingt neuesten!) Version ausgeführt wird, dass der Code gut faktorisiert ist und dass keine Redundanz im System vorhanden ist (doppelter Code, nicht verwendeter Code usw.)

  • Verbesserung der Praktiken; Paarung wo möglich (ja, ich habe festgestellt, dass dies die Geschwindigkeit erhöht), sich die Zeit nimmt, aggressiv umzugestalten (ebenso!) und skrupellos in Bezug auf Umfang und Fokus ist

  • Finden und / oder Kaufen der besten Tools für den Job (z. B. ReSharper für .NET ist Gold wert, Airbrake und Splunk für Ruby-Entwicklung usw.)

Ich stimme anderen hier zu, die sagen, dass Ihr Manager, der nach einer willkürlichen Geschwindigkeitssteigerung fragt, eine rote Fahne ist. Ich würde einen anderen Job als eine hohe Priorität suchen.

Duncan Bayne
quelle
3

Ihr Manager fordert Ihr Team auf, zusätzliche Stunden zu arbeiten. Während das Entfernen von Engpässen und das Erhöhen der Effizienz Ihre Geschwindigkeit etwas verbessern kann, können Sie diese Steigerung (40%) nur erzielen, indem Sie länger arbeiten, da Sie in diesem Zeitraum mehr Arbeitseinheiten einsetzen müssen.

Nehmen wir ein Szenario.

Für eine zweiwöchige Interaktion sagen wir 10 Tage. Die Utopie würde 8 Stunden pro Tag betragen, wobei ein Story-Point zu einem Arbeitstag abstrahiert würde. Von oben gesehen wäre Ihre Geschwindigkeit also 8. Relistisch gesehen erreichen die Leute mit E-Mails, Besprechungen, Pausen im Badezimmer usw. in 6 guten Stunden pro Tag. Angenommen, Sie möchten, dass die Mitarbeiter Überstunden leisten, und zwar jetzt bei 10 Stunden pro Tag. Das wären also 10 Geschwindigkeitspunkte pro Entwickler.

Ihre Geschwindigkeit wird immer schwanken, vielleicht war sie niedrig, weil Sie während dieser Iteration mit vielen Fehlern zu kämpfen hatten, vielleicht fehlten die Voraussetzungen, vielleicht wurde jemand für ein paar Tage krank. Vielleicht war es hoch, weil die Arbeit überschätzt wurde oder Ihr Team zusätzliche Stunden aufgewendet hat.

Aber wenn Sie in einem Stall 50 sind, brauchen Sie zusätzliche Stunden, um wirklich 70 zu erreichen.

Jon Raynor
quelle
2

Das Problem mit der Geschwindigkeit ist, dass es sich um eine abhängige Variable handelt, eine gemessene Ausgabe Ihres Entwicklungsprozesses. Die Forderung, die Geschwindigkeit um 40% zu erhöhen, ist wie der Versuch, schneller zur Arbeit zu kommen, indem man die Autos anschreit, schneller zu fahren. Die Geschwindigkeit erhöht sich, indem mehr Kraftstoff und Luft in den Motor geleitet oder ein schnelleres Auto gefahren wird und eine Route mit weniger Verkehr gefunden wird.

Wenn Sie länger arbeiten, erhöht sich die Geschwindigkeit nicht, wenn Sie sie richtig messen, beispielsweise in Feature-Punkten pro Entwicklerstunde. Dies funktioniert nur, wenn Sie Punkte pro Tag messen und dann neu definieren, was ein "Tag" in der Mitte der Messung ist. Dies liefert nur die Illusion von Geschwindigkeit.

Eine Erhöhung der Geschwindigkeit erfordert die Verbesserung der unabhängigen Variablen im Entwicklungsprozess. Schnellere Computer und Compiler, effizienteres Build-System, besserer Designprozess, fähigere Entwickler, besserer Arbeitsbereich, überragende Motivation. Eine Verbesserung um 40% würde sehr bedeutende Änderungen erfordern.

Fragen Sie, ob Ihr Manager in Erwägung ziehen würde, Ihr Team in geschlossenen Büros in einem gemeinsamen Arbeitsraum unterzubringen, die brandneue Entwicklerhardware des Teams zu kaufen oder ein paar wirklich hochrangige Entwickler einzustellen, um das Team zu betreuen, wenn ihm dies 40% bringen würde. Wenn keine Ressourcen zur Verfügung stehen, um die Eingaben für Ihren Entwicklungsprozess zu verbessern, schließt dies ein ernsthaftes Interesse an Verbesserungen aus. Dies überlässt Ihrem Manager das Reverse Engineering, um herauszufinden, was ihn wirklich motiviert, was das Thema eines weiteren Threads wäre.

SeattleCplusplus
quelle
1

Nun, ich bin ein bisschen überrascht, dass die anderen Antworten die Bitte des Chefs ernst nehmen. Wer eine Produktivitätssteigerung von 40% fordert, weiß nicht, was Softwareentwicklung bedeutet.

Ich lese immer noch gerne Phil Factor zu diesem Thema:

Es gibt zwei grundlegende Wege zum IT-Management. Sie können Ihren Beruf durch Blut, Schweiß und Tränen erlernen und sich schrittweise nach oben arbeiten, basierend auf der Glaubwürdigkeit, die Sie durch hart erarbeitetes technisches Know-how und erfolgreiche Projekte erlangt haben. Alternativ können Sie einen scharfen Anzug und eine scharfe Krawatte anziehen, die Umgangssprache erlernen und reibungslos nach oben sprechen.

Beide Routen scheinen gleich effektiv zu sein. Der Umgang mit der letzteren Rasse kann zweifellos einige Momente der Bestürzung und des Unglaubens hervorrufen, sogar der Verzweiflung, und einige davon sind in diesen Geschichten dokumentiert.

Es ist jedoch leicht, traurig und verbittert zu werden, wenn man auf technische Inkompetenz in Machtpositionen stößt, und alle Manager mit demselben Pinsel zu tarieren. Phil rät davon ab. Die meisten Manager arbeiten hart und leisten einen guten Beitrag für das Unternehmen, und selbst schlechte Manager können bis zum erforderlichen Standard geschult werden, wenn Sie nur ein paar einfachen Richtlinien folgen. Es gehört zu Ihrer Teamverantwortung, Ihrem Manager dabei zu helfen, auf eine Weise zu funktionieren, die allen zugute kommt.

Wenn Sie sie letztendlich nicht trainieren, befördern oder meiden können, können Sie vielleicht lernen, sie nur für ihren unbeabsichtigten Beitrag zur reichen Komödie am Arbeitsplatz zu lieben.

Der Rat, nicht "traurig und verbittert" zu werden, ist der beste, den Sie bekommen können. Kämpfe nicht gegen einen technisch inkompetenten Chef. Er wird das nur als persönlichen Angriff ansehen.

Andomar
quelle
Nun, ich denke, diese Art von hängt davon ab, welches Managementmodell Sie abonnieren. Coaching Leader: Ein anerkannter Experte, der sich die Hände schmutzig macht und anderen beibringt, wie man gut wird, aber im Allgemeinen "der Guru" bleibt. Führungsdirektor: Der "Experte", der alles weiß (oder glaubt, dass er es tut) und nur Befehle erteilt und den Leuten sagt, was zu tun ist. Führung durch Delegation: kann nicht der Experte sein, vertraut auf ihr Fachwissen und erleichtert. Unterstützende Führung: Die Cheerleaderin für die Gruppe hilft ihnen beim Aufbau, bei der Motivation, überzeugt das Team, dass sie es können, und hilft ihnen dabei, es zu erreichen.
Curtis Reed
0

Ihr Manager hat den Geschwindigkeitsgebrauch falsch verstanden. Es ist keine Metrik und kein Ziel. Ihr Zweck ist die Kalibrierung der Teamarbeitsbelastung pro Sprint.
Wenn Sie darüber nachdenken, ergibt sich Ihre Geschwindigkeit aus einer bestmöglichen Schätzung, die Sie nach jedem Sprint erneut messen. Normalerweise sollte es im Laufe der Zeit etwas stabiler werden. Das ändert aber nichts an der Tatsache, dass es ein Nebenprodukt dessen ist, was Ihr Team tatsächlich tut: Mehrwert für Ihre Kunden zu schaffen.

Der Grund, warum es falsch ist, es als Ziel und / oder Metrik zu verwenden, liegt darin, dass es dadurch zu einer Vanity-Metrik wird. Auf dem Papier würde es gut aussehen, aber es würde absolut nichts daran ändern, ob Ihre Produkte die Bedürfnisse Ihrer Kunden erfüllen oder nicht. Und das ist das Wichtigste (hoffe ich).

Stefan Billiet
quelle
Soweit ich das beurteilen kann, wird dies bereits in einer anderen Antwort erläutert : "Ein Bereich, der die durchschnittliche Kapazität eines Teams über einen historischen Zeitraum ausdrückt. Es handelt sich um eine statistische Analyse der Leistung in der Vergangenheit, die dann verwendet werden kann, um probabilistische Schätzungen der zukünftigen Arbeitsbelastung zu erstellen Kapazität oder Zykluszeiten ... "
Mücke
@gnat ein Teil davon, ja, obwohl diese Antwort nichts über die Verwendung von Velocity als Vanity-Metrik aussagt, was immer noch wichtig ist, da für viele Manager dumme Dinge auf der Basis von Proxy-Nummern gemacht werden. Das OP sagte, er habe das Gefühl, es sei falsch, könne es aber nicht erklären. Ich hatte das Gefühl, dass der Begriff Vanity Metric (von The Lean Startup) eine gute Erklärung bietet.
Stefan Billiet
-1

In Bezug auf meine Erfahrung und auf den Punkt.

Erstens könnten Sie die Schätzung erhöhen, aber das bedeutet nicht, dass Sie mehr tun.

Zweitens (Voraussetzung: ohne Aufpumpen, nur Konzentration auf die Teamgeschwindigkeit),

Versuchen Sie, die Fähigkeiten in Ihrem Team zu finden. Arbeiten sie daran, was sie am besten können? Benötigen Sie einen Systemarchitekten, um die schwierigen Entscheidungen bezüglich der Konstruktion der Anwendung und komplexer Dinge zu treffen? Wie investiert das Team? Sie verbringen Zeit damit, nach Lösungen für ihre Probleme zu suchen, umzugestalten, geschäftliche Entscheidungen zu treffen, oder was?

Sind sie bequem, konzentriert und geschätzt? Was kommt als nächstes für sie?

Das ist nicht "Ich bin am Limit" ... es ist eher eine Frage für das gesamte Team "Sind wir am Limit?" und "Wie können wir die Grenzen verschieben?" ...

Ich habe leitende Hochleistungsteams (für Erstkonstruktionen und / oder Migrationen) ... die Motivation des Teams ist der Schlüssel zum Erfolg ... und es ist wichtig zu planen, wie die Basis der Anwendung aussehen soll. Manchmal bekomme ich oder ein Teammitglied die Rolle eines Systemarchitekten und entscheide, wie und wohin das "Ding" gehen soll.

Manchmal, wenn ich sehe, dass meine Teammitglieder an Effizienz verlieren, versuche ich zu brechen und lade sie ein, ein Bier zu trinken oder etwas, das sie mögen. Dies löst alle Konflikte und am nächsten Tag sind sie wieder konzentriert.

VERKAUF...

Wenn es schwierig ist, die Gründe zu erklären, aus denen Sie die Geschwindigkeit nicht erhöhen können, verwenden Sie den ROI.

Scrum konzentriert sich auf das, was für den Kunden am wichtigsten ist. Theoretisch die rentabelsten Aufgaben.

Wenn sich Ihre Probleme auf den Verkauf des Entwicklungsaufwands beziehen, was ist Ihrer Meinung nach der ROI des Entwicklungsaufwands, wenn Sie Story Points direkt in den "Preis" umwandeln? Wenn Sie nachweisen können, dass Ihr Team mit einem hohen ROI arbeitet, wer wird Sie dann befragen? Außerdem hat jedes Team seine Grenzen, wenn das Team seine "Komfortgröße" gefunden hat, versuchen Sie es von Monat zu Monat leicht zu erhöhen, wenn sie nicht alle Aufgaben erledigen können, ist dies (wahrscheinlich) die Grenze.

Zeigen Sie den Verlauf der Aufgaben, die Gewinneinnahmen (falls verfügbar), den von Ihnen verwendeten Story Point und zeigen Sie, dass PRODUKTIVITÄT NICHT DER TEAMAUFWAND ist. Dies ist eine Berechnung, die vom Team festgelegt wird, um die Komplexität und möglicherweise die Zeit zu ermitteln, die erforderlich ist, um etwas zu erhalten getan

Marcos Lima
quelle