Scrum transforme-t-il les développeurs actifs en développeurs passifs?
Je suis un développeur web travaillant dans une équipe de trois développeurs et un designer. Cela fait maintenant environ cinq mois que nous avons implémenté la méthodologie de développement logiciel Agile Scrum. Mais j'ai un sentiment étrange que je voulais juste partager sur ce site.
Un facteur important dans la vie humaine est le processus de prise de décision. Cependant, il y a une grande différence dans les décisions que vous prenez. Certaines décisions ne sont que le résultat d'une force interne ou externe, tandis que d'autres décisions sont entièrement basées sur votre libre arbitre, et certaines décisions sont simplement quelque chose entre les deux. Plus vous avez de liberté dans la prise de décisions, plus votre travail devient autonome. Cela semble être une règle. Parce que nous avons tendance à façonner nos vies nous-mêmes.
Il y a une grande différence entre vous décider quoi faire , ou se faire dire quoi faire .
Avant la mêlée, j'avais envie d'avoir plus de liberté pour prendre les décisions liées au développement, à l'analyse, à la priorisation de la mise en œuvre, etc. J'avais plus l'impression que je décidais ce que je fais .
Cependant, en raison de la méthodologie Scrum, de nombreuses décisions viennent maintenant simplement du propriétaire du produit. Il priorise PBI , il analyse comment le logiciel devrait fonctionner, même parfois comment l'interface utilisateur et les fonctionnalités devraient être implémentées. Je sais que cela fait partie de la méthodologie Scrum, et je sais aussi que cela peut entraîner de meilleures ventes de produits à l'avenir. Cependant, j'ai maintenant l'impression que on me dit toujours de faire quelque chose, au lieu de décider de faire quelque chose . Ce syndrome m'a rendu plus passif envers le travail.
- J'ai tendance à chercher moins pour trouver une meilleure solution, approche ou technique
- Je ne me réveille pas le matin en m'attendant à un travail agréable. J'ai plutôt envie d'être obligé de travailler pour vivre
- J'ai plus envie de travailler sur mes propres projets de loisirs après le travail
- Je ne pousserai plus l'équipe pour atteindre les niveaux technologiques supérieurs
- Je passe plus de temps maintenant au dîner ou au goûter et j'ai moins d'enthousiasme pour retourner au travail
- Je veux maintenant plus pour que le travail se termine plus tôt, afin que je puisse rentrer à la maison
Le gros problème est que je vois et diagnostique également ce comportement chez mes collègues. Est-ce le résultat de la mêlée? Scrum fait-il vraiment sentir à l'équipe de développement qu'elle n'a aucun rôle à jouer dans la formation du logiciel global, rendant ainsi le passif du projet? Comment puis-je surmonter ce sentiment?
Cependant, j'ai maintenant l'impression qu'on me dit toujours de faire quelque chose, au lieu de décider de faire quelque chose.
C'est un indicateur sérieux que quelque chose a disparu des rails. Un projet agile ne devrait pas ressembler à ça. Cette rhétorique sur les "gens au-dessus du processus" devrait inclure "nous ne forçons pas nos gens à faire des choses qui sont nulles". Voici quelques idées:
Faites-vous "mêlée mais"? Autrement dit, en partie mêlée, en partie autre chose. (Par exemple: "Nous faisons de la mêlée, mais toutes nos histoires doivent provenir de notre PMO, pas d'un propriétaire de produit.") Beaucoup de merde folle s'appelle Scrum de nos jours.
N'êtes-vous pas personnellement impliqué dans le processus où vous devriez être? J'ai connu un certain nombre de personnes bouleversées par le contenu des histoires, et il s'avère qu'elles ne s'impliquent qu'une fois que l'histoire est dans l'arriéré du sprint. Discutez avec le propriétaire du produit au début du développement de l'histoire et obtenez vos commentaires. (En tant que PO, il a le dernier mot, mais cela ne signifie pas qu'il doit le faire seul.)
Dans Scrum, l'équipe est censée être propriétaire du processus, et il est prévu que le processus change au fil du temps pour répondre aux besoins de l'équipe. Faites part de vos préoccupations lors de la rétrospective. Si vous pouvez proposer un processus que Tweak peut suggérer, cela a tendance à faciliter la vente pour certaines équipes.
Votre problème n'est pas Scrum (et comme Jarrod Roberson l'a mentionné dans les commentaires, ce n'est pas Scrum ce que vous décrivez) - c'est la microgestion du Product Owner et votre ( et Team) manque d'assertivité .
"Cependant, en raison de la méthodologie Scrum, maintenant de nombreuses décisions viennent simplement du propriétaire du produit. Il priorise les PBI, il analyse comment les logiciels devraient fonctionner, même parfois comment l'interface utilisateur et les fonctionnalités devraient être implémentées. Je sais que cela fait partie de Scrum méthodologie. "
Vous vous trompez. Juste à partir d'un bref aperçu de page wikipedia pour Scrum on peut voir que: "l'équipe, un groupe interfonctionnel qui fait l'analyse, la conception, la mise en œuvre, les tests, etc." Voir? Le Product Owner vous dit quoi à faire, mais c'est à l'équipe de décider comment de le faire.
Vous êtes la personne responsable de l'implémentation, vous devez donc décider comment l'application va être implémentée. Écoutez l'opinion du Product Owner, mais la décision finale dépend de vous (ou de l'équipe).
BTW micromanagement does transformez les développeurs actifs en développeurs passifs.
Ce que vous décrivez n'est PAS SCRUM
Votre propriétaire de produit dépasse ses limites s'il vous dit comment faire votre travail techniquement, ce n'est pas du tout le but de SCRUM.
SCRUM consiste à libérer les développeurs pour qu'ils se concentrent sur les problèmes de développement et responsabilisation eux se chargent de déterminer combien de temps les choses prennent et comment les faire.
SCRUM concerne la collaboration, c'est à cela que servent les réunions de planification de Sprint, pour promouvoir la collaboration entre toutes les parties prenantes; propriétaire du produit, développeurs et tests.
Oui, le propriétaire du produit doit prioriser les fonctionnalités, ce qui doit être livré en premier selon les besoins des clients, mais les développeurs doivent faire l'ingénierie et la conception, pas le propriétaire du produit.
Je ne suis pas d'accord que les développeurs devraient concevoir des interfaces graphiques et des workflows à moins qu'ils ne soient spécifiquement chargés et formés pour travailler avec les clients et hacher les fonctionnalités directement avec les clients. Le programmeur a construit des GUI dans le vide répondant rarement aux besoins des clients.
SCRUM consiste à mettre un processus léger qui peut être prévisible et reproductible sur le manifeste agile.
Cela me rend triste d'entendre des histoires selon lesquelles de très bonnes choses sont perverties comme ça.
Il semble que vos aventures dans Agile aient été corrompues par Scrum. Je trouve que, de toutes les méthodologies agiles, Scrum est la moins agile. Ses plus comme des cascades miniatures et une gestion de projet supplémentaire. Cela, bien sûr, en fait le plus apprécié par la direction qui estime qu'ils reprennent le contrôle de ces développeurs embêtants, mais bien sûr, vous voyez la réalité de la situation.
Agile ne consiste pas à suivre un chemin prescrit, il est conçu pour vous rendre plus productif et motivé. Les gens ne traitent pas dit le manifeste (paraphrasé), et c'est perdu dans le système que vous utilisez.
Alors changez-le. Apportez-le à la direction et dites que c'est une étape rétrograde, que votre productivité est inférieure à ce qu'elle était et que vous n'êtes pas satisfait de la façon dont cela fonctionne. Montrez le Manifeste Agile (et son jumeau maléfique ) et démontrez que vous avez non seulement tiré les leçons de cette expérience mais que vous souhaitez en faire évoluer les bons éléments dans un meilleur système (celui qui vous ressemble, qui semble bien fonctionner pour vous).
Je suppose qu'avant Scrum, tout le monde a fait ce que je voulais: yippee ki-yay mf'er. Vos utilisateurs sont vos bienfaiteurs et ils conduisent l'histoire et paient les factures. Le propriétaire du produit s'assure que l'histoire se termine. Quelque part, votre groupe est arrivé à la conclusion que le Product Owner devrait vous dire comment programmer.
Vous voulez écrire du code ou créer de petites applications soignées qui vous semblent cool? "Je veux faire la fonctionnalité A d'abord et non B, afin que je puisse conserver ma liberté de choix." Trouvez un bienfaiteur différent et non une nouvelle méthodologie de développement.
Vous êtes pris dans le titre du propriétaire du projet ou quelque chose. Si vous avez une raison valable d'être en désaccord avec l'histoire, dites quelque chose, faites votre argumentation. Vous ne gagnerez peut-être pas toujours. Il leur appartient de retourner auprès des utilisateurs et de leur faire savoir qu'il existe un problème valide avec leur demande. Avouons-le, si l'histoire vous demande de supprimer une base de données au hasard tout au long de la journée, sans sauvegarde, sans perte de données ni temps d'arrêt, vous avez un problème et le devoir de redresser l'histoire.
Je pense que vous êtes simplement habitués à avoir plus de propriété - et tout le monde, je pense, préfère cela, sa nature humaine.
Malheureusement, je pense que beaucoup de logiciels sont inférieurs à ce qu'ils pourraient être, car souvent les parties sont écrites pour le développeur et non pour le client. Votre nouvelle approche devrait réduire cela, mais au détriment de votre sentiment d'appartenance.
Je ne sais pas comment vous suggérer de rendre les choses meilleures ou plus amusantes, mais c'est une excellente question et un très bon aperçu.
Recevez-vous des user stories sous la forme "En tant que --rôle--, je veux --objectif/désir-- pour que --bénéfique--"? Il semble que votre propriétaire de produit veuille faire le travail de conception, et il/elle n'est peut-être pas la meilleure personne pour le faire. L'utilisation du modèle de la user story peut aider à garantir que le propriétaire du produit s'en tient à l'intérêt commercial et que le développement logiciel est effectué par les développeurs de logiciels.
Dans Scrum, il y a beaucoup d'espace pour que les développeurs contribuent et donnent leurs conseils sur les nouvelles fonctionnalités, l'interface utilisateur, la convivialité ... La collaboration et la conversation entre les hommes d'affaires et les développeurs sont nécessaires dans Scrum et cela le permet. Cependant à la fin, le propriétaire du produit aura toujours le dernier mot, car il est le responsable de la maximisation de la valeur commerciale des incréments logiciels produits sprint après sprint (en d'autres termes, le retour sur investissement).
Du Manifeste Agile:
Notre priorité absolue est de satisfaire le client par la livraison précoce et continue de logiciels précieux.
Le propriétaire du produit vous indiquant comment l'interface utilisateur et les fonctionnalités doivent être implémentées n'est cependant pas acceptable. Dans ce cas vous devriez avoir le dernier mot puisque vous êtes responsable de la qualité interne du logiciel que vous produisez.
Peut-être que vous travaillez dans une entreprise créée par des développeurs où les programmeurs étaient libres d'implémenter les fonctionnalités qu'ils voulaient. Cependant, la plupart des méthodologies Agile font une séparation claire entre les gens du domaine commercial et l'équipe responsable de la production de logiciels (développeurs, testeurs ...) qui est la division de travail la plus courante dans la plupart des endroits. Si mes hypothèses sont bonnes, je peux comprendre le sentiment que vous avez que vous n'êtes plus en mesure "d'avoir une influence sur la situation dans son ensemble", mais avec la croissance de l'entreprise, je suppose que cela aurait été le cas de toute façon, Scrum ou non.
En ce qui concerne l'analyse, la conception et les autres activités de méta-développement que vous mentionnez (qui ne sont pas censées être effectuées par le Product Owner), les équipes Agiles sont censées être interfonctionnelles et sans silo. Personne n'est censé posséder toutes les connaissances autour d'une activité de développement spécifique, donc il y a peut-être une opportunité pour vous de vous y diversifier plutôt que de "coder des codes".
Au contraire, j'ai trouvé qu'avoir un propriétaire de produit prendre des décisions sur la fonctionnalité me permet de consacrer plus de temps à la production de code de qualité. De plus, s'il y a des préoccupations valables, je peux toujours remettre en question les décisions des propriétaires de produits, ce qui mène généralement à des discussions fructueuses.
Nous pratiquons Scrum ici. Nous avons une réunion de planification bimensuelle où nous nous nourrissons des priorités commerciales actuelles et des succès et échecs du sprint précédent, et nous décidons, en équipe, ce que nous voulons aborder pour le prochain sprint.
L'une des façons de procéder consiste à trier l'arriéré d'un conseil en fonction de la complexité verticalement et de la priorité métier horizontalement. Après cela, le Product Owner a eu son avis, donc c'est à l'équipe de choisir ce que nous voulons faire. De toute évidence, choisir une tâche hautement prioritaire et peu prioritaire est mal vu, mais nous décidons cela en équipe. Cela rend les sessions de planification plus longues, mais cela en vaut la peine et fait partie intégrante du processus Agile.
Et nous avons parfois de la micro-gestion, mais c'est un problème différent.
Le vrai problème que vous décrivez est une pathologie courante lorsque les équipes adoptent une méthodologie: elles éteignent leur cerveau. Cela est aussi vrai avec un système agile new-school qu'avec des systèmes poids lourds old-school.
Q: La méthodologie prescrit x, mais x ne fonctionne pas bien. Que devrions nous faire?
R: Affinez votre implémentation de x. Peut-être arrêter complètement de le faire. La méthodologie n'est pas votre patron!
Dans ce cas précis, il semble que le propriétaire du produit en fasse trop. Êtes-vous à l'aise de lui en parler? Seriez-vous à l'aise d'avoir cette conversation si vous ne faisiez pas de mêlée? Si le propriétaire du produit n'est pas sensible aux commentaires constructifs, ce n'est pas un problème de méthodologie, c'est un problème avec le propriétaire du produit.
Je ne suis pas vraiment en phase avec toute la mêlée, car il y a eu plus de cascade depuis un moment.
Mais pour être honnête, cela ressemble plus à un problème de personnel de gestion qu'à un problème de technique de gestion de projet. Comme c'est plus basé sur les gens que sur la technique.
J'ai eu la même expérience avec Scrum et j'aime l'appeler "la tyrannie de l'histoire".
D'après mon expérience, les développeurs du côté création/design/frontend semblent en souffrir davantage que les personnes impliquées dans le travail backend.
La seule issue que j'ai trouvée jusqu'à présent était soit d'abandonner Scrum - souvent impossible et/ou approprié car après tout, il a ses avantages - ou d'introduire quelque chose comme le temps de 20% de Google pour donner aux développeurs un débouché créatif en dehors du "vous" re libre de choisir comment implémenter le Page de connexion ", car en réalité vous n'êtes pas comme votre implémentation est limitée par le code existant et l'architecture du système - c'est à moins que l'on considère la liberté de choisir entre 'un pour et un moment boucle 'une liberté.
Le rôle des leaders dans une équipe auto-organisée serait un article de blog sur quelque chose qui semble manquer dans votre article. Où l'équipe décide-t-elle du travail à effectuer dans un sprint? Où l'équipe est-elle propriétaire du processus et du travail? Avez-vous quelqu'un qui connaît suffisamment Scrum pour que vous fassiez Scrum et pas une version perverse de celui-ci?
Selon mon expérience, Scrum est de vous regarder profondément ce que vous faites. C'est juste assis sur votre épaule et regarder ce que vous faites. Même si elle a son propre avantage, je déteste la méthodologie Scrum. Il attend le décompte, pas la qualité. La qualité est compromise avec la méthodologie Scrum.
Il y a une grande différence entre vous décider quoi faire, ou se faire dire quoi faire.
D'après mon expérience, il y a juste un long chemin de se faire dire quoi faire à décider quoi faire.
À la fin de cette façon, il s'avère généralement que nous avons été informés non pas parce que eux aiment le pouvoir et non pas parce que n'ont rien de mieux à faire. Bien au contraire, à la fin de cette voie - quand ils gagnent suffisamment de confiance en notre équipe - ils semblent soulagés et nous passent avec autant de contrôle que nous pouvons gérer (et si leur confiance est vraiment ferme, ils essaient même de passer plus que ça)
Oh et d'après mon expérience, cela n'a pratiquement rien à voir avec Scrum/agile. Arrivé avec mêlée, itératif, cascade, peu importe. Semble que la question de confiance est ag processus indépendant
Dans notre équipe, le propriétaire du produit nous dit quoi faire et nous décidons comment nous le faisons. Il est vraiment important d'avoir cette séparation ou vous vous retrouverez dans la situation que vous avez décrite.