J'ai récemment interviewé des entreprises qui font de l'Agile, Scrum pour être plus précis et il y a des choses qui ne me semblent pas tout à fait Agiles. Je vais prendre un cas qui m'intéresse particulièrement en ce moment, celui des Scrum sprints.
Un chef de projet particulier à qui j'ai parlé (oui, j'ai dit chef de projet) a fièrement déclaré que les membres de son équipe comprenaient ("on m'a dit" c'est ce que j'ai retenu du contexte) que vous ne rentrez pas chez vous lorsque les heures de travail sont terminées , vous rentrez chez vous lorsque le travail est terminé, peu importe combien cela prend. Ce que j'ai lu entre les lignes, c'est que nous emballons autant de fonctionnalités que possible dans un sprint et travaillons des heures supplémentaires pour y arriver.
Maintenant, je n'ai pas encore fait Agile (j'ai travaillé avec des institutions financières et gouvernementales qui préfèrent encore la cascade), mais je crois comprendre que:
- sprint dans Scrum est le nom de l'itération générique dans Agile;
- l'équipe devrait travailler à un rythme soutenable et essayer d'éviter les heures supplémentaires à long terme car cela n'a des effets que sur le court laps de temps et les effets sont éclipsés par les problèmes qu'ils rencontrent sur le long terme.
Mes déclarations sont-elles exactes? Et, dois-je prendre la présentation du manager comme un drapeau rouge?
la source
Réponses:
Vous n'avez pas besoin de chercher loin pour voir que ces pratiques vont à l'encontre des principes d'Agile. L'un des principes du Manifeste Agile stipule:
Il y a quelques années, Scrum a opéré un changement subtil mais important . Au lieu que les équipes s'engagent dans le travail qui peut être accompli, elles prévoient ce qu'elles pensent pouvoir faire.
Le changement vient de l'abus, qui ressemble beaucoup à l'attitude de ne pas rentrer à la maison jusqu'à ce que vous décriviez. Pendant le développement, il y a de nombreux facteurs hors du contrôle des équipes sur lesquels ils ne peuvent pas s'engager - pour utiliser l'analogie avec la météo, vous ne pouvez pas "vous engager" qu'il pleuvra demain.
Pour répondre directement à vos questions:
la source
Oui, vous avez raison, et si on me disait ce qu'on vous a dit, je m'enfuirais le plus vite possible. Ils utilisent simplement l'agile comme excuse. Cela ressemble à la marche de la mort classique.
la source
Il y a une chose clé qui peut rendre cela acceptable: l'équipe accepte la portée du sprint.
Dans Scrum, les équipes ne se contentent pas de se voir confier un travail. Le propriétaire du produit négocie avec l'équipe pour prioriser le travail sur le produit et le travail technique (dette). Le chef de projet, le propriétaire du produit et l'équipe négocient ensuite sur ce qui est tiré dans un sprint et quelle est la portée de ce travail.
Dans ce monde, l'équipe dit essentiellement "nous pouvons faire le travail X, tester et expédier cette itération". Je m'attends donc à ce qu'une équipe fasse occasionnellement des heures supplémentaires pour respecter ces engagements.
Cela dit, tant d'endroits bastardisent l'agile - et si peu de chefs d'équipe peuvent négocier efficacement avec des gens qui sont généralement leurs patrons ... Je considérerais cela comme un énorme drapeau rouge.
la source
Scrum est divisé en sprints où vous estimez un ensemble de tâches à accomplir pendant la durée de ce sprint (généralement 2 semaines, mais j'ai vu de 1 jour à 4 semaines). Je pense que cela crée une incitation à sous-estimer les tâches. Les PO (propriétaires de produits) voudront des estimations basses pour obtenir un gros engagement par sprint. L'équipe mettra de grosses estimations pour générer de beaux graphiques de burndown pour les PM à voir. Ce sont, bien sûr, indicatifs d'une organisation merdique. Vous voulez vraiment obtenir des estimations précises et ne pas avoir peur de ne pas être à la hauteur et de reporter les histoires au prochain sprint ou de terminer tôt et de retirer des tâches supplémentaires de l'arriéré. Je pense que le terme «sprint» crée cette image de personnes travaillant plus rapidement.
la source
Non: les sprints scrum sont une timebox, rien de plus, rien de moins. Au début du sprint / de l'itération, l' équipe donne une estimation du nombre de points d'histoire qu'elle pense pouvoir atteindre, en fonction de choses comme les performances précédentes, la disponibilité, les événements à venir, les obstacles ouverts, etc. Ils négocient ensuite avec le propriétaire du produit sur les user stories mises dans le sprint. C'est (ou était? Voir autre réponse) l' engagement que l'équipe donne au propriétaire du produit.
Pendant le développement, s'il s'avère que les choses ne sont pas vraiment comme prévu (c'est le développement de logiciels après tout) et qu'il y a un risque que l'équipe ne respecte pas l'engagement, ils informent le propriétaire du produit qu'il y a un risque qu'une ou plusieurs histoires pas terminé.
Et ça va. Bien sûr, ça fait du mal de devoir admettre à la fin du sprint que le sprint a échoué, mais ce n'est pas une défaite, c'est une opportunité d'amélioration. Parce qu'à la fin du sprint / début du nouveau, vous pouvez faire une rétrospective du sprint, et la première chose que tout le monde demandera est 'Pourquoi avons-nous échoué à ce sprint, et que devons-nous faire pour ne pas échouer à nouveau ? '. Une option serait de dégager moins d'engagement (= prendre moins de points d'histoire).
tl; dr: Sustainable Pace. Scrum concerne la cadence, quelque chose que l'équipe peut suivre indéfiniment de sprint à sprint. Les heures supplémentaires ne le sont pas; l'équipe deviendra surmenée, le travail deviendra bâclé, les membres appelleront malades ou arrêteront complètement, et alors vous aurez un problème bien plus grave qu'un sprint raté.
la source
Des gens du Manifeste Agile
Faire des heures supplémentaires tout le temps ne me semble pas viable.
Cela dit, je ne vois aucun problème à ce qu'un engagement de printemps soit fort (si c'est la façon dont l'équipe veut travailler), et devoir faire des heures supplémentaires lorsque vous engagez trop ou fous des estimations est une bonne incitation à améliorer vos estimations ou à communiquer. attentes à PO.
la source
Ce n'est pas Scrum. La charge de travail proposée pour une boîte de temps est basée sur la vitesse de l'équipe , pas sur la liste de souhaits du manager. Ils essaient simplement de vous inciter à croire que faire des heures supplémentaires sans fin est «Agile», ce qui n'est pas le cas. L'équipe deviendra plus efficace tout en travaillant sans être dérangée et concentrée, mais Scrum n'est pas une baguette magique pour des gains d'efficacité sans fin .
Soit le gestionnaire a une légère incompréhension d'Agile, soit (plus probablement) il pense que les développeurs sont aussi stupides. D'un autre côté, lorsque l'équipe accepte le sprint encore et encore, sachant qu'elle devra faire des heures supplémentaires, peut-être est-elle vraiment stupide et ne la mérite-t-elle pas mieux?
Je suppose que vous connaissez la réponse ... ;-)
la source