Comment pouvons-nous rendre agiles agréables pour les développeurs qui aiment posséder de façon indépendante de gros morceaux du début à la fin

Nous sommes à peu près à mi-chemin de notre transition de cascade à agile en utilisant Scrum; nous sommes passés de grandes équipes de silos technologie / discipline à des équipes interfonctionnelles plus petites.

Comme prévu, le passage à l'agilité ne convient pas à tout le monde. Une poignée de développeurs ont du mal à s’adapter à l’agile. Je veux vraiment les garder engagés et stimulés et, au final, être heureux de venir travailler chaque jour. Ce sont des personnes intelligentes, heureuses et motivées que je respecte tant sur le plan personnel que professionnel.

Le problème de base est le suivant: certains développeurs sont principalement motivés par la joie de prendre un morceau de travail difficile, de réfléchir à un design, de réfléchir aux problèmes potentiels, puis de résoudre le problème pièce par pièce, avec seulement une interaction minimale avec les autres, sur une longue période. période de temps. Ils achèvent généralement leurs travaux à un niveau de qualité élevé et dans les délais impartis; leur travail est maintenable et correspond à l'architecture globale. Passant à une équipe multidisciplinaire qui valorise l'interaction et la responsabilité partagée du travail, ainsi que la fourniture de fonctionnalités de travail dans des intervalles plus rapprochés, les équipes évoluent de manière à ce que toute l'équipe parvienne à résoudre ce problème difficile. Beaucoup de gens trouvent qu'il s'agit d'un changement positif. Quelqu'un qui aime prendre un problème et le posséder indépendamment du début à la fin perd l'opportunité de travailler comme ça.

Ce n'est pas un problème avec les gens étant ouverts au changement. Certes, nous avons vu quelques personnes qui n’apprécient pas le changement, mais dans les cas qui me préoccupent, les individus sont performants, réellement ouverts au changement, ils font un effort, ils voient comment le reste de l’équipe est changer et ils veulent s’intégrer. Ce n’est pas le cas de quelqu'un de difficile, d’obstructionniste ou de désir de garder le travail le plus juteux. Ils ne trouvent simplement pas la joie de travailler comme avant.

Je suis sûr que nous ne pouvons pas être le seul endroit à ne pas avoir été dépassé à ce sujet. Comment les autres ont-ils abordé cela? Si vous êtes un développeur motivé par le fait de posséder personnellement une grande quantité de travail de bout en bout et que vous vous êtes adapté à une méthode de travail différente, qu'est-ce que cela vous a apporté?

Je dirai qu'il y a très peu de magasins de logiciels qui ont la chance d'avoir la rare distinction où Agile n'a vraiment aucun sens en tant que méthodologie. Si toute votre équipe est composée de développeurs de logiciels vraiment exceptionnels possédant une compréhension approfondie des aspects de l'entreprise et de la longévité avec l'entreprise et les uns des autres, et si vos exigences commerciales et les besoins de vos clients sont généralement toujours similaires et rarement soumis à des changements en cours de route. Libérez-vous, vous avez la chance de travailler dans un environnement aussi rare où Agile peut probablement réellement faire mal.

Il est conçu pour être l'approche la plus efficace parmi des exigences commerciales et des besoins chaotiques et en constante évolution, des ressources de projet en constante évolution, ainsi que des délais serrés ou changeants. Un tel environnement est catastrophique pour le développement typique des chutes d’eau, car il est vulnérable aux changements d’équipe en cours de projet, vulnérable aux exigences changeantes et extrêmement vulnérable aux changements de date.

Je suis sensible aux membres de votre équipe qui ne trouvent plus de joie dans leur travail. Ce sont peut-être des personnes exceptionnellement talentueuses qui s’immiscent dans leur travail, mais au final, un certain nombre de facteurs échappant à leur contrôle peuvent tout de même tuer le projet. La meilleure façon d'aborder le développement des fonctionnalités est de perdre l'attitude et l'expression individuelles et de penser en termes d'approche d'équipe.

Si vous trouvez que cela ne fonctionne pas pour eux, vous pouvez leur trouver un usage spécial. S'ils sont exceptionnellement talentueux et expérimentés, voyez s'ils seraient intéressés par un rôle architectural, en présentant des conceptions et des approches de haut niveau, en expérimentant de nouvelles technologies et en faisant évoluer les meilleures pratiques. Demandez à ces personnes de contrôler et d'examiner la documentation de conception.

Si cela ne leur convient pas encore, demandez-leur de travailler séparément sur des réaménagements techniques extrêmement complexes sur une branche distincte, des prototypes extrêmement complexes et des preuves de concepts, ou tout autre travail de pionnier qui doit parfois être effectué mais qui ne cadre pas bien dans le futur. portée d'un projet ou d'une version unique.

Ils ne trouvent simplement pas la joie de travailler comme avant.

Correct.

C'est un gros symptôme que vous le faites mal.

Agile ne devrait pas imposer un mauvais nouvel ordre aux gens.

Agile devrait permettre à l'équipe de s'auto-organiser de manière à la rendre plus efficace.

L'auto-organisation signifie que la direction n'impose pas de règles étranges. Il n'impose pas de mauvais horaires ni d'interaction inutile.

Certains développeurs sont principalement motivés par la joie de prendre un morceau de travail difficile, de réfléchir à une conception, de réfléchir aux problèmes potentiels, puis de résoudre le problème pièce par pièce, avec seulement une interaction minimale avec les autres, sur une période prolongée.

Pourquoi ne peuvent-ils pas continuer à faire cela?

Pourquoi les changer?

Veuillez lire le Manifeste Agile à quelques reprises.

Le Manifeste Agile dit

Individus et interactions sur les processus et les outils

Cela ne dit pas forcer les gens à travailler de manière inconfortable et improductive.

Si vous forcez les gens à trop d’interactions de faible valeur, vous êtes allé trop loin.

Logiciel de travail sur une documentation complète.

Est-ce qu'ils font ça? Puis laissez-les tranquille.

Collaboration client sur négociation de contrat.

Tu le fais déjà? Alors ne change pas.

Répondre au changement au sujet d'un plan.

Où ces gens sont-ils déjà capables de réagir au changement? Si oui, ils étaient déjà agiles. Ils n'avaient pas besoin de changer.

mon entreprise a essayé (et essaie encore après des années d’essais) de faire la même transition et jusqu’à présent personnellement, je n’ai pas eu beaucoup de succès avec cela. Au cours de cette transition, j'ai beaucoup lu sur le développement agile et sur différents aspects / préoccupations / techniques. Un point sur lequel je suis tout à fait d'accord est que le développement purement agile convient mieux à une équipe entière composée de personnes de haut niveau et de grande qualité. (ou du moins toutes les personnes du même niveau).

La dernière version, je faisais partie d’une équipe "agile" qui comptait un trop grand nombre de développeurs possédant des niveaux de compétence identiques et nous avons essayé de faire participer tout le monde au même projet. Ce fut un désastre. Nous avons plus parlé / discuté que travaillé, et à la fin, l’équipe a produit un travail moyen (lisez Peopleware ou Mythical Man Month sur la prise de moyenne). Oubliez les modèles de conception, oubliez le couplage faible ou le code de rupture en petites classes et méthodes. Oubliez d'essayer de faire quelque chose d'intéressant car a) cela ne pourrait pas être expliqué et compris par tous les membres de l'équipe (du moins pas à temps) et b) puisque nous étions agiles, quelle que soit la raison pour laquelle j'ai commencé cette itération, quelqu'un d'autre sans aucune compréhension continuerait à la prochaine itération. Personnellement,

Je détestais absolument le fait que je ne pouvais rien faire avec les modèles C ++, ni écrire des bibliothèques de frameworks de niveau inférieur (bien qu'un peu complexes) qui auraient beaucoup simplifié notre vie. Comment peut-on faire quelque chose comme ça alors que personne dans l'équipe n'est même capable de lire les fichiers d'en-tête STL alors que nous sommes tous supposés travailler sur une chose à la fois. Tout le projet a fini par être forcé, fonction par caractéristique, car c’est ce que l’agile semble souligner.

En même temps, il y a peu (très peu) de personnes dans mon entreprise avec lesquelles j'aimerais absolument travailler côte à côte et partager l'ensemble de mon code.

Mais maintenant, vous avez le choix. A) Prenez tous vos bons développeurs expérimentés qui produisent du code de haute qualité et mettez-les dans leur propre équipe et mettez le reste dans une équipe séparée. Ou B) essayer d’équilibrer les équipes et de mettre les bonnes avec les moins bonnes. En (A), le problème est que l’une de vos équipes sera sous-performante et ne récupérera pas les bonnes aptitudes / habitudes des bons. En (B), vos bons gars (dans un environnement purement agile) se sentiront frustrés et commenceront à travailler sur leur CV. Le mien est à jour.

Alors qu'est-ce que tu vas faire?

Je ne sais pas si c'est la bonne solution. Demandez-moi à nouveau dans environ un an ou deux. Mais que se passe-t-il si au lieu d'être "purement agiles", vous formez une équipe, mais identifiez clairement la ou les personnes qui ont le plus d'influence (conception, critiques de code, etc.) et assurez-vous que cette personne comprend cela et est récompensée pour ses responsabilités supplémentaires. Au fur et à mesure que les membres de l'équipe commencent à travailler ensemble, identifiez ceux qui adoptent de bonnes habitudes / pratiques et élevez-les au même niveau que vos bons collaborateurs. Espérons que lorsque les utilisateurs passeront une ou deux versions à travailler ensemble, ils apprendront ce que pense l'autre personne et comment ils travaillent, de sorte qu'ils seront plus compatibles pour travailler dans le même code en même temps. Mais jusqu'à ce que cela se produise, si vous vous contentez de lancer des personnes dans un projet, ce ne sera que frustration (encore une fois, à mon avis).

Certaines de mes pensées sont basées sur la façon dont j'ai commencé professionnellement dans le logiciel. Lorsque j'étais une coopérative, j'ai travaillé avec un gars qui était mon mentor. Il m'a tout appris, de l'éthique du codage au bon design en passant par la lecture de milliers de lignes de code que vous n'avez pas écrites. Au début, nous étions loin du même niveau et il serait risible de nous placer dans une équipe agile et de nous dire que nous pouvons travailler sur le code de chacun. Mais avec le temps (quelques années), nous avons commencé à penser de la même manière. Je pouvais comprendre son code d'un simple coup d'œil et il m'avait répété à plusieurs reprises qu'il n'avait absolument aucun problème (et qu'il en avait été étonné) de naviguer dans mon code qu'il n'avait jamais vu auparavant. Cela a pris des années, pas quelque chose qui s'est passé pendant la nuit. Après avoir connu catastrophe après catastrophe dans un environnement agile au cours des dernières années,

Ce n'est pas vraiment une réponse, mais cela résume mon expérience / mes observations. Je veux voir ce que les autres diraient à ce sujet.

Qu'est-ce que l'agile?

Est-ce:

• un ensemble de règles que vous devez suivre pour réaliser ce que les responsables de la réglementation voulaient?

• une meilleure approche pour obtenir des résultats concrets en tenant compte de vos forces, de vos exigences et de vos limites?

Si vous pensez que Agile est le premier, et que vous suivez toujours chacune des règles Scrum et que vous vous inquiétez constamment de savoir si vous le faites correctement ou non, ce lien vous éclairera peut-être un peu.

Si vous pensez plus à la seconde, félicitations, vous obtenez Agile. Toute méthodologie Agile ne peut qu’être une suggestion de la manière dont on peut faire avancer les choses. Si un aspect de la méthode agile que vous avez choisie ne vous convient pas, vous devez alors cesser de l'utiliser, la modifier ou être autrement agile.à propos de ça. Ce qui est important, c’est que vous réalisiez quelque chose et que vous ne soyez pas freiné par des contraintes artificielles - et pas seulement par celles que nous connaissons et aimons depuis notre temps jadis, où le Premier ministre vous demandait des schémas complets et documentés que personne ne pourrait jamais imaginer. lire simplement parce que "c'est ce que le processus dit de faire", mais aussi des contraintes de ce que vous utilisez. Si une mêlée quotidienne ressemble à une contrainte, alors ne la cochez pas! Les avoir aveuglément parce que les règles le disent n'est pas plus agile que les anciennes méthodes.

Maintenant, si vous avez des gars qui font le travail en étant enfermés dans une pièce avec seulement un gallon de cola et une trappe pour une pizza, utilisez ce fait. Donnez-leur une partie du système essentiellement autonome et enfermez-les. Une fois qu'ils ont terminé, vous devriez les amener à intégrer ce travail (ou à le faire faire à quelqu'un d'autre s'ils le préfèrent) au reste du système.

Alistair Cockburn a décrit cela dans ses méthodes. Si vous avez des "praticiens de niveau 3", une méthode agile parfaitement valide est la suivante:

«Mettez 4 à 6 personnes dans une pièce avec des postes de travail et des tableaux blancs et donnez accès aux utilisateurs. Demandez-leur de fournir aux utilisateurs un logiciel en cours d'exécution et testé tous les mois ou tous les deux mois, sinon laissez-les tranquilles. "

Comme vous avez un mélange de personnes, vous devez trouver un moyen de les faire travailler ensemble de manière constructive. Cela signifie qu'une approche unique ne sera probablement pas très efficace. Vous devez donc diviser les tâches tout en veillant à ce que l'objectif commun soit souligné. C'est bien d'envoyer ces types au code, mais il faut leur faire comprendre que leur travail fera partie intégrante du reste du travail de l'équipe et que ne pas y parvenir est un échec de la production qu'ils produisent. . Une fois qu'ils ont compris cela (c.-à-d. Qu'ils ne peuvent pas faire ce qu'ils veulent et livrer quelque chose d'inutilisable), votre travail est terminé.

Disons que l'agile n'est pas pour tout le monde et l'agile n'est pas pour chaque projet. Dans le même temps, agile est un terme très large et Scrum n’est qu’une implémentation d’un processus agile - je peux dire en quelque sorte que cette implémentation est probablement la plus contraignante et qu’elle tente de mettre en place un processus standardisé comportant des étapes bien connues.

Un autre domaine à considérer est le but de l'agile. La manière dont les développeurs travaillent est-elle agile? Peut-être que certaines méthodologies vont effectivement dans cette direction. Mais l'agile lui-même couvre des zones en dehors du développement. Agile consiste davantage à diriger l'ensemble du processus, la manière dont une interaction fonctionne, la manière dont vous livrez le produit fonctionnel avec les fonctionnalités les plus importantes dans les temps, la façon dont vous contrôlez les ressources, comment vous voyez où vous vous trouvez dans le projet, etc.

Il existe des méthodologies qui n'essayent pas de changer votre processus de développement - Scrum n'est pas celui-là. Toutes les méthodologies agiles mettent l'accent sur l'amélioration continue. Vous détecterez une étape inefficace dans votre processus et vous essaierez de l'améliorer / de la changer - c'est la manière agile. Vérifiez une autre méthodologie agile populaire - Kanban.

Vous / votre entreprise avez décidé d’utiliser Scrum et cela peut conduire à ce que certaines personnes ne l’aimeront pas et partiront. Vous devez traiter chacun de vos développeurs séparément. Vous devriez en discuter avec chacun d’entre eux et essayer de trouver des centres d’intérêt qui leur permettraient de profiter à nouveau du travail.

Ils peuvent avoir un rôle de mentors, ils peuvent enseigner aux autres, leur montrer comment restructurer le code pour une meilleure architecture lors du travail itératif. Ils peuvent former ensemble un schéma d’architecture globale à utiliser dans tous les projets. Ils peuvent également travailler sur des preuves de concepts, participer à une demande d'informations lorsque les clients s'informent de la faisabilité des exigences. Ils peuvent travailler en binôme avec des développeurs moins qualifiés et s’acquitter de tâches complexes en commun, etc. Leur principale utilité devrait être d’utiliser leurs compétences et de permettre à d’autres d’en tirer des enseignements.

Scrum et agile à l’échelle mondiale retiennent effectivement les individus et hiérarchisent les équipes - les équipes livrent les applications, pas les individus. Cette idée est basée sur le fait que vous ne formerez jamais une équipe où tout le monde possède les mêmes compétences et la même expérience.

Si votre transition vers Scrum aboutit, ils devraient constater une amélioration du processus, une réduction des délais de livraison, une amélioration de la qualité et une plus grande satisfaction des clients. Ils peuvent toujours croire que les applications développées elles-mêmes sont bien pires qu’elles pourraient l’être, mais c’est l’essentiel - le client ne veut pas du meilleur code jamais écrit. Les clients veulent le code de travail minimal / le moins cher / le plus rapide qui réponde à leurs besoins. Si la force brute est suffisante pour cela, alors soit. C’est quelque chose qui peut poser des problèmes aux développeurs hautement qualifiés, mais ce n’est pas un échec de l’agile, c’est le lieu où les exigences commerciales et le perfectionnisme s’opposent.

Si vous résolvez certains des problèmes majeurs et que vous les transmettez à un excellent développeur, vous en bénéficierez. Tout le monde peut ensuite se mettre à niveau et apprendre quelque chose dans le processus. Juste ne construisez pas une application entière de cette façon.

Vous ne diluez pas le code au plus petit dénominateur commun. Vous faites le rattrapage inexpérimenté aux meilleurs développeurs.

Il y a eu beaucoup de discussions sur ce qui est ou non "agile" et beaucoup de sentiments personnels, d'expériences et de doutes concernant le processus agile partagé ici, mais je n'ai pas vraiment vu de réponse réelle à la question. La question initiale était de savoir comment garder vos meilleurs développeurs motivés quand ils voyaient leur code écrit au niveau purement artistique, et y investissaient leur sueur et leur sang, piratés par quelqu'un d'autre et "corrompus". Notez que, agile ou non, cela se produira à un moment donné, il est simplement plus visible maintenant, car ils travaillent toujours sur le code en même temps que d'autres, au lieu d'un transfert typique à prendre en charge, auquel cas ils ne voulaient tout simplement pas voir ces modifications apportées.

Ce que je verrais comme la clé ici est d’élargir la responsabilité de ces développeurs et de les aider à changer d’orientation. Cela signifie peut-être un nouveau titre, comme architecte logiciel, chef d’équipe ou ingénieur logiciel principal. Puis montrez-leur que c'est une opportunité d'avoir un impact plus important, pas seulement sur un projet à la fois, mais sur plusieurs projets. Le sentiment d'appartenance peut encore être présent, mais leur objectif ne devrait plus être de livrer un seul et même grand projet, mais d'aider à définir la barre pour TOUSprojets. Aidez-les à saisir leur fort désir de créer quelque chose de grand, mais concentrez-vous sur la construction des pratiques d'ingénierie logicielle de votre entreprise et des autres développeurs. Plutôt que de craindre que leurs collègues modifient leur code, cela peut être une chance pour eux de passer au niveau supérieur, d'encadrer leurs coéquipiers et de les amener à leur niveau.

Je vais essayer d’illustrer certains aspects qui n’ont pas été traités dans d’autres réponses et qui, à notre avis, sont importants.

Le problème de base est le suivant: certains développeurs sont principalement motivés par la joie de prendre un morceau de travail difficile, de réfléchir à un design, de réfléchir aux problèmes potentiels, puis de résoudre le problème pièce par pièce, avec seulement une interaction minimale avec les autres, sur une longue période. période de temps. Ils achèvent généralement leurs travaux à un niveau de qualité élevé et dans les délais impartis; leur travail est maintenable et correspond à l'architecture globale.

Ce type de développeurs peut avoir du mal à s’adapter à un environnement agile et leur attitude est souvent qualifiée de "réticence à changer", éventuellement liée à l’ego ou à l’ancienne.

Ce que l’on ignore souvent, c’est que pour résoudre des problèmes complexes, il faut gérer beaucoup d’informations, ce qui peut nécessiter beaucoup d’analyses, de réflexions, de tentatives, d’esquisser une solution, de la jeter à la poubelle, d’en essayer une autre. Un problème aussi complexe peut nécessiter de quelques heures à quelques semaines de travail ciblé jusqu'à ce que vous obteniez une solution finale.

Une approche est qu'un développeur prend la spécification du problème, se rend dans sa chambre et revient deux ou trois semaines plus tard avec une solution. À tout moment (lorsque cela est nécessaire), le développeur peut initier des interactions avec d'autres membres de l'équipe ou avec les parties prenantes (en posant des questions sur des problèmes spécifiques), mais la majeure partie du travail est effectuée par le développeur à qui est confiée la tâche.

Que se passe-t-il dans un scénario agile? L’équipe décompose le problème en petits morceaux (user stories) après une analyse rapide (nettoyage). L'espoir est que les user stories soient indépendantes les unes des autres, mais ce n'est souvent pas le cas: pour diviser un problème complexe en plusieurs morceaux vraiment indépendants, il vous faut une connaissance que vous n'obtenez normalement qu'après l'avoir travaillé pendant plusieurs jours. En d’autres termes, si vous êtes en mesure de scinder un problème complexe en petites parties indépendantes, cela signifie que vous l’avez déjà résolu en principe et qu’il ne vous reste plus qu’un travail de diligence. Pour un problème qui nécessite, par exemple, trois semaines de travail, ce sera probablement le cas lors de la deuxième semaine, et non après quelques heures de toilettage effectuées au tout début du sprint.

Ainsi, après la planification d’un sprint, l’équipe travaille sur différents morceaux d’un problème qui ont probablement des dépendances entre eux. Cela génère beaucoup de temps de communication en essayant d’intégrer différentes solutions qui peuvent être aussi bonnes mais qui sont différentes les unes des autres. Fondamentalement, le travail d’essai et d’erreur est réparti sur tous les membres de l’équipe impliqués, avec une surcharge de communication supplémentaire (augmentant de façon quadratique). Je pense que certains de ces problèmes sont très bien illustrés dans cet article de Paul Graham, en particulier le point 7.

Bien entendu, le partage du travail entre les membres de l’équipe réduit les risques liés au départ d’un membre de l’équipe. D'autre part, les connaissances sur le code peuvent être communiquées de différentes manières, par exemple en utilisant des révisions de code ou des présentations techniques aux collègues. À cet égard, je ne pense pas qu'il existe une solution miracle valable dans toutes les situations: la propriété partagée du code et la programmation par paires ne sont pas la seule option.

En outre, "la fourniture de la fonctionnalité de travail dans des intervalles plus courts" entraîne une interruption du flux de travail. Cela peut être correct si la fonctionnalité est "Ajouter un bouton d'annulation dans la page de connexion" qui peut être complétée à la fin d'un sprint, mais lorsque vous travaillez sur une tâche complexe, vous ne souhaitez pas de telles interruptions: c'est comme essayez de conduire une voiture 100 km aussi vite que vous le pouvez et arrêtez-vous toutes les 5 minutes pour vérifier votre distance. Cela ne fera que vous ralentir.

Bien sûr, avoir des points de contrôle fréquents est censé rendre un projet plus prévisible, mais dans certains cas, l'interruption peut être très frustrante: on peut à peine gagner de la vitesse qu'il est déjà temps d'arrêter et de présenter quelque chose.

Je ne pense donc pas que l'attitude décrite dans la question concerne uniquement l'ego ou la résistance au changement. Il se peut également que certains développeurs considèrent que l’approche de résolution de problèmes décrite ci-dessus soit plus efficace, car elle leur permet de mieux comprendre les problèmes qu’ils résolvent et le code qu’ils écrivent. Forcer ces développeurs à travailler de manière différente peut réduire leur productivité.

De plus, je ne pense pas que le fait de faire travailler certains membres de l'équipe de manière isolée sur des problèmes spécifiques et difficiles soit contraire aux valeurs agiles. Après tout, les équipes devraient s'auto-organiser et utiliser le processus qu'elles ont jugé le plus efficace au fil des ans.

Juste mes 2 cents.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

On dirait qu'ils sont "Lone Rangers". Dans le Scrum canonique, ces personnes ne peuvent tout simplement pas faire partie de l'équipe (elles manquent le bit "interaction").

S'ils ne sont pas des "Lone Rangers", il y a de l'espoir. Si vous utilisez Scrum correctement, ils doivent faire partie de la conception de la fonctionnalité sur laquelle ils vont travailler (pendant la planification du sprint). C'est à peu près le seul moment où ils ont besoin d'interagir avec les autres. Vous pouvez même "assigner" toutes les histoires liées à cette caractéristique.

Pendant le sprint, ils seront seulement "dérangés" par le journal Scrum ... jusqu'à ce que vous puissiez leur prouver (par des actions, pas par des mots) qu'il ne leur restera que 15 minutes, et uniquement pour garantir que tout fonctionne correctement. doucement. Restez proche des trois questions et la plupart des gens cesseront de se conformer.

Dans notre équipe, nous avons un groupe spécial juste pour améliorer les performances. Nous ne les voyons pas beaucoup, juste au début du sprint pour parler des changements à apporter, et à la fin de la rétrospective. Ils ont leur propre "chef de file" qui rend compte à l'équipe Scrum of Scrum. Je peux vous dire qu'ils s'amusent.

Si Joe (votre développeur Hero) est un peu flexible, alors je ne vois pas de problème:

Comme indiqué ci-dessus, laissez l'équipe s'auto-organiser: s'il est préférable de s'attaquer à certains problèmes en laissant Joe le mâcher lui-même, alors vous vous attendriez à ce qu'une équipe auto-organisatrice, ouverte d'esprit, parvienne à cette conclusion par elle-même.

Les seuls défis restant dans les quelques contraintes imposées par Scrum:

1. Fournir des fonctionnalités à intervalles réguliers: si vous laissez Joe régler un problème pendant des mois, sans rien afficher jusqu'à la fin, Joe n'est en effet pas agile: il prend le propriétaire du produit en otage et ne lui permet pas de modifier les spécifications. cette partie du produit. Avec cette pratique, il risque également d'être en retard et personne ne le remarque. (Mais selon votre description, ce n'est pas si probable). Remède: Est-ce trop demander à Joe, de s'asseoir avec le bon de commande, de diviser la user story et de s'accorder sur les produits livrables intermédiaires, de préférence (mais pas nécessairement) avec la valeur utilisateur?

2. Respecter les priorités définies par le propriétaire du produit: si des éléments de code appartiennent à des experts, vous risquez une situation dans laquelle l'évolution du produit est déterminée par la disponibilité de chaque expert, plutôt que par les priorités commerciales: le reste de l'équipe peut travailler sur des fonctionnalités moins importantes, alors que les 3 principales sont bloquées parce que "seul Joe peut le faire". C'est mauvais. À ce moment-là, l'équipe doit (temporairement) changer ses habitudes et répartir le travail de Joe entre plusieurs membres de l'équipe.

En bref: si Joe, le développeur héros, convient avec le bon de commande de la manière dont il affichera les progrès réalisés à chaque sprint, l'équipe peut alors lui assigner certaines histoires et le laisser tranquille. Mais si le bon de commande a trop de travail pour Joe et pas assez pour l'équipe (ou vice-versa), alors Joe et l'équipe doivent s'adapter, pas le bon de commande.

Les règles pour une équipe agile doivent être personnalisées pour s'adapter à l'équipe - ceci peut être une personnalisation vraiment personnelle; Par exemple, j'ai travaillé dans une équipe où la règle était la suivante:

Tout le code doit être écrit par un couple, sauf que David peut écrire du code seul.

David était un développeur / architecte senior, qui travaillait principalement sur des outils que d'autres utiliseraient dans leur propre code. Il possédait beaucoup le code qu'il avait écrit. Elle était maintenable et testée, et tous les membres de l’équipe savaient qu’il était probablement le meilleur codeur, et que l’équipe serait mieux servie en lui permettant de construire certaines pièces-cadres et de les présenter comme complètes à l’équipe.

Je n'ai pas de réponse pour les introvertis des variétés de jardins, mais pour les introvertis exceptionnels, l'équipe se fera un plaisir de suivre des règles différentes pour en tirer le bénéfice.