Une augmentation importante de la vitesse est-elle réaliste dans un environnement Scrum?

Mon responsable a récemment beaucoup insisté sur l'utilisation de la vélocité comme cible et mesure de la productivité. Nous travaillons actuellement à une vitesse moyenne de 50 points d'histoire. Mon responsable souhaite que nous augmentions ce pourcentage de 40% à 70 points d’histoire (sans augmentation du nombre de membres de l’équipe). Si nous n'atteignons pas cette augmentation, il souhaite que nous fournissions une analyse détaillée en expliquant pourquoi.

L'idée de mesurer la performance d'une équipe en fonction de sa vitesse et de l'utiliser comme cible me semble fausse, mais j'ai du mal à expliquer pourquoi. De l'aide? Pourquoi n'est-ce pas la bonne façon de mesurer et d'encourager la productivité?

Eh bien, il est parfaitement simple d’augmenter la vélocité de 40% - ajoutez simplement 40% de points en plus à toutes vos estimations et effectuez le même travail.

Etant donné qu'il en est ainsi, il devrait être évident que l'utilisation de la vélocité comme cible est fausse, cela encourage simplement les estimations gonflées.

Une réponse moins délicate est que votre estimation suppose déjà que vous allez aussi vite que vous pouvez tout en faisant tout correctement. Le seul moyen d'augmenter réellement la productivité de 40% est soit de faire des heures supplémentaires, soit de ne pas tout faire correctement. Ces deux choses accélèrent les choses à court terme, mais ralentissent les choses à long terme. Et le long terme dans ce cas n’est pas très long, un mois à l’extérieur. La stratégie optimale à long terme est de ne jamais aller plus vite que votre rythme soutenu.

Peopleware aborde avec éloquence la question de l’ obligation de forcer les programmeurs à accroître leur productivité. C’est un classique souvent cité. Mais en général, il ne sera pas facile de changer l’esprit d’un manager qui s’engage dans la voie qui est la vôtre. Votre projet est peut-être en difficulté - il s'agit certainement d'un drapeau rouge.

Comme le soulignent les commentaires, la demande est manifestement erronée. Mais il n'a pas vraiment tort de vouloir améliorer constamment la productivité. En règle générale, c’est ce que les gestionnaires recherchent (et évaluent).

Cela dit, les gestionnaires cherchent toujours à améliorer les performances, et Scrum and Agile est synonyme d’adaptation. Bien que la vélocité soit une mesure de votre rythme soutenu actuel, vous ne devriez pas vous laisser aller à vos lauriers. Scrum a une place pour évaluer et modifier ce qui fonctionne et ce qui ne fonctionne pas dans votre processus: la rétrospective. Si vous en profitez et ajustez votre processus, la productivité (et éventuellement la vitesse) devrait augmenter.

Alors, cherchez-vous (dans vos rétrospectives) des moyens de devenir plus productifs en équipe? Y a-t-il quelque chose dans vos sprints qui consomme régulièrement une quantité démesurée d'efforts? Peut-il être adressé? Cela ne vous donnera probablement pas une augmentation de 40%, mais 5 à 10% est un début, non? Chaque sprint, vous devez rechercher les goulots d'étranglement et y remédier. Finalement, vous pouvez vous rapprocher de l'objectif qu'il vous a fixé.

TL; DR

Velocity est très utile pour estimer les calendriers ou pour générer des valeurs de planification. Il peut également constituer un contrôle de détection significatif pour évaluer les goulots d'étranglement des processus ou les modifications de la capacité de l'équipe. Ce n'est toutefois pas une mesure valable de la productivité.

Quand Velocity est confondu avec les objectifs de gestion

"Velocity" est une gamme qui exprime la capacité moyenne d'une équipe sur une période historique. Il s'agit d'une analyse statistique des performances passées, qui peut ensuite être utilisée pour projeter des estimations probabilistes de la capacité de charge de travail ou des temps de cycle futurs. Cela contraste nettement avec un "objectif de planification", qui est un objectif de gestion qui définit un calendrier ou un objectif à des fins de planification.

Les gestionnaires de projet agiles expérimentés savent que la bonne utilisation de Velocity consiste à déterminer si une équipe a la capacité durable de respecter les objectifs de planification définis par la direction. Parfois, la réponse est oui et tout le monde est heureux. Parfois, la réponse est non. À ce stade, le triangle de fer force les entreprises à prendre des décisions concernant la portée, les coûts, les délais et la qualité.

Évaluez vos options politiques

Nous avons une vitesse moyenne de 50 points d'histoire ... On m'a demandé de l'augmenter de 40% à 70 points d'histoire (sans augmentation du nombre de membres de l'équipe).

En supposant que vos pratiques d’estimation soient saines et que votre vélocité soit raisonnablement stable, votre responsable n’aura aucune joie à ajuster l’échelle d’estimation ou à fixer des objectifs de gestion non basés sur les performances historiques. Comme vous l'avez souligné à juste titre, il s'agit fondamentalement d'un problème de capacité .

La limite de capacité peut être liée au nombre de personnes de votre équipe ou à une limitation de vos processus organisationnels. Bien sûr, ajouter plus de personnes n'augmente pas toujours la capacité réelle du projet. voir la loi de Brooks pour plus d'informations sur cette idée fausse commune.

Le problème que vous rencontrez est politique. D'après le ton de votre message, il semble que votre responsable souhaite une augmentation de la productivité sans modifier réellement la capacité sous-jacente de l'équipe. Les solutions sont donc également de nature politique et essentiellement éducative.

Si vous êtes un magasin Scrum, demandez à votre Scrum Master d’aborder ce problème par le biais des canaux de cadre appropriés. Les rétrospectives de traitement en attente et de sprint sont souvent les occasions idéales d'inspecter et d'adapter ce problème particulier.

Si vous n'êtes pas un magasin Scrum, vous devez choisir le meilleur moyen de répondre à vos préoccupations au sein de votre organisation. Si vous êtes en bons termes avec votre responsable, vous pouvez même lui prêter une copie du logiciel Agile Estimating and Planning pour que vous puissiez en discuter pendant le déjeuner.

Si tout le reste échoue, préparez-vous pour une marche de la mort en révisant votre CV et en faisant de votre mieux professionnel jusqu'à l'implosion du projet. 68% des projets informatiques échouent ; à moins que les objectifs de gestion ne soient fermement ancrés dans la capacité organisationnelle, le vôtre en fera probablement partie.

Je ne comprends pas quel rôle votre manager a dans l'équipe Scrum? Est-il un entraîneur? Est-il un produit propriétaire?

S'il fait partie de l'équipe comme un entraîneur ou autre (il travaille à une tâche de développement), vous pouvez lui demander pourquoi il sous-estime sa propre productivité, car il semble que ce n'était pas le cas pour les autres membres de l'équipe. S'il croit pouvoir assumer personnellement 30 points d'histoire de plus à chaque itération, laissez-le le montrer.

Plus probable: il est en dehors de l'équipe, peut-être le propriétaire du produit? Si c'est le cas, il devrait comprendre qu'il fait une demande aussi stupide qu'il vient d'arrêter l'agilité.

Une règle de base est que le propriétaire du produit définit l'objectif pendant que l'équipe définit ce qui peut être fait lors d'une itération. Ne pas le faire conduit au cercle de fer classique et bien connu: ressources, vitesse, caractéristiques. Choisis en deux! Vous ne pouvez pas en choisir trois à la fois (et rappelez-vous: la qualité n’est pas une variable d’ajustement, essayer de rogner sur une qualité médiocre aggravera encore les choses).

S'il ne veut pas changer l'objectif actuel, peut-être qu'une augmentation de productivité de 40% peut être atteinte en recrutant plus de personnes pour l'équipe? Peut-être investir dans une formation préalable pour certains membres de l'équipe? Les équipes peuvent également gagner en rapidité avec le temps grâce à une amélioration continue, mais certainement pas par une décision arbitraire.

Essayer de changer la vélocité d'une équipe, c'est comme essayer de changer la taille d'une pièce. Cela peut être fait, mais fondamentalement, vous devez changer de pièce.

N'avez-vous pas un Scrum Master, ou d'autres personnes avec une compréhension de base de Scrum, qui pourraient l'expliquer?

Dans ce cas, le manager a pris la mauvaise direction après avoir obtenu une estimation honnête et fidèle de l'équipe. Le gestionnaire est censé se tourner vers les parties prenantes et leur faire savoir que leurs exigences ne peuvent pas être satisfaites dans les délais requis. Le responsable / analyste doit ensuite définir les fonctionnalités devant être incluses et les autres pouvant attendre (même quelques semaines). Si la partie prenante se montre déraisonnable, il pourrait alors être nécessaire d'impliquer des gestionnaires supérieurs, ce qui peut généralement être difficile et nécessite toute une série d'autres discussions.

Si j'étais dans vos chaussures , je viens avec un cas en détail pourquoi le projet IS va prendre aussi longtemps que a été estimé. Essayez également d'identifier les articles à faible retour. Recherchez les éléments qui n’ajoutent pas beaucoup de valeur et qui nécessitent des efforts de programmation importants, et plaidez pour les supprimer du sprint. Proposez également une approche itérative qui fournit "X" à la date "Y" et assurez-vous que c'est faisable, puis proposez une itération de suivi qui leur fournira les éléments restants.

Fondamentalement, quelqu'un doit dire aux parties prenantes ce qu'elles peuvent s'attendre à recevoir d'ici la date limite et que cela inclut la majorité de leurs exigences. et que, lors de la publication suivante, ils disposeront des éléments restants. Si le client est déraisonnable, alors la haute direction doit être impliquée, le responsable doit pouvoir y arriver.

Cependant, si le client était promis, et que personne ne s’était exprimé jusqu’à présent, la bataille serait rude. Ce n'est pas une situation rare malheureusement.

On dirait que vous faites face à deux problèmes.

La partie qui vous dérange dans la mesure de la vitesse est probablement que la mesure est le coût . Ce que vous voulez vraiment améliorer, c'est la valeur . Malheureusement, mesurer la valeur d'un logiciel est notoirement difficile et subjectif. Néanmoins, même une métrique imparfaite et subjective peut être utile. Le problème réel n’est peut-être pas que votre équipe a besoin d’écrire plus de code, mais que les histoires doivent avoir plus de valeur.

L’autre problème est que, selon votre compte, votre responsable s’attend à une augmentation de 40% de la productivité. Votre question ne précisait pas le contexte de cette demande. Cela pourrait être un désir sincère que votre équipe s’améliore. Ou cela pourrait être une indication peu subtile que votre responsable estime que votre équipe est sous-performante.

edit: En fonction de votre commentaire, la situation semble mauvaise. Il semble que votre entreprise prépare le terrain pour vous licencier, ainsi que votre équipe (peut-être votre responsable également). Je vous suggère de chercher un autre travail.

Renvoie le. C’est-à-dire qu’il va au-delà de la tête et explique qu’il a perdu toute confiance en son équipe et qu’il n’a aucune valeur pour l’entreprise. Expliquez que les gestionnaires présentant ce niveau d'incompétence sont beaucoup plus faciles à remplacer que l'équipe ci-dessous.

Il n'y a pas de bonne raison de supporter un tel manager, mais cela ne signifie pas automatiquement que les développeurs doivent démissionner. Il n'y a pas nécessairement quelque chose qui ne va pas dans l'entreprise, juste avec cette personne. Résoudre ce problème.

Et pour éviter toute confusion de la part de la haute direction, faites bien comprendre que ce n’est pas une erreur pardonnable. Cela indique que le responsable n’a aucune idée de l’équipe qu’il gère. Cela ne se prête pas à la réparation, et il n’est pas nécessaire de le faire sur le marché du travail actuel. Les gestionnaires sont éminemment remplaçables, tout comme les entraîneurs sportifs. Les propriétaires ne renvoient pas d'équipes.

Maintenant, cela pourrait ressembler à une stratégie qui peut se retourner. Mais considérez que si les cadres supérieurs avec votre supérieur, peu importe, vous seriez déjà dans une position perdante de toute façon. Donc, si vous ne considérez que les situations dans lesquelles vous n'êtes pas déjà dans cette position de perdant, le résultat sera probablement beaucoup plus positif. Le vrai risque, c’est que la haute direction congédie l’ensemble de l’équipe, y compris le responsable. Vous seul pouvez estimer ce risque. Apparemment, votre production est recherchée, sinon ils n'en demanderaient pas davantage, mais à quel prix?

D'après mon expérience, il était très, très difficile d'augmenter la vélocité réelle d'une équipe, car ni l'équipe, ni le domaine problématique, ni la pile de technologies ne changent.

Là où j'ai pu atteindre des augmentations, c'est une question de:

• épuration de la dette technique; s'assurer que tout fonctionne avec la bonne version (pas nécessairement la version la plus récente!), que le code est bien factorisé et qu'il n'y a pas de redondance dans le système (code dupliqué, code inutilisé, etc.)

• amélioration des pratiques; le jumelage si possible (oui, j'ai trouvé que cela augmentait la vitesse), en prenant le temps de refactoriser de manière agressive (idem!) et en étant impitoyable quant à la portée et à la focalisation

• trouver et / ou acheter les meilleurs outils pour le poste (par exemple, ReSharper pour .NET vaut son pesant d'or, Airbrake et Splunk pour le développement de Ruby, etc.)

Je suis d’accord avec d’autres ici qui disent que votre responsable qui demande une augmentation arbitraire de la vitesse est un drapeau rouge. Je chercherais un autre travail en priorité.

Votre responsable demande (ou dit) à votre équipe de travailler des heures supplémentaires. Si éliminer les goulots d'étranglement et gagner en efficacité peuvent améliorer quelque peu votre vitesse, le seul moyen d'obtenir cette augmentation (40%) est de travailler plus longtemps, car vous devez augmenter le nombre d'unités de travail au cours de cette période.

Prenons un scénario.

Pour un échange de deux semaines, disons 10 jours. L'utopie serait de 8 heures par jour, un point d'histoire étant résumé par une journée de travail. Donc, en partant du haut, votre vitesse serait de 8. Mais, de manière réaliste, les gens commencent probablement à passer 6 bonnes heures par jour avec des courriels, des réunions, des pauses dans la salle de bain, etc. Donc, votre niveau de référence est 6. Supposons que vous souhaitiez que les gens fassent des heures supplémentaires, maintenant à 10 heures par jour. Donc, ce serait 10 points de vitesse par développeur.

Votre vitesse fluctuera toujours, peut-être était-elle basse parce que vous avez dû faire face à de nombreux bugs lors de cette itération, que les exigences manquaient peut-être, que quelqu'un est tombé malade pendant quelques jours. C'était peut-être élevé parce que le travail avait été surestimé ou que votre équipe avait consacré des heures supplémentaires.

Mais si vous êtes à 50, vous aurez besoin d’heures supplémentaires.

Le problème avec Velocity est qu’il s’agit d’une variable dépendante, d’une sortie mesurée de votre processus de développement. Demander d'augmenter la vélocité de 40%, c'est comme essayer de se mettre au travail plus tôt en criant aux voitures d'aller plus vite. La vitesse augmente en introduisant plus de carburant et d'air dans le moteur ou en obtenant une voiture plus rapide, en plus de trouver un itinéraire avec moins de circulation.

Travailler plus d'heures n'augmente pas la vélocité si vous la mesurez correctement, disons en points de fonctionnalités par heure de développeur. Cela ne fonctionne que si vous mesurez des points par jour, puis redéfinissez ce qu'est un "jour" au milieu d'une mesure. Cela ne fournit que l'illusion de vitesse.

Une augmentation de la vitesse nécessite l'amélioration des variables indépendantes dans le processus de développement; des ordinateurs et des compilateurs plus rapides, un système de construction plus efficace, un meilleur processus de conception, des développeurs plus capables, un meilleur espace de travail, une motivation extrême. Une amélioration de 40% nécessiterait des changements très importants.

Demandez si votre responsable envisagerait de regrouper votre équipe dans des bureaux fermés autour d'une salle de travail commune, achetant à l'équipe du tout nouveau matériel de développeur, ou embauchant deux développeurs vraiment expérimentés pour guider l'équipe si cela lui permettrait d'atteindre ses 40%. S'il n'y a pas de ressources disponibles pour améliorer les entrées dans votre processus de développement, cela exclut quasiment tout intérêt sincère à l'amélioration. Cela laisse l’ingénierie inverse à votre responsable pour déterminer ce qui le motive réellement, ce qui ferait l’objet de tout un fil conducteur.

Eh bien, je suis un peu surpris que les autres réponses prennent la demande du patron au sérieux. Quelqu'un qui exige une augmentation de 40% de sa productivité ne connaît pas le développement de logiciels.

J'aime toujours lire Phil Factor sur ce sujet:

Il existe deux itinéraires de base dans la gestion informatique. Vous pouvez apprendre votre métier à travers le sang, la sueur et les larmes et gravir progressivement les échelons, en vous basant sur la crédibilité que vous avez acquise grâce au savoir-faire technique durement acquis et aux projets couronnés de succès. Alternativement, vous pouvez enfiler un costume pointu et une cravate, apprendre le jargon et parler en douceur pour vous rendre au sommet.

Les deux voies semblent également efficaces. Traiter avec cette dernière race peut certainement causer des moments de consternation et d'incrédulité… voire de désespoir… et une partie de cela est documentée dans ces histoires.

Cependant, il est facile de devenir triste et aigri lorsque l’on rencontre une incompétence technique aux postes de pouvoir et de ternir tous les cadres. Phil déconseille cela. La plupart des managers travaillent dur et contribuent bien à l'entreprise. Même les plus démunis peuvent être formés selon les normes requises, si vous ne suivez que quelques directives simples. Cela fait partie de la responsabilité de votre équipe d'aider votre responsable à fonctionner de manière à profiter à tous.

En fin de compte, si vous ne pouvez pas les former, obtenir leur promotion ou les éviter, vous pouvez peut-être apprendre à les aimer simplement pour leur contribution involontaire à la riche comédie du monde du travail.

Le conseil de ne pas devenir "triste et aigri" est le meilleur que vous puissiez obtenir. Ne combattez pas un patron techniquement incompétent pour des questions techniques. Il verra cela comme une attaque personnelle.

Votre responsable a mal compris l'utilisation de la vélocité. Ce n'est pas une métrique et ce n'est pas une cible. Son but est de calibrer la charge de travail de l'équipe par sprint.
Si vous y réfléchissez, votre vélocité émerge d’une meilleure estimation, que vous réévaluez après chaque sprint. Habituellement, à mesure que le temps passe, il devrait devenir quelque peu stable. Mais cela ne change pas le fait que c'est un sous-produit de ce que votre équipe fait réellement: créer de la valeur pour vos clients.

La raison pour laquelle il est erroné de l'utiliser en tant que cible et / ou métrique est que cela en ferait une métrique de vanité. Cela semblerait bien sur papier, mais cela ne ferait absolument rien de refléter si vos produits répondent pleinement aux besoins de vos clients. Et c'est ce qui est le plus important (j'espère).

En ce qui concerne mon expérience et aller droit au but.

Premièrement, vous pouvez gonfler l'estimation, mais cela ne signifie pas que vous en faites plus.

Deuxième (principe: sans gonfler, se concentrer uniquement sur la vitesse de l’équipe),

Essayez de trouver les compétences au sein de votre équipe. Travaillent-ils sur ce qu'ils sont les meilleurs? Avez-vous besoin d'un architecte de systèmes pour prendre les décisions difficiles concernant la construction de l'application et les choses complexes? Comment l'équipe dépense-t-elle ses efforts? Ils passent du temps à chercher des solutions à leurs problèmes, à refactoriser, à prendre des décisions commerciales ou quoi?

Sont-ils à l'aise, concentrés et estimés? Quelle est la suite pour eux?

Ce n'est pas "je suis poussé sur les limites" ... c'est plutôt une question pour toute l'équipe "Sommes-nous sur les limites?" et "Comment pouvons-nous repousser les limites?" ...

J'ai des équipes dirigeantes de haut niveau (pour les premières constructions et / ou les migrations) ... la motivation de l'équipe est la clé du succès ... et il est essentiel de prévoir la base de l'application. Parfois, un collaborateur ou moi-même acquérons le rôle d'architecte de systèmes et décidons comment et où la "chose" devrait aller.

Parfois, quand je vois que mes coéquipiers perdent en efficacité, j'essaie de faire une pause et je les invite à sortir boire un verre de bière ou quelque chose qu'ils aiment. Cela résout tous les conflits et le lendemain, ils sont à nouveau concentrés.

VENTE...

Si vous expliquez les raisons pour lesquelles vous ne pouvez pas augmenter la vitesse est difficile, utilisez le retour sur investissement.

Scrum se concentre sur ce qui est le plus important pour le client. Théoriquement les tâches les plus rentables.

Si vos problèmes concernent la vente de l’effort de développement, que pensez-vous de la valeur du retour sur investissement de l’effort de développement, convertissez directement les points d’histoire en "prix". Si vous pouvez prouver que votre équipe travaille avec un retour sur investissement élevé, qui va vous interroger? De plus, chaque équipe a ses limites si l’équipe a trouvé sa "taille confort", essayez d’augmenter légèrement de mois en mois, si elle ne peut pas terminer toutes les tâches, c’est (probablement) la limite.

Affichez l’historique des tâches, le chiffre d’affaires (le cas échéant), le récit que vous avez utilisé et montrez que la productivité n’est pas l’effort de l’équipe est un calcul déterminé par l’équipe pour évaluer la complexité et peut-être le temps d’obtenir quelque chose. terminé