Mon chef de projet n'accepte pas le report dans Scrum - est-ce normal?
Je suis un développeur travaillant sur une nouvelle application mobile pour Android et iOS avec un gros composant backend. Nous avons participé à trois sprints de ce projet, et nous utilisons Scrum avec toutes ses cérémonies (raffinement , planification, quotidiens, rétrospectives, etc.).
Dans deux des sprints, l'équipe a dû travailler (non rémunéré) des heures supplémentaires et des week-ends, car la direction était très alarmée de ne pas terminer l'engagement de sprint à temps. Tout le monde a travaillé dur, mais certaines dépendances externes et des estimations optimistes nous ont poussés à accomplir toutes les histoires de sprint.
D'après mon expérience, avoir un petit pourcentage d'histoires non terminées pendant certains sprints est quelque peu normal, et ils peuvent être abordés dans le prochain. Mais notre chef de projet dit que c'est de notre faute car nous avons fait l'estimation nous-mêmes, nous devons donc compléter tous les éléments du sprint.
Est-ce une variation acceptable/courante de Scrum que je ne connais pas?
Comment proposez-vous que je devrais agir à ce sujet?
Quelques choses me viennent à l'esprit.
L'idée de la direction selon laquelle l'équipe s'engage dans un ensemble de travaux n'est pas cohérente avec les dernières versions du Scrum Guide. Le mot "commit" ou "engagement" n'est utilisé que deux fois dans la version la plus récente (novembre 2017) du guide Scrum - une fois lors de la liste des valeurs Scrum et une fois pour indiquer que "les gens s'engagent personnellement à atteindre les objectifs de l'équipe Scrum ".
L'idée d'objectifs est importante pour Scrum. Non seulement les organisations et les équipes ont des objectifs généraux, mais dans Scrum, chaque Sprint a un objectif Sprint qui est défini dans Sprint Planning comme une collaboration entre le Product Owner et l'équipe de développement. Le Sprint Goal est atteint en implémentant des éléments du Product Backlog, mais il ne s'agit pas simplement de "terminer ce travail" et il ne représente souvent pas le Sprint Backlog complet. Autrement dit, vous devriez être en mesure d'atteindre l'objectif de sprint sans terminer chaque élément de backlog de produit sélectionné pour le sprint ou chaque élément du backlog de sprint. Ma pensée actuelle est que le travail nécessaire pour atteindre l'objectif de sprint devrait se situer autour de 60 à 70% de la capacité de votre équipe, mais vous tenez compte de la capacité. Différentes organisations seront différentes, cependant, mais c'est probablement un bon point de départ.
Les heures supplémentaires et les week-ends sont également une pratique anti-Agile Software Development. L'un des principes sous-jacents est que toutes les parties prenantes d'un effort sont capables de travailler à un rythme durable. Les longues journées et les week-ends, même s'ils ont été payés, ne sont pas durables pour une équipe.
À ce stade, il y a quelques étapes suivantes. Le Scrum Master de l'équipe devrait éduquer la direction sur les valeurs et les principes de Scrum et du développement logiciel agile (tels que "l'engagement" et le "rythme durable"). L'équipe doit travailler sur sa capacité à prévoir le travail et à négocier la portée avec le Product Owner. L'équipe doit également identifier et travailler à résoudre ou à prévenir les obstacles qui ont conduit à cette situation (éliminer ou réduire l'impact des dépendances externes).
La situation que vous décrivez, où la direction exige que l'équipe fasse des heures supplémentaires pour terminer toutes les histoires planifiées, est l'une des raisons pour lesquelles la littérature Scrum a cessé d'utiliser le terme "engagement". Un véritable engagement ne peut être donné que lorsque toute incertitude est supprimée, y compris l'incertitude sur les dépendances de tiers, la quantité de travail de chaque élément, le temps dont chacun sera disponible en tenant compte de la maladie, etc.
L'une des idées de base de Scrum est que l'équipe travaille à un rythme durable, ce qui signifie essentiellement travailler des heures normales sans heures supplémentaires (rémunérées ou non). Cela signifie directement que vous rencontrez pas une variation acceptable de Scrum.
Ce que vous pouvez faire à ce sujet dépend de votre rôle.
Si vous êtes développeur, le mieux que vous puissiez faire est
- (collectivement en tant qu'équipe de développement) refusent de "s'engager" dans plus de travail que vous n'êtes absolument certain de pouvoir en livrer dans un sprint. Ce sera probablement beaucoup moins que ce que la direction attend de vous.
- concentrez-vous sur la fin du travail plutôt que de commencer de nouvelles tâches. Si vous voyez que certains travaux ne peuvent pas être terminés, indiquez-le le plus tôt possible afin que les plans puissent être ajustés.
Si vous êtes un maître Scrum, vous pouvez vraiment prouver votre valeur en éduquant la direction à propos de Scrum. Quelques points qui me viennent à l'esprit:
- Comme indiqué dans le premier paragraphe, l'équipe ne prend pas d'engagement lors de la planification du sprint, mais elle donne une prévision du travail qu'elle espère avoir terminé.
- Bien que l'équipe doive éviter d'avoir un travail inachevé à la fin d'un sprint, cette situation est presque inévitable au début d'un projet (ou après un changement dans la composition de l'équipe). La quantité de travail que l'équipe peut accomplir de manière réaliste dans un sprint ne peut être déterminée qu'en fonction des chiffres historiques des derniers sprints de l'équipe dans cette composition. Au début du projet, de telles figures historiques n'existent tout simplement pas, donc une équipe accomplissant dans les 3 premiers sprints exactement ce qui est prévu pour chaque sprint est plus accidentelle qu'une bonne planification. Après environ 5 sprints à un rythme soutenable, il y a suffisamment de données pour avoir une idée raisonnable de la quantité de travail que l'équipe peut terminer de manière réaliste dans un sprint.
Votre PM n'a aucune entreprise impliquée dans votre mêlée.
Votre PM n'a aucun problème à vous demander des heures supplémentaires non rémunérées.
La chose évidente à faire est d'estimer toutes les tâches de manière à garantir qu'elles seront terminées à temps. Ensuite, vous devriez pouvoir aller au pub de la deuxième manière, car clairement si sous-estimer une tâche signifie que vous l'avez terminée gratuitement, alors surestimer signifie que vous avez du temps sans travail.
Il y a un certain nombre d'aspects à cela, mais à un niveau élevé, oui - le PM voudra absolument comprendre clairement pourquoi le travail prévu n'a pas été achevé. Cependant, cela devrait être soulevé (et résolu) dans la rétrospective. Du côté des développeurs, de nombreux facteurs peuvent contribuer aux échecs de sprint.
Certaines choses que vous voudrez peut-être considérer:
Trop dans le sprint
Si vous vous engagez régulièrement à trop de travail, les sprints échoueront. La vitesse de sprint doit être suivie dans le temps pour savoir quel est le nombre optimal de points (ou jours).
allocation des ressources
Assurez-vous que la planification du sprint tient correctement compte des activités non liées au développement, telles que les cérémonies, les vacances, la formation, l'administration, le soutien et d'autres projets, etc. vous mettre sur le pied arrière dès le départ.
Variation estimée
Vous faites du raffinement, mais y a-t-il certaines sortes de tâches qui dépassent toujours? Il s'agit généralement d'exigences manquantes ou vagues. Si les exigences sont laineuses, l'histoire ne devrait même pas entrer dans le sprint à moins qu'elle n'ait été suffisamment affinée ou qu'un pic n'ait été prévu.
vitesse
Si la vitesse est correctement suivie, le vrai nombre d'histoires devrait devenir clair. Cela ne veut pas dire qu'ils seront toujours faits à temps, mais cela devrait rendre les choses beaucoup plus faciles.
Bonne volonté
Sur tout projet, la bonne volonté est limitée. Si vous travaillez constamment en dehors des heures de livraison, le moral en souffrira et les développeurs s'épuiseront - c'est un échec de gestion de projet =. Comme je l'ai déjà indiqué, assurez-vous que la planification du sprint ne planifie qu'un nombre réaliste d'histoires en utilisant la vitesse et les pointes pour vous aider tout au long du processus.
pointes
Si un article est mal raffiné ou simplement laineux, n'ayez pas peur de mettre un pic pour fournir une meilleure estimation pour les sprints ultérieurs. Oui, certaines personnes sont simplement mauvaises à l'estimation, mais la plupart du temps, les faits complets ne sont tout simplement pas connus à l'époque. Idéalement, cela aurait dû être couvert dans le raffinement ou ramassé tôt par l'OP, mais parfois ils peuvent se glisser dans un sprint. Les développeurs devraient repousser ces efforts, car ceux-ci peuvent facilement torpiller un sprint qui se déroule normalement.
Non, ce n'est pas une forme reconnue d'Agile, pour une raison très importante: si vous vous engagez à livrer tout , vous ne faites pas Agile, vous faites Waterfall - et si vous pensez que vous faites Agile à la place, vous faites probablement Waterfall mal , à ce. Je suis sûr que vous avez entendu le vieux voir "bon, rapide, bon marché, choisissez-en deux", non? Avec le développement de logiciels, c'est plus comme "toutes les fonctionnalités livrées, dans les délais, selon le budget, choisissez la première ou les deux autres". Waterfall choisit le premier et Agile choisit les deux autres.
Si vous allez être agile, vous avez besoin de la flexibilité pour supprimer les histoires du sprint que vous ne pouvez pas terminer à temps. Une façon possible de le faire est de demander à votre Product Owner d'évaluer les histoires en utilisant la hiérarchisation MoSCoW. Cela impliquerait de ne pas sélectionner plus de 60% des histoires (par le nombre total de points d'histoire) en tant que Must Haves qui seront terminées, 20% en tant que devoir Haves que vous devez compléter à la fin du projet et le produit minimum viable est publié, 20% en tant que Pourrait Haves qui pourrait être terminé si vous avez le temps, et quoi que ce soit en dehors de la portée de la version actuelle comme Won't Haves. Il est également important de noter que lorsqu'ils sont combinés, les Must Haves devraient avoir suffisamment de viande jusqu'à leurs os pour créer le produit minimum viable sans avoir à inclure des éléments des autres catégories.
La décision de supprimer ou non des éléments du Sprint Backlog est de la responsabilité du Product Owner, après que cela a été demandé par l'équipe, et tous les éléments qui sont supprimés du Sprint Backlog sont évalués par le Product Owner, puis sont soit supprimé du projet entièrement ou placé sur le carnet de commandes du projet dans une position correctement classée.
Dans ce cas, je suppose que votre Product Owner est votre Project Manager, non? Ce serait son travail de déterminer les tâches à abandonner, donc il ne devrait certainement pas vous reprocher de trop vous engager, car ce serait son travail de supprimer les tâches pour compenser cela, et il semble qu'il ne le fasse pas.
Il a raison, qu'il ne devrait pas y avoir de report entre les sprints. Les équipes Scrum ayant un report entre les sprints sont un anti-modèle et non quelque chose que Scrum canonique accepte comme résultat valide.
Mais son approche n'est pas bonne.
Pendant un sprint, l'équipe doit surveiller en permanence le travail en cours et si elle peut respecter son engagement de planifier le sprint pour terminer les histoires sélectionnées. Si l'équipe identifie qu'elle ne peut pas terminer toutes les histoires, elle doit rencontrer le PO et sélectionner une histoire à retirer du sprint. Ce faisant, tout le monde ARRÊTE DE TRAVAILLER SUR L'HISTOIRE et se concentre sur la réalisation des histoires restantes. N'oubliez pas: il vaut toujours mieux terminer une histoire complètement que d'avoir deux histoires à moitié terminées.
Les problèmes de dépendances externes et d'estimation imprécise expliquent exactement pourquoi les rétrospectives existent. Pendant Retro, l'équipe doit réfléchir et identifier ces problèmes. Et l'équipe devrait ensuite trouver et mettre en œuvre des solutions à ces problèmes. Les estimations peuvent être rendues plus précises en connaissant mieux le système et l'expérience concrète. Les dépendances externes sont plus difficiles, mais pas impossibles à corriger.
Votre PM ( que fait même PM faire sur une équipe Scrum ?? ) ne devrait pas être autorisé par Scrum Master à vous forcer pour finir toutes les histoires. Au lieu de cela, s'il se plaint, il devrait les garder pour la rétrospective. Et encore mieux, devrait faire partie de la résolution des problèmes qui ont empêché la fin des histoires à temps.
Est-ce une variation acceptable/courante de Scrum que je ne connais pas?
Non. C'est complètement faux. Je pourrais peut-être sympathiser avec payé heures supplémentaires, si le PO a fait l'erreur de donner les estimations comme faits avant la fin du sprint , mais non rémunéré les heures supplémentaires sont complètement ridicules et me feraient chercher un autre emploi dès que possible.
Comment proposez-vous que je devrais agir à ce sujet?
D'après mon expérience, les gens qui font autant de chemin de fer n'écouteront pas les arguments logiques. La seule façon pour eux de voir à quel point il est cassé est show, not tell. Donc, la prochaine fois que vous estimez et vous engagez, engagez-vous le plus petit montant possible . Engagez-vous à terminer un petit ticket à la fin du sprint. Celui que vous pourriez faire en une journée. Voyez comment votre PM réagit. Ensuite, lancez une discussion à partir de là sur ce à quoi le système est utilisé et à quoi le système devrait être utilisé pour.
Généralement, au début du projet, lorsque nous décidons de la vitesse de l'équipe, nous optons pour un nombre conservateur (inférieur à la normale) compte tenu du fait qu'il s'agit d'une nouvelle équipe, il faudrait un peu de temps à l'équipe pour s'installer , se comprendre, comprendre les exigences fonctionnelles et NFR, etc. Fondamentalement, après les premiers sprints, nous optimisons la vitesse de l'équipe et, évidemment, la vitesse ne s'améliorera qu'à partir de ce point.
Il est inutile d'engager une vitesse plus élevée au début et d'étirer l'équipe pour y parvenir.
Une autre chose est que, dans un scénario ponctuel, où il y a un engagement de livraison qui ne peut être manqué, les chefs de projet peuvent faire pression sur l'équipe pour s'étirer, travailler tard et travailler le week-end. Mais alors cela doit être considéré comme une exception et non comme la norme de travail. Travailler comme ça pourrait augmenter la vitesse à court terme, mais à plus long terme, cela serait contre-productif, car cela pourrait entraîner des problèmes de qualité du code, des problèmes d'épuisement professionnel, une équipe mécontente avec une faible motivation, etc.
FAQ sur l'engagement
Ce comportement est-il normal?
Je ne suis pas sûr.
Est-ce surprenant?
Non. Certaines personnes comprendront toujours "engagement" pour signifier tout dans l'engagement doit être rempli.
Est-ce que c'est une bonne idée?
Non. Le développement agile a durabilité comme sujet central: Travaillez seulement autant/longtemps/dur que vous pouvez le faire indéfiniment. C'est une idée sensée dans la plupart des cas. (Si votre direction n'accepte pas cela, elle ne doit pas appeler son organisation agile.)
Que devrions nous faire?
- Expliquez que le contenu du sprint est basé sur un estimation. "Estimer" signifie que ce ne sera parfois que correct - et généralement faux. Quand c'est faux, c'est parfois trop bas et parfois trop haut.
- Expliquez qu'il est beaucoup plus facile de modifier le comportement d'estimation que la vitesse de travail.
- Expliquez que lorsque l'équipe est punie pour avoir estimé trop élevé, elle estimera simplement plus bas et la direction perdra beaucoup plus de progrès de cette façon qu'en poussant occasionnellement une partie du contenu d'un sprint à l'autre.
Ce qui est bien, c'est que votre chef de projet saura déjà toutes ces choses et les reconnaîtra comme étant exactes. C'est seulement que à court terme on peut préférer les ignorer.
Je ne suis pas d'accord avec votre équipe de direction. Ils n'auraient pas dû vous faire travailler des heures supplémentaires pour terminer le sprint.
Cependant, l'idée que des engagements ne sont pas possibles vient d'une mauvaise compréhension du développement logiciel. J'ai vu de nombreuses équipes essayer de prédire les histoires qu'elles peuvent terminer dans un sprint par le nombre de points d'histoire qu'elles ont terminés dans les sprints précédents. Si c'était possible, cela signifierait que le développement logiciel est linéaire, c'est-à-dire que si je travaille deux heures, j'en fais deux fois plus qu'en une heure.
Le développement de logiciels est créatif et donc non linéaire. C'est une meilleure pratique pour l'équipe de dire à la direction ce qu'elle peut faire dans un sprint, puis de livrer ces histoires. Si vous manquez constamment vos engagements, vous n'aviez aucune idée de la portée de l'histoire pour commencer ou vous êtes poussé par votre propriétaire de produit à en prendre plus.
Dans le premier cas, vous devez vous assurer que vous comprenez la portée de l'histoire avant d'accepter de la reprendre. Si c'est le dernier, vous avez un problème de culture et il n'y a pas grand-chose à faire.