Comment puis-je empêcher Scrum de transformer les grands développeurs dans des développeurs moyens?
J'ai trouvé ceci est également arrivé dans mon équipe bien qu'il ait peut-être exagéré la situation un peu.
Scrum est un moyen de prendre un développeur inférieur à la moyenne ou médiocre et de les transformer en un développeur moyen. Il est également génial de prendre de grands développeurs et de les transformer en développeurs moyens.
Tout le monde veut juste prendre quelque chose de facile du conseil d'administration que vous pouvez vous faire faire dans une journée afin que vous ayez quelque chose à signaler dans le quotidien quotidien de demain. Ce n'est que tout le monde essayant de choisir le fruit de suspension bas. Il n'y a aucune incitation à être intelligente et à prendre le temps de réfléchir à des solutions, si rien ne se déplace sur ce que tu fais même? Vous laissez l'équipe en bas! La vélocité est tombée!
Je pense que si vous avez des problèmes difficiles à résoudre, vous les résolvez en leur donnant aux personnes intelligentes, alors les laissant seul. Vous ne les harcelez pas constamment tous les jours exigeant de savoir ce qu'ils ont fait hier et ce qu'ils envisagent de faire aujourd'hui. Avec des mises à jour quotidiennes où est l'incitation aux personnes intelligentes de travailler sur les problèmes difficiles? Ils ont maintenant la même incitation que le développeur junior; Trouvez les billets les plus faciles à passer à travers le tableau.
Parfois, je voudrais juste être seul et penser à une solution pendant quelques jours. Si je le fais, je n'aurais rien à dire à la mêlée. Donc, au lieu de cela, je choisirai l'histoire de l'utilisateur où la couleur sur une extrémité frontale était la mauvaise nuance de vert ou une faute d'orthographe! Voyez, j'ai assommé 2 histoires en une journée, avant le déjeuner! Allez-y!
...
Je ne suis pas entièrement d'accord avec ses mots. E.G., je suis d'accord avec un commentaire dit: Ce n'est pas qu'ils ne leur font pas confiance, c'est qu'ils ne font pas les choses sans surveillance constante.
Lorsqu'un grand développeur devient un développeur moyen, il y a toujours de multiples raisons, mais je trouve que la mêlée quotidienne pourrait être l'une des raisons. Alors, comment puis-je empêcher cet effet secondaire des réunions de Scrum?
Je me suis aussi réalisé que c'est plus facile à dire qu'à faire, mais j'aime voir comment les autres voient ce problème.
----- mettre à jour -----
Après avoir lu toutes les réponses que j'ai jusqu'à présent, je me rends compte que je dois ajouter des informations pour rendre ma question plus pertinente.
Mais avant que je passe dans cela, je veux répéter les mots Martin Maat a donné sa réponse: "Le simple fait que tant de personnes ressentent la nécessité de dire quelque chose à ce sujet est un indicateur de Les causes de Scrum de frustration. "
Je suis entièrement d'accord! Quand j'ai posé pour la première fois la question que je m'attendais déjà à ce que certaines réponses soient " Oh, tu ne fais pas Scrum Droite !"
Certaines corrections que je veux faire de ma question initiale sont,
- J'ai utilisé le mot " Great Developer" Et je devrais probablement dire un Développeur décent/bon Parce que j'ai vu cette réponse distraite. En outre, tout au long de ma carrière, je ne travaille jamais avec de grands développeurs, je ne devrais donc pas l'utiliser en premier lieu. Ce que je voulais dire, c'est que je vois de temps en temps que Scrum a fait un bon développeur moins bien performer.
- Certaines réponses se concentrent sur la phrase "C'est qu'ils ne font pas les choses sans surveillance constante" et croyaient que c'était une question de microgestion. Mais ce n'était pas mon cas, par exemple Je ne suis pas micromanage. Le problème que j'ai vécu (encore une fois de temps à autre) est bon/tech-aver les développeurs ne sont pas nécessairement avantageux. Parfois, ils se concentreront trop pour perfectionner trop leur solution technique sans se rendre compte que nous avons un produit à livrer à la fin. D'autres fois, il s'agit d'une fonctionnalité transversale qui a besoin de coordination, en particulier chaque équipe peut avoir sa propre priorité/planification. C'est pourquoi ils ont besoin de supervision. Mais je suppose que je ne devrais pas simplement copier le mot " supervision constante" Du post d'origine et ne doit pas utiliser constante En premier lieu. Mais encore une fois, si quelqu'un fait valoir que "les grands développeurs" et "une grande équipe" ne font pas cela, je n'ai aucun contre-argument alors.
- Une réponse a déclaré: "Le Scrum quotidien est devenu en quelque sorte transformé en compétition qui a terminé le plus de billets". I jamais expérimenté cela. Une équipe mature ne fait pas cela (une mature n'est pas nécessairement une grande équipe). Quelqu'un a-t-il vécu cela?
- Pour ceux qui m'ont suggéré de lire le manifeste agile, mon contre-projet est-ce ceci ne longue critique de livres J'ai écrit en 2008 (il y a 12 ans) pour le livre "L'Enterprise and Scrum (Developer Pratiques)" par Scrum Cofounder Ken Schwaber. J'ai répertorié mon commentaire ici, de ne pas montrer, mais de montrer (1) je crois que j'ai fait Scrum assez longtemps pour voir sa force et sa faiblesse. (2) Je sais ce qu'est l'agile.
Considérez qui introduit Scrum et tous les autres problèmes que ces personnes causent.
Je n'ai rencontré qu'un seul ingénieur qui préconisait Scrum. Tous les autres fois, il a été imposé par des personnes atteintes de MBA sur les développeurs de la même manière que grain est pompé dans des oies .
Dans ce cas de l'ingénieur, il s'est essentiellement comporté comme un responsable, avec des croyances qui alignées parfaitement avec Scrum tels que:
"Embaucher des développeurs moyens. Les bons viennent de partir."
"Ne vous inquiétez pas avec les testeurs. Cela fait simplement des développeurs Lazier."
"Vous (développeur moyen) n'a pas besoin de savoir quoi que ce soit sur l'architecture. Faites simplement vos billets."
Scrum provoque des ingénieurs Medicore pour les mêmes raisons que les gestionnaires intermédiaires tapotent votre épaule toutes les heures, tenant des réunions sans fin, ne pas être dérangé de faire de la planification ni de la préparation, puis de crier à tout le monde décrite la productivité.
Finalement, le travail cesse d'être agréable car vous avez été transformé en drone soviétique par les locuteurs quotidiens, le Toujours View Scrum Board, et la non-perturbation totale de l'initiative individuelle de votre carrière (comme c'est une "équipe").
Avez-vous déjà vu un directeur médian démotiver quelqu'un en ignorant leur travail? Scrum construit cela dans le cadre. Les gestionnaires de projets Scrum (propriétaire du produit et maître Scrum) sont souvent hilareux technologiquement illettrés.
Jamais vu un projet voler le Rails par une planification médiocre? Scrum abolit la planification avec seulement deux fois-cadres de semaine. Avez-vous déjà vu un ingénieur arrêtez de prendre soin après leur gestion et a été ignoré? Scrum jette les ingénieurs hors de la décision de la décision entièrement.
Avez-vous déjà vu un ingénieur prennent une fierté attentive dans sa petite section du projet? Dans Scrum, vous n'avez pas de section. Vous êtes censé être un widget remplaçable. Les soins provenaient de la propriété, mais si je ne peux rien posséder, je peux aussi bien générer de la merde et passer mon effort de propriété sur un projet open source.
Pour les ingénieurs, Scrum tourne dans un salaire. Scrum laisse également beaucoup de façons d'ingénieurs de faire beaucoup plus facilement que le chèque de paie, comme les estimations de gonflage, faisons aveuglément tout ce que la spécification indique et générant de plus d'erreurs qui ont besoin de la fixation.
Entre les ingénieurs battant dans la misère et leur donner un moyen de s'échapper au moins la partie de travail acharnée, c'est la manière dont Scrum fait des ingénieurs sous performance.
Un autre problème avec Scrum (et les méthodologies agiles en général) est que cela rend l'entreprise paresseuse des besoins en matière d'écriture. La meilleure entreprise que j'ai jamais travaillée pour des personnes licenciées publiquement, qui ont écrit de mauvaises exigences en tant que budgets cassés. Cela les a fait très attention à la spécification de ce qu'ils veulent. Scrum utilise des billets, qui sont souvent une phrase d'une mot.
En fait, j'aime bien la cascade parce que c'est mon bouclier contre des bêtises mal pensées. Je n'ai pas besoin de m'impliquer dans des arguments avec des extravertis. Je ne suis pas blâmé pour de mauvais résultats. Je peux même refuser d'avoir des conversations significatives. Je peux simplement indiquer la page et la ligne chaque fois qu'ils veulent quelque chose.
La citation citée reflète un malentendu fondamental de la façon dont Scrum travaille dans une équipe saine. L'ensemble du point de Scrum est "Comment pouvons-nous fonctionner le mieux en tant qu'équipe?" C'est définitivement pas "Comment pouvons-nous rivaliser les uns avec les autres pour regarder le meilleur?" En concurrence les uns avec les autres pour regarder le mieux ne fonctionne pas dans le cadre d'une équipe - c'est exactement le contraire de cela.
Si les principaux plats à emporter du STANDUP sont que vous devez déplacer quelque chose à travers le tableau tous les jours, alors quelque chose s'est sérieusement faux. L'essentiel est de savoir si vous êtes sur la bonne voie pour terminer le travail que vous vous êtes engagé dans le sprint à temps et si vous avez des obstacles à le faire. Je m'attendrais à ce que les gens signalent une sorte de progrès en pleine muvetation tous les jours, mais si le seul objectif est de "beaucoup de choses pour que notre vitesse soit bonne", c'est une approche erronée. Mettez-vous différemment, que vous souciez-vous réellement de regarder bon ou réellement être bon?
Le fait que cela se passe suggère également que la planification du sprint ne va pas bien. Si les gens se trébuchent sur l'autre pour tenter d'obtenir le fruit peu suspendu et d'éviter les tâches compliquées, alors c'est un problème grave. Pourquoi le propriétaire du produit ne donne-t-il pas la priorité à vos histoires correctement? Sûrement, vos fruits peu suspendus ne peuvent pas toutes être des priorités plus élevées que les tâches compliquées.
D'avoir cette affaire, pourquoi même écrire des histoires "fruits peu suspendues" en premier lieu? Les histoires doivent refléter certains produits livrables qui ajoute de la valeur au client final, non Juste des choses qui fournissent des fruits à suspension faibles pour vos développeurs à fermer chaque jour. Encore une fois, ce qui est plus important - d'avoir l'air bien ou en fait être bon?
Enfin, pourquoi les gens ne prennent-ils pas de travail en fonction de leurs capacités? Un ingénieur plus expérimenté/qualifié devrait prendre plus de travail et travailler une plus grande complexité, qu'un ingénieur plus junior. S'ils ne sont pas, le maître Scrum devrait repousser cela.
Les données indiquent le contraire. Scrum fait des équipes plus productives et plus heureuses (j'ai recueilli des données à ce sujet pour toutes les équipes que j'ai caressées pour la dernière décennie).
Le bonheur fait partie du guide de Scrum
"Le Master Scrum encourage l'équipe de Scrum à améliorer, dans le cadre de processus Scrum Process, son processus de développement et ses pratiques pour le rendre plus efficace et plus agréable pour le prochain sprint."
La plupart des équipes que j'ai coachées ont dit qu'ils faisaient déjà Scrum ou qu'ils connaissaient Scrum. Toutes les équipes autorisées par la direction de faire en réalité Scrum contentent après quelques mois que ce qu'ils faisaient et ce qu'ils avaient pensé que Scrum était tout ce qui n'était pas scrum. Donc, la réponse courte est comme quelques-unes ont déjà déclaré: "Faites-le bien". Le fait droit ne consiste pas à avoir les bonnes réunions. Il s'agit de comprendre travail d'équipe Il s'agit de bâtir - Trust et d'autonomiser l'équipe (et beaucoup d'autres mais ceux qui sont fondamentaux)
Dans Agile, comme je l'ai pratiqué, une réunion quotidienne est le moment de signaler si vous avez besoin d'aide, surtout si vous êtes bloqué sur votre tâche. Il est tout à fait d'accord d'avoir une réunion quotidienne où personne n'a rien d'intéressant à dire (puis à reconnaître cela et à arrêter la réunion ...). Il n'est pas le moment de signaler ce que vous avez terminé la journée après. Franchement, personne ne devrait se soucier de ce que vous avez fait, cette information est déjà présente sur le conseil d'administration et elle n'est pertinente que pour une personne qui souhaite prendre une nouvelle tâche. Ce n'est certainement pas une réunion où la hiérarchie est présente, même s'il est courant de poser un point d'action impliquant un gestionnaire comme résultat de la discussion.
Des questions sur la vélocité doivent être discutées après une longue période, dans une réunion rétrospective.
Le point de la manière formelle que les tâches sont traitées consiste à allouer des efforts dans lesquels des efforts sont nécessaires. Vous devez demande qu'un propriétaire de produit donne clairement la priorité au travail et modifier la priorité aussi rarement que possible. Quelque chose qui est à mi-chemin n'a pas de valeur, il est donc tout à fait normal d'avoir de grandes tâches aussi. Si vous décomposez une grande tâche dans des bits de taille plus petite (ou même pire, de taille jour), vous courez le risque bien pire de faire quelque chose à mi-chemin, surtout si la façon dont vous brisez une tâche consiste à le casser dans étapes d'un processus de développement traditionnel (généralement, développement et test).
Si Scrum pousse tous les développeurs pour éviter des tâches complexes, cela signifie probablement que le propriétaire du produit n'alloue pas ces tâches la priorité qu'ils méritent. L'objectif du sprint est d'atteindre des points de fonctionnalité bien définis et de fixer des bugs, de ne pas "faire de choses pour des points". En pratique, cela signifie que vous avez un arriéré de tâches et au début d'un sprint, le propriétaire du produit et l'équipe négocient un sous-ensemble de tâches de cet arriéré qui sera fait à la fin du sprint. Travailler sur des tâches qui ne figurent pas dans ce sous-ensemble alors qu'il y ait des tâches restantes dans sa dysfonction. Sélection constamment la sélection de plus de tâches que ce que l'équipe peut gérer dans un sprint est également un dysfonctionnement.