Comment gérer une équipe de mêlée contre-productive?
Backstory:
Je travaille au sein de cette équipe depuis trois ans et pendant cette période, nous avons eu trois Scrum Master différents qui ont tous géré les choses différemment.
En raison de ce changement dans les Scrum Masters et de leur façon de diriger le spectacle, cela a laissé mon équipe engourdie à l'idée de Scrum parce que les principes n'ont pas été appliqués de manière cohérente et l'un des Scrum Masters était une personne qui ne croit pas en l'agilité. développement et juste gardé des événements et des artefacts en tant que novice pour se conformer aux décisions de l'entreprise.
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 en raison de mon dévouement au travail agile et à ses principes.
Je souffre énormément sous la pression atmosphérique de la réticence des membres de mon équipe à faire Scrum.
Comme mentionné, ils sont ennuyés par l'ensemble du processus, ce qui me complique la tâche car ils ne s'engagent pas dans les conversations nécessaires pour rendre efficaces Planning, Retrospective et Daily Scrum.
Pour eux, la planification n'est qu'une perte de temps, car nous déplaçons simplement le débordement dans le nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s'embêter.
Pendant la rétrospective, je peux juste sentir qu'ils veulent dire "Arrête de faire Scrum". Une personne le fait, mais les autres se taisent et je dois y faire face à chaque fois.
Daily Scrum n'est encore qu'une perte de temps pour eux car aucun d'entre eux ne se soucie de parler et de planifier la journée. Ils déclarent simplement "J'ai travaillé sur la tâche X hier et j'y travaillerai encore aujourd'hui". Et la plupart du temps, ils plaisantent jusqu'à ce que je sois plus sévère.
J'ai été très grande en ce qui concerne la façon dont ils ont passé leur temps lors de ces événements. Mais je meurs à l'intérieur parce que je suis passionné par ça et qu'ils s'en moquent.
Aujourd'hui, la personne qui est toujours contre moi m'a dit d'arrêter de dire "Ils ont dit que c'était ce à quoi ils s'étaient engagés pour ce sprint" parce que, selon ses propres mots, "nous ne terminons jamais un sprint. Nous nous contentons de déplacer des tâches et prochain Sprint pour remplir un quota. Nous faisons du KanBan en réalité. Alors arrêtez de le dire. "
Je comprends pourquoi il dit cela, mais il ne semble pas réaliser que c'est ainsi parce que lui et tous les autres membres de l'équipe s'en moquent. Ils ne font que travailler au lieu de faire face à des obstacles. Ils se plaignent des obstacles, mais ne font rien à leur sujet. Et quand j'essaie d'aider, ils haussent les épaules.
Ils s'en foutaient, mais au cours des deux dernières années, leur volonté est tombée à plus ou moins bas.
Comment puis-je leur faire voir que plaisanter et perdre du temps lors de ces réunions coûte cher à l'entreprise?
Vous avez peut-être entendu de nombreuses statistiques sur les projets logiciels qui ont échoué et vous êtes arrivé à la conclusion que l'échec n'était pas de nature technique. Les problèmes technologiques peuvent être résolus via des centaines de solutions techniques, mais la résolution de problèmes dans votre atmosphère de travail en utilisant Scrum ne fonctionnera pas.
Ma suggestion ici est d'arrêter complètement de considérer cela comme un problème technique. Il ne s'agit pas de Scrum, il ne s'agit pas de standups quotidiens, de sprints, de rétrospectives ou de quoi que ce soit d'autre. Vous devez entrer en contact avec votre équipe et trouver un moyen 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 faire des quotidiens et d'essayer d'insérer votre raisonnement. Pensez par vous-même à ce que les quotidiens vous offrent. 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, pas comme pour les convaincre de quoi que ce soit. Vérifiez ensuite si les quotidiens aident réellement votre équipe ou si vous pouvez en faire plus avec un autre mécanisme. Ce qui est drôle au sujet des maîtres Scrum, c'est qu'ils sont des serviteurs de leur équipe - vous pouvez bien les servir au mieux en abolissant complètement Scrum.
En résumé, arrêtez de vous concentrer sur Scrum et revenez à la base de l'agilité. Vous voudrez peut-être commencer dès le début avec le manifeste agile : valoriser les individus et les interactions sur les processus et les outils.
D'après mon expérience, les équipes déçues doivent commencer par avoir des rétrospectives efficaces. C'est pourquoi, à mon avis, les rétrospectives sont la seule partie obligatoire d'un processus agile. Tout le reste est susceptible de changer à travers les rétrospectives.
Dans des rétrospectives efficaces, vous ne vous contentez pas de vous plaindre de vos problèmes, vous choisissez au moins un de ces problèmes et identifiez des solutions possibles, puis essayez cette solution au cours de la prochaine itération. Lors de la prochaine rétrospective, vous discutez de la façon dont cette solution a fonctionné ou n'a pas fonctionné, et effectuez d'autres ajustements si nécessaire, ou choisissez un autre problème sur lequel travailler.
Lorsque les membres de l'équipe constateront qu'ils ont le pouvoir d'apporter des changements réels à leur processus, ils deviendront plus disposés à s'engager.
Le processus rétrospectif est la raison pour laquelle si vous rendez visite à toutes les équipes d'une entreprise qui se comporte bien, elles le font toutes un peu différemment. Nous avons des équipes qui font du Kanban, d'autres qui font de l'XP, d'autres qui ne font que des standups lundi mercredi vendredi.
Si votre équipe n'aime pas la façon dont vous traitez les gueules de bois, réfléchissez à différentes approches. J'ai gagné très des développeurs réticents juste en écoutant constamment des rétrospectives et en essayant des solutions.
Ok alors commençons rudement - une grande partie du problème vient de vous Votre équipe vous dit clairement quels sont les problèmes. Vous devez les aborder au lieu de blâmer votre équipe.
Planification
Pour eux, la planification n'est qu'une perte de temps, car nous déplaçons simplement le débordement dans le nouveau Sprint et ne terminons pas le travail de toute façon, alors pourquoi s'embêter.
Exactement. Si vous ne parvenez pas à allouer correctement le temps aux tâches et qu'elles sont systématiquement 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 d'histoire (en tant que combinaison de temps et de risque).
- Ne pas autoriser dans un sprint des tâches> 55 SP
- Estimations comparatives
- Planification basée sur des preuves
Comme base pour cela, vous devez absolument suivre le temps qu'il a fallu en fait 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 disposez d'un temps total pour une tâche donnée, vous pouvez baser le temps prévu sur ces tâches précédentes.
Demandez à chaque membre si la tâche qui lui est confiée semble plus compliquée ou plus facile que la sélection des tâches précédentes, ajustez le nombre de tâches allouées en fonction de cela.
Si vous n'avez pas utilisé SP auparavant, mon conseil est de commencer avec 1h de travail honnête à Dieu = 5SP comme guide. Gardez à l'esprit que dans un environnement de développement habituel, vous obtiendrez peut-être 6 de ceux par jour, donc 30SP/jour max. Ne jamais autoriser une tâche qui prend plus de 2 jours à monter sur le tableau. Idéalement, d'après mon expérience, vous devriez avoir 2 tâches par jour.
Si vous ne faites pas correctement la planification, le reste de vos activités Scrum ressemblera à une perte de temps (y compris la planification).
Rétrospective
Pendant la rétrospective, je peux juste sentir qu'ils veulent dire "Arrête de faire Scrum". Une personne le fait, mais les autres se taisent et je dois y faire face à chaque fois.
Me fait penser à Daily beatings will continue until morale improves! et deux des emplois précédents. Si vous ne supprimez pas les obstacles, ils ont 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 faire?
Donc:
- Considérez les techniques Six Thinking Hats pour améliorer la communication.
- Réduisez le temps consacré à la rétrospective, 30 minutes maximum.
- Veiller à ce que les plaintes soulevées lors de la rétrospective soient traitées avant la prochaine.
SCRUMs quotidiens
Daily Scrum n'est encore qu'une perte de temps pour eux car aucun d'entre eux ne se soucie de parler et de planifier la journée. Ils déclarent simplement "J'ai travaillé sur la tâche X hier et j'y travaillerai encore aujourd'hui". Et la plupart du temps, ils plaisantent jusqu'à ce que je sois 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'avez-vous fait hier.
- Que planifiez-vous aujourd'hui.
- Ce que les membres de votre équipe (pas vous!) Devraient savoir sur la tâche, comment elle va les affecter.
- Ne vous embêtez pas avec les obstacles si vous ne comptez pas les résoudre.
Ceci est une deuxième preuve que votre planification altère votre situation - si vous n'avez rien de spécifique à signaler, cela signifie généralement que la tâche est trop grande et tout ce que vous pourriez dire était: j'y travaillais.
- Décomposez les tâches en puces.
- Assurez-vous que les tâches sont suffisamment petites pour prendre moins d'une journée. Idéalement, l'OMI, la tâche devrait durer ~ 3h et être équivalente à environ 13 SP, vous pouvez donc 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 d'arrêter de dire "Ils ont dit que c'était ce à quoi ils s'étaient engagés pour ce sprint" parce que, selon ses propres mots, "nous ne terminons jamais un sprint. Nous nous contentons de déplacer des tâches et prochain Sprint pour remplir un quota. Nous faisons du KanBan en réalité. Alors arrêtez de le dire. "
Il a raison. Vous avez tort. Vous faites un SCRUM bâtard et/ou une variation sur Kanban. Pas du tout de leur faute.
Je comprends pourquoi il dit cela, mais il ne semble pas réaliser que c'est ainsi parce que lui et tous les autres membres de l'équipe s'en moquent.
Je ne pense pas que vous compreniez du tout. Ils se soucient peut-être moins qu'auparavant, mais les blâmer non seulement n'améliorera rien, mais pourrait aggraver la situation. Si c'était le fond, ils pourraient commencer à creuser.
Ils ne font que travailler au lieu de faire face à des obstacles.
Et ici, je pensais que faire du travail était leur métier. Je me demande qui était censé faire face aux obstacles ... oh c'est vrai. Un Scrum Master. C'est votre travail. Ils vous disent ce qui ne va pas. Vous le réparez. 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 secousses circulaires pendant ces réunions coûtent beaucoup d'argent à l'entreprise?
Arrêtez les réunions inutiles et ils plaisanteront à la place autour du refroidisseur d'eau. Voir également le paragraphe sur les coups qui améliorent le moral. S'ils utilisent l'humour comme mécanisme de défense, vous avez de sérieux problèmes, monsieur!
Faites une blague - comme au travail avec votre équipe, pas contre. (Qui le fuuuuuuck se soucie de l'argent de l'entreprise? Êtes-vous actionnaire maintenant?)
Pour résumer
Votre mauvaise planification fait échouer d'autres parties de SCRUM, et tous ceux qui participent misérables. Ils voient que rien ne change, rien n'est traité et leurs plaintes ne sont pas entendues.
Améliorez votre planification et vous améliorerez le flux et le moral.
Faites votre travail en supprimant les obstacles et votre équipe progressera plus rapidement. Demandez-leur ce que ils estiment que vous devriez faire pour les aider.
Plus important encore: Écoutez vos gens. Ils vous ont déjà dit (et moi) quel était le problème.
Bonne chance!
L'un des principes agiles majeurs est de revenir en arrière et de corriger tout ce qui ne va pas. Cela n'inclut pas seulement la refactorisation du code et les corrections de bogues, mais aussi la correction du processus de développement.
Alors, pourquoi ne pas rencontrer votre équipe et voir comment améliorer le processus de développement? Si cela signifie, pas de mêlée ou de réunions debout, que ce soit.
Vous brisez également l'un des principes de manifeste agile : "Les individus et les interactions sur les processus et les outils".
D'un autre côté, si votre équipe pense que le développement itératif est mauvais, alors vous vous trompez peut-être. Peu importe si vous ne terminez pas tout ce que vous avez planifié pour une seule 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 d'avoir", etc. Tant que vous fournissez de nouvelles fonctionnalités, vous le faites bien.
Juste une petite diatribe: dans mon entreprise précédente et actuelle, nous avons fait et faisons toujours des réunions debout. D'après mon expérience, ils sont une énorme perte de temps, car chaque fois qu'ils se transforment en réunions de rapport de situation de plus de 30 minutes, et pour moi, fournissent peu ou pas d'informations. Les gens parlent de leurs problèmes, honnêtement je m'en fiche.
Dans mon entreprise précédente, ils étaient intelligents, ont reconnu ce problème avec les standups et les ont arrêtés peu de temps après que les gens ont commencé à se plaindre.
Si vous aimez voir une très bonne vidéo sur la mêlée, voir " Robert C. Martin - The Land that Scrum Forgot ".
En priorité, j'examinerais des tâches qui ne cessent de se poursuivre. Ne pas atteindre les objectifs est extrêmement démoralisant. Vous engagez-vous trop? Y a-t-il des fatlogs à décomposer? 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? Les heures par développeur sont-elles raisonnables (c'est-à-dire en tenant compte de l'administrateur, des standups, de la planification, des rétrospectives, des pauses clavier, des travaux hors projet).
Ensuite, abandonnez tout ce qui ne fonctionne pas. Un processus sans valeur n'est qu'un voleur de temps. Les standups peuvent consommer beaucoup de temps s'ils ne sont pas ciblés et ne fournissent pas de valeur à l'équipe. Les heures pourraient être mieux utilisées ailleurs. Peut-être envisagez-vous également de diviser l'équipe si elle est trop grande.
Essayez de comprendre ce qui démotive l'équipe. Ayez des rétrospectives et, surtout, agissez sur la sortie. Il est tout aussi important de célébrer les réussites que de regarder les échecs.
Enfin, vous voudrez peut-être évaluer les approches des maîtres de mêlée qui ont précédé et qui ont pour ainsi dire endommagé la marque. J'ai déjà travaillé avec un scrum master toxique où chaque problème soulevé s'ajoutait à votre charge de travail, que vous le sachiez ou non. Résultat final: les problèmes ont été ignorés et tout le monde a travaillé sur sa propre petite zone avec très peu de travail d'équipe.
Faire en sorte que votre équipe ferme efficacement votre sprint (comme au moins 80% des histoires) sprint sur 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 devrait être réceptive à cela, bien qu'il puisse être très difficile d'amener les développeurs à être plus réalistes sur les estimations - j'ai travaillé sur une équipe qui n'a pas fermé de sprint pendant un an (fermant régulièrement moins de 50% du sprint) , toujours sous-estimé et dans chaque planification/rétrospective, j'étais une voix seule en leur disant que vos estimations sont nulles, vous êtes follement trop confiant, arrêtez de chercher des excuses pour ce qui vous a empêché de faire l'estimation et ajustez plutôt l'estimation pour refléter la réalité ( peut-être plus diplomatiquement que cela, mais c'était le sentiment de base) - Lorsque vous êtes dans cette position, je suis entièrement d'accord avec le curmudgeon de votre équipe qui dit que le processus est une perte de temps car vous faites en fait KonBon, indépendamment de comment vous l'appelez. À un certain moment, son opinion est validée par les circonstances. Il est difficile de surmonter cette inertie, mais si vous ne pouvez pas le faire, je ne pense pas que l'équipe réussira un jour.
À un moment donné, vous devez réinitialiser les choses, vous devez obliger l'équipe à compenser considérablement ses estimations juste pour mettre le système en marche. Une fois qu'une équipe commence à clore les histoires de manière cohérente, elle doit se rendre compte que le processus Agile est principalement du bon sens et ne pas le matérialiser d'une manière ou d'une autre 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 une imposture et devient un drain sur la productivité des équipes.
Amener les gens à adhérer à un sprint significativement différent (en termes d'estimations, de planification, d'engagement, etc.) est difficile, dans cette équipe, j'ai finalement réussi à le faire pour deux raisons. L'un était simplement en train de collecter les données de JIRA et de dire "il n'y a aucune excuse pour cela, les chiffres sont loin, ils sont toujours dans une direction, nous devons les corriger, je ne veux pas d'excuses en rétro, je veux les chiffres à additionner "- et l'autre était la pression de plus haut niveau dans la gestion que je leur ai finalement expliqué comme ..." Le but de ce processus est de rendre notre chronologie de développement prévisible. Si nous accomplissons une quantité constante de travail 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 à l'engagement qu'à sa production réelle, pour votre bien, faites la projection avec la sortie de sorte qu'il semble que vous fassiez votre travail plutôt que de passer la moitié de chaque sprint à ne rien faire. Plus les personnes éloignées sont de cette époque, plus elles vous voient juste échouer, les excuses que vous faites en rétro ne sont même pas quelque chose dans leur domaine, ils vous voient juste échouer g."
Finalement, notre équipe a pris de la traction et les choses ont commencé à aller beaucoup plus doucement et bas et voici, nous avons même commencé à avoir un rendement plus élevé une fois que le processus a commencé à fonctionner. Donc tl; dr - 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 curmudgeon de votre équipe continuera de faire valider sa résistance à Scrum par les résultats et aura finalement raison que votre processus n'est en fait qu'une imposture et une perte de temps pour tout le monde.
En tant que Scrum Master, vous encadrez et guidez l'équipe pour devenir plus productive. Le framework Scrum est un outil puissant pour y arriver, mais le framework Scrum ne doit absolument jamais devenir le but en soi - sinon vous le faites Cargo Cult .
Il semble que vous fassiez Cargo Cult depuis 3 ans maintenant et les gens ont réalisé que c'était une horrible méthodologie de gestion de projet. La bonne nouvelle est que vous avez des gens intelligents , ils ont raison. Malheureusement, certaines personnes de votre entreprise l'appellent Scrum, mais encore une fois vous avez des gens intelligents , ils vous ont même dit ce que l'équipe ne faisait pas appelé Scrum.
La planification n'est qu'une perte de temps, car nous déplaçons simplement le débordement 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 changer la planification et le sprint lui-même, donc il y a un point à planifier. Soit ça, soit arrêtez de perdre le temps de tout le monde avec un Sprint Planning inutile. Vous voudrez peut-être demander à l'entreprise de vous envoyer une formation Scrum Master, car la gestion d'un bon Sprint Planning n'est pas anodine.
Pendant la rétrospective, [...] les autres sont silencieux et je dois y faire face à chaque fois.
Si vous faites face au même problème à chaque Rétrospective, un peuple ne prend même plus la peine de parler pendant la Rétrospective, c'est juste une perte de temps. À moins que vous ou l'équipe ne puissiez résoudre les problèmes soulevés dans la Rétrospective, la réunion ne fait que démoraliser l'équipe. Les questions soulevées dans la Rétrospective doivent être traitées et des progrès devraient être réalisés d'ici la prochaine Rétrospective.
Daily Scrum n'est encore qu'une perte de temps pour eux car aucun d'entre eux ne se soucie de parler et de planifier la journée. Ils déclarent simplement "J'ai travaillé sur la tâche X hier et j'y travaillerai encore aujourd'hui".
En effet, pourquoi s'embêter à perdre du temps à tout le monde s'ils travaillent sur les mêmes tâches plusieurs jours? Ils ont absolument raison, que Daily Standup est en effet inutile. Le Standup facilite une collaboration étroite sur de nombreuses tâches qui peuvent chacune être accomplies en une demi-journée ou moins. Si vos tâches ne peuvent pas être décomposées de cette façon (en raison d'une planification de sprint interrompue ou parce que vos tâches ne cadrent pas bien avec Scrum), il est inutile de tenir la réunion de stand-up quotidienne de 5 minutes (c'est pas plus de 5 minutes, non?).
"Nous ne terminons jamais un Sprint. Nous déplaçons simplement des tâches et en prenons 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 réaliser que c'est ainsi parce que lui et tous les autres membres de l'équipe s'en moquent.
Non, vous ne comprenez absolument pas pourquoi il dit cela . Vous avez la cause profonde de l'obstacle - que vous devez résoudre - mal. Ils s'en moquent parce que les pratiques de gestion de projet de l'équipe sont nulles. Prendre soin de faire Cargo Cult et de faire Cargo Cult plus dur ne l'empêche pas d'être Cargo Cult, l'une des pires méthodologies de gestion de projet existantes (à votre défense: également la plus largement utilisée).
Que pouvez-vous y faire?
Écoutez leurs préoccupations. Encore une fois, vous êtes béni en ce que vous avez des gens intelligents .
Aidez-les à résoudre les obstacles.
Et c'est tout, vraiment. Vous devrez expérimenter comment changer la planification de sprint, la scrum quotidienne et les rétrospectives pour les rendre utiles à l'équipe - même si vous vouliez supprimer l'étiquette Scrum, vous avez toujours ces 3 réunions avec une fréquence similaire et un objectif similaire dans toutes les autres méthodologie de gestion de projet là-bas. Quant à la façon dont vous allez expérimenter (fréquence, contenu, qui héberge la réunion, heure, durée, etc.), c'est étonnamment facile: Demandez à l'équipe. Ne forcez pas vos idées sur eux, si quelque chose vous devez les laisser vous forcer leurs idées (en supposant qu'ils peuvent s'entendre sur certains).
Si vous avez peur de perdre le contrôle, définissez des limites à l'avance, 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 expérimentez actuellement, donc tout changement ne dure que 2 sprints, après quoi vous revenez à l'ancien modèle (il vaut mieux donner 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 de même: "Les individus et les interactions sur les processus et les outils".
Si vous, en tant que maître SCRUM, souhaitez utiliser SCRUM pour faire le travail, vous devez les approcher comme une personne interagissant avec une autre. Commencez à réfléchir à comment améliorer le processus. Vous pouvez peut-être les convaincre d'aimer SCRUM. Ils peuvent peut-être 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 citez quelques exemples. Si vous surchargez le Sprint pour qu'il coule toujours ... arrêtez. C'est votre équipe SCRUM. Aidez-les à arrêter de trop s'engager. Repousser la gestion pour obtenir un peu de répit. Utilisez SCRUM pour ce qu'il est bon. Utilisez-le pour présenter à la direction les données qu'elle pousse assez fort pour perdre la valeur de son processus. Si la direction souhaite que SCRUM soit un processus, demandez-lui 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 bouclez une petite partie du calendrier et dites "dans cette partie de notre calendrier, nous allons comprendre comment utiliser les outils correctement". Ne vous engagez pas trop là-bas. Utilisez vos métriques. Concentrez-vous sur toutes vos réunions là-bas. Juste la partie restante de votre projet "SCRUM" comme bouclier pour garder la gestion heureuse pendant que vous et votre équipe "[découvrez] de meilleures façons 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 vos tâches valorisées dans ce seau, et l'ancien seau mourra lentement. Bientôt, vous disposez d'un environnement de développement logiciel dynamique et personne n'est plus sage.
Ou mélangez-les et associez-les. J'ai travaillé sur un programme anti-mêlée. Les clients voulaient pouvoir ajouter de nouvelles tâches à tout moment du processus et nous faire agir immédiatement. (C'était en fait une demande sensée: leur travail était très volatil et ils avaient souvent besoin d'un soutien rapide ... c'est ce pour quoi nous étions payés). Bien sûr, nous avons dû trouver un moyen de résoudre leurs problèmes "pourquoi X n'est-il pas terminé quand vous l'avez promis dans le sprint". Notre solution était en fait de construire un processus en deux étapes. Des tâches à long terme ont été mises dans SCRUM pour une priorisation appropriée. Les tâches à court terme ont été mises dans un processus homebrewed qui s'est concentré sur une interaction étroite entre le client et le développeur. Il était entendu que les clients étaient invités à nous pousser en utilisant ce processus à court terme, mais qu'ils comprenaient que cela poussait sur le calendrier du Sprint, et il leur était interdit d'ajouter des demandes sans entendre et résoudre simultanément les problèmes d'horaire qu'ils ont causés. Résultat? Ça a marché. La plupart des tâches ont été placées dans le processus SCRUM, comme elles devraient l'être, et les urgences ont interagi de manière transparente avec elles. L'attitude était "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 quotidien et à faire fonctionner ce produit. ! "
Je dis cela parce que je sais vraiment. Vous avez un problème dans la haute direction avec un dépassement de calendrier, incapable de définir des priorités et une volonté d'ajouter plus d'éléments mais de ne pas repousser les dates de sortie.
Je disais qu'il n'y a pas de méthodologie qui puisse fonctionner comme ça, mais maintenant que j'ai vu Kanban, je dis que c'est possible, mais seulement parce que Kanban n'a pas à s'en soucier. Il continue de fonctionner en cas de surcharge. Cela n'apportera pas de résultats plus rapidement, mais la sauvegarde dans les files d'attente ne doit pas être effectuée sur un individu et le problème de gestion incombe donc à la direction. Les rapports de rétroaction montrent une surcharge, ce qui est correct.
En raison de ce changement dans Scrum Masters et de leur façon de diriger le spectacle
Eh bien, c'est peut-être votre problème. Un Scrum master n'est pas là pour animer un show, 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. Serait-ce qu'ils étaient plus ou moins autonomes avant que Scrum (y compris l'inévitable Scrum master) ne leur soit tombé dessus? Pourquoi Scrum a-t-il été introduit en premier lieu? Qu'est-ce que c'était censé résoudre?
Scrum est censé fournir des conseils et votre équipe indique clairement qu'elle ne les considère pas comme utiles en aucune façon. Ils ne se soucient pas de l'orientation, ils la considèrent comme une perte de temps inappropriée. Apparemment, au moins un décideur pense qu'il faut de toute façon être guidé. Qui? Pourquoi? Ont-ils un point?
Il s'agit d'un problème non limité aux logiciels.
Dans n'importe quel environnement de travail, il y aura différentes personnes avec différentes personnalités et capacités. Même si Scrum était une méthode parfaite, il y aurait toujours des gens contre cela en raison de leurs personnalités et de leurs capacités.
Les développeurs gèrent les tâches difficiles de manière rationnelle. Pour pouvoir le faire, chaque développeur aura sa façon de gérer ces choses qui peuvent apparaître comme une aversion pour des choses comme Scrum. Si tous les développeurs ont été formés à partir de zéro exactement de la même manière, alors il peut être beaucoup plus facile d'utiliser un modèle, mais sinon une adaptation du côté développeur ou du côté gestion est nécessaire.
De plus, les penseurs indépendants (développeurs et autres spécialistes) n'aiment souvent pas qu'on leur dise comment faire les choses, car c'est leur travail et il est facile pour les opinions d'opposer. Scrum peut sembler être un rituel inutile pour un penseur logique qui habituellement analyserait et agirait en conséquence pour chaque problème à la main.
Ce qui suit semble suggérer où est le problème mais pas ce qu'il est. Il y a certainement plus que cela. Je peux seulement supposer (par expérience) que les développeurs ont essayé mais ont été empêchés. Je l'ai vu à plusieurs reprises où les développeurs veulent réparer quelque chose mais quelque chose de systématique (gestion, politique de l'entreprise, etc.) rend presque impossible, alors ils abandonnent. Ne se soucient-ils vraiment pas ou ne se soucient-ils pas seulement de faire quelque chose qui, selon eux, n'aidera pas (peut-être par expérience).
Je comprends pourquoi il dit cela, mais il ne semble pas réaliser que c'est ainsi parce que lui et tous les autres membres de l'équipe s'en moquent. Ils ne font que travailler au lieu de faire face à des obstacles. Ils se plaignent des obstacles, mais ne font rien à leur sujet. Et quand j'essaie d'aider, ils haussent les épaules.
Ils s'en foutaient, mais au cours des deux dernières années, leur volonté est tombée à plus ou moins bas.
Comment puis-je leur faire voir que les plaisanteries et les secousses circulaires pendant ces réunions coûtent beaucoup d'argent à l'entreprise?
Si quelque chose est imposé à d'autres personnes, c'est à elles de forcer la méthode pour les convaincre des avantages. Bien que je ne crois pas vraiment à forcer 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 fonctionne pour l'environnement actuel.
Vous avez obtenu beaucoup d'excellentes réponses. Voici quelques points supplémentaires qui pourraient être utiles:
Changer la méthodologie est difficile
C'est un énorme défi dans un espace de travail, parce que vous travaillez sous l'inertie de "c'est ainsi que nous faisons les choses", et contre la pression des délais et des besoins de l'entreprise.
Vous avez tout à fait raison de conclure que votre équipe doit consacrer plus du temps à la planification, pas moins ; cette planification est quelque chose que votre temps n'est pas très bon actuellement 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 grande aide. Et s'ils n'apportent pas une grande valeur immédiatement, vous obtiendrez l'évitement plutôt que la coopération.
Je recommande fortement Roy Osherove sur ce sujet. Il a un bref résumé de comment planifier et effectuer des changements dans votre entreprise , et il aborde le sujet de manière beaucoup plus approfondie 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 le faire littéralement?
Motivation sociale: Existe-t-il une pression des pairs pour ce comportement?
Capacité sociale: Est-ce que les gens autour de moi soutiennent mon comportement et m'aident quand j'ai besoin d'aide?
Motivation structurelle: Y a-t-il des récompenses\des punitions pour les bons\mauvais comportements?
Capacité structurelle: L'environnement physique prend-il en charge 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 j'y travaillerai encore aujourd'hui", et ils semblent avoir raison, dans le sens où les tâches continuent d'être repoussées une semaine.
Ce qui est vraiment utile ici, c'est d'apprendre à décomposer les tâches en petits composants. Ce que vous cherchez est la réponse à la question "OK, vous travaillez sur la tâche X, mais sur quoi spécifiquement dans la tâche X travaillez-vous aujourd'hui?"
Certaines réponses pourraient être:
- J'apprends cette classe de code hérité.
- Je corrige un bogue dont les symptômes sont (SYMPTÔMES).
- S'il s'agit d'un bug en cours qui prend un certain temps: "Aujourd'hui, ce que je vais essayer est ... (PLAN)"
- J'ai besoin de changer cette interface.
- J'écris des tests.
- J'intègre du code non testé.
... et ainsi de suite. Être en mesure d'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 avez réellement besoin pour regarder la résolution des jours individuels, pas une tâche X monolithique qui sera prête quand elle sera prête.
Terminé vs livré
Un problème commun (avec Agile et la planification du lieu de travail en général) est que les délais ont tendance à venir de la direction, pas des développeurs. Ce délai pourrait être dissocié du travail réel à effectuer - et en particulier, il est probable 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. Il encourage à couper les coins; codage "rapide et sale"; ignorer les directives; ne pas nettoyer après vous. Il encourage une mentalité de "l'essayer, voir si cela fonctionne. Si oui, livrer. Sinon, essayer autre chose" - et, ainsi formulé, vous pouvez voir pourquoi personne ne peut prédire combien de temps quelque chose prendra.
Alors que si vous êtes travaillez méthodiquement, si vous êtes rigoureux sur la planification et les tests et ainsi de suite, alors vous avez mis en place un tas de panneaux de signalisation et de filets de sécurité. Cela peut prendre plus - vous consacrez beaucoup de temps à des choses qui ne favorisent pas la livraison immédiate, et vous pourriez ne pas être encore très bon dans ce type de flux de travail - mais il sera beaucoup moins volatil.
Donc, une chose à vous demander est: Est-ce les développeurs qui fixent les objectifs de sprint, selon les besoins et les nécessités qu'ils voient réellement? Ou est-ce la gestion fixer les délais, laissant les développeurs essayer de placer leurs engagements dans un calendrier de type sprint?
Si les développeurs n'ont pas le temps de planifier les choses ou de travailler selon un plan fiable, il n'est pas étonnant qu'ils ne puissent pas faire d'estimations utiles. :)
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 bonne raison. C'est mon opinion honnête que cela ne doit pas être tenté .
Pour comprendre pourquoi, lisez ce que tout Scrum Master devrait savoir sur Scrum . Ce n'est pas écrit par moi, mais tout ce qu'il y a de représentatif de mon expérience, que je ne peux que résumer comme pure terreur.
Dans mon cas, j'ai particulièrement souffert au point 5. En gros, la mêlée m'a traité comme un enfant et un perdant. Maintenant, je suis un co-développeur ingénieux aidant mes collègues… pas étonnant ce que je préférerais!
J'ai maintenant un nouveau patron (sans scrum), qui se promène et parle aux gens, et je suis tellement tellement reconnaissant pour ça! Une partie de la raison pour laquelle cela fonctionne est que nous avons également une salle de chat (nous utilisons le plus important) pour la communication entre développeurs. Si quelqu'un a un ordre du jour, nous le prenons là. Les réunions sont réservées aux discussions ad hoc avec les développeurs et non à l'imposition de délais quotidiens artificiels.