Que faire lorsque les développeurs ne sont pas motivés ? - Scrum Life 23

🎁 Le guide du Scrum Master compétent 👉 sl.run/OwiNkI
Déjà travaillé dans une équipe avec des développeurs en manque de motivation ? Quelle en était la raison ? Qu'avez-vous fait pour y remédier ?
➙ Vos réponses dans les commentaires !
💜️ La communauté Scrum Life 👉 sl.run/2hbZ5i
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
- Les principes sous-jacents au Manifeste Agile, en français : agilemanifesto....
- Scrum Life 8 - "Je n'arrive pas à définir l'objectif d'itération" : • Je n'arrive pas à défi...
- Scrum Life 9 - La Revue d'itération, bien plus qu'une démo : • La Revue d'itération, ...

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/V5o7Tc

[@eth2.1]

Bonjour bonjour, J'apprécie beaucoup ce dont tu parles et je suis particulièrement très intéressé par ce sujet en ce moment. Il y a tout de même un truc dont je ne suis pas d'accord, tu sais avec ce monde de consulting et le trop de sous-traitance les développeurs n'aiment pas le legacy parce qu'ils peuvent très facilement sortir du marché s'ils tardent trop sur de vieilles technos et on sait tous à quelle vitesse ça avance et des releases tous les jours ... et c'est pareil pour le produit, le dev se dit oui mais dans 6 mois je serai peut-être plus là et ce que je prendrai avec moi ce n'est pas ma maîtrise de ce produit mais ce que j'aurai appris techniquement ! Voilà mon avis de pourquoi les développeurs ont peur du legacy et trop de fonctionnel sur un produit et non parce que c'est des juniors lol.

[@TechAvecBertrand]

Vrai !

[@kaloumbousdan9997]

@@TechAvecBertrand il peut maintenir ses compétences à jour avec des side projects perso , et tester toutes les technos qu’il veut . Parce qu’il y’a aussi plusieurs techno qui apparaissent chaque jour mais qui finissent comme des effets de mode , de nouveaux SGBD , langages, environnements , etc . A un moment dans développement mobile cross-platform on ne parlait que de Xamarin , aujourd’hui c’est Flutter , et demain ? Donc comme Lambert le dit je pense qu’un bon Dev devrait être en mesure de se challenger y compris sur des vielles techno, faire du legacy si c’est nécessaire à atteindre les objectifs d’itération / vision produit et dans une maj ultérieure où on fera le refectory du projet ça pourra être avec les nouvelles techno qui cadrent le plus , mais pour ne pas perdre la main il fait ses side projects ou participe à des projets open source à ses heures perdues.

[@Yo67]

@@kaloumbousdan9997 si ton taff n'est pas intéressant, ta solution c'est de t'en satisfaire en faisant des heures supp à côté sur une techno plus intéressante, sérieusement ?

[@CallMeVanou]

Bonjour, encore merci JP pour cette excellente vidéo. Pour ma part en tant que PO j'ai la chance de travailler avec une équipe au top et naturellement volontaire. Et en terme d'agilité nous avons grandis ensemble (et nous continuons de grandir). Nous avons clairement vu la différence entre il y a 1 an et aujourd'hui. Au départ on faisait des US, on les mettait dans le sprint et le seul objectif était de les finir dans le sprint(ce qui n'arrivait jamais). Mais c'était pas grave parce qu'on les reportait dans le sprint suivant et la vie continuait ainsi. En creusant la philosophie de scrum, nous avons commencé à définir un sprint goal et là tout à changer : l'équipe d'elle même était capable de concentrer son énergie sur les US pour atteindre l'objectif d'itération et ce grâce au sprint goal défini. De plus, disposant à présent d'un objectif clair, nous avons également pu le communiquer aux parties prenantes au début du sprint. De ce fait, c'était beaucoup plus clair pour eux et il nous est devenu beaucoup plus facile d'obtenir leur présence à la sprint review fort du teasing effectué via ce sprint goal. Pour finir, c'est l'équipe elle-même qui présente leur travail aux skateholders durant la review et cette proximité avec le métier booste clairement leur motivation. L'équipe se sent désormais encore plus impliquée et cherche réellement à fournir un service aux métiers. Nous avons donc obtenu aujourd'hui un beau cercle vertueux qui est parti innocemment de la mise en place du sprint goal!

[@ScrumLife]

Waaah super partage et retour d'expérience ! C'est top 👍👍👍 Merci beaucoup !!! Et bonne continuation dans cette voie 😊

[@mwood292]

Merci Jean-Pierre ! Voilà plusieurs mois que je me questionne sur le manque de motivation dans mon équipe. Il y a quelques semaine j'ai enfin mis le doigt dessus : le manque de vision produit ! Du coup ta vidéo me conforte dans mes décisions de continuer d'améliorer cet aspect. Merci

[@naveedmirza1261]

Carrément, Tous les je me prends la tête avec des dev zombis. Si tu voyais le mood des daily Et l’ambiance des reviews / retros

[@coach-okr]

Super vidéo ! pour ma part j'ai vu le changement le jour ou l'équipe de devs c'est assise à côté d'une utilisatrice finale qui leur a montré son travail et expliqué combien l'application était importante pour elle. Vision direct du service rendu ! Merci pour la vidéo !

[@oniyonkuru]

Ta vidéo est pile poil sur ce que j'ai vécu dans l'entreprise que je viens de quitter. Un management tyrannique et qui entrave toutes les décisions prises par les développeurs. Bref les dev et moi (qui était censé les booster) étaient complètement démotivés. 100% de l'équipe a démissionné. Ta vidéo m'a permis de réfléchir sur mes erreurs et sur ce que je devais faire pour maintenir une bonne motivation dans l'équipe. Merci pour tes conseils JP

[@paullagues2375]

Pour avoir été développeur et maintenant Business analyst en équipe agile, je me rends compte de plus en plus que donner du sens a ce que l'on demande aux développeurs non seulement les motive mais en plus les pousse à donner le meilleur d'eux mêmes. C'est aussi quelque chose que j'ai apprécié qu'on fasse avec moi lorsque j'étais dev, ça me permettait d'avoir une vision globale de la demande et du coup me motivait à trouver la meilleure solution.

[@ScrumLife]

Oui ! C'est, à vrai dire, une généralité qui s'applique à n'importe quel être humain. Es-tu d'accord ? -- JP

[@CoinCoin86]

Merci pour la vidéo, ça m'a permis de bien réfléchir sur mon problème dans mon équipe. La vision produit est importante, clairement. Aujourd'hui, ma motivation vient de celle-ci. Répondre à un besoin est ce qui me motive aujourd'hui. Pouvoir dialoguer avec l'utilisateur final, voir comment il travail est très instructif et productif. Après, je me suis posé la question, comment ça se passe lorsque le produit en lui-même n'est pas l'idée révolutionnaire que tout les devs ont envie de faire, comment faire lorsque c'est peut-être le domaine métier qui n'intéresse pas? Y a-t-il des outils un peu comme l'ESVP afin de pouvoir prendre conscience, guide? Après, j'ai l'impression qu'on commence à rentrer dans un problème qui n'est plus lié à scrum en lui-même

[@PierreBonneau]

Bonjour, Je pense que les motivations de chacun sont différentes, et que la vision produit correspond à certains profils. De mon coté ca m''enthousiasme plus ou moins selon les fois. En revanche il y a un point que je retrouve à chaque fois : Est-ce que les intervenants ont l'impression qu'ils sont utiles et écoutés. C'est véritablement ça le différentiateur dans une équipe. Ca peut passer par la vision produit, qui peut même être co-construite. Mais ca passe aussi par la possibilité de travailler sur les petits problèmes qui bouffe la vie de l'équipe, sur cette dette technique qui n'est pas génante en soit, mais qui le devient si on continue à la faire augmenter. En résumé, il y a en général 3 éléments dans un sprint : La vision produit, la vision technique / amélioration continue et les évenements de production. Si on conserve un ratio équilibré qui assure a tous une reconnaissance, on pourra facilement y déroger parfois en cas de coup de bourre demandé par l'une ou l'autre des dominantes. Mais si la vision produit écrase les autres, on obtient souvent des dev super démotivés, qui vont chercher des challenges plus sympa ailleurs(le boulot ne manque pas) et qui du coup vont charger la barque encore plus pour les survivants. La vision produit doit donc être importante, presque centrale, mais pas omniprésente. Un exemple : vous avez ce problème sur GIT qui vous fait planter un merge sur deux. Sur 20 US dans le sprint, ca vous fait perdre 2 ou 3h. Le PO décide que non, c'est pas important parce que l'on construit une machine qui rapportera des millions... On oublie juste que les dev encaissent la difficulté quotidiennement, se découragent, etc... les 3 h deviennent une souffrance. A l'opposé, la société va encaisser des millions... ce qui a peu de chance de ruisseler jusqu'au dev. ils s'en foutent donc pas mal. Et on peut appliquer ca aussi à la MCO, et aux équipes de support qui souffrent en face des clients pendant des mois, quand le PO ignore leurs demandes parce que les clients ont déjà payé par exemple. Coté client, ca peut avoir un certain sens (on ne perd pas d'argent aujourd'hui), coté employés c'est une souffrance infligée volontairement par un collègue de travail.

[@PierreBonneau]

Merci pour cette précision. C'est vrai que la vision produit devrait inclure les aspects techniques. Il reste beaucoup à faire pour que ca soit le cas, mais peut etre que le cout du délai pourra aider comme vous le suggérez dans une autre vidéo. A bientôt, pierre

[@elisevanholsbeeck8240]

J'expérimente le même genre de chose. La démotivation de mon équipe est venue du manque d'intérêt dans le produit. On n'autorise plus l'amélioration technique car la dette technique s'est tellement accumulée que cela devient trop cher. La stratégie est de faire le minimum pour maintenir le produit fonctionnel en production. La direction ne veut plus laisser du temps pour faciliter le travail des développeurs et l'équipe opérationnelle. C'était sympa pourtant le challenge technique. Compliqué de se motiver quand la stratégie n'est pas intéressante.

[@jarod51]

Je suis content car on commence à retrouver la coupe de cheveux des premières vidéos ! Non, plus sérieusement, encore une analyse plus que pertinente ! L A V I S I O N P R O D U I T est essentielle !!! Par contre moyen d'accord sur le côté challenge hyper intéressant de maintenir à flot du code legacy, certaines applications méritent le bûcher et puis c'est tout !

[@john-yn5tr]

Hello, j'ai regardé la vidéo en entier mais j'ai du mal à adhérer, malheureusement. A un moment, j'ai vraiment aimé un produit (un site de cartes virtuelles, c'était vraiment un projet fun), mais j'utilisais un cms que je détestais (ez publish 4) et j'ai tellement souffert à faire des choses simples (et à tenter de les faire proprement...) que ma motivation est descendue en flèche très rapidement. Les deux autres dev adoraient ez publish et ont pris leur pied. Et pour reprendre un exemple personnel, dans le cadre de mes études, je dois réaliser un projet perso. Du coup, la motivation est forcément là, puisque je choisis le projet (et j'ai hâte d'avoir le rendu final!) mais... je dois le faire en jee, que je trouve très très lourd, et je sais que ça casse complètement ma motivation. Donc je ne dirais pas que la techno n'est qu'un détail, même important. Idem, je suis un jour intervenu sur un projet vraiment sympa, en Symfony2 (donc la techno n'était pas en cause, tu connais mon AMOUR pour ce framework), mais je suis arrivé deux mois après le début du projet, et le code était si horrible (et le niveau des dev à l'époque vraiment très bas, même celui du lead dev), si mal construit, que le projet a tourné devant le client mais je ne me suis pas senti du tout motivé. J'ai essayé de pousser de bonnes pratiques, que ce soit pour la gestion du projet, pour l'architecture, la scalabilité du code... mais il fallait produire vite et "on s'en foutait de la qualité". Et bien au bout de quelques mois, je n'ai même plus fait d'efforts. A quoi bon essayer de faire un code propre, souple, SOLID, si un autre dev qui n'écoutera pas mes conseils va finir par me le pourrir. Le projet a fini avec une floppée de régressions incontrôlables (dommage qu'ils n'aient pas voulu faire de tests...), un code qui était verrouillé à un tel point que la maintenance et l'évolution en sont devenus quasiment impossibles à moins de rajouter des if else un peu partout, et une équipe qui n'était pas fière sauf le lead dev qui se contentait d'un produit présentable peu importe le code à l'arrière. Mais le client était content car c'était joli graphiquement et qu'il s'attendait aux bugs... qui continuaient à être corrigés un an plus tard à ce qu'on m'a dit. Pour moi, la motivation est un ensemble: - une équipe motivée (difficile de l'être si peu le sont) - un produit vraiment cool - une techno qui plait (je t'assure, va demander à quelqu'un de faire évoluer un produit génial sur une techno qu'il déteste, même s'il se sent porté par le produit, je doute qu'il garde sa motivation jusqu'à la fin) - un désir commun de qualité (et une harmonisation permettant d'avoir des pratiques de code communes) - une méthodologie qui convienne à tout le monde (agile ou pas, car je vois bien qu'aujourd'hui, même si nous ne sommes plus du tout dans l'agilité dans mon équipe, j'aime y être et je me sens très motivé en grande partie par le désir de qualité poussé par le lead dev et les autres dev de l'équipe) - une bonne ambiance (ça joue énormément à mon sens) - une écoute commune (car si on ne se sent pas écouté dans son équipe, la motivation baisse) On en reparle si tu veux, et je comprends que les sensibilités de chacun sur les différents points que j'ai évoqués peuvent énormément varier et influer peu ou beaucoup sur la motivation.

[@john-yn5tr]

ah ah! En fait, j'ai encore des objections, votre honneur! Je suis d'accord, apprécier un produit ne veut pas dire qu'on en a une bonne vision (c'est vrai que je l'ai pensé implicitement, mais ce n'est pas la même chose) Pour faire le parallèle avec le projet d'étude, si tu savais le nombre de projets où la "mauvaise" techno a été prise pour le projet en agence web (et pourtant, on était nombreux à dire que ça serait bien mieux dans telle ou telle techno qui était vraiment adaptée à ce type de projet et pour lequel nous avions une maîtrise - par exemple drupal 7 pour un site vitrine alors que, personne ne connaissant le cms, on s'est retrouvé à la fin avec des plugins qui ne faisaient pas ce qu'on voulait, qui étaient bugués (du style la traduction d'une langue qui disparaissait dès qu'on en rajoutait une nouvelle dans une autre langue). Idem, parce qu'on avait vendu drupal 7 pour un backoffice couplé à une api REST et que personne ne le maîtrisait (mais que ça faisait bien de dire qu'on utilisait drupal 7), on s'est heurté à des problèmes... parce que la techno est très bien pour certaines choses (notamment des sites vitrines si ça colle au cahier des charges - ce qui n'était pas le cas pour le projet dont je parle - et si on a vraiment conscience des limites de l'outil, du code qu'il va devoir faire derrière pour les contourner et des limites des plugins existants). Et clairement, quand on a comparé le temps passé à rajouter des bouts de pansement partout + la TMA, on a compris à la fin qu'il aurait été plus simple et plus pérenne de le faire avec un framework php plutôt que de tenter à tout prix de faire rentrer quelque chose de rond dans une fente carrée (car c'est vraiment ce qu'on a fait à la fin en comprenant qu'aucun plugin ne pouvait faire ce qu'on voulait car ils avaient tous un bug à un moment ou à un autre) Dans l'équipe où je suis aujourd'hui, peut-être que refondre toutes les api dans un an avec API Platform serait la bonne techno à employer plutôt que de faire du Symfony3 et de recopier le même code pour chaque API. Peut-être. Mais il faut un vrai POC pour cela. Je suis d'accord, quand il faut livrer parce qu'on s'est engagé à livrer et qu'au final, on s'en fiche du code, ça n'est pas dû à une vision produit incomplète ou inexistante. En effet, nous l'avions et nous en connaissions bien les tenants et aboutissants (c'est nous qui avions rédigé le DAT donc on avait vraiment bien cerné le produit). C'est une politique de la boîte (jugeable ou non, à nous de décider) "Une bonne vision produit va mécaniquement amener vers une bonne qualité, car la qualité est généralement implicite : personne ne veut d'un produit sans qualité. Et qui plus est, sans qualité la vélocité et la flexibilité vont diminuer... Et on ne pourra pas réaliser la vision produit." => malheureusement, en agence web, c'est très très rarement appliqué. On sort un truc qui "marche" pour le client et on se dit que le code, on s'en fiche un peu. C'est le discours que l'on m'a sorti à chaque fois que j'ai proposé des améliorations, et ce dans plusieurs boites. Et clairement, plus il y a eu des bugs, plus la velocité et la flexibilité ont diminué... malgré une bonne vision produit mais une équipe trop junior, pas rigoureuse et qui ne voulait pas écouter quelqu'un qui avait plus d'expérience (même si je n'avais qu'un an d'expériences de plus, j'avais fait des missions qui m'avaient confronté aux mêmes problématiques mais les solutions que j'ai proposées auraient rajouté plusieurs jours de dev et on m'a dit que ce serait plus rapide de rajouter des if else à 10 endroits différents et que ça n'évoluerait sûrement pas derrière... et boum, ça a évolué quelques mois plus tard et on a rajouté de nouveaux else car la dette technique était devenue trop importante) "Et c'est aussi pour ces raisons qu'une bonne vision produit amène naturellement vers des technos modernes et sympa : parce qu'au final c'est ce dont on a besoin pour réaliser la vision produit."=> idem, souvent, le client veut imposer sa techno (drupal 7, 8, EZ Publish) parce qu'il connait des clients qui en sont satisfaits et que les produits sont connus. Et souvent, les agences web, trop contentes d'avoir remporté l'appel d'offre, ne disent rien et essaient de se calquer sur le désir du client plutôt que d'apporter une réelle expertise en leur disant qu'elles maîtrisent une techno qui collerait davantage au produit. C'est fou comme j'ai vu ce type de cas se produire encore et encore que ce soit en SSII ou en agence web. Du coup, malgré une bonne vision produit (et, si possible, une appréciation du produit), j'ai vraiment l'impression que c'est un ensemble de choses qui jouent sur la motivation et pas principalement la vision produit. Par contre, je suis à 100% d'accord pour dire que sans vision produit claire, la motivation ne suit pas.

[@Cendrounet]

Il faut également accepter que l'équipe de dev' est une des parties prenantes du logiciel, et que si elle travail dans des mauvaises conditions, son moral va en être affecté. C'est intéressant ce que vous dites, mais ça ne corrige pas les problèmes autres : - équipe de dev avec beaucoup de responsabilité mais aucune autonomie - code très fragile où chaque mise en prod est source d'angoisse voire de bug à l'autre bout du logiciel - aucune priorisation du métier informatique

[@franckdelinard8099]

Oui je me suis retrouvé avec des jeunes chez BNP sympa mais pas motivé j'ai essayé d'expliquer qu'il y avait des bug sur l'application que j'utilisais mais il n'était pas motivé malgré qu'il avait des compétences pour le faire

[@hukar075]

On voit que les vieilles hiérarchie sont de retour, le PO et le Scrum Master ayant plus d'affinités avec les dirigeants. De l'autre côtés des Dev ayant besoin d'être motivé !? De quoi parle-t-on ? Il y a legacy et legacy, dans ma carrière j'ai pu une fois reconstruire sur un ancien projet en le modernisant, mais sur deux autres projets (dont un écrit dans 11 langages de programmation différents !!) la réécriture semble une solution loin d'être junior. J'entend les propos de quelqu'un qui ne doit pas beaucoup coder dans son quotidien :)

[@olivierledru2765]

Avoir des Objectifs, du Sens est l'un des 3 piliers de la motivation intrinsèque proposés par Dan Pink, Cf. kzbin.info/www/bejne/l3u6eWtqg9yomcU et c'est vrai que ça manque bien souvent, surtout quand une équipe Scrum est en mode "course aux Story Points"

[@AlexandreGucia]

Autant je suis d'accord qu'utiliser de vieilles technos est une mauvaise excuse, autant pour la dette technique c'est justifié. Attention aussi à ne pas confondre vieilles techno et techno obsolètes bardées de failles de sécurité. Un projet legacy est une opportunité pour améliorer sa compréhension du projet et affûter ses connaissances en développement. Dans ces projets, la partie tests est négligée, l'architecture est brouillonne, il y a des code smells partout, ... ce qui freine la productivité et démotive l'équipe. Les causes sont diverses comme des développeurs négligeant, un manager qui pousse l'équipe à délivrer toujours plus vite, une succession de développeurs peu expérimentés, un turnover élevé, ... Le paysage est posé. Il est nécessaire d'identifier l'origine du problème et d'inverser la tendance. L'action prioritaire est de s'assurer que les tests soient suffisamment complets, puisqu'ils sont notre garantie que l'application a le comportement attendu. Ensuite, ces tests vont nous permettre d'améliorer le code en tout sérénité. De facto, la productivité et la motivation vont revenir. La meilleur manière d'être productif est de prendre du recul pour mieux avancer.

[@H3_Vince]

Give them Psilocybin

[@TheGragol]

"Ca c'est un point de vue de junior" Sévère mais juste !

[@j0hnmerrick]

oui très juste. Sauf que des fois dans une équipe on a beaucoup (beaucoup) de juniors (surtout en ESN). Du coup c'est un vrai challenge de les faire changer de mindset. Que la vie c'est pas une techno. Surtout que ce que voit le junior c'est aussi son cv. et un cv avec des technos récentes c'est mieux que des vieilles techno. et que souvent les sujets innovants se font avec des technos récentes. Ca va aussi avec le fait que beaucoup de juniors ne jurent que pas le build, que la tma "c'est le mal" à leur yeux. Alors qu'il y a tellement de chose à apprendre dans une tma qui vie. Mais là où je rejoins la vidéo, c'est qu'il faut trouver une vision, un sens a ce qu'on fait. Et hélas il y a des projets sans vision, sans réel sens. Il y a du budget donc on fait des trucs, mais depuis longtemps le produit est mature. A ce niveau là, je pense qu''il faut fuir. Pour revenir à la motivation, n'y a pas des exercices à proposer à son équipe pour déceler leurs réelles motivations (intra et intrinsèque ), il peut arriver que certain profil se foute de la vision, mais privilégie la techno uniquement. je crois qu'il existe des méthodes issue de management 3.0 qui vont dans ce sens. @scrumlife : moyen de traiter de ce sujet dans une future vidéo ?

[@ScrumLife]

Oui en effet il y a le célèbre "Moving Motivators" de Jurgen Appelo / Management 3.0. Oui, ce pourrait être le sujet d'une future vidéo.

[@constantinguay1726]

@@ScrumLife Hey justement l'épisode est sorti : kzbin.info/www/bejne/oomXioSsZZh-opI :)