Comment puis-je traiter avec une équipe Scrum contre-productive?

Backstory:
Je fais partie de cette équipe depuis trois ans et nous avons eu trois Scrum Master différents qui ont tous géré les choses différemment.

En raison de ce changement dans Scrum Masters et de leur manière de diriger le spectacle, mon équipe est restée engourdie par l’idée de Scrum car les principes n’ont pas été respectés et un des Scrum Masters était une personne qui ne croyait pas en l’agile. développement et a simplement gardé les événements et les artefacts en tant que novice pour se conformer aux décisions de la société.

Maintenant, les membres de mon équipe sont ennuyés et ennuyés lorsque nous organisons des événements Scrum et une personne en particulier est très verbale à ce sujet.

Présent:
Il y a deux mois, la société m'a nommé Scrum Master de mon équipe pour son dévouement au travail agile et à ses principes.

Je souffre énormément de la pression atmosphérique due à la réticence des membres de mon équipe à faire Scrum.

Comme mentionné, ils sont ennuyés par l'ensemble du processus, ce qui me rend très difficile, car ils ne participent pas aux conversations nécessaires pour rendre Planification, Rétrospective et Daily Scrum efficaces.

Pour eux, la planification n’est qu’une perte de temps, car nous ne faisons que déborder du nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s’embêter.

Pendant la rétrospective, je peux simplement sentir qu'ils veulent dire "Arrête de faire Scrum". Une personne le fait, mais les autres se taisent et je dois régler ce problème à chaque fois.

Daily Scrum est encore une perte de temps pour eux, car aucun d’eux ne veut parler et planifier sa journée. Ils disent simplement: "J'ai travaillé sur la tâche X hier et y travaillerai encore aujourd'hui". Et la plupart du temps, ils plaisantent jusqu'à ce que je devienne plus sévère.

J'ai été très important quand il s'agit de la façon dont ils ont passé leur temps lors de ces événements. Mais je meurs intérieurement parce que je suis passionné par cela et ils ne s'en soucient plus.

Aujourd'hui, la personne qui est toujours contre moi m'a dit de cesser de dire: "Ils ont dit que c'était ce qu'ils s'engageaient pour ce Sprint" parce que, selon ses mots, "Nous ne terminons jamais un Sprint. Nous ne faisons que déplacer des tâches et en intégrer de nouvelles dans le prochain sprint pour remplir un quota. Nous faisons KanBan en réalité. Alors arrêtez de dire ça. "

Je comprends pourquoi il dit cela, mais il ne semble pas se rendre compte que c’est comme cela parce que lui et tous les autres membres de l’équipe ne s’inquiètent pas. Ils travaillent simplement au lieu de gérer les obstacles. Ils se plaignent des obstacles, mais ne font rien à leur sujet. Et quand j'essaie d'aider, ils s'en vont.

Ils s'en foutaient, mais au cours des deux dernières années, leur volonté a décliné de fond en comble.

Comment leur faire comprendre que plaisanter et perdre du temps lors de ces réunions coûtent beaucoup d'argent à l'entreprise?

Vous avez peut-être entendu beaucoup de statistiques sur les projets logiciels ayant échoué et vous êtes parvenu à la conclusion que l'échec n'était pas de nature technique. Des centaines de solutions techniques permettent de résoudre les problèmes technologiques, mais résoudre des problèmes dans votre environnement de travail en utilisant Scrum ne fonctionnera pas.

Ma suggestion ici est de cesser complètement de considérer cela comme une question technique. Il ne s'agit pas de Scrum, il ne s'agit pas de relevés quotidiens, de sprints, de rétrospectives ou autres Vous devez entrer en contact avec votre équipe et trouver une méthode de travail efficace qui les satisfasse aussi bien que vous et vos supérieurs.

S'ils pensent que les quotidiens sont une mauvaise idée, vous ne devriez pas leur dire de les faire et d'essayer de leur donner raison. Pensez par vous-même à ce que les quotidiens vous proposent. Vérifiez auprès de votre équipe si elle apprécie également ces avantages. Découvrez pourquoi ils ne partagent pas votre compréhension - comme pour comprendre leur point de vue, et non comme pour les convaincre de quoi que ce soit. Ensuite, vérifiez si les quotidiens aident réellement votre équipe ou si vous pouvez en faire plus avec un autre mécanisme. Ce qui est amusant avec les Scrum masters, c’est qu’ils sont au service de leur équipe - vous pouvez bien leur servir au mieux en abolissant complètement Scrum.

En résumé, arrêtez de vous concentrer sur Scrum et revenez plutôt aux bases de l'agilité. Vous voudrez peut-être commencer par le manifeste agile : Valorisez les individus et les interactions par rapport aux processus et aux outils.

D'après mon expérience, les équipes désillusionnées doivent commencer par disposer de rétrospectives efficaces. C’est pourquoi, à mon avis, les rétrospectives sont le seul élément obligatoire d’un processus agile. Tout le reste est sujet au changement à travers les rétrospectives.

Lors de rétrospectives efficaces, vous ne vous contentez pas de vous plaindre de vos problèmes, vous en choisissez au moins un et identifiez les solutions possibles, puis vous essayez cette solution à la prochaine itération. Lors de la rétrospective suivante, vous expliquez comment cette solution a fonctionné ou n'a pas fonctionné et apportez des ajustements supplémentaires si nécessaire ou choisissez un autre problème sur lequel travailler.

Lorsque les membres de l'équipe s'aperçoivent qu'ils ont le pouvoir d'effectuer des changements réels dans leur processus, ils deviennent plus disposés à participer.

Le processus rétrospectif est la raison pour laquelle, si vous visitez toutes les équipes d’une entreprise agile, elles le font toutes un peu différemment. Nous avons des équipes qui font du Kanban, certaines qui font de l’XP, d’autres qui ne se lèvent que lundi, mercredi, vendredi.

Si votre équipe n'aime pas la façon dont vous gérez la gueule de bois, réfléchissez à différentes approches. J'ai conquis les développeurs très réticents en écoutant systématiquement les rétrospectives et en essayant des solutions.

Ok donc commençons rudement - une grande partie du problème est avec vous - Vous entendez, mais vous n'écoutez pas. Votre équipe vous dit clairement quels sont les problèmes. Vous devez vous adresser à eux au lieu de blâmer votre équipe.

Planification

Pour eux, la planification n’est qu’une perte de temps, car nous ne faisons que déborder du nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s’embêter.

Exactement. Si vous omettez systématiquement d'allouer le temps correct aux tâches et que celles-ci sont constamment sous-estimées, cela a des effets très négatifs:

• Les développeurs se sentent constamment sous pression.
• "Je ne peux rien faire à temps".
• Comme le processus ne fonctionne pas, ils le voient à juste titre comme une perte de temps.

Solution : corrigez vos estimations en utilisant une combinaison de:

• Points de récit (en combinant temps et risque).
• Ne pas autoriser les tâches dans un sprint supérieures à 55 PS
• Estimations comparatives
• Planification basée sur des preuves

En guise de base, vous devez absolument suivre le temps qu'il a effectivement fallu pour terminer les tâches précédentes. Cela inclut les tests, la rédaction de la documentation, la rédaction des tests, la formation des utilisateurs finaux, les efforts d'intégration, le déploiement. etc.

Une fois que vous avez le temps total pour une tâche donnée, vous pouvez baser le temps attendu sur ces tâches précédentes.

Demandez à chaque membre si la tâche qui leur est confiée vous semble plus compliquée ou plus facile que la sélection des tâches précédentes, ajustez le nombre de tâches attribuées en fonction de cela.

Si vous n'avez pas utilisé SP auparavant, mon conseil est de commencer par 1h de vrai travail honnête avec dieu = 5SP à titre indicatif. Gardez à l'esprit que dans l'environnement de développement habituel, vous en obtiendrez peut-être 6 par jour, donc 30 PS / jour maximum . Ne permettez jamais à une tâche de prendre plus de 2 jours pour être inscrite au tableau. Idéalement, d'après mon expérience, vous devriez avoir 2 tâches par jour.

Si vous ne planifiez pas correctement, le reste de vos activités Scrum ressemblera à une perte de temps (y compris la planification).

Rétrospective

Pendant la rétrospective, je peux simplement sentir qu'ils veulent dire "Arrête de faire Scrum". Une personne le fait, mais les autres se taisent et je dois régler ce problème à chaque fois.

Cela me rappelle Daily beatings will continue until morale improves!deux emplois passés. Si vous ne supprimez pas les obstacles, ils ont alors raison de dire que c'est une perte de temps.

Encore une fois, écoutez ce que les gens disent réellement. Si les plaintes soulevées lors de la rétrospective ne sont pas traitées, pourquoi se donner la peine de les traiter?

Alors:

• Considérez les techniques Six Thinking Hats pour améliorer la communication.
• Réduisez le temps passé sur Rétrospective, maximum 30 minutes.
• Assurez-vous que les plaintes formulées lors de la rétrospective sont traitées avant la prochaine.

SCRUM quotidiens

Daily Scrum est encore une perte de temps pour eux, car aucun d’eux ne veut parler et planifier sa journée. Ils disent simplement: "J'ai travaillé sur la tâche X hier et y travaillerai encore aujourd'hui". Et la plupart du temps, ils plaisantent jusqu'à ce que je devienne plus sévère.

On dirait que vous avez deux problèmes ici: les réunions SCRUM sont trop longues et votre planification et la création de tâches sont nulles.

Les deux peuvent donner l'impression qu'une réunion de mêlée est une perte de temps.

Pour la longueur SCRUM:

• Essayez 15 minutes maximum.
• Essayez tout le monde debout.
• Formule fixe:
  • Qu'as-tu fait hier?
  • Que comptez-vous aujourd'hui?
  • Ce que les membres de votre équipe (pas vous!) Devraient savoir sur la tâche, comment cela va les affecter.
• Ne vous embêtez pas avec des obstacles si vous n'allez pas les aborder.

C'est une deuxième preuve que votre planification nuit à votre situation - si vous n'avez rien de précis à signaler, cela signifie généralement que la tâche est trop lourde et que tout ce que vous pouvez dire, c'est: je travaillais là-dessus.

• Décomposer les tâches en points critiques.
• Assurez-vous que les tâches sont suffisamment petites pour prendre moins d'une journée. Dans l’idéal, la tâche de l’OMI devrait durer environ 3 heures et équivaloir à 13 SP environ, de sorte que vous puissiez en faire 2 par jour dans la plupart des conditions.

Traiter avec l'équipe

Aujourd'hui, la personne qui est toujours contre moi m'a dit de cesser de dire: "Ils ont dit que c'était ce qu'ils s'engageaient pour ce Sprint" parce que, selon ses mots, "Nous ne terminons jamais un Sprint. Nous ne faisons que déplacer des tâches et en intégrer de nouvelles dans le prochain sprint pour remplir un quota. Nous faisons KanBan en réalité. Alors arrêtez de dire ça. "

Il a raison. Vous avez tort. Vous faites un SCRUM bâtard et / ou une variation sur le Kanban. Pas de leur faute du tout.

Je comprends pourquoi il dit cela, mais il ne semble pas se rendre compte que c’est comme cela parce que lui et tous les autres membres de l’équipe ne s’inquiètent pas.

Je ne pense pas que vous comprenez du tout. Ils se soucient peut-être moins qu'avant, cependant, les blâmer ne permettra pas d'améliorer rien, cela pourrait simplement aggraver la situation. Si c'était le fond, ils pourraient commencer à creuser.

Ils travaillent simplement au lieu de gérer les obstacles.

Et là, je pensais que faire leur travail était leur travail. Je me demande qui était supposé avoir affaire à des empêchements ... oh oui. Un Scrum Master. C'est ton travail. Ils vous disent ce qui ne va pas. Vous le réparer. Pas l'inverse.

C'est probablement pourquoi vous avez tant de problèmes dans la rétrospective.

Comment puis-je leur faire voir que les plaisanteries et les cercles saccadés lors de ces réunions coûtent beaucoup d'argent à l'entreprise?

Arrêtez les réunions inutiles et ils vont plutôt plaisanter autour du refroidisseur d'eau. Voir également le paragraphe sur les passages à tabac qui améliorent le moral. S'ils utilisent l'humour comme mécanisme de défense, vous avez de sérieux problèmes, monsieur!

Plongez dans une blague - comme dans le travail avec votre équipe, pas contre. (Qui le fuuuuuuck se soucie de l'argent de la société? Êtes-vous actionnaire maintenant?)

Résumer

Votre mauvaise planification fait échouer d’autres parties de SCRUM, et tous ceux qui participent participent malheureux. Ils voient que rien ne change, que rien n’est adressé et que leurs plaintes ne sont pas entendues.

Améliorez votre planification et vous améliorerez le flux et le moral.

En éliminant les obstacles, votre équipe progressera plus rapidement. Demandez-leur ce qu'ils pensent que vous devriez faire pour les aider.

Le plus important: écoutez votre peuple. Ils vous ont déjà dit (et moi) quel est le problème.

Bonne chance!

L'un des principes agiles majeurs est de revenir en arrière et de corriger ce qui ne va pas. Cela inclut non seulement le refactoring de code et les corrections de bugs, mais également la résolution du processus de développement.

Alors, pourquoi ne pas organiser une réunion avec votre équipe et voir comment améliorer le processus de développement? Si cela signifie, pas de réunions Scrum ou Standup, alors soit-il.

En outre, vous enfreignez l'un des principes du manifeste agile : "Les individus et les interactions par-dessus les processus et les outils".

D'autre part, si votre équipe pense que le développement itératif est mauvais, alors vous le faites peut-être mal. Peu importe si vous ne terminez pas tout ce que vous avez prévu pour une itération - vous pouvez toujours déplacer les choses à la prochaine itération. C’est aussi pourquoi vous marquez les choses comme "doit contenir", "agréable à avoir", etc. Tant que vous fournissez de nouvelles fonctionnalités, vous le faites bien.

Juste un petit coup de gueule: dans mon entreprise précédente et actuelle, nous avons fait et nous organisons toujours des réunions debout. D'après mon expérience, elles représentent une perte de temps considérable, puisqu'elles se transforment chaque fois en plus de 30 minutes en réunions de rapport de statut et ne fournissent que peu, voire aucune information. Les gens parlent de leurs problèmes et, honnêtement, cela m'est égal.
Dans mon entreprise précédente, ils étaient intelligents, reconnaissaient ce problème avec les redressements et les arrêtaient peu de temps après que les gens aient commencé à se plaindre.

Si vous aimez voir une très bonne vidéo sur la mêlée, consultez " Robert C. Martin - La terre que Scrum a oublié ".

En priorité, je regarderais les tâches qui continuent à être reportées. Ne pas atteindre les objectifs est extrêmement démoralisant. Vous engagez-vous trop? Y a-t-il des fatlogs qui devraient être décomposés? Y a-t-il des goulots d'étranglement hors de votre contrôle? Avez-vous une définition claire de "terminé"? Les exigences sont-elles claires? Le nombre d’heures par développeur est-il raisonnable (c’est-à-dire qu’il prend en compte les tâches administratives, les mises en attente, la planification, les rétrospectives, les ruptures de clavier, le travail hors projet)

Ensuite, abandonnez tout ce qui ne fonctionne pas. Processus sans valeur est juste un voleur de temps. Les standups peuvent prendre beaucoup de temps s'ils ne sont pas ciblés et ne fournissent pas de valeur à l'équipe. Les heures pourraient être mieux dépensées ailleurs. Peut-être aussi envisager de séparer l'équipe si elle est trop grande.

Essayez de comprendre ce qui démotive l’équipe. Ayez des rétrospectives et, plus important encore, agissez sur les résultats. Il est tout aussi important de célébrer les succès que de regarder les échecs.

Enfin, vous voudrez peut-être évaluer les approches des Scrum Master précédents qui pourraient avoir endommagé la marque pour ainsi dire. J'ai déjà travaillé sous un scrum master toxique, où chaque problème soulevé était ajouté à votre charge de travail, que vous en ayez eu connaissance ou non. Résultat final: les problèmes ont été ignorés et chacun a travaillé sur son propre petit espace avec très peu de travail d'équipe.

Amener votre équipe à clôturer efficacement votre sprint (au moins 80% des histoires): sprint après sprint est, à mon avis, la chose la plus importante que vous puissiez faire. Si votre équipe manque systématiquement, c'est une indication claire que vous devez ajuster vos estimations.

L'équipe doit être réceptive à cela, même s'il peut être très difficile d'amener les développeurs à être plus réalistes à propos des estimations - j'ai travaillé pour une équipe qui n'a pas clôturé un sprint pendant un an (clôturant systématiquement moins de 50% du sprint). , toujours sous-estimé et dans chaque planification / rétrospective, j’étais une voix solitaire qui leur dit que vos estimations sont nulles, vous êtes stupidement trop confiant, arrêtez de chercher des excuses pour ce qui vous a empêché de faire l’estimation et ajustez plutôt cette estimation pour refléter la réalité ( peut-être plus diplomatiquement que cela, mais c’était le sentiment de base) - Lorsque vous occupez ce poste, je suis tout à fait d’accord avec le conseiller ministériel de votre équipe, qui déclare que le processus est une perte de temps, car vous travaillez en fait avec KonBon, peu importe les circonstances. comment vous l'appelez À un moment donné, son opinion est validée par les circonstances. Il'

À un moment donné, il faut réinitialiser les choses, obliger l'équipe à compenser de manière drastique ses estimations, juste pour mettre le système en marche. Une fois qu'une équipe commence à fermer les récits de manière cohérente, elle doit se rendre compte que le processus Agile relève principalement du bon sens et que le non-matérialisation de celui-ci nuit à votre productivité. Mais tant que «l'engagement» et les «objectifs de sprint» ne sont pas pris au sérieux, ce qui se produit lorsqu'ils ne sont pas atteints de manière cohérente, le tout est un simulacre et devient un fardeau pour la productivité des équipes.

Amener les gens à participer à un sprint très différent (en termes d’estimations, de planification, d’engagement, etc.) est difficile, cette équipe j’ai finalement accompli cela à cause de deux facteurs. L’un d’eux collectait simplement les données de JIRA et disait: "Il n’ya pas d’excuse pour cela, les chiffres sont faux, ils vont toujours dans une direction, nous devons le corriger, je ne veux pas d’excuses rétro, je veux les chiffres à additionner "- et l'autre était une pression exercée par la direction, que je leur ai finalement expliquée:" L'objectif de ce processus est de rendre notre calendrier de développement prévisible. Si nous effectuons un volume de travail constant chaque sprint c'est bien, indépendamment de cela, notre conseil d'administration doit refléter avec précision ce que nous faisons. La direction est plus consciente de notre succès par rapport à notre engagement que par rapport à notre résultat réel. Pour votre propre intérêt, alignez la projection sur le résultat pour donner l'impression que votre travail est fait au lieu de passer la moitié de chaque sprint. Ne rien faire. Plus les gens sont éloignés de cette époque, plus ils vous voient simplement en échec, les excuses que vous faites en rétro ne sont même pas de leur ressort, elles vous voient juste en échec. "

Finalement, notre équipe a eu de la traction et les choses ont commencé à aller beaucoup plus doucement et doucement et voici, nous avons même commencé à avoir une production plus élevée une fois que le processus a réellement commencé. Alors, faites tout ce qui est nécessaire pour commencer à clôturer les sprints avec un degré de réussite relativement élevé. Si vous ne le faites pas, le soldat de votre équipe continuera à faire valider sa résistance à Scrum par les résultats et aura finalement raison de dire que votre processus n'est en réalité qu'un simulacre et une perte de temps.

En tant que Scrum Master, vous coachez et guidez l'équipe pour qu'elle devienne plus productive. Le framework Scrum est un outil puissant pour y parvenir, mais le framework Scrum ne doit absolument jamais devenir l'objectif par lui-même - sinon vous faites Cargo Cult .

Il semble que vous jouiez à Cargo Cult depuis 3 ans maintenant et les gens se sont rendu compte que c'était une méthodologie de gestion de projet horrible. La bonne nouvelle est que vous avez des gens intelligents , ils ont bien compris. Malheureusement, certaines personnes de votre entreprise l’appellent Scrum, mais encore une fois, vous avez des gens intelligents . Ils vous ont même dit que l’équipe ne s'appelle pas Scrum.

Planifier n'est qu'une perte de temps, car nous ne faisons que déborder dans le nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s'embêter.

Exactement. Pourquoi s'embêter? Vous devez trouver une réponse, ou plutôt, vous devez modifier la planification et le sprint lui-même pour que la planification ait un sens. Soit ça, soit arrêter de perdre tout le temps de tout le monde avec une planification de sprint inutile. Vous voudrez peut-être demander à la société de vous envoyer suivre une formation Scrum Master, car la planification d'un bon sprint n'est pas anodine.

Pendant la rétrospective, les [...] autres sont silencieux et je dois régler ce problème à chaque fois.

Si vous traitez le même problème à chaque rétrospective, un peuple ne se soucie même plus (plus?) De s'exprimer pendant la rétrospective, c'est juste une perte de temps. À moins que vous ou l'équipe ne puissiez d'une manière ou d'une autre aborder les problèmes soulevés dans la rétrospective, la réunion n'est qu'un moyen de démoraliser l'équipe. Les problèmes soulevés dans la rétrospective doivent être résolus et la prochaine rétrospective devrait progresser.

Daily Scrum est encore une perte de temps pour eux, car aucun d’eux ne veut parler et planifier sa journée. Ils disent simplement: "J'ai travaillé sur la tâche X hier et y travaillerai encore aujourd'hui".

En effet, pourquoi perdre du temps à tout le monde s’il s’occupe des mêmes tâches plusieurs jours? Ils ont tout à fait raison, ce Daily Standup est en effet inutile. Le Standup facilite la collaboration étroite sur de nombreuses tâches pouvant être complétées en une demi-journée ou moins. Si vos tâches ne peuvent pas être réparties de cette façon (en raison d'une planification de sprint interrompue ou parce que vos tâches ne correspondent pas vraiment à Scrum), il n'y a pas de raison de tenir la réunion de 5 minutes quotidienne avec stand-up (c'est pas plus de 5 minutes, non?).

"Nous ne terminons jamais un sprint. Nous ne faisons que déplacer des tâches et en assumer de nouvelles lors du prochain sprint pour remplir un quota. Nous réalisons KanBan en réalité. Alors arrêtez de dire cela."

Je comprends pourquoi il dit cela, mais il ne semble pas se rendre compte que c’est comme cela parce que lui et tous les autres membres de l’équipe ne s’inquiètent pas.

Non, vous ne comprenez absolument pas pourquoi il dit cela . Vous avez la mauvaise cause de l'obstacle - qu'il vous faut résoudre -. Ils s'en moquent car les pratiques de gestion de projet de l'équipe sont nulles. S'occuper de Cargo Cult et de Cargo Cult plus durement ne l'empêche pas d'être Cargo Cult, l'une des pires méthodologies de gestion de projet (à votre défense: aussi la plus largement utilisée).

Que pouvez-vous faire à ce sujet?

1. Écoutez leurs préoccupations. Encore une fois, vous avez la chance de pouvoir compter sur des gens intelligents .

2. Aidez-les à résoudre les obstacles.

Et c'est tout, vraiment. Vous devrez faire des essais sur la façon de modifier la planification de sprint, le scrum quotidien et les rétrospectives pour les rendre utiles à l’équipe. Même si vous vouliez supprimer l’étiquette Scrum, ces trois réunions ont toujours la même fréquence et le même but. méthodologie de gestion de projet là-bas. Pour ce qui est de la manière dont vous allez expérimenter (fréquence, contenu, organisateur de la réunion, heure, durée, etc.), c’est étonnamment simple: demandez à l’équipe. Ne forcez pas vos idées sur eux, si vous devez les laisser vous forcer (en supposant qu’ils puissent s’accorder sur certaines idées).

Si vous avez peur de perdre le contrôle, définissez au préalable certaines limites, par exemple:

• Les étiquettes des réunions restent les mêmes.
• Les réunions ont toujours lieu et la fréquence des réunions ne peut pas changer de plus d'un facteur 2.
• Vous êtes en train d'expérimenter, donc tout changement ne dure que 2 sprints, après quoi vous revenez à l'ancien modèle (il est préférable d'indiquer le temps en semaines pour éviter toute ambiguïté quand ils veulent doubler la durée du sprint).

Je pense que tout le monde cite la même ligne du Manifeste Agile . Je ferai la même chose: "Individus et interactions sur des processus et des outils."

Si vous, en tant que maître SCRUM, souhaitez utiliser SCRUM pour effectuer le travail, vous devez les aborder en tant qu'individu interagissant avec un autre. Commencez à réfléchir à la façon d'améliorer le processus. Peut-être pourrez-vous les convaincre d'aimer SCRUM. Peut-être qu'ils peuvent vous convaincre d'utiliser un processus différent. Découvrons-le!

Il semble que l'équipe reconnaisse déjà que le système actuel ne fait pas le travail. Pouvez-vous les encourager à croire que cela peut faire le travail? Vous mentionnez quelques exemples. Si vous remplissez trop le Sprint pour qu'il y ait toujours des fuites, arrêtez-vous. C'est votre équipe SCRUM. Aidez-les à ne pas trop s'engager. Appuyez sur la direction pour obtenir une marge de manœuvre. Utilisez SCRUM pour son utilité. Utilisez-le pour présenter aux gestionnaires les données qu’ils insistent suffisamment pour perdre la valeur de leur processus. Si la direction souhaite que SCRUM soit un processus, demandez-leur de vous aider à créer l'espace et l'énergie dont vous avez besoin pour le réparer. En tant que maître SCRUM, votre travail consiste à résoudre les problèmes afin que l’équipe puisse être productive.

Une autre approche utile peut être de générer un nouveau processus dans l’ancien. Continuez à utiliser le SCRUM de la même manière inutile, mais scellez une petite partie de l’horaire et dites: "Dans cette partie de notre emploi du temps, nous allons trouver comment utiliser les outils correctement". Ne pas trop engager là-bas. Utilisez vos métriques. Concentrez-vous sur toutes vos réunions là-bas. La partie restante de votre projet "SCRUM" sert de bouclier pour rendre la gestion heureuse, tandis que vous et votre équipe "découvrez de meilleurs moyens de développer des logiciels en le faisant et en aidant les autres à le faire". Au fil du temps, vous voudrez mettre de plus en plus de tâches de valeur dans ce seau et l'ancien seau mourra lentement. Bientôt, vous avez un environnement de développement logiciel dynamique et personne n’est le plus sage.

Ou mélangez-les et faites-les correspondre. J'ai travaillé sur un programme anti-mêlée. Les clients souhaitaient pouvoir ajouter de nouvelles tâches à tout moment du processus et nous demander de les exécuter immédiatement. (C’était en fait une requête sensée: leur travail était très instable et ils avaient souvent besoin d’un soutien rapide… c’est ce pour quoi nous avons été payés). Bien sûr, nous devions trouver une solution à leurs problèmes "Pourquoi X n'est pas fait quand vous l'avez promis dans le sprint". Notre solution consistait en réalité à construire un processus en deux étapes. Les tâches à long terme ont été intégrées à SCRUM pour une hiérarchisation appropriée. Les tâches à court terme ont été placées dans un processus homebrewed qui a mis l'accent sur une interaction étroite entre le client et le développeur. Il était entendu que les clients étaient les bienvenus pour faire pression sur nous en utilisant ce processus à court terme, mais qu’ils comprenaient que cela avait poussé le sprint vers le haut. s il leur était interdit d’ajouter des demandes sans entendre et régler simultanément les problèmes de planification qu’elles posaient. Résultat? Ça a marché. La plupart des tâches ont été placées dans le processus SCRUM, comme il se doit, et les urgences ont interagi de manière transparente avec elles. L'attitude était la suivante: "Si vous voulez être un client, faites la queue pour une histoire SCRUM. Si vous voulez être un partenaire, n'hésitez pas à venir travailler avec nous au niveau quotidien et faire en sorte que ce produit fonctionne ! "

Je dis cela parce que je sais vraiment. Vous avez un problème de gestion avec l'encombrement du planning, l'incapacité de définir des priorités et la volonté d'ajouter plus d'éléments, mais de ne pas repousser la date de sortie.

J'avais l'habitude de dire qu'il n'y avait pas de méthodologie qui puisse fonctionner de la sorte, mais maintenant que j'ai vu Kanban, je le dis, mais seulement parce que Kanban n'a pas à s'en soucier. Il continue à fonctionner lorsqu'il est surchargé. Cela n'apportera pas de résultats plus rapidement, mais la sauvegarde dans les files d'attente ne peut être effectuée par aucune personne. Le problème de gestion incombe donc à la direction. Les rapports de retour indiquent une surcharge, ce qui est correct.

En raison de ce changement dans Scrum Masters et de leur façon de diriger le spectacle

Oh bien, c'est peut-être votre problème. Un Scrum Master n’est pas là pour animer une émission, il n’est pas un chef de projet. Il est là pour s'assurer que toutes les parties prenantes communiquent et que l'opération est transparente.

Je me demande d'où vient l'équipe. Se pourrait-il qu'ils soient plus ou moins autonomes avant que Scrum (y compris l'inévitable Scrum master) ne leur soit lâché? Pourquoi Scrum a-t-il été introduit? Qu'est-ce que c'était censé résoudre?

Scrum est censé fournir des conseils et votre équipe indique clairement qu’ils ne les considèrent pas comme utiles. Ils se moquent bien des conseils, ils considèrent que c'est une perte de temps inappropriée. Apparemment, au moins un décideur pense qu’il doit être guidé de toute façon. Qui? Pourquoi? Ont-ils un point?

Ce problème ne se limite pas aux logiciels.

Dans tout environnement de travail, il y aura différentes personnes avec des personnalités et des capacités différentes. Même si Scrum était une méthode parfaite, il y aurait toujours des opposants à cause de leurs personnalités et de leurs capacités.

Les développeurs gèrent les tâches difficiles de manière rationnelle. Pour ce faire, chaque développeur aura son moyen de gérer ce qui peut sembler être une aversion pour des choses comme Scrum. Si tous les développeurs ont été formés à partir de rien de la même manière, il sera peut-être beaucoup plus facile d'utiliser un modèle, mais sinon, une adaptation du côté du développeur ou du côté de la gestion est nécessaire.

En outre, les penseurs indépendants (développeurs et autres spécialistes) n’apprécient souvent pas que l’on leur dise comment faire, car c’est leur travail et qu’il est facile de provoquer des conflits d’opinion. Scrum peut sembler être un rituel inutile pour un penseur logique qui analyserait et agirait en conséquence en fonction de chaque problème.

La liste ci-dessous semble indiquer où se situe le problème mais pas ce qu’il est. Il y a certainement plus que cela. Je ne peux que supposer (par expérience) que les développeurs ont essayé mais ont été empêchés. J'ai souvent constaté que les développeurs voulaient régler quelque chose, mais que quelque chose de systématique (gestion, politique d'entreprise, etc.) rend cela presque impossible, alors ils abandonnent. Est-ce qu'ils ne se soucient vraiment pas ou ne se soucient pas seulement de faire quelque chose qui, à leur avis, ne va pas aider (peut-être par expérience).

Je comprends pourquoi il dit cela, mais il ne semble pas se rendre compte que c’est comme cela parce que lui et tous les autres membres de l’équipe ne s’inquiètent pas. Ils travaillent simplement au lieu de gérer les obstacles. Ils se plaignent des obstacles, mais ne font rien à leur sujet. Et quand j'essaie d'aider, ils s'en vont.

Ils s'en foutaient, mais au cours des deux dernières années, leur volonté a décliné de fond en comble.

Comment puis-je leur faire voir que les plaisanteries et les cercles saccadés lors de ces réunions coûtent beaucoup d'argent à l'entreprise?

Si quelque chose est imposé à d'autres personnes, c'est à elles d'imposer la méthode pour les convaincre des avantages. Bien que je ne croie pas vraiment obliger les gens à faire des choses, je suggère, comme dans n'importe quelle situation, d'écouter tout le monde et de développer une méthode qui convient à l'environnement actuel.

Scrum n’est pas sans ses faiblesses. Je peux parler pour moi bien sûr, mais je pense que les développeurs le détestent pour une bonne raison . C'est mon opinion honnête qu'il ne faut pas tenter cela .

Pour comprendre pourquoi, lisez ce que tout Scrum Master devrait savoir sur Scrum . Ce n'est pas écrit par moi, pourtant tout y est représentatif de mon expérience, ce que je ne peux que résumer comme une terreur pure .

Dans mon cas, j'ai particulièrement souffert au point 5. En gros, Scrum m'a traité comme un enfant et un perdant. Maintenant, je suis un co-développeur plein de ressources aidant mes collègues… rien d'étonnant à ce que je préférerais!

J'ai un nouveau patron (non-scrum) maintenant, qui se promène et parle aux gens, et je suis tellement reconnaissant pour cela! Cela s’explique en partie par le fait que nous disposons également d’une salle de discussion (la plupart des solutions sont utilisées) pour la communication entre développeurs. Si quelqu'un a un agenda, nous le prenons là. Les réunions servent uniquement à des discussions ad-hoc avec les développeurs, et non à imposer des délais journaliers artificiels.

Vous avez obtenu d'excellentes réponses. Voici quelques points supplémentaires qui pourraient être utiles:

Changer de méthodologie est difficile

C’est un défi de taille pour un lieu de travail, car vous travaillez sous l’inertie de "c’est comme ça que nous faisons" et contre la pression des délais et des besoins de l’entreprise.

Vous avez parfaitement raison de conclure que votre équipe doit consacrer plus de temps à la planification, pas moins ; que la planification est une chose à laquelle votre temps actuellement n'est pas excellent et doit être amélioré. Le problème est que vous n'y arrivez pas simplement en dictant de nouvelles règles. Les nouvelles règles sont un nouveau fardeau avant de devenir une aide précieuse. Et s'ils n'offrent pas une grande valeur immédiate , vous obtiendrez de l'évitement plutôt que de la coopération.

Je recommande vivement Roy Osherove à ce sujet. Il a un bref résumé sur la façon de planifier et d’effectuer des changements dans votre entreprise , et il approfondit le sujet dans cette vidéo .

L’observation fondamentale d’Osherove est que tous les défis suivants doivent être relevés:

Motivation personnelle: Pourquoi quelqu'un devrait-il se comporter de manière spécifique?
Capacité personnelle: peuvent-ils littéralement le faire?
Motivation sociale: Y a - t-il une pression exercée par les pairs pour ce comportement?
Capacité sociale: les gens autour de moi soutiennent-ils mon comportement et m'aident-t-il quand j'ai besoin d'aide?
Motivation structurelle: Existe-t-il des récompenses \ punitions pour un bon \ mauvais comportement?
Capacité structurelle: Est-ce que l'environnement physique supporte ce comportement?

Vous devez apprendre à décomposer les tâches

Votre équipe a le sentiment que «j’ai travaillé sur la tâche X hier et que je vais y travailler encore aujourd’hui», et ils semblent avoir raison, en ce sens que les tâches continuent d’être repoussées d’une semaine.

Ce qui est vraiment utile ici, c'est d'apprendre à décomposer des tâches en petites composantes. Ce que vous cherchez, c'est la réponse à la question "OK, vous travaillez pour la tâche X, mais sur quoi portez-vous spécifiquement la tâche X aujourd'hui ?"

Certaines réponses pourraient être:

• J'apprends cette classe de code hérité.
• Je répare un bogue dont les symptômes sont (SYMPTÔMES).
  • S'il s'agit d'un bogue persistant qui prend du temps: "Aujourd'hui, ce que je vais essayer, c'est ... (PLAN)"
• J'ai besoin de changer cette interface.
• J'écris des tests.
• J'intègre du code non testé.

... et ainsi de suite. Pouvoir observer ce que vous pouvez réellement faire en une journée ou en une semaine est l’un des grands avantages d’Agile. Mais cela signifie que vous devez réellement examiner la résolution des jours individuels, et non une tâche monolithique X qui sera prête quand elle sera prête.

Fait vs livré

Un problème courant (avec Agile et la planification en milieu de travail en général) est que les délais viennent généralement de la direction, et non des développeurs. Ce délai peut être dissocié du travail à effectuer - et en particulier, il est probable que vous souhaiterez que les choses soient livrées le plus rapidement possible.

Le problème est que "livré dès que possible" est un processus très chaotique. Cela encourage les coupures. codage "rapide et sale"; ignorer les directives; ne pas nettoyer après vous-même. Cela encourage une mentalité de "essayer, voir si cela fonctionne. Si oui, livrer. Si non, essayer autre chose" - et, exprimé comme cela, vous pouvez voir pourquoi personne ne peut prédire combien de temps cela prendra.

Alors que si vous êtes travaillez méthodiquement, si vous êtes rigoureux sur la planification et les essais et ainsi de suite, vous avez mis en place un groupe de panneaux indicateurs et des filets de sécurité. Cela peut prendre plus de temps - vous consacrez beaucoup de temps à des tâches qui ne favorisent pas la livraison immédiate, et vous n'êtes peut-être pas très bon pour ce type de flux de travail - mais ce sera beaucoup moins volatile.

Une question à vous poser est donc la suivante: les développeurs fixent-ils les objectifs du sprint en fonction des besoins et des nécessités qu’ils voient réellement? Ou bien est-ce la direction qui fixe les délais, laissant les développeurs essayer d’intégrer leurs engagements dans un calendrier semblable à un sprint?

Si les développeurs ne disposent pas du temps nécessaire pour planifier leurs tâches ou travaillent selon un plan fiable, il n’est donc pas surprenant qu’ils ne puissent pas faire d’estimations utiles. :)

Cela pourrait être une opinion impopulaire, mais vous ne pourrez peut-être rien y faire.

Je peux imaginer qu'au fil des années d'existence de l'équipe et du flux de dirigeants, des personnes réellement insatisfaites de l'équipe sont parties. Ce que vous avez, ce sont des restes de personnes qui pourraient se plaindre, mais qui ne sont pas intéressées à déployer des efforts pour améliorer la situation. Ils veulent juste passer leurs 8 heures de code, sans être interrompu par personne, et rentrer chez eux en fin de journée. Ce que vous avez ici semble être un grave problème de motivation. Et ce n’est pas le travail du scrum master de résoudre ce problème. C'est le problème de quiconque paie ces personnes.

Si tel est vraiment le cas, seule l'option réelle consiste à se débarrasser de l'équipe actuelle et à recommencer à zéro. Vous pouvez peut-être laisser une ou deux personnes qui, selon vous, sont les meilleures dans l’équipe, et renvoyer ou déplacer le reste vers des équipes différentes. Vous devriez au moins discuter de cette possibilité avec vos supérieurs.