it-swarm-eu.dev

Ist eine starke Geschwindigkeitssteigerung in einer Scrum-Umgebung realistisch?

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 es um 40% auf 70 Story Points erhöhen (ohne Erhöhung der Teammitglieder). Wenn wir diesen Anstieg nicht erreichen, möchte er, dass wir eine vollständige Aufschlüsselung liefern und erklären, warum.

Die ganze Idee, die Teamleistung anhand 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 zu fördern?

90
P2l

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

In Anbetracht dessen sollte klar sein, warum die Verwendung der Geschwindigkeit als Ziel falsch ist, sondern nur überhöhte Schätzungen fördert.

Eine weniger eindeutige 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 wirklich um 40% zu steigern, besteht darin, Überstunden zu leisten oder nicht alles richtig zu machen. Beide beschleunigen die Dinge kurzfristig, verlangsamen sie aber langfristig. Und die langfristige in diesem Fall ist nicht sehr lang, ein Monat außerhalb. Die optimale langfristige Strategie besteht darin, niemals schneller als Ihr nachhaltiges Tempo zu fahren.

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 geht, den Sie gehen. Ihr Projekt könnte in Schwierigkeiten geraten - dies ist sicherlich eine rote Fahne.

158
psr

Wie die Kommentare gezeigt haben, ist die Anfrage offensichtlich falsch, wie sie gestellt wurde. Aber er ist nicht wirklich falsch, die Produktivität ständig verbessern zu wollen. Dies ist in der Regel das, wonach Manager streben (und bewertet werden).

Manager sind jedoch stets bemüht, die Leistung zu verbessern, und bei Scrum und Agile geht es darum, anpassungsfähig zu sein. Während Geschwindigkeit ein Maß für Ihr derzeit nachhaltiges Tempo ist, sollten Sie sich nicht auf Ihren Lorbeeren zurücklehnen. Scrum hat einen Ort, an dem Sie bewerten und ändern können, was in Ihrem Prozess funktioniert und was nicht: die Retrospektive. Wenn Sie dies nutzen 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 unverhältnismäßig viel Aufwand erfordert? Kann es angesprochen werden? Es wird Ihnen wahrscheinlich keine 40% Steigerung geben, aber 5-10% sind ein Anfang, nein? Bei jedem Sprint sollten Sie nach Engpässen suchen und diese beheben. Möglicherweise nähern Sie sich dem Ziel, das er sich für Sie gesetzt hat.

53
Matthew Flynn

TL; DR

Die Geschwindigkeit ist sehr nützlich, um Zeitpläne zu schätzen oder Planungswerte zu generieren, und kann auch eine sinnvolle Detektivkontrolle für Bewertung von Prozessegpässen oder Änderungen der Teamkapazität sein. Es ist jedoch kein gültiges Maß für die Produktivität.

Wenn Geschwindigkeit mit Verwaltungszielen verwechselt wird

"Geschwindigkeit" ist 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, anhand derer dann probabilistische Schätzungen der zukünftigen Arbeitslastkapazität oder der Zykluszeiten erstellt werden können. Dies steht in krassem Gegensatz zu einem "Planungsziel", bei dem es sich um ein Managementziel handelt, das einen Zeitplan oder ein Ziel für Planungszwecke festlegt.

Erfahrene agile Projektmanager wissen, dass die richtige Verwendung der Geschwindigkeit darin besteht, zu bestimmen, ob ein Team die nachhaltige Fähigkeit besitzt, vom Management definierte Planungsziele zu erreichen. Manchmal lautet die Antwort ja und alle sind glücklich. Manchmal lautet die Antwort nein. An diesem Punkt erzwingt das Eisendreieck Geschäftsentscheidungen über Umfang, Kosten, Zeit und Qualität.

Bewerten Sie Ihre politischen Optionen

Wir haben eine durchschnittliche Geschwindigkeit 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, die Schätzskala anzupassen oder Managementziele festzulegen, die nicht auf der historischen Leistung basieren. Wie Sie richtig hervorheben, handelt es sich grundsätzlich um ein Kapazitätsproblem .

Das Kapazitätslimit kann sich auf die Anzahl der Personen in Ihrem Team beziehen oder auf Ihre organisatorischen Prozesse. Das Hinzufügen weiterer Personen erhöht natürlich auch nicht immer die tatsächliche Projektkapazität. Weitere Informationen zu diesem häufigen Missverständnis finden Sie unter Brooks'sches Gesetz .

Das Problem , mit dem Sie konfrontiert sind, ist politisch. Aus dem Ton Ihres Beitrags geht hervor, dass Ihr Manager eine Steigerung der Produktivität wünscht, ohne die zugrunde liegenden Kapazitäten des Teams tatsächlich zu ändern. Die Lösungen sind daher auch politisch und weitgehend pädagogischer Natur.

Wenn Sie ein Scrum-Shop sind, bitten Sie Ihren Scrum Master, dieses Problem über die entsprechenden Framework-Kanäle zu beheben. Backlog Grooming und Sprint Retrospectives 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 Bedenken in Ihrem Unternehmen richtig angehen können. Wenn Sie mit Ihrem Manager gute Beziehungen haben, können Sie ihm sogar eine Kopie von Agile Estimating and Planning ausleihen, 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 professionelles Bestes geben, bis das Projekt implodiert. 68% der IT-Projekte schlagen fehl ; Wenn die Managementziele nicht fest in der organisatorischen Kapazität verankert sind, werden Ihre wahrscheinlich eines davon sein.

26
CodeGnome

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

Wenn er wie ein Trainer oder dergleichen im Team ist (er arbeitet an einer Entwicklungsaufgabe), können Sie ihn fragen, warum er seine eigene Produktivität unterschätzt, da dies bei anderen Teammitgliedern anscheinend nicht der Fall war. Wenn er glaubt, dass er persönlich mit jeder Iteration 30 Story Points mehr annehmen kann, lassen Sie ihn dies zeigen.

Wahrscheinlicher: Er ist außerhalb des Teams, vielleicht der Produktbesitzer? Wenn ja, sollte er verstehen, eine so dumme Anfrage zu stellen, dass er einfach die Beweglichkeit gestoppt hat.

Eine Grundregel ist, dass der Product Owner das Ziel festlegt, während das Team festlegt, was in einer Iteration getan werden kann. Nichtbeachtung führt zum klassischen und bekannten Eisenkreis: Ressourcen, Geschwindigkeit, Merkmale. Wähle zwei aus! Sie können nicht drei davon gleichzeitig auswählen (und denken Sie daran: Qualität ist keine Anpassungsvariable. Der Versuch, Ecken durch schlechte Qualität zu schneiden, macht die Sache noch schlimmer).

Wenn er das aktuelle Ziel nicht ändern möchte, kann möglicherweise eine Steigerung der Produktivität um 40% erreicht werden, indem mehr Mitarbeiter für das Team eingestellt werden? Vielleicht in ein Training für einige Teammitglieder investieren? Teams können im Laufe der Zeit auch durch kontinuierliche Verbesserung an Geschwindigkeit gewinnen, aber sicherlich nicht durch willkürliche Entscheidungen.

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 grundlegendem Verständnis von Scrum, die ihm das erklären könnten?

21
kriss

In diesem Fall hat der Manager die falsche Richtung eingeschlagen, nachdem er vom Team eine ehrliche und getreue Schätzung erhalten hat. Der Manager soll sich an den Stakeholder wenden und ihn darüber informieren, 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 welche anderen 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 sein kann und eine ganze Reihe anderer Diskussionen erfordert.

Wenn ich in Ihren Schuhen stecken würde, würde ich einen detaillierten Fall finden, warum das Projekt IST so lange dauern wird, wie geschätzt wurde. Versuchen Sie auch, Artikel mit geringer Rendite zu identifizieren. Finden Sie die Elemente, die nicht viel Wert hinzufügen und einen erheblichen Programmieraufwand erfordern, und sprechen Sie dafür, diese aus dem Sprint zu entfernen. Überlegen Sie sich auch einen iterativen Ansatz, der "X" am "Y" -Datum liefert, und stellen Sie sicher, dass dies machbar ist. Erstellen Sie dann eine Folgeiteration, mit der die verbleibenden Elemente abgerufen werden.

Grundsätzlich muss jemand dem Stakeholder mitteilen, was er bis zum Stichtag erwarten kann und dass es den Großteil seiner Anforderungen enthält. und dass sie bis zur folgenden Version die restlichen Gegenstände 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 wurde und bis jetzt noch niemand etwas gesagt hat, wird es ein harter Kampf. Dies ist leider keine ungewöhnliche Situation.

15
hanzolo

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 Unternehmen keinen Wert hat. Erklären Sie, dass Manager mit dieser Inkompetenz weitaus 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. Es ist nicht unbedingt etwas falsch mit dem Geschäft, nur mit dieser einen Person. Beheben Sie das Problem.

Machen Sie deutlich, dass dies kein verzeihbarer Fehler ist, um ein Schweigen des oberen Managements zu verhindern. Es signalisiert, dass der verantwortliche Manager nein Verständnis für das Team hat, das er leitet. Das eignet sich weder für die Festsetzung noch für die Notwendigkeit auf dem gegenwärtigen Arbeitsmarkt. Manager sind ebenso wie Sporttrainer hervorragend austauschbar. Besitzer feuern keine Teams.

Dies könnte wie eine Strategie aussehen, die nach hinten losgehen kann. Aber bedenken Sie: Wenn das obere Management mit Ihrem Manager zusammenarbeitet, sind Sie ohnehin schon in einer Verlustposition. Wenn Sie also nur die Situationen berücksichtigen, in denen Sie sich noch nicht in dieser Verlustposition befinden, wird das Ergebnis wahrscheinlich weitaus positiver sein. Das wirkliche Risiko besteht darin, dass das obere Management nur das gesamte Team einschließlich des Managers entlässt. Nur Sie können dieses Risiko abschätzen. Anscheinend ist Ihre Ausgabe erwünscht, sonst würden sie nicht mehr davon verlangen, aber zu welchem ​​Preis?

9
MSalters

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

Der Teil über die Geschwindigkeitsmessung, der Sie stört, ist wahrscheinlich, dass die Messung Kosten ist. Was Sie wirklich verbessern möchten, ist der Wert. Leider ist es notorisch schwierig und subjektiv, den Wert von Software zu messen. 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 Steigerung der Produktivität um 40% erwartet hat. In Ihrer Frage wurde der Kontext dieser Anfrage nicht angegeben. Es könnte ein gutmütiger Wunsch sein, Ihr Team zu verbessern. Oder es könnte ein nicht so subtiler Hinweis darauf sein, dass Ihr Manager glaubt, dass Ihr Team unterdurchschnittlich abschneidet.

bearbeiten: Basierend auf Ihrem Kommentar sieht die Situation schlecht aus. Es hört sich so an, als würde Ihr Unternehmen die Grundlagen schaffen, um Sie und Ihr Team (vielleicht auch Ihren Manager) zu entlassen. Ich schlage vor, dass Sie nach einem anderen Job suchen.

9
Aaron Kurtzhals

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

Wo ich Erhöhungen erzielen konnte, war es eine Frage von:

  • technische Schulden bereinigen; Sicherstellen, dass auf allem die richtige (nicht unbedingt neueste!) Version ausgeführt wird, dass der Code gut berücksichtigt ist und dass das System keine Redundanz aufweist (duplizierter Code, nicht verwendeter Code usw.)

  • verbesserung der Praktiken; Pairing wo möglich (ja, ich habe festgestellt, dass dies die Geschwindigkeit erhöht), sich die Zeit nehmen, aggressiv umzugestalten (dito!) und rücksichtslos in Bezug auf Umfang und Fokus zu sein

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

Ich stimme anderen hier zu, die sagen, dass Ihr Manager, der um eine willkürliche Erhöhung der Geschwindigkeit bittet, eine rote Fahne ist. Ich würde nach einem anderen Job mit hoher Priorität suchen.

6
Duncan Bayne

Ihr Manager bittet (oder 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, besteht die einzige Möglichkeit, diesen Anstieg (40%) zu erzielen, darin, länger zu 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 am Tag betragen, wobei ein Story Point auf einen Arbeitstag abstrahiert würde. Von oben gesehen wäre Ihre Geschwindigkeit also 8. Aber relativ gesehen kommen die Leute wahrscheinlich in 6 guten Stunden am Tag mit E-Mails, Besprechungen, Toilettenpausen usw. an. Jetzt sind Sie also bei 6 pro Entwickler. Ihre Grundlinie ist also 6. Nehmen wir an, Sie möchten, dass die Leute Überstunden machen, jetzt um 10 Uhr am 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 umgehen mussten, vielleicht fehlten Anforderungen, 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 investiert hat.

Aber wenn Sie bei stabilen 50 sind, werden Sie zusätzliche Stunden benötigen, um wirklich auf 70 zu kommen.

3
Jon Raynor

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, früher 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 werden oder ein schnelleres Auto gekauft wird und eine Route mit weniger Verkehr gefunden wird.

Mehr Stunden zu arbeiten erhöht 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 Entwurfsprozess, fähigere Entwickler, besserer Arbeitsbereich, überragende Motivation. Eine Verbesserung um 40% würde sehr signifikante Änderungen erfordern.

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

2

Nun, ich bin ein bisschen überrascht, dass die anderen Antworten die Anfrage des Chefs ernst nehmen. Jemand, der eine Produktivitätssteigerung von 40% verlangt, weiß nicht das Erste über Softwareentwicklung.

Ich lese immer noch gerne Phil Factor zu diesem Thema:

Es gibt zwei grundlegende Wege in das IT-Management. Sie können Ihr Handwerk 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 gewonnen haben. Alternativ können Sie einen scharfen Anzug und eine Krawatte anziehen, den Jargon lernen und sich reibungslos nach oben unterhalten.

Beide Routen scheinen gleich effektiv zu sein. Der Umgang mit der letzteren Rasse kann sicherlich einige Momente der Bestürzung und Ungläubigkeit verursachen… sogar Verzweiflung… und einiges davon ist 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 zum Unternehmen, und selbst arme Manager können auf den erforderlichen Standard geschult werden, wenn Sie nur ein paar einfache Richtlinien befolgen. 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 des Arbeitsplatzes 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 in technischen Angelegenheiten. Er wird das nur als persönlichen Angriff sehen.

1
Andomar

Ihr Manager hat die Verwendung von Geschwindigkeit 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 besten Vermutung, 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: Wertschöpfung für Ihre Kunden.

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

0
Stefan Billiet