Une grande augmentation de la vitesse est-elle réaliste dans un environnement Scrum?
Mon manager a récemment vraiment insisté pour utiliser la vitesse comme objectif et mesure de la productivité. Nous travaillons actuellement à une vitesse moyenne de 50 points d'histoire. Mon manager veut que nous l'augmentions de 40% à 70 points d'histoire (sans augmentation des membres de l'équipe). Si nous n'atteignons pas cette augmentation, il veut que nous fournissions une ventilation complète expliquant pourquoi.
L'idée de mesurer la performance d'une équipe par la 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 vitesse de 40% - ajoutez simplement 40% de points supplémentaires à toutes vos estimations et effectuez la même quantité de travail.
Étant donné qu'il en est ainsi, il devrait être évident pourquoi l'utilisation de la vitesse comme cible est erronée, cela encourage simplement des estimations gonflées.
Une réponse moins claire est que votre estimation suppose déjà que vous allez aussi vite que possible tout en faisant tout correctement. La seule façon d'augmenter réellement la productivité de 40% est de faire des heures supplémentaires ou de ne pas tout faire correctement. Ces deux éléments 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 durable.
Peopleware parle avec éloquence des problèmes de forcer les programmeurs à une productivité plus élevée, et est un classique souvent cité. Mais en général, il ne sera pas facile de changer d'avis d'un manager qui emprunte la voie qui est la vôtre. Votre projet pourrait bien être en difficulté - c'est certainement un drapeau rouge.
Comme l'ont souligné les commentaires, la demande est manifestement erronée telle qu'elle a été formulée. Mais il n'a pas vraiment tort de vouloir constamment améliorer sa productivité. En règle générale, c'est ce que les gestionnaires s'efforcent (et sont évalués).
Cela dit, les gestionnaires cherchent toujours à améliorer les performances, et Scrum et Agile sont tout à fait adaptables. Bien que la vélocité soit une mesure de votre rythme soutenable actuel, vous ne devriez pas vous asseoir sur vos lauriers. Scrum a un endroit pour évaluer et changer ce qui fonctionne et 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é disproportionnée d'efforts? Peut-il être résolu? 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 les résoudre. Finalement, vous pouvez vous rapprocher de l'objectif qu'il vous a fixé.
TL; DR
La vélocité est très utile pour estimer les plannings ou générer des valeurs de planification, et peut également être un contrôle de détection significatif pour évaluer les goulots d'étranglement du processus ou les changements dans la capacité de l'équipe. Ce n'est cependant pas une mesure valable de la productivité.
Quand la vitesse est confondue avec les cibles 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 future ou des temps de cycle. Cela contraste fortement avec une "cible de planification", qui est un objectif de gestion qui fixe un calendrier ou un objectif à des fins de planification.
Les chefs de projet agiles expérimentés savent que la bonne utilisation de la vitesse est de déterminer si une équipe a la capacité durable d'atteindre les objectifs de planification définis par la direction. Parfois, la réponse est oui et tout le monde est content. Parfois, la réponse est non, à quel moment le triangle de fer force les décisions commerciales concernant la portée, le coût, le temps 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 des membres de l'équipe).
En supposant que vos pratiques d'estimation sont saines et que votre vitesse est raisonnablement stable, votre gestionnaire n'aura aucune joie à ajuster l'échelle d'estimation ou à fixer des objectifs de gestion non basés sur les performances historiques. Comme vous le signalez correctement, il s'agit fondamentalement d'un problème de capacité .
La limite de capacité peut être liée au nombre de personnes dans votre équipe, ou elle peut être une limitation de vos processus organisationnels. Bien sûr, ajouter plus de personnes n'ajoute pas toujours la capacité réelle du projet; voir Brooks 'Law pour en savoir plus sur cette idée fausse commune.
Le problème auquel vous faites face est politique. D'après le ton de votre message, il semble que votre responsable souhaite voir une augmentation de la productivité sans apporter de modifications réelles à la capacité sous-jacente de l'équipe. Les solutions sont donc également politiques et de nature largement éducative.
Si vous êtes une boutique Scrum, demandez à votre Scrum Master de résoudre ce problème via les canaux de framework appropriés. Le backlog Grooming et Sprint Retrospectives sont souvent les opportunités idéales d'inspection et d'adaptation pour ce problème particulier.
Si vous n'êtes pas une boutique Scrum, vous devez décider de la manière appropriée de répondre à vos préoccupations au sein de votre organisation. Si vous êtes en bons termes avec votre manager, vous pourriez même lui prêter une copie de Agile Estimating and Planning pour que vous puissiez en discuter pendant le déjeuner.
Si tout le reste échoue, préparez-vous à une marche de la mort en brossant votre CV et en faisant de votre mieux jusqu'à ce que le projet implose. 68% des projets informatiques échouent ; à moins que les objectifs de gestion ne soient solidement ancrés dans la capacité organisationnelle, la vôtre en sera probablement une.
Je ne comprends pas quel rôle votre manager a dans l'équipe Scrum? Est-il entraîneur? Est-il propriétaire d'un produit?
S'il est à l'intérieur de l'équipe comme un entraîneur ou autre (il travaille à une tâche de développement), vous pouvez lui demander pourquoi il sous-évalue sa propre productivité, car il semble que ce n'était pas le cas pour les autres membres de l'équipe. S'il pense 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 faire une demande aussi stupide, il a juste arrêté l'agilité.
Une règle de base est que le propriétaire du produit fixe l'objectif tandis que l'équipe définit ce qui peut être fait dans 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 choisir trois d'entre eux à la fois (et rappelez-vous: la qualité n'est pas une variable d'ajustement, essayer de couper les coins à travers la mauvaise qualité aggravera les choses).
S'il ne veut pas changer l'objectif actuel, peut-être qu'une augmentation de 40% de la productivité 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 vitesse au fil du temps grâce à une amélioration continue, mais certainement pas par décision arbitraire.
Essayer de changer la vitesse 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 lui expliquer cela?
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 la partie prenante et lui faire savoir que ses exigences ne peuvent être satisfaites dans le délai demandé. Le gestionnaire/analyste doit alors prioriser lesquelles des fonctionnalités DOIVENT être incluses et les autres qui peuvent attendre (ne serait-ce que quelques semaines). Si la partie prenante est déraisonnable, cela peut nécessiter l'intervention de cadres supérieurs, ce qui peut généralement être difficile et nécessiter un tout autre ensemble de discussions.
Si j'étais à votre place, je trouverais un cas détaillé expliquant pourquoi le projet EST va prendre autant de temps que prévu. Essayez également d'identifier les articles à faible retour. Trouvez les éléments qui n'ajoutent pas beaucoup de valeur et nécessitent des efforts de programmation substantiels et plaidez pour la suppression de ceux du sprint. Trouvez également une approche itérative qui délivre "X" à la date "Y" et assurez-vous que c'est faisable, puis proposez une itération de suivi qui leur donnera les éléments restants.
Fondamentalement, quelqu'un doit dire à la partie prenante ce qu'elle peut s'attendre à recevoir avant la date limite et que cela inclut la majorité de ses besoins. et que dans la version suivante, ils auront les éléments restants. Si le client est déraisonnable, la haute direction doit être impliquée, le gestionnaire devrait être en mesure de le faire.
Cependant, si le client a été trop promis et que personne n'a parlé jusqu'à présent, ce sera une bataille difficile. Ce n'est malheureusement pas une situation inhabituelle.
Renvoie le. C'est-à-dire aller au-dessus de sa tête et expliquer qu'il a perdu toute confiance en son équipe et expliquer qu'il n'a aucune valeur pour l'entreprise. Expliquez que les gestionnaires ayant ce niveau d'incompétence sont beaucoup plus faciles à remplacer que l'équipe ci-dessous.
Il n'y a aucune bonne raison de supporter un tel gestionnaire, mais cela ne devrait pas automatiquement signifier que les développeurs doivent démissionner. Il n'y a pas nécessairement quelque chose qui ne va pas avec l'entreprise, juste avec cette seule personne. Résolvez ce problème.
Et pour empêcher tout rejet de la part de la haute direction, indiquez clairement que ce n'est pas une erreur pardonnable. Cela signale que le gestionnaire responsable a non compréhension de l'équipe qu'il dirige. Cela ne se prête pas à la fixation, ni sur le marché du travail actuel. Les managers sont éminemment remplaçables, tout comme les entraîneurs sportifs. Les propriétaires ne licencient pas les équipes.
Maintenant, cela pourrait ressembler à une stratégie qui peut se retourner. Mais considérez: si la haute direction se range du côté de votre manager, vous seriez déjà de toute façon en perte. Donc, si vous ne considérez que les situations dans lesquelles vous n'êtes pas déjà dans cette position perdante, le résultat sera probablement beaucoup plus positif. Le vrai risque est que la haute direction ne fasse que licencier toute l'équipe, y compris le manager. Vous seul pouvez estimer ce risque. Apparemment, votre production est souhaitée, sinon ils n'en demanderaient pas plus, mais à quel prix?
Il semble que vous soyez confronté à deux problèmes.
La partie sur la mesure de la vitesse qui vous dérange 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. Pourtant, même une métrique imparfaite et subjective peut être utile. Il se pourrait que le vrai problème ne soit pas que votre équipe doive écrire plus de code, mais que les histoires doivent être plus valables.
L'autre problème est que sur la base de votre compte, votre manager s'attend à une augmentation de 40% de la productivité. Il n'était pas précisé dans votre question le contexte de cette demande. Ce pourrait être une bonne humeur si désireux de voir votre équipe s'améliorer. Ou cela pourrait être une indication pas si subtile que votre manager pense que votre équipe est sous-performante.
edit: D'après votre commentaire, la situation semble mauvaise. Il semble que votre entreprise prépare le terrain pour vous licencier, vous et votre équipe (peut-être aussi votre manager). Je vous suggère de chercher un autre emploi.
D'après mon expérience, il a été très, très difficile d'augmenter la vitesse réelle d'une équipe, étant donné que ni l'équipe, ni le domaine problématique ni la pile technologique ne changent.
Là où j'ai pu réaliser des augmentations, il s'agissait de:
nettoyer la dette technique; s'assurer que tout fonctionne avec la bonne version (pas nécessairement 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.)
l'amélioration des pratiques; couplage si possible (oui, j'ai trouvé que cela augmente la vitesse), en prenant le temps de refactoriser agressivement (idem!), et en étant impitoyable sur la portée et la concentration
trouver et/ou acheter les meilleurs outils pour le travail (par exemple, ReSharper pour .NET vaut son pesant d'or, Airbrake et Splunk pour Ruby, etc.)
Je suis d'accord avec d'autres ici qui disent que votre manager demandant une augmentation arbitraire de la vitesse est un drapeau rouge. Je chercherais un autre emploi comme une priorité élevée.
Votre manager demande (ou dit) à votre équipe de travailler des heures supplémentaires. Bien que la suppression des goulots d'étranglement et l'amélioration de l'efficacité puissent améliorer quelque peu votre vitesse, la seule façon d'obtenir cette augmentation (40%) est de travailler plus d'heures, car vous devez ajouter plus d'unités de travail pendant cette période.
Prenons un scénario.
Pour une interaction de deux semaines, disons 10 jours. L'utopie serait de 8 heures par jour, un point d'histoire étant résumé à une journée de travail. Donc, à partir du haut, votre velcoity serait de 8. Mais, relistiquement, les gens obtiennent probablement 6 bonnes heures par jour avec e-mail, réunions, pauses toilettes, etc. Alors maintenant, vous êtes à 6 par développeur. Votre point de référence est donc de 6. Supposons que vous vouliez que les gens fassent des heures supplémentaires, maintenant à 10 heures par jour. Ce serait donc 10 points de vitesse par développeur.
Votre vitesse fluctuera toujours, peut-être qu'elle était faible parce que vous avez dû faire face à beaucoup de bugs pendant cette itération, peut-être que les exigences manquaient, peut-être que quelqu'un est tombé malade pendant quelques jours. Peut-être était-ce élevé parce que le travail était surestimé ou que votre équipe avait consacré des heures supplémentaires.
Mais si vous êtes à 50 stables, vraiment pour atteindre 70, il faudra des heures supplémentaires.
Le problème avec la vitesse est qu'elle est une variable dépendante, une sortie mesurée de votre processus de développement. Exiger d'augmenter la vitesse de 40%, c'est comme essayer de se mettre au travail plus tôt en criant sur les voitures pour aller plus vite. La vitesse augmente en injectant plus de carburant et d'air dans le moteur ou en obtenant une voiture plus rapide, ainsi qu'en trouvant un itinéraire avec moins de trafic.
Travailler plus d'heures n'augmente pas la vélocité si vous la mesurez correctement, par exemple en points de fonctionnalité par heure de développeur. Cela ne fonctionne que si vous mesurez des points par jour, puis redéfinissez ce qu'est un "jour" à mi-mesure. Cela ne donne que l'illusion de la vitesse.
Une augmentation de la vitesse nécessite d'améliorer les 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 super-duper. Une amélioration de 40% nécessiterait des changements très importants.
Demandez si votre manager envisagerait de co-implanter votre équipe dans des bureaux fermés autour d'une salle de travail commune, d'acheter le tout nouveau matériel de développement de l'équipe ou d'embaucher quelques développeurs vraiment seniors pour encadrer l'équipe si cela lui permettait d'obtenir ses 40%. S'il n'y a pas de ressources disponibles pour améliorer les entrées de votre processus de développement, cela exclut à peu près tout intérêt sincère à l'amélioration. Cela laisse l'ingénierie inverse à votre manager pour comprendre ce qui le motive vraiment, ce qui ferait l'objet d'un tout autre 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 demande une augmentation de 40% de sa productivité ne connaît pas la première chose du développement logiciel.
J'aime toujours lire Phil Factor sur ce sujet:
Il existe deux voies de base dans la gestion informatique. Vous pouvez apprendre votre métier par le sang, la sueur et les larmes et gravir les échelons progressivement, en fonction de la crédibilité que vous avez acquise grâce à un savoir-faire technique durement gagné et à des projets réussis. Alternativement, vous pouvez enfiler un costume pointu et une cravate, apprendre le jargon et parler en douceur vers le haut.
Les deux itinéraires semblent tout aussi efficaces. Traiter avec cette dernière race peut certainement provoquer des moments de consternation et d'incrédulité… même du désespoir… et cela est documenté dans ces histoires.
Cependant, il est facile de devenir triste et aigri quand on rencontre l'incompétence technique dans des postes de pouvoir, et de tarer tous les managers avec ce même pinceau. Phil le déconseille. La plupart des managers travaillent dur et contribuent bien à l'entreprise, et même les managers pauvres peuvent être formés jusqu'au niveau requis, si vous suivez simplement quelques directives simples. Cela fait partie de la responsabilité de votre équipe d'aider votre manager à fonctionner d'une manière qui profite à tous.
En fin de compte, si vous ne pouvez pas les former, les faire promouvoir ou les éviter, vous pouvez peut-être apprendre à les aimer juste pour leur contribution involontaire à la riche comédie du lieu de 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 va juste voir ça comme une attaque personnelle.
Votre manager a mal compris l'utilisation de la vitesse. Ce n'est pas une métrique et ce n'est pas une cible. Son objectif est l'étalonnage de la charge de travail de l'équipe par sprint.
Si vous y réfléchissez, votre vitesse émerge d'une meilleure estimation, que vous remesurez après chaque sprint. Habituellement, au fil du temps, il devrait devenir quelque peu stable. Mais cela ne change pas le fait qu'il s'agit d'un sous-produit de ce que fait réellement votre équipe: créer de la valeur pour vos clients.
La raison pour laquelle il est mal de l'utiliser comme cible et/ou métrique est que cela en ferait une métrique de vanité. Cela semblerait bien sur le papier, mais cela ne ferait absolument rien pour 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).