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 concepteur. 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.

Le processus de prise de décision est un facteur important dans la vie humaine. 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 sont entièrement basées sur votre libre arbitre, et certaines décisions sont simplement quelque chose entre les deux. Plus vous êtes libre de prendre des décisions, plus votre travail sera autonome. Cela semble être une règle. Parce que nous avons tendance à façonner nous-mêmes nos vies.

Il y a une grande différence entre décider quoi faire ou se faire dire quoi faire .

Avant Scrum, j'avais plus de liberté pour prendre des décisions liées au développement, à l'analyse, à la hiérarchisation des priorités de mise en œuvre, etc. J'avais plus l'impression de décider de ce que je fais .

Cependant, en raison de la méthodologie Scrum, de nombreuses décisions sont maintenant prises par le propriétaire du produit. Il priorise les PBI , il analyse comment le logiciel devrait fonctionner, même parfois comment implémenter l'interface utilisateur et les fonctionnalités. Je sais que cela fait partie de la méthodologie Scrum et je sais aussi que cela pourrait entraîner de meilleures ventes de produits à l'avenir. Cependant, j'ai maintenant l'impression qu'on me dit toujours de faire quelque chose, au lieu de décider de faire quelque chose . Ce syndrome m'a maintenant rendu plus passif envers le travail.

1. J'ai tendance à chercher moins pour trouver une meilleure solution, approche ou technique
2. Je ne me lève pas le matin en espérant avoir un travail agréable. Au contraire, je me sens comme obligé de travailler pour vivre
3. J'ai plus faim de travailler sur mes projets de passe-temps après le travail
4. Je ne pousserai plus l'équipe à atteindre les plus hauts niveaux technologiques
5. Je passe plus de temps maintenant à dîner ou à prendre le thé et j'ai moins d'enthousiasme pour retourner au travail
6. Je suis maintenant prêt à ce que le travail se termine plus tôt pour pouvoir rentrer chez moi

Le gros problème est que je vois et diagnostique ce comportement chez mes collègues aussi. Est-ce le résultat de la mêlée? Scrum donne-t-il vraiment à l'équipe de développement le sentiment de ne pas participer à la formation du logiciel dans son ensemble, rendant ainsi le projet passif? 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.

Ceci est un indicateur sérieux que quelque chose a dérapé. Un projet agile ne devrait pas se sentir comme ça. La rhétorique "sur le processus des personnes" devrait inclure "nous ne forçons pas notre peuple à faire des choses qui sont nulles". Voici quelques idées:

Est-ce que tu fais "scrum but"? C’est-à-dire, partie scrum, partie autre chose. (C'est-à-dire: "Nous faisons de la mêlée, mais toutes nos histoires doivent provenir de notre bureau du premier ministre, et non d'un propriétaire de produit.") Beaucoup de merde folle s'appelle Scrum ces jours-ci.

Êtes-vous personnellement impliqué dans le processus où vous devriez être? J'ai connu un certain nombre de personnes contrariées par le contenu des articles, et il s'avère qu'elles ne sont impliquées que lorsque l'histoire est dans l'arriéré des sprints. Parlez au propriétaire du produit dès le début de l’élaboration de l’histoire et obtenez-lui vos commentaires.

Dans Scrum, l'équipe est censée être propriétaire du processus et il est prévu que le processus change avec le temps pour répondre aux besoins de l'équipe. Présentez vos préoccupations lors de la rétrospective. Si vous pouvez suggérer un ajustement du processus, cela facilitera la vente de certaines équipes.

Votre problème n’est pas Scrum (et comme Jarrod Roberson l’a mentionné dans des commentaires, ce n’est pas ce que vous décrivez): c’est la microgestion du Product Owner et votre manque d’assurance (et de votre équipe) .

"Cependant, en raison de la méthodologie Scrum, de nombreuses décisions sont maintenant prises par le propriétaire du produit. Il priorise les PBI, il analyse le fonctionnement des logiciels, voire parfois la mise en œuvre de l'interface utilisateur et des fonctionnalités. Je sais que cela fait partie de la méthodologie Scrum."

Vous vous trompez. Il suffit de regarder brièvement la page wikipedia pour Scrum : "l’Équipe, un groupe interfonctionnel qui effectue l’analyse, la conception, la mise en oeuvre, les tests, etc." Voir? Product Owner vous dit quoi faire, mais c'est à l'équipe de décider comment faire.

Vous êtes la personne responsable de la mise en œuvre. Vous devez donc décider du mode de mise en œuvre de l'application. Écoutez l'opinion du responsable du produit, mais la décision finale appartient à vous (ou à l'équipe).

BTW microgestion ne tourne développeurs actifs dans les 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 ce dont SCRUM est capable.

SCRUM vise à permettre aux développeurs de se concentrer sur les problèmes de développement et de les responsabiliser, ce qui leur permet de déterminer la durée et la manière de procéder.

SCRUM, c’est la collaboration, c’est le but des réunions de planification de Sprint, de promouvoir la collaboration entre toutes les parties prenantes; propriétaire du produit, les développeurs et les tests.

Oui, le propriétaire du produit doit hiérarchiser les fonctionnalités, ce qui doit être livré en premier en fonction des besoins du client, mais les développeurs doivent effectuer l'ingénierie et la conception, et non le propriétaire du produit.

Je ne suis pas d'accord pour dire que les développeurs devraient concevoir des interfaces utilisateur graphiques et des flux de travail, à moins qu'ils ne soient spécialement chargés de la tâche et formés à travailler avec les clients et à en traiter directement les fonctionnalités. Programmeur construit des interfaces graphiques réalisées en vase clos rarement répondre aux besoins des clients.

SCRUM consiste à mettre en place un processus léger, 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 de la sorte.

J'imagine qu'avant Scrum, tout le monde faisait ce qu'il voulait: yippee ki-yay mf'er . Vos utilisateurs sont vos bienfaiteurs et ils dirigent l’histoire et paient les factures. Le responsable du produit s'assure que l'histoire se termine. Certains comment, 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 ordonnées que vous jugez cool? "Je veux faire les fonctionnalités A d'abord et non B, afin de pouvoir 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 de ne pas être d'accord avec l'histoire, dites quelque chose, argumentez. Vous ne pouvez pas toujours gagner. C'est leur travail de retourner aux utilisateurs et de leur faire savoir que leur demande pose problème. Regardons les choses en face, si l’histoire vous demande d’abandonner une base de données de manière aléatoire tout au long de la journée, sans sauvegarde, sans perte de données ni temps d’immobilisation, vous avez un problème et vous devez le mettre au clair.

On dirait que vos aventures dans Agile ont été corrompues par Scrum. Je trouve que parmi toutes les méthodologies agiles, Scrum est la moins agile. Cela ressemble plus à des cascades miniatures et à une gestion de projet supplémentaire. Bien sûr, cela en fait le plus apprécié par la direction qui a le sentiment de reprendre le contrôle de ces développeurs ennuyeux, mais vous voyez bien sûr 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 change-le. Parlez-en à la direction et dites que c'est une étape rétrograde, que votre productivité est inférieure à ce qu'elle était auparavant et que vous êtes tous mécontents de la façon dont cela fonctionne. Montrez le Manifeste Agile (et son jumeau diabolique ) et montrez que vous avez non seulement tiré les leçons de cette expérience, mais que vous souhaitez en transformer les avantages en un système plus performant (un système semblable à celui que vous utilisiez auparavant, qui semble bien fonctionner). pour vous).

Je pense que vous êtes simplement habitués à avoir plus de propriétaires - et tout le monde, je pense, préfère cela, sa nature humaine.

Malheureusement, je pense qu'un grand nombre de logiciels est inférieur à ce qu'il pourrait être, car souvent des parties sont écrites pour le dev et non pour le client. Votre nouvelle approche devrait réduire cela, mais au détriment de votre sentiment de propriété.

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 récits d'utilisateurs sous la forme "En tant que - rôle -, je veux - objectif / désir - pour que - avantage -"? Il semble que votre responsable de produit souhaite effectuer le travail de conception, et il / elle peut ne pas être la meilleure personne pour le faire. L'utilisation du modèle de scénario utilisateur peut aider à garantir que le responsable du produit respecte les intérêts de l'entreprise et que les développeurs du logiciel sont en train de développer les logiciels.

Dans Scrum, les développeurs ont amplement la possibilité de contribuer et de donner leurs conseils sur les nouvelles fonctionnalités, l'interface utilisateur, la convivialité ... La collaboration et la conversation entre les professionnels et les développeurs sont nécessaires dans Scrum et cela le permet. Cependant, au bout du compte, le propriétaire du produit aura toujours le dernier mot, car il est responsable de la maximisation de la valeur commerciale des incréments logiciels générés 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 rapide et continue de logiciels de valeur.

Le propriétaire du produit qui vous explique comment l'interface utilisateur et les fonctionnalités doivent être implémentées n'est pas acceptable. Dans ce cas, vous devriez avoir le dernier mot, puisque vous êtes responsable de la qualité interne du logiciel que vous produisez.

Vous travaillez peut-être dans une entreprise créée par des développeurs où les programmeurs étaient libres d’implémenter les fonctionnalités qu’ils souhaitaient. Cependant, la plupart des méthodologies Agiles établissent une séparation claire entre les personnes du domaine métier et l'équipe chargée de la production des logiciels (développeurs, testeurs, etc.), qui est la division de travail la plus courante dans la plupart des endroits. Si mes hypothèses sont correctes, je peux comprendre le sentiment que vous avez que vous n'êtes plus en mesure "d'influencer 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 pas.

En ce qui concerne l’analyse, la conception et les autres activités de méta-développement que vous avez mentionnées (qui ne sont pas supposées être réalisées par le Product Owner), les équipes Agiles sont censées être interfonctionnelles et ne comporter aucun silo. Personne n’est censé posséder toutes les connaissances relatives à une activité de développement spécifique. Vous avez donc peut-être l’occasion de vous diversifier par rapport à un simple "code monkey".

Au contraire, j'ai constaté que le fait qu'un propriétaire de produit prenne des décisions concernant les fonctionnalités me permet de consacrer plus de temps à la production de code de qualité. De plus, s'il y a des préoccupations valides, je peux toujours remettre en question les décisions des propriétaires de produits, ce qui donne généralement lieu à des discussions fructueuses.

Nous pratiquons Scrum ici. Nous avons une réunion de planification bimensuelle où nous prenons en compte les priorités commerciales actuelles, les succès et les échecs du sprint précédent, et nous décidons, en équipe , de ce que nous voulons aborder pour le prochain sprint.

Pour ce faire, l’un des moyens consiste à classer l’arriéré sur un tableau par complexité verticale et priorité commerciale horizontalement. Après cela, le responsable produit a eu son mot à dire, il appartient donc à l’équipe de choisir ce que nous voulons faire. Évidemment, choisir une tâche hautement complexe et peu prioritaire est mal vu, mais nous décidons de le faire en équipe. Cela allonge la durée des sessions de planification, mais cela en vaut la peine et constitue une partie essentielle du processus Agile.

Et nous avons parfois de la micro-gestion, mais le problème est différent.

Le vrai problème que vous décrivez est une pathologie courante lorsque les équipes adoptent une méthodologie: elles désactivent leur cerveau. Ceci est aussi vrai avec un système agile de nouvelle école qu’il l’était avec des systèmes lourds d’ancienne école.

Q: La méthodologie prescrit x, mais x ne fonctionne pas bien. Que devrions nous faire?

A: Affinez votre implémentation de x. Peut-être arrêter de le faire tout à fait. La Méthodologie n'est pas votre patron!

Dans ce cas précis, il semble que le responsable du produit en fasse trop. Êtes-vous à l'aise de lui parler de ça? Seriez-vous à l'aise d'avoir cette conversation si vous n'étiez pas "faire de la mêlée?" Si le propriétaire du produit n'est pas sensible aux commentaires constructifs, il ne s'agit pas d'un problème de méthodologie, mais d'un problème avec le propriétaire du produit.

Je ne suis pas vraiment au courant de tout le problème de la mêlée, qui a été plus de cascade pendant 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 dans plus de personnes que de technique.

Le rôle des leaders dans une équipe auto-organisée serait un article de blog sur quelque chose qui semble manquer à votre article. Où l'équipe décide-t-elle du travail à effectuer dans un sprint? Où l'équipe est-elle en possession du processus et du travail? Avez-vous quelqu'un qui connaît assez Scrum pour le faire et pas une version perverse de celui-ci?

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é des créateurs / concepteurs / frontaux, semblent en souffrir plus que les personnes impliquées dans le backend.

Jusqu'à présent, la seule solution que j'ai trouvée consistait à abandonner Scrum - ce qui est souvent impossible et / ou inapproprié, car après tout, il présente des avantages - ou à introduire quelque chose comme le temps de 20% de Google pour donner aux développeurs un débouché créatif en dehors du "vous". Vous êtes libre de choisir comment mettre en oeuvre la page de connexion ", car en réalité, votre code et votre architecture système ne vous contraignent pas à la mettre en oeuvre - c’est-à-dire, à moins que vous ne considériez la liberté de choisir entre" une boucle for et une boucle while "a liberté.

Il y a une grande différence entre décider quoi faire ou se faire dire quoi faire .

D'après mon expérience, il y a encore un long chemin à parcourir avant de savoir quoi faire pour décider quoi faire.

Au bout du compte, il s’avère généralement que nous avons été instruits non pas parce qu’ils aiment le pouvoir et non parce qu’ils n’ont rien de mieux à faire. Au contraire, au bout de ce chemin, quand ils ont suffisamment confiance en notre équipe, ils semblent être soulagés et nous transmettent volontiers le plus de contrôle possible (et si leur confiance est vraiment ferme, ils essaient même de passer plus que ça)

Oh, et selon mon expérience, cela n’a fondamentalement rien à voir avec Scrum / agile. Arrivé avec mêlée, itérative, cascade, peu importe. Il semble que la question de la confiance soit agnostique

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 sinon vous vous retrouverez dans la situation que vous avez décrite.

D'après mon expérience, Scrum doit vous regarder profondément ce que vous faites. Il suffit de s'asseoir sur votre épaule et de regarder ce que vous faites. Même si cela présente un avantage, je déteste la méthodologie Scrum. Il attend le compte, pas la qualité. La qualité est compromise avec la méthodologie Scrum.