MVP Agile (Joueur / Programmeur le plus utile)

Récemment, j'ai été impliqué dans un projet agile (utilisant Scrum) où la direction a eu l'idée que l'équipe nommerait un développeur 'MVP' ainsi qu'un QA 'MVP' à la fin de chaque sprint, voté par le équipe. Le MVP reçoit ensuite une petite récompense monétaire et un déjeuner gratuit ainsi qu'un trophée à afficher sur son bureau. Jusqu'à présent, nous avons eu deux sprints avec ce système de récompense.

Le bon que j'en vois est le suivant:

• Plus de bugs ont été corrigés (c'est ce que la haute direction veut voir, un nombre change dans la direction qu'elle veut)
• Le MVP de chaque `` équipe '' est reconnu et reçoit un boost d'estime de soi (ou est-ce un boost d'ego?)

J'ai remarqué quelques-uns de ce que je considérerais comme de mauvais côtés pour faire une telle chose (au moins du point de vue du développeur):

• Il y a quelques développeurs qui sont tellement préoccupés par le nombre que la qualité des corrections de bogues a baissé. Les correctifs dans un domaine provoquent des régressions dans un autre.
• Il y a quelques développeurs qui choisissent des bogues «plus faciles / plus rapides» pour augmenter leur nombre de bogues. Cela pourrait être bon ou mauvais ici, je suppose.
• Une priorité plus élevée (qui correspond la plupart du temps à des problèmes «plus difficiles / plus longs à réparer») devient en fait une priorité plus faible.
• Les défauts de blocage ne sont pas traités en temps opportun, car ils prennent généralement plus de temps et nécessitent plus de coordination avec l'AQ.
• L'aspect d'équipe au sein de l'équipe de développement a été perdu. L'aspect d'équipe de Dev et QA travaillant ensemble ne s'est pas amélioré non plus, mais n'a pas vraiment trop changé par rapport à avant.
• Travailler au-delà des corrections de bogues ou travailler vers CE nombre n'est pas facilement reconnaissable / suivi.

Je crois que chacun des «mauvais» ci-dessus peut être traité dans une certaine mesure, selon la façon dont l'équipe les gère.

Ma question est, alors, est-ce que quelqu'un a réussi quelque chose comme ça, où vous reconnaissez un MVP par sprint? Si oui, qu'est-ce qui, selon vous, a contribué à ce succès?

Agile met l'accent sur l' effort d'équipe , pas sur l'effort des individus. Donc non, cette approche n'est clairement pas agile.

Plutôt que d'encourager la collaboration d'équipe, cela encourage chaque membre de l'équipe à se concentrer sur son propre résultat. Cela peut même conduire les membres à éviter de s'entraider (ou pire), ce qui à long terme empêchera l'équipe de s'améliorer.

Je suggère de récompenser l'équipe dans son ensemble si elle a fait du bon travail.

Je pense que c'est un bon exemple d'application de la «mauvaise» gamification . Le problème est que vos programmeurs avaient potentiellement une motivation intrinsèque à résoudre des problèmes et à surmonter des défis (trouver et corriger des bogues durs) ET, depuis que vous avez implémenté Scrum, à travailler en tant qu'ÉQUIPE. En d'autres termes, ils voulaient potentiellement faire du bon travail.

Maintenant, au moins pour certains d'entre eux, cette motivation intrinsèque ou une partie de celle-ci a été remplacée par une motivation extrinsinc consistant en des titres ("MVP de la semaine") et des récompenses (montant monétaire et déjeuner gratuit), qui sont souvent des mécanismes de jeu. d'un processus gamifié.

La gamification peut être appliquée avec succès au travail, mais vous devez être très prudent en tirant parti de la motivation intrinsèque / extrinsèque. La motivation extrinsèque doit pouvoir alimenter l'autodétermination pour que la motivation devienne intrinsèque. Cependant, ce qui s'est passé ici est l'inverse, les programmeurs "jouent le jeu" pour gagner .

Pour résoudre ce problème, vous pouvez demander à la direction de modifier un peu les règles:

• donner des points correspondant à la difficulté et à la priorité des billets. Faites en sorte qu'il soit beaucoup plus intéressant, par points, de corriger un bug difficile à trouver / reproduire.
• donner des points pour résoudre les problèmes en coopération (encore une fois, l'ÉQUIPE). C'est là que vous pourriez amener plus de programmeurs à interagir avec le contrôle qualité. Donnez des points pour un problème résolu en coopération par un programmeur ET un AQ par exemple.
• donner différents titres, un pour le plus de points et un pour le plus de billets. Cela devrait satisfaire les instincts compétitifs des programmeurs.
• établir éventuellement une compétition amicale entre le Dev et le QA en résumant les points de chaque membre d'une équipe

La réduction de la possibilité d'apparition de bogues de régression est cependant un autre problème. Vous pourriez par exemple appliquer des points négatifs, mais je suis sûr que ce n'est pas une bonne idée car ce serait une forme de punition. Il serait peut-être préférable de démarrer automatiquement un sprint avec quelques points si aucun bug de régression n'a été détecté la semaine dernière. Si des bogues de régression ont été détectés, le programmeur commence par 0.

De plus, dans "gamification" il y a "jeu". Et l'aspect fondamental d'un jeu est que vous jouez / participez volontairement. Dans le cadre du travail, elle peut être imposée par la direction comme c'est le cas ici, mais normalement personne ne devrait y être contraint.

Pour conclure, cette chose MVP n'est pas nécessairement une mauvaise idée, mais l'approche pourrait être légèrement modifiée pour faire passer les affaires (résoudre les bugs importants) en premier, et mettre l'accent sur le travail d'équipe plutôt que sur les individus.

Une sorte de reconnaissance de groupe des efforts d'un membre de l'équipe peut être un facteur de motivation précieux, mais dans ce cas, il semble qu'il soit mal appliqué. Vous déclarez que le MVP est choisi par vote, mais il y a beaucoup de mentions de nombres de bugs corrigés par sprint. Il semble que votre temps ait une définition amusante de MVP - je suppose que la personne qui mérite le titre de "la plus précieuse" est la personne qui a ajouté le plus de valeur au logiciel dans ce sprint. Si un membre de l'équipe sélectionne des bogues qui peuvent être corrigés rapidement, les traverse le plus rapidement possible et provoque des bogues de régression et d'autres problèmes dans leur sillage, alors ils n'ajoutent pas de valeur, ils créent plus de travail pour quiconque a de les suivre pour identifier et résoudre ces problèmes.

Ma suggestion serait d'essayer d'entamer une discussion appropriée la prochaine fois que votre équipe aura l'un de ces votes. Ne vous contentez pas d'en faire un vote à main levée; parlez-en d'abord. Si quelqu'un semble gagner des votes sur la base du nombre de "correctifs" qu'ils ont faits, indiquez (avec tact) où ces correctifs ont provoqué des régressions, et suggérez que peut-être la personne qui a corrigé ces régressions soit nommée pour nettoyer d'autres personnes désordre. Si quelqu'un a passé tout le sprint à asservir un problème désagréable, signalez-le à l'équipe, soulignant le fait que bien que le nombre de correctifs de cette personne soit un, ils ont à eux seuls résolu un problème majeur avec votre logiciel - un problème qui était si méchant que personne d'autre ne voulait y toucher.

Choisir des correctifs faciles et les faire de manière précipitée ou au hasard n'est pas utile, donc les développeurs qui le font ne devraient probablement pas être considérés comme des candidats MVP. Lors de la sélection du nouveau MVP, oubliez tout sur l'équipe et les personnes qui s'y trouvent, et regardez le logiciel. Choisissez le changement le plus important dans ce logiciel depuis la dernière fois. Je veux dire célibataire ici; "pas autant de petits bugs" n'est pas un changement majeur. Un bug particulièrement flagrant a-t-il été corrigé? Une excellente nouvelle fonctionnalité a-t-elle été ajoutée? Une fois que vous avez identifié ce qu'est ce grand changement, demandez qui en est responsable. L'une de ces personnes est probablement votre véritable MVP. Si "pas autant de minuscules bogues" est la seule différence, alors et seulementalors le nombre de bogues est une mesure valide de MVP - et même dans ce cas, je regarderais le rapport des bogues corrigés aux bogues de régression causés. Chaque bug que quelqu'un cause en déduit au moins 1 de son décompte. En fait, je dirais plus de 1, car une mauvaise correction entraînera un bogue inconnu que vous devrez ensuite trouver, ce qui est pire qu'un bogue connu qui a déjà été trouvé. Un bogue connu nécessite des efforts de développement de la part du développeur; un bogue inconnu demande des efforts de contrôle qualité pour trouver, et des efforts de développement pour résoudre, et il y a alors le risque que le contrôle qualité le manque.

En théorie, si les développeurs réalisent que le chemin vers le prix est de résoudre moins de problèmes plus gros, ils viseront les plus difficiles, les plus complexes, les défauts de blocage. Cela les obligera parfois à se regrouper, soit parce qu'il n'y a pas assez de problèmes charnus pour contourner, soit parce que le problème est assez délicat pour nécessiter plus de paires d'yeux . Peut-être suggère que dans des cas comme celui-ci, le prix pourrait être partagé s'il n'est pas immédiatement clair lequel parmi un ensemble de personnes a fait plus de travail pour corriger un bogue - et rappelez-vous, travail fait! = Lignes de code écrites. Les développeurs le sauront probablement, mais vous avez dit que la direction est impliquée, et la direction ne comprend pas toujours ce point.

Et bon, si tout le reste échoue, oubliez le programme MVP. Parlez à vos collègues développeurs en dehors de la mêlée et montrez l'impact négatif que les récompenses MVP ont sur le logiciel. Voyez si vous pouvez les amener à l'ignorer ou à ne pas en faire un gros problème. Laissez le trophée dans un tiroir, dépensez le prix en argent sur une série de boissons pour l'équipe après le travail, utilisez le déjeuner gratuit pour obtenir quelque chose que vous pouvez partager, comme un tas de petits gâteaux. Agile est un système d'équipe; mettre en évidence les performances individuelles risque de confronter l'équipe. Unis, vous vous tenez, divisé, vous expédiez des logiciels remplis de bogues, après la date limite, en dépassant le budget.

Il s'agit d'un exemple classique de la façon dont une pratique spécifique (reconnaissance publique en tant que MVP) peut avoir un impact significatif mais indirect sur le comportement de votre équipe. Cela va au-delà des incitations, des motivations et des récompenses et touche en fait des idées en psychologie environnementale / comportementale et en architecture de décision. Truc cool.

La question est - comment pouvez-vous concevoir un processus de sorte que votre équipe semble simplement faire toutes les bonnes choses naturellement, sans avoir à mettre en place des politiques rigides ou à forcer les gens à faire quelque chose?

J'ai écrit sur l'utilisation des opportunités (dans la tradition de la conception des choses de tous les jours de Donald Norman ) pour les processus en tant que mécanisme de conception d'un processus qui fonctionne pour votre équipe. L'idée de base est que les pratiques d'un processus influencent directement le comportement d'une personne. En tant que tel, des problèmes surviennent lorsque les opportunités de votre processus ne sont pas entièrement alignées sur les valeurs de votre équipe.

J'ai organisé plusieurs ateliers sur ce sujet et ce problème particulier revient de temps en temps à titre d'exemple en groupe. L'application de la théorie des opportunités au cas que vous avez partagé dans votre question pourrait ressembler à ceci .....

Supposez que votre équipe valorise la cohérence, la prévisibilité et le code de haute qualité.

Vous avez une liste de comportements négatifs que vous avez observés et ils semblent tous provenir de l'utilisation de mesures de défauts pour choisir un MVP d'équipe. Par exemple, les coéquipiers semblent naturellement vouloir choisir et corriger les bogues au hasard, ce qui a un impact négatif sur vos trois valeurs. (Je suppose qu'il y a eu un problème avant aussi, et c'est ce qui a conduit à l'idée MVP).

Plutôt que d'avoir un seul MVP basé sur des mesures de défauts, nous essaierons de changer le comportement de l'équipe en effectuant des changements petits mais significatifs.

• Permettez à quiconque de donner un «coup de cœur» à toute personne (et à tous, pas à une seule) qui adhère manifestement aux valeurs de votre équipe. Cela favorisera la prévisibilité en démocratisant le système de valeurs de l'équipe à travers des exemples. (Nous le faisons en fait dans notre équipe ..)
• Démarrez la programmation par paire (ou affectez des "amis de bogues") pour toutes les corrections de bogues. Cela favorisera la qualité en décourageant les décisions de programmation hâtives ou à moitié réduites et encouragera la cohérence, car les copains tempèrent les comportements irréguliers. (Cette idée est couramment suggérée lors des ateliers, semble intuitive ..)

Et ce ne sont que quelques exemples pour démontrer l'approche et vous aider à démarrer ...

Ce qui est génial avec cette approche, c'est que vous concevez activement vos changements de processus et que vous avez des raisons justifiables pour les changements de processus que vous apportez. Tout comme dans la conception d'objets ou d'interface utilisateur, vous pouvez même mesurer les résultats pour comprendre si les choses fonctionnent ou non.

L'un des ajustements les plus faciles à faire pour s'assurer que quelque chose comme un programme MVP fonctionne est de récompenser les membres de l'équipe pour être le plus précieux pour le succès de l'équipe, et non pour être le travailleur le plus acharné.

Nous l'avons fait avec succès en reconnaissant les personnes qui ne travaillaient même pas sur les bogues ou les fonctionnalités, mais qui ont fait quelque chose de génial qui a fait mieux réussir tout le monde dans l'équipe. Par exemple, nous avons eu un développeur qui a assumé la tâche de mentorat d'un groupe de nouveaux membres de l'équipe afin qu'ils puissent apprendre l'architecture et comment nous travaillions. Notre vitesse a augmenté parce que nous avions ces nouvelles recrues capables de fournir des résultats rapidement et efficacement, même si individuellement la vitesse d'un développeur a baissé parce qu'il passait plus de temps à aider le reste de l'équipe.

Récompensez le travail d'équipe, et l'équipe remarquera que c'est l'ÉQUIPE qui compte, pas son succès personnel.