Quelqu'un a-t-il déjà essayé d'assimiler Scrum à une équipe où la plupart des développeurs sont simplement médiocre? Je veux dire que les développeurs qui ne sont pas la plus sévéris technologique, ont des compétences de mauvaise gestion du temps, mais surtout - manquent le sentiment de responsabilité personnelle et d'engagement.
Pensez-vous que peut travailler? Ou essayiez-vous une méthodologie différente?
22 Réponses :
Le Agile Manifesto Disclaimer indique votre question. Dans le premier point:
'individus et interactions sur les processus et les outils'
Je pense que si les personnes ont des problèmes, la méthodologie est inutile.
Je dirais que votre méthodologie est futile si elle ne peut pas gérer les personnes qui ont des problèmes. Ils font tous.
Je ne l'ai pas essayé personnellement, mais j'ai vu un projet de descendre B / C de cette situation problématique.
Le développement agile prend la discipline dans les développeurs. Beaucoup de gens pensent qu'Agile signifie, pas de documentation, pas de planification, aucune spécification ... Vous n'avez donc pas besoin de discipline.
mais réussir avec les méthodes agiles nécessite un engagement et une responsabilité.
Si vous devez travailler dans un tel environnement, il est plus probable que vous réussissiez à utiliser une méthodologie plus guidée. et n'oubliez pas: uniquement parce que vous n'utilisez pas une approche puriste d'Agility ("Fais exactement la façon dont ils nous ont dit dans ce parcours CSM") ne signifie pas que tu ne prends pas Pour ramener à la maison les avantages des itérations temporelles, de la programmation par paire, etc. Vous pouvez faire de nombreux bons pratiques
De nombreux critiques agiles (et experts) disent que Agile fonctionne uniquement avec des développeurs brillants. J'ai tendance à être d'accord. Si vous me faites confiance, Scrum ne fonctionnerait pas avec des développeurs médiocres. : -)
Pourquoi est-ce vrai? Eh bien, parce qu'Agile suppose que tellement de choses émerge automatiquement le code des développeurs. L'architecture, par exemple, est rarement prévue pour; Il est censé se présenter au fur et à mesure que le code est ajouté et refactored sur et plus. Les développeurs brillants peuvent y arriver, mais les médiocres ne peuvent pas.
Je dirais que si par le développeur Mediocre, nous comprenons que quelqu'un n'est pas engagé, je suis d'accord. Mais le non génie peut ajouter de la valeur s'ils sont attachés au projet et à l'équipe. La connaissance est quelque chose que nous accumulons avec le temps. Engagement non.
D'une part, planifiez en détail pour la courte période de temps, une sprint fonctionnerait bien. D'autre part, vous aurez des problèmes pour que ces développeurs puissent faire un véritable engagement à faire du travail prévu pendant le sprint.
Je pense que cela peut être meilleur que pas le faire, mais je vous souhaite la meilleure des chances de toute façon. :)
J'ai mis en œuvre Scrum avec une telle équipe.
Il a fallu quelques itérations pour qu'ils soient à bord, mais ils ont découvert que Scrum leur a fait de meilleurs développeurs. Ils ont apprécié de pouvoir influencer le processus. Lors de la rétrospective de chaque itération, nous avons examiné les facteurs et les défis de réussite, et en tant qu'équipe, nous avons travaillé pour éliminer les obstacles aux défis créés.
Au dîner annuel de reconnaissance des employés de cette année, mon équipe m'a désigné pour un prix de réalisation: pas pour mes réalisations, mais pour les réalisations, l'équipe a pu atteindre à la suite de la déménagement à Scrum.
Trop d'équipes sont battues et démotivées parce qu'elles n'ont pas leur mot à dire dans le processus. L'absence de responsabilité personnelle et d'engagement peut être un artefact du processus de développement actuel et Scrum peut aider votre équipe à surmonter cela.
+1 bravo. La plupart des développeurs seniors deviendront frustrés s'ils continuent de travailler dans une entreprise qui n'autorise pas la prise de décision de haut niveau.
Grande prise. En regardant la situation comme une opportunité d'enseignement plutôt qu'une pièce remplie de développeurs médiocres travaille mieux pour tout le monde à long terme.
Commentaires intéressants mais ... Qu'en est-il du logiciel produit?
Cela ne ressemble pas à un avantage de Scrum autant qu'un avantage du leadership de la qualité.
"... Qu'en est-il du logiciel produit?" À l'heure, de haute qualité et nos clients étaient très heureux. Ils ont particulièrement apprécié d'aider à définir des priorités pour l'arriéré de fonctionnalités afin que nous puissions livrer leurs composants de haute priorité plus tôt.
Cela aide à ce que les développeurs médiocres sont meilleurs que les développeurs pauvres. Je définis les développeurs pauvres à être ceux avec moins qu'aucun intérêt pour toujours essayer quelque chose de nouveau, voire d'apprendre les outils qu'ils sont déjà prétendument responsables de la connaissance. Certaines personnes refusent activement d'apprendre.
Je pense que la plupart des choses majeures avec Agile sont le fait que vous devriez travailler dans de petites équipes. Quelque chose de plus d'environ 6 personnes et votre équipe est trop grande. Personnellement, je pense que 4 est un bon nombre. Le bonus est que, avec des équipes beaucoup plus petites, les gens sont beaucoup plus heureux de s'approprier de ce qu'ils font et font face aux conséquences de leurs erreurs (à condition que le reste de l'équipe soit heureux d'intervenir et d'aider avec n'importe quel calendrier de planification, c'est-à-dire pas assis et blâmer la personne qui a commis une erreur pour tous les problèmes). Rapidement, les gens apprennent à bien planifier parce qu'ils planifient de telles tâches. Après quelques mois, ils sauront vraiment combien de temps une tâche donnée est susceptible de prendre et le système sera alors inestimable.
S'ils souffrent toujours après quelques mois, cela ne fonctionnera jamais et, TBH, il est peu probable que tout ce qui les amène au travail. IMHO, à ce stade, sa peine d'admettre qu'ils sont inutiles. Certains peuvent être en désaccord mais si vous donnez des chances que les gens et qu'ils ne les prennent pas, vous ne pouvez pas passer tout votre temps à essayer de les faire utiles, déplacez-les à quelque chose qu'ils peuvent faire ou de vous en débarrasser. Je ne vois pas beaucoup d'autres choix ...
Vous pouvez utiliser Scrum à votre avantage avec votre situation:
+1 - et j'ajouterais quelques choses. Veillez à casser des histoires en petits morceaux. ceci: vous avez besoin d'un bon propriétaire de produit
J'ai eu le "privilège" de travailler avec des équipes moins que optimales à l'aide d'une méthodologie de type Scrum, et l'a trouvé plus réussie qu'une méthodologie de cascade traditionnelle aurait été avec les mêmes personnes, pour des raisons, notamment: < / p>
Le travail est effectué (et les progrès sont mesurés) dans des morceaux plus petits, de sorte que votre équipe gâche ou manque une échéance, vous savez plus tôt et peut s'adapter plus tôt. Il est également plus facile de tenir les personnes responsables des problèmes de travail d'une journée d'une journée d'articles de travail par mois.
Scrum a une attente plus élevée de transparence au sein de l'équipe, de sorte que si les choses se passent mal (comme ils le feront certainement avec une équipe sous-équipée et / ou sous-motivée), vous découvrirez plus facilement les problèmes. Dans la méthode de la cascade traditionnelle, il est plus acceptable pour un développeur de "aller sombre" pendant des semaines à la fin ... et avec une mauvaise équipe, c'est la pire chose possible qui puisse arriver.
Les développeurs qui ont de bonnes compétences de base mais sont bâclés et / ou non motivés peuvent particulièrement bénéficier de l'approche incrémentielle élevée de Scrum.
Les preuux quotidiens signifient que chaque membre de l'équipe doit au moins apparaître au travail tous les jours et proposer quelque chose pour dire qu'ils ont fait. Cela peut augmenter la motivation pour certains Devs qui peuvent être paresseux ou distraits, mais qui ne veulent pas non plus être gênés devant leurs pairs. Et les stands debout fournissent au moins une barre de transparence et de responsabilité minimum sans que les membres de l'équipe grincheuse, pour des rapports d'état écrit.
Scrum a également une attente plus élevée de transparence dehors l'équipe (propriétaires d'entreprise, etc.), il y a donc plus d'occasion pour plus de personnes de voir à quel point votre équipe de Dev est une meilleure équipe, et donc Vous aurez plus probablement le soutien de votre entreprise pour améliorer votre équipe.
Si vous avez un mélange de Devs bons et moins bons sur votre équipe, Scrum (avec des attentes plus élevées de transparence et des attentes plus faibles de la propriété individuelle sans retour d'information) facilite la possibilité de garder l'équipe sur la bonne voie.
Notez que je suis d'accord avec les autres réponses, que la situation idéale est d'obtenir une meilleure équipe. Mais il y a certainement des cas où vous n'avez pas d'autre choix, par ex. Sauvegarder un projet a disparu avec seulement quelques mois avant l'expédition, où le remplacement de l'équipe n'est pas réalisable et que vous devez faire le meilleur avec les personnes que vous avez.
La marque du bon travail d'équipe, quelle que soit la méthodologie, est la capacité d'obtenir d'excellents résultats avec des personnes ordinaires. Il s'agit beaucoup de la motivation, de la communication et de la coopération. Si vous n'avez pas ces choses, cela n'a pas vraiment d'importance à quel point les individus sont brillants.
Si vous incluez des idées XP dans votre cadre de Scrum, vous pourrez peut-être apporter des développeurs «plus faibles» le long d'un peu. Le meilleur exemple serait probablement de mettre en œuvre une programmation de paires. J'étais sceptique à ce sujet au début, mais je suis maintenant complètement vendu sur l'idée. Bien qu'il tombe quelque peu en dehors de la méthodologie Scrum Scrum, vous devez choisir ce qui vous convient de toutes les méthodologies agiles, et ne pas être contraint à un seul locataire.
est-ce que cette équipe de développeurs non engagée / manquant de motivation ou est que le sentiment général au sein de l'organisation, c'est-à-dire que leur attitude est un symptôme de problèmes institutionnels plus importants?
Dans ce cas, Scrum pourrait être
q.e.d.
Je suis d'accord et l'effet de Dunning-Kruger ( APA.ORG/JOURNALS/FEATURS/PSP7761121. PDF ) prouve que la personne la plus non qualifiée est non qualifiée, plus ils surestiment leurs propres compétences. Sans méthodes agiles pour concentrer l'attention sur des objectifs réalisables, les personnes incompétentes vont trop loin.
Votre logique est défectueuse. Vous ne pouvez pas montrer que les "nombreuses équipes" au point 2 correspondent à "la majorité des développeurs" au point 1. Peut-être que les "nombreuses équipes" (combien de "nombreuses équipes" sont-elles quand même?) Au point 2 correspondent, précisément, aux équipes fait de personnes qui sont bien au-dessus de la moyenne. Quelles sont vos données pour sauvegarder votre logique? Donc, votre conclusion au point 3 ne suit pas. :-(
Je ne m'attendais pas à ce que cela soit tenu dans les mêmes normes que le dernier théorème de Fermat. :-) Mon sentiment réel sur le développement agile est que c'est simplement la meilleure approche pour faire face aux réalités du développement logiciel. C'est plus un mécanisme d'adaptation qu'une méthodologie.
Je suis désolé de dire que l'argument de 3 points de Jamie Ide est défectueux. Il suppose que les nombreuses équipes qui utilisent avec succès des méthodes agiles (point 2) sont composées des développeurs médiocres décrits au point 1. Cependant, nous n'avons aucune preuve de cela. Ces équipes pourraient aussi bien être composées principalement de développeurs supérieurs à la moyenne. Cela offrirait une explication alternative sur la raison pour laquelle ils réussissent.
Peut-être que la loi des moyennes semblerait indiquer son hypothèse.
Mon argument est la langue dans la joue, mais le fait qu'Agile est bien adopté et en grande partie réussie est un argument prima facie qu'Agile convient bien aux développeurs médiocres. Même si nous acceptons votre argument, les équipes travaillent sur plusieurs projets et technologies et les particuliers seront brillants sur un projet et médiocre (ou pire) sur l'autre.
C'est peut-être assez juste. :-) Ce n'est peut-être pas. Je pense que cette recherche impartiale et rigoureuse est nécessaire.
Cela dépend de votre définition de Ken Schwaber a déclaré dans son Google Talk que les développeurs de la merde qui utilisent des outils sans espoir et que les autres peuvent certainement suivre les règles de Scrum et produire des augmentations de logiciels de la Crap sur le temps et le budget.
... donc je suppose que les développeurs médiocres avec la norme industrielle (c'est-à-dire des outils moyens) et un niveau moyen de coopération d'équipe sont Si c'est ce que vous êtes après, bien - mais voici les problèmes:
travail .
Qu'est-ce que j'aime chez Scrum, c'est ceci: C'est l'équipe qui exerce une pression sur les membres de l'équipe Erring. Pas le maître de Scrum, pas l'équipe n'engage (rien de tel dans Scrum), et pas même la direction.
Cela facilite l'engagement et la responsabilité.
Je l'ai vu avec des codeurs moyens et ça marche. La bonne chose à propos de Scrum est que, dans chaque itération (Sprint), vous pouvez utiliser un certain temps pour améliorer leurs compétences (livres, vidéos ...), mettre de l'ancien code dans des tests - peut-être qu'un objectif pourrait être de mettre 1% de l'ancien code En test dans chaque sprint - pour nettoyer le désordre, faites une programmation de paire, de sorte qu'elles apprennent les unes des autres ...
Les développeurs médiocres peuvent certainement suivre Scrum et l'appliquer avec succès. Mais ce n'est pas une fin, la fin est de produire des logiciels. Vont-ils produire de bons logiciels? Je ne le pense pas, ou du moins pas avec une vélocité très élevée. Trouver une solution innovante, codage, persistance, orm, conception de logiciels et architecture, test unitaire, refactoring, avis de code, test d'acceptation, construction, automatisation, etc. exigent certaines compétences. Pour cela, vous avez besoin de personnes talentueuses, ou au moins deux développeurs alpha.
Le plus important est leur volonté d'apprentissage. S'ils sont prêts à apprendre et à progresser, alors Scrum peut les guider. S'ils sont satisfaits de choses comme décrit, alors ...
En outre, avec Scrum L'équipe saura plus tôt comment elles vont, ce qui pourrait les défier.
Ajouter un développeur chevronné pour diriger par l'exemple, si possible.
La réponse courte: Oui, Scrum travaille avec des équipes indépendamment de la capacité innée des membres de l'équipe.
La longue réponse: une équipe de développement de logiciels aura un taux de mise en œuvre de la fonctionnalité naturelle. La plupart des équipes ne fonctionnent pas à leur meilleur tarif car elles se battent des obstacles cachés. Scrum expose ces obstacles cachés afin qu'ils puissent être adressés et supprimés. Une fois que les problèmes liés au processus ont disparu, l'équipe peut alors se concentrer sur l'amélioration des compétences comme étape suivante pour augmenter la vitesse.
Ainsi, peut-être une équipe de développeurs médiocres collaboratifs ne sera peut-être pas aussi rapide qu'une équipe de superstars collaboratifs, mais une équipe collaborative de développeurs médiocres qui travaillent à une efficacité maximale sera plus productive qu'une équipe dysfonctionnelle composée de Prima Donna. superstars à chacune de la leur part. En fait, une équipe collaborative de développeurs en grande partie moyenne avec une superstar capable de mentoriser des coéquipiers et d'aider à résoudre leurs problèmes sera une équipe très productive.
Bien sûr, cela fonctionne avec une telle équipe. Cela fonctionne comme vous et vous comprenez plus vite qu'ils doivent développer certaines compétences. Avec la gestion de projet traditionnelle, vous le découvririez à la fin du projet.
Comme @Justin Subvention suggère, la visibilité et la transparence plus élevées de Scrum peuvent aider les Devs médiocres à se motiver à des performances plus élevées.
mettre toute l'équipe dans un espace pour permettre beaucoup de communication.
Utilisez la programmation de paires - Il répand de connaissance et aide à empêcher les gens de rester coincés et de frapper la tête contre un mur. En outre, Les gens passent naturellement moins de temps sur les non-travailleurs si Il y a une personne assise à côté d'eux .
garder des sprints courts (essayez de commencer par 1 semaine) à, comme @Richardtallent a dit, gardez l'équipe de vous perdre sur les pistes de lapin.
Commencez par une réunion de localisation traditionnelle de 3 questions: Qu'est-ce que je ferais hier, ce que je ferai aujourd'hui, et ce qui est dans mon chemin. Associer des membres de l'équipe qui ont des problèmes avec ceux qui peuvent aider. Prenez toute autre discussion hors ligne.
Prenez soin de casser des histoires en petits morceaux. Les réunions de fond quotidien perdent de l'efficacité si des rapports sonnent comme "Je continue de travailler sur le GiantDatabasecontrolermanManagerFactory" au lieu de "Hier, j'ai reçu l'aperçu de l'impression effectué pour le rapport principal. Aujourd'hui, je vais commencer à la partie d'impression - il devrait prendre 2 jours ou moins. " Briser des histoires est une compétence. Techniques de fractionnement de l'histoire de recherche.
Vous aurez besoin d'un bien propriétaire du produit, qui peut donner la priorité à des histoires bien pour garantir autant que possible que le travail effectué fournit une valeur commerciale.
Vous aurez besoin d'un bon Scrum Master, une personne qui peut reconnaître les obstacles à des progrès de l'équipe et à suggérer des étapes pour les supprimer. Votre organisation devra donner suffisamment à l'autorité de Scrum Master pour agir.
Les rétrospectives du sprint sont très importantes. Demandez à l'équipe: qu'est-ce qui a fonctionné? Qu'est-ce qui ne fonctionnait pas si bien? De quoi avons-nous besoin de plus? De quoi avons-nous besoin de moins? Que devons-nous ajouter à notre processus?
Préparez-vous que certains membres de l'équipe soient résistants. Si vous ne pouvez pas les convaincre de l'essayer pour quelques sprints, ils peuvent partir ou vous devrez peut-être leur donner une poussée à la porte.
Aussi précieux que je pense que le design piloté (TDD) et l'intégration continue (CI) sont non triviaux pour apprendre, surtout si une équipe n'a pas faim de le faire. Si vous pouvez obtenir quelques sprints assez réussies, peut-être dans l'une des rétrospectives que vous pouvez résoudre le problème des bogues en faisant monter TDD et CI. Si vous pouvez intéresser l'équipe, voir si vous pouvez apporter un entraîneur et / ou envoyer quelques membres de l'équipe à une classe. Tout le monde ne survit pas la transition à Scrum / Agile.
Certaines choses importantes peuvent être trop pour qu'une équipe médiocre commence avec tout de suite.
oui. Scrum est en fait très bon pour faire de la productivité pour les équipes qui ne sont pas autonomes, engagées et passionnées par leur travail. D'autre part, il n'est pas rare d'entendre des ingénieurs très innovants et dévoués que Scrum les ralentissait effectivement.
Vos problèmes sont au-delà de la méthodologie
On dirait qu'il est temps de trouver un autre emploi. Ont-ils des valeurs positives?
"Manque le sens de la responsabilité personnelle et de l'engagement" - Maintenant, il y a votre problème! Yikes! Les compétences peuvent être engagées, mais l'équipe doit être intéressée à apprendre. Pourtant, il y a encore de l'espoir - il peut être qu'ils ne sont pas frustrés par le processus habituel, de sorte que l'introduction d'une structure de processus différente peut aider.