Press "Enter" to skip to content

“Je ne suis pas intégré dans l’équipe de développement !”

Photo by George Bonev on Unsplash

“Je ne suis pas intégré dans l’équipe de développement !”

Récit de la détresse d’un business analyst et d’un testeur

Je me permet de partager un échange dans lequel un Business Analyst ainsi que son collègue testeur se sentent exclus de l’équipe de développement.

On aime bien ranger les gens dans des cases ! 😅

Je viens de lire que Scrum ne reconnaissait pas de rôles supplémentaires car c’est une source de blocage dans l’auto-organisation de l’équipe.

Typiquement, si on désigne quelqu’un en tant que lead tech, les autres personnes seront contraintes dans leurs capacité d’initiative par cette relation de référent.

L’abstraction des rôles est une idée que je trouve très intéressante car cela permet à l’équipe de monter en compétence sur tous les types de tâches et de pouvoir devenir pluridisciplinaire et efficiente.

Malgré cela, sur le terrain on ne peut pas s’empêcher de donner des rôles… testeur, analyste, développeur front… et du coup, on recrée les barrières que Scrum tente de lever.

J’ai rencontré ce problème de blocage au cours de mon dernier projet.

Ayant un rôle de business analyst, les développeurs ne voulaient pas que je les aide à coder alors que j’ai un petit background technique qui aurait pu les aider à dégager du temps pour faire des choses à plus forte valeur ajoutée.

Je pense que c’est en partie lié au fait que dans Scrum, on parle de « l’équipe de développement ». À cause de cette détermination, les gens comprennent implicitement qu’il s’agit des personnes qui font du code (des DÉVELOPPEURS).

On est d’accord qu’il s’agit de bien plus que ça car il y a aussi les activités d’analyse, rédaction de spec et tests.

À cause de cette confusion, le testeur et moi-même avions parfois le sentiment de ne pas vraiment faire partie de l’équipe, mais être juste des satellites.

Pourquoi « équipe de développement », terme qui peut porter à confusion ?

Effectivement, certains coach agiles vont parler « d’équipe de réalisation » plutôt que d’équipe de développement, c’est sûrement une manière de s’abstraire un peu du constat qui est ici fait.

Honnêtement, un certain nombre de choses sont maladroites dans Scrum, le framework est clairement bien conçu mais nulle œuvre n’est parfaite et après plusieurs décennies de recul on voit forcément les défauts ! Historiquement Scrum servait à livrer des projets pour des clients, et je pense qu’à l’époque, considérer qu’il ne s’agissait que de développeurs correspondait à 90% des projets.

Comment faire comprendre que l’équipe de dev Scrum ce n’est pas que des dev ?

Dans ce cas de figure, je suggère de mener un raisonnement par l’absurde autour du Definition of Done ou DoD. Dit simplement, le DoD engage l’équipe de développement, et uniquement elle. Est-ce que le travail de Business Analyst et celui du testeur font partie du DoD ?

  • Si oui : alors il semble logique de les y inclure…
  • Si non : alors il sera intéressant de poser la question de ce qui est livré, quitte à les titiller avec des expressions comme « pisseur de code »… Peut-être se perçoivent-ils réellement comme juste des « codeurs » et pas comme des développeurs à part entière, qui analysent un besoin, conçoivent une architecture, et testent leurs développements.

Pour aller plus loin

Que pensez-vous de cet article ?

Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

Et pensez à souscrire à ma future newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.

À bientôt 😊

Top