Les sprints Scrum signifient-ils travailler au rythme le plus rapide possible?

21

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?

agile scrum development-methodologies

— JohnDoDo
source

Aucune expérience réelle avec Agile non plus, mais d'après ce que j'ai compris, votre charge de travail de sprint devrait être équilibrée avec la durée de votre sprint, donc soit les développeurs sous-estiment leur charge de travail, soit le gestionnaire leur donne juste du travail sans leur demander leur avis sur la charge de travail . Dans ce cas, probablement ce dernier. - Corrigez-moi si je me trompe, cependant

— Andreas

4

@gnat Je pense que les questions sont trop différentes

— Andreas

27

"... 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 ...". Courez comme le vent. C'est une idiote.

— JᴀʏMᴇᴇ

J'ai voté pour rouvrir cette question. La question du duplicata proposé est-agile-la-nouvelle-microgestion a en commun avec cette question, que le manager appelle quelque chose de "mêlée" et le demandeur veut savoir si c'est vraiment de la mêlée. Cette question concerne les "heures supplémentaires", la proposition concernant "il n'est pas permis de parler à d'autres développeurs".

— k3b

"... 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" semble être un conflit direct avec le concept clé du rythme durable - je travailler là-bas si je devais mettre de la nourriture sur la table. TVH, si cela se produit de temps en temps, cela ne me pose aucun problème. Parfois, malgré tous les efforts, il y a un problème et le client passe en premier. Mais elle donne l'impression que c'est un événement régulier et que c'est admirable. Cela signifie qu'ils ne font pas de cause profonde pour comprendre pourquoi cela se produit et résoudre le problème sous-jacent.

— Don Branson

27

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:

Les processus agiles favorisent le développement durable. Les sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.

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:

oui, Sprint est le nom d'une itération dans Scrum voir cette réponse pour la différence
oui, les équipes doivent travailler à un rythme durable. La seule certitude des heures supplémentaires est qu'il permettra de réduire les équipes de la productivité à long terme.
oui, c'est un drapeau rouge!

— Dave Hillier
source

23

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.

— Miki Watts
source

3

Une marche de la mort n'aurait-elle généralement pas de fin? Ce projet sonne comme un enfer éternel si c'est comme ça qu'ils fonctionnent sprint après sprint.

— DXM

5

Non, dans une marche de la mort, il y a toujours "nous avons juste besoin de passer à la prochaine version, puis nous pouvons refactoriser et corriger les bugs! version!" et ainsi de suite, vous avez l'idée.

— Miki Watts

2

@DXM, il prend fin lorsque tout le monde quitte ou est mis à pied. Les projets de la Marche de la mort peuvent durer des années.

— Dogweather

3

Les marches de la mort @DXM se terminent à votre mort.

— Dave Hillier

hmm, je suppose que je projetais ma propre expérience là-bas. D'une manière ou d'une autre, dans mon esprit, les projets mal gérés sont une combinaison de la marche de la mort suivie de mois d'indécision sur la prochaine étape. Notre équipe a été la plus longtemps assise sur le pouce avec un carnet de commandes vide pendant près de 8 mois. Ensuite, nous aurions 4 à 6 mois pour une sortie avec la déclaration "nous sommes sur un cycle de sortie annuel"

— DXM

11

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.

— Telastyn
source

8

«occasionnellement, faire des heures supplémentaires pour respecter ces engagements ( mal estimés )» => faire de fausses estimations une habitude

— gnat

1

@gnat - pssh. Les estimations sont parfois élevées. Les estimations sont parfois faibles. Si la sous-estimation devient une tendance, c'est certainement un problème. Mais c'est en grande partie pourquoi les itérations existent: pour aider à affiner l'estimation.

— Telastyn

8

Les ateliers clandestins de programmation n'acceptent généralement pas les négociations des travailleurs.

— maple_shaft

1

@gnat: Si vous trouvez, en équipe, que vous sous-estimez habituellement le travail, vous devriez vous engager à moins de travail lors du prochain sprint.

— Bart van Ingen Schenau

Lorsque les objectifs de la direction sont de faire le plus de travail possible, quelles que soient les limites des heures de travail (et l'expérience indique que cela est vrai dans la grande majorité des cas), et les objectifs des employés sont de faire le plus de travail possible sans dépasser le travail rémunéré heures (j'admets que certains gestionnaires peuvent affirmer que cela est optimiste), alors quelle que soit l'erreur inhérente à l'estimation, la planification tendra toujours vers> = heures de travail. L'extension logique est que les objectifs des employés doivent passer à une sous-estimation. @BartvanIngenSchenau c'est ainsi que cette habitude se développe naturellement.

— Steven Evers

1

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.

— jiggy
source

1

sauf que PO ne devrait pas participer au processus d'estimation. S'ils devaient être agiles, les équipes seraient les seules responsables de l'élaboration d'estimations et sur la base de ce que l'équipe estime que l'OP ne peut que modifier les priorités de l'arriéré.

— DXM

2

"L'équipe mettra de grosses estimations pour générer de beaux graphiques de combustion pour les PM.": C'est une des raisons pour lesquelles je pense que tout ce mécanisme est défectueux. Je pense qu'un manager peut obtenir de bien meilleures performances d'une équipe en qui il a confiance qu'en forçant une équipe à fournir des estimations à intégrer dans les graphiques.

— Giorgio

L'équipe devrait, mais comme je l'ai dit, elle est incitée à remplir les estimations. Si c'est l'OP qui paie, ils peuvent exercer une pression pour estimer plus agressivement. Pour le fond, je travaille dans le conseil, donc l'équipe Scrum est mes collègues, tandis que le PO est généralement externe et paie notre taux de facturation gonflé :)

— jiggy

@Giorgio, une équipe peu fiable peut toujours compléter les estimations et aggraver les choses. Mais une équipe de confiance, même composée d'experts, peut apprendre à mieux estimer. C'est pourquoi les estimations sont faites, puis comparées au travail réel, pour essayer d'améliorer leur capacité d'estimation. Le mécanisme n'est pas défectueux, avoir une équipe qui profite d'un système est le problème, et le sera quel que soit le système de gestion.

— Chris

1

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é.

— Cthulhu
source

0

Les processus agiles favorisent le développement durable. Les sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.

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.

— ptyx
source

0

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.

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 ... ;-)

— JensG
source