6 raisons du rejet de l'Agilité par les développeurs
Par Cyrille » 26 décembre 2011 (20:30) - Scrum - Méthodes agiles
Je viens de lire le billet de Guillaume Saint Etienne intitulé : "2011: petits arrangements avec l’agilité" et une phrase m'a interpellé : "Et là où l’on s’est rendu compte que la situation était ubuesque, c’est que ces opposants (à l'Agilité) étaient eux même... des développeurs!".
D'où ma question : pourquoi les développeurs rejèteraient l'Agilité ?
Voici 6 raisons issus d'une énorme séance de brainstorming arrosée d'alcool locaux (enjoy).
1/ Plus je suis indispensable plus j'aurais du poids à mon entretien annuel
Tout le monde le sait :
- Si tu veux une vraie augmentation il faut être indispensable
- Plus je suis indispensable, plus je suis certain de ne pas me faire sortir du projet
- Donc moins je communique plus je deviens indispensable
2/ Je fais ce que je veux avec mes cheveux...
Tu m'as donné 5 jours pour coder ce truc : si je le fais en 3 jours, je gagne 2 jours où je peux faire ce que je veux...
Et puis ta réunion du matin, ça me gave, ça tombe pile durant ma pause café...
3/ L'esprit d'équipe... C'est des mecs qui sont une équipe, ils ont un esprit ! Alors, ils partagent !
Pourquoi j'aiderais les mecs autours de moi ?
Pourquoi je ne le fais pas ?
Facile :
- à mon époque, on se démerdait, donc les "bleus" de maintenant ils se démerdent, de plus :
- Ce n'est pas dans ma fiche de poste de faire du babysitting technique
- Quand je vois leur salaire, je ne comprends pas pourquoi ils auraient besoin de moi, à moins que je sois sous-payé ?
etc...
4/ Moi le client : je m'en fous
Moi je suis là pour coder ce que l'on m'a spécifié, le client il ne comprend rien à ce que je fais.
Alors je ne vais quand même pas faire le traducteur pour des gens qui ne connaissent pas la différence entre un WAR et un EAR.
Chacun son métier et les vaches seront bien gardées.
5/ Je veux être CHEF de projets
Donc si on fait de l'agilité, il n'y aura plus de chef de projet dans quelques temps donc je n'aurais plus d'avenir.
6/ L'Agilité paie moins bien que le cycle en V
C'est mathématique, regarde :
- Sur mon ancien projet en cycle en V on a été obligé de bosser le soir et les week-end,
- On comptait nos heures par semaines au delà de 40h par semaine cela était compté en heure sup
- Pour les Week-End, un samedi c'est +50% et un dimanche +100%
Au final, j'arrive à avoir 50% de mon salaire mensuel en plus par an donc avec ton Agilité je perds bien de l'argent.
Les personnages et les situations de ce billet étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite.
Évaluer ce billet
4/5
- Note : 4
- Votes : 8
- Plus haute : 5
- Plus basse : 2
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Espérons que d'ici quelques années tu puisses renommer ce billet en "Mémoires de dinausores" :D (à moins que ce titre te donne d'autres idées de billets
)
Au final est-ce que ce sont vraiment les dévs qui rejettent l'agilité ?
De mon point de vue:
1°/ Finalement le problème ici c'est la gestion caricaturale des augmentations non ?
2°/ "Tu m'as donné 5 jours..." => c'est pas la team qui fait ses estimations ?
Après le standup meeting a tendance a gaver les gens allergiques aux réunions, mais si on le timebox bien ça se résorbe vite quand même !
3°-4°/ Devoir se séparer de gens c'est un peu un constat d'échec mais bon un gars comme ça c'est bon ni pour la boite ni pour lui-même, c'est moche mais bon qui sème le vent...
5°/ En effet le type qui sort ça s'est trompé de métier, faut qu'il fasse vite des études de trader
6°/ Jamais croisé de boite d'info ou les heures sup étaient payées, ça existe en vrai ?
Bref tout ça pour dire qu'en tant que développeur ces raisons me semblent un peu caricaturales, je pourrais faire les mêmes sur les raisons qui empêchent les managers d'adopter l'agilité (ou les commerciaux).
et en mode TMA vu du point qui raque les factures ça donne quoi ?
Avait-on correctement expliqué l'agilité aux personnes qui ont sorti ces énormités?!
Tous ces points convergent à mon avis vers une problématique unique.
Quel place réserve-t-on aux développeurs au sein de l'entreprise et quelles perspectives d’évolution de carrière sont offertes ?
Je travaille à l’étranger depuis un certain temps et ici il est tout à fait possible de faire toute sa carrière en temps que développeur. Le salaire évolue avec l’expérience et l'unique solution pour avoir un salaire satisfaisant n'est pas de devenir chef de projet. De même l'organisation du temps de travail est beaucoup plus souple (cf. point 2).
Je pense sincèrement qu'un travail sur ce sujet en France amènerait à de meilleures conditions afin de pouvoir implanter et faire accepter les méthodes agiles. Après tout le cœur de ces méthodes n'est-il pas d'avoir une équipe auto-gérée ?
Entièrement d'accord avec jbld !
Mais il faudra attendre encore longtemps (à mon avis) avant de voir ces points évoluer globalement.
La façon de penser de la génération Y est très largement ouverte à ce type de changement ce qui n'est pas le cas des générations précédentes (je fais là une généralité évidemment et il y a toujours des exceptions, heureusement !).
Avant la génération Y, il est difficile de remettre en cause des procédés "qui marchent", de prendre en compte le bien-être des individus au sein d'une société.
Il n'est d'ailleurs pas rare d'entendre encore au jour d'aujourd'hui des phrases comme "Si tu travailles 1h de plus par jour, ça fait 5h par semaine et 20h par mois ! multiplié par le nombre de salariés ça fait autant d'heures de PRODUCTIVITé en plus !"
Ce n'est qu'un exemple, mais cela montre que l'idée de productivité est encore trop souvent pensée comme étant liée au temps de travail !
Or, en informatique en particulier, cela ne s'applique pas ! On peut produire plus en 1h qu'en 8 (ce qui ne veut pas dire qu'il faut finir sa journée à 10h ^_^) !
Bref, il faut faire évoluer ce type de situation, pour de meilleures conditions, pour effectivement obtenir des équipes auto-gérées, mais il faut d'abord que les mentalités changent ce qui me fait finalement conclure sur ceci : La génération Y au pouvoir ! :o)
C'est la que le ScrumMaster doit jouer tout son rôle de facilitateur et également de Coach Agile, afin d'amener l'équipe de développement à faire abstraction de ces points de blocage et pousser chacun à penser "équipe" et non plus "moi je".
Cela doit, à mon sens, passer par la mise en oeuvre des actions suivantes :
).
- Une écoute de chaque membre de l'équipe sur ces attentes, ces frustrations et les actions à mener pour que chacun se sente à sa place.
- Une forte sensibilisation auprès de la hiérarchie de chaque membre de l'équipe (une équipe agile ne provient pas toujours du client ou d'une même SSII), afin de mettre en avant le travail effectué et l'apport positif de chacun (pour le point 1).
- L'organisation d'événements hors contexte travail (aller prendre un verre après le boulot, organiser un petit-dej ou chacun apporte les croissants à tour de rôle, prévoir un déjeuner par semaine ensemble ou en fin d'itération, avec le PO et le sponsor ou le CP)
- Pour ceux qui veulent être CP, leur expliquer qu'avant d'être CP il faut savoir écouter les autres, être meneur et prendre quelques responsabilités de management. Une idée serait que chaque développeur le souhaitant devienne ScrumMaster, pendant 2 itérations, à tour de rôle et puisse ainsi toucher au rôle de "manager" (pas de panique je ne dit pas que le SM est un CP
- Mettre en place le pair-programming afin d'améliorer la communication, surtout auprès des collaborateurs introverti ou réticent à partager. Cela les inciteras (mais rien n'est jamais sur) à échanger un peu plus.
- Utiliser la rétrospective pour identifier les problèmes de personne ou les revendications et mettre en place un plan d'action pour y répondre (si possible).
Pour le point 6, lorsque des heures sup ou un travail le WE est nécessaire pour finir un projet en Y ou V, cela signifie souvent que les délais forfaitisés ne sont pas respectés et bien que le développeur sera payé un peu plus un ou deux mois, je ne suis pas sur que tout soit rose lors de l'entretien d'évaluation pour son évolution de carrière.
Maintenant, il arrive que malgré tous les efforts mit en oeuvre une ressource fasse sa mauvaise tête et perturbe le travail de l'équipe et mette en risque la Release et la cohésion. Dans ce cas extrême ... le mieux est de se séparer de la personne.
Couthaïer.
Fil des commentaires de ce billet
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
URL de rétrolien : http://www.bouzin-agile.fr/?trackback/215