Question

Je suis le deuxième développeur et récemment embauché ici dans une boutique PHP/MySQL.J'ai été embauché principalement en raison de mon expérience dans la lutte contre une sorte de processus pour sortir d'un désordre chaotique.Du moins, c'est ce que j'ai fait dans ma dernière entreprise.;)

Depuis que je suis ici (quelques mois maintenant), j'ai intégré mon patron, mon chef de produit et plusieurs autres personnalités clés (mais surtout des poulets, si vous pardonnez les stéréotypes basés sur Scrum).J'ai également contribué à apporter une certaine visibilité au cycle de développement d'un produit majeur en retard depuis plus d'un an.Les gens adorent ça !

Cependant, mon collègue (le seul autre développeur ici pour le moment) n'est pas intéressé.Elle préfère fermer sa porte, se concentrer sur son travail et rester seule.Moi?Je suis dans toute l'approche Agile de collaboration, de coopération et d'ouverture.Sans sa contribution, j'ai commencé les pratiques Scrum (mêlées quotidiennes, burndown charts et autres choses que j'ai trouvées et qui fonctionnaient pour moi et mes équipes précédentes (ala H.Le tableau mural sympa de Kniberg).Pendant notre lever quotidien, elle se faufile et nous ignore comme si nous n'étions pas réellement devant sa porte (nous le sommes en fait).C'est assez étonnant.Je n'ai jamais vu une telle résistance.

Question...comment puis-je la faire embarquer ?La pression des pairs ne fonctionne pas.

Merci de la part de mon collègue Scrum-borg,

beau

Était-ce utile?

La solution

Alors que d'autres méthodologies agiles comme Scrum incarnent de nombreuses bonnes pratiques, lui donner parfois un nom et en faire (comme de nombreux blogueurs l'ont commenté) une « religion » qui doit être adoptée sur le lieu de travail est plutôt rebutant pour beaucoup de gens, moi y compris.

Cela dépend de vos options et de vos engagements, mais je sais que je serais beaucoup plus enclin à accepter les idées parce que ce sont de bonnes idées, et non parce qu'elles sont un mouvement en marche.Essayez de la mettre en œuvre/de l'impliquer dans les pratiques une par une, en lui montrant comment elles peuvent également améliorer sa vie et son flux de travail.

Les programmeurs aiment les choses sympas qui les aident à accomplir leurs tâches.Ils détestent qu’on leur prêche ou qu’on leur demande de monter à bord de ce qu’ils considèrent comme un mouvement en marche.Présentez-le comme le premier plutôt que comme le second.(Cela va sans dire, assurez-vous qu'il s'agit bien du premier)

Modifier:une autre question

Je n'ai jamais réellement travaillé pour un endroit qui utilisait une méthodologie agile spécifique, même si je suis assez heureux où j'en suis actuellement dans la mesure où nous intégrons de nombreuses pratiques agiles sans le battage médiatique ni le dogme (le meilleur des deux mondes, à mon humble avis). ).

Mais je viens de lire sur Scrum et un système comme celui-ci est-il même bénéfique pour une équipe de 2 personnes ?Scrum ajoute une certaine surcharge à un projet, semble-t-il, et cela peut contrebalancer les avantages lorsque vous avez une très petite équipe où la communication et la planification sont déjà faciles.

Autres conseils

Sans sa contribution, j'ai commencé les pratiques Scrum (mêlées quotidiennes, burndown charts et autres choses que j'ai trouvées et qui fonctionnaient pour moi et mes équipes précédentes (ala H.Le tableau mural sympa de Kniberg).Pendant nos levées quotidiennes, elle se faufile et nous ignore comme si nous n'étions pas réellement debout juste devant sa porte (nous le sommes en fait).C'est assez étonnant.Je n'ai jamais vu une telle résistance.

Question...comment puis-je la faire embarquer ?La pression des pairs ne fonctionne pas.

Ouais !Qui aurait envie de travailler dans un environnement aussi oppressant ?Si vous avez de la chance, elle enverra son curriculum vitae et vous pourrez embaucher quelqu'un qui participe à votre processus de développement.

En supposant que vous souhaitiez vous accrocher à elle, je refuserais (ou désactiverais) la rhétorique et m'efforcerais d'abord d'être un ami et un collègue.Si le projet est en retard d'un an, elle ne peut pas se sentir bien dans sa peau et il semble que vous n'ayez pas peur de claironner votre succès.Cela peut être intimidant.

Cependant, je ne connais rien à Scrum.J'imagine juste ce que ce serait de se promener à la place de votre collègue.

beau, mon pote,

Je vous suggère vraiment de lire le blog de Steve Yegge intitulé "Bon Agile, Mauvais Agile".C'est un vieux mais bon, et je pense que c'est une lecture incontournable pour quiconque - comme moi il y a environ 2 mois - qui est un peu, disons, « trop désireux » d'améliorer l'agilité de son lieu de travail.Agile propose de nombreuses bonnes pratiques, mais vous devez toutes les prendre avec des pincettes et adopter ce qui vous manque et ignorer toutes les autres choses qui pourraient être inutiles dans une situation particulière - par ex.la mêlée quotidienne.Si votre collègue souhaite simplement coder en silence (lisez Peopleware pour savoir pourquoi c'est une bonne chose) et qu'elle est un membre productif de l'équipe, arrêtez de la déranger avec votre mêlée et laissez-la travailler de la manière qu'elle préfère.

Les gens sont généralement moins « hostiles » à l'égard de ces pratiques si vous les approchez et leur dites simplement : « Avez-vous une seconde ?Écoute, la communication est vraiment un problème en ce moment, j'ai l'impression de ne pas savoir ce que tu fais et je n'ai vraiment pas envie de te marcher sur les pieds et de passer deux jours à écrire quelque chose que tu as déjà aimé la semaine dernière, alors travaillons là-dessus.J'aimerais essayer X, qu'en pensez-vous ?".Soyez compatissant et ne tolérez pas les « pommes pourries », c'est littéralement ainsi que j'ai amélioré mon lieu de travail, et de nombreux problèmes ont commencé à s'évaporer.Nous ne sommes en aucun cas un endroit conforme à 100 % XP ou 100 % Scrum, car nous utilisons simplement tout ce qui fonctionne et est nécessaire.

Simple.Ne parlez pas de mêlée.N'utilisez pas Scrum sur elle.Prenez plutôt les principes sous-jacents de Scrum (par ex.le but plutôt que l'application) et créer différentes approches qui s'adaptent à sa façon de travailler mais qui ont de subtiles teintes de mêlée.

Tous les humains sont différents et beaucoup de programmeurs n'aiment pas Scrum.Je ne leur imposerais pas cela, car cela serait tout simplement contre-productif.Je suggérerais d'identifier les problèmes dans le processus de développement (de manière non Scrum), de voir si vous pouvez l'amener à accepter que les problèmes existent, puis de demander son ce qu'elle pense être une bonne solution.Sa coopération et sa contribution au processus sont essentielles à sa coopération, car si elle n'a pas d'adhésion, elle ne deviendra pas une citoyenne.

À partir de là, vous pourrez, espérons-le, créer une sorte de mêlée quasi hybride + son approche du processus où vous pourrez tous les deux convenir de la voie à suivre.

Je pense que la clé serait de l'aider à comprendre pourquoi vous faites Scrum en premier lieu.Je suppose que tu as tes raisons, alors pourquoi ne pas lui dire ?Vous risquez de rencontrer une résistance à tout changement si les personnes impliquées ne comprennent pas pourquoi il y a un changement ou quels en bénéficieront elles.Si vous pouvez lui expliquer les raisons pour lesquelles vous utilisez Scrum et les avantages suivants d'une manière qui se rapporte à son travail quotidien, je pense qu'elle est plus susceptible d'adopter une attitude plus positive à son égard.

Si elle ne voit aucune valeur dans le processus Scrum, ou ne comprend pas en quoi cela la concerne, elle ne s'en souciera probablement pas.

Je pense que l'un des concepts les plus importants à comprendre concernant Scrum est le fait que vous travaillez en groupe et que vous vous engagez dans votre projet en tant que groupe, et non en tant qu'individus.Pour beaucoup de gens, c'est la chose la plus difficile à comprendre, tant ils sont habitués à vivre dans « leur propre monde ».

Je ne suis pas sûr que Scrum soit le problème central ici ;Je suppose qu'elle se sent menacée par le nouveau venu qui apporte beaucoup de nouvelles idées et fait bouger les choses.J'ai déjà été dans cette situation en tant que nouvelle personne apportant une nouvelle perspective sur les choses, et parfois il est tout simplement difficile d'amener immédiatement les personnes existantes à une nouvelle façon de penser.Cela nécessite souvent un changement de culture qui ne se produit pas du jour au lendemain.

Essayez d'obtenir son avis et son opinion sur les choses autant que possible, et essayez de montrer que vous respectez le fait qu'elle fait partie de l'équipe depuis plus longtemps que vous.Si après un certain temps elle ne participe toujours pas, tout ce que vous pouvez faire est d'en parler à votre manager et de le laisser s'en charger à partir de là.

Continuez vos efforts pour impliquer l’autre développeur.N'oubliez pas que c'est vous qui souhaitez effectuer ce changement.Demandez de l'aide pour les problèmes que vous rencontrez.Invitez-les à la réunion debout quotidienne.Je fais actuellement la planification du stand up quotidien et je m'assure que tous les cochons et poules sont invités.Si vous êtes le chef de file du projet, c'est à vous de faire face à la situation et de prendre un risque.Mettez-vous là-bas.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top