Méthodologie

J’entends parler d’équipes d’ingénierie qui confient aux développeurs une large responsabilité sur leur travail, avec très peu de réunions récurrentes.

Un ancien collègue, aujourd’hui chez Mistral, et un ami qui travaille chez Synthesia depuis quelque temps m’ont tous les deux décrit ce type d’environnement dans leurs équipes. Les entretiens individuels existent toujours, mais une grande partie de l’organisation quotidienne repose sur chaque développeur.

Pendant des années, les discussions sur la méthode de travail d’une équipe se résumaient souvent à Scrum, Kanban ou à une combinaison des deux. Ces témoignages m’amènent à me demander comment la coordination se fait quand moins de décisions passent par des réunions planifiées.

Il existe d’autres exemples. Ashby décrit des ingénieurs responsables de projets au sein d’« équipes d’une seule personne », sans planification de sprint. Chez PFF, un projet pilote autour de l’IA, mené par deux ingénieurs, a remplacé les cérémonies Scrum par des mises à jour automatisées et des points de retour d’expérience tous les deux jours.

Je comprends l’attrait de cette approche, particulièrement pour le travail à distance. Des résultats attendus clairement définis, du temps pour se concentrer et la liberté de choisir comment aborder un problème peuvent rendre le travail gratifiant.

Ce qui m’intéresse le plus, c’est l’étendue de cette responsabilité. Celle d’un développeur peut aller de la compréhension du problème à la définition du périmètre, au développement de la solution et à la vérification de son utilité. Cela demande du discernement pour savoir quand agir seul, quand associer ses collègues et quand demander de l’aide. Les priorités communes et le système dans son ensemble restent importants.

Cette approche est antérieure aux derniers outils d’IA. J’ai l’intuition que l’IA pourrait la rendre praticable pour un plus large éventail de tâches, en aidant un développeur à aller plus loin dans la résolution d’un problème avant de devoir passer le relais. Il vaut donc la peine d’examiner notre façon d’organiser le travail au même titre que les outils eux-mêmes.

Les pratiques qui soutiennent cette approche semblent importantes. Dans son témoignage publié, Synthesia décrit des propositions écrites, des points quotidiens asynchrones et des objectifs clairs. L’entreprise souligne aussi l’importance de recruter des ingénieurs expérimentés. Derrière un calendrier relativement dégagé, il y a une façon délibérée de tenir tout le monde informé.

En tant que manager, je voudrais comprendre ce que les routines actuelles apportent à une équipe avant de les changer. Planifier ensemble peut mettre au jour une dépendance que personne n’avait remarquée. Une rétrospective peut donner à quelqu’un l’occasion de soulever un problème qu’il n’évoquerait pas dans un point d’avancement. Tout changement devrait préserver ces bénéfices.

J’aimerais comprendre les effets dans la durée, tant sur les livraisons que sur les personnes. À quelle vitesse les changements utiles parviennent-ils aux utilisateurs ? Combien de travail faut-il reprendre ensuite ? Les développeurs sentent-ils qu’on leur fait confiance, qu’ils sont soutenus et qu’ils peuvent apprendre les uns des autres ?

Je serais particulièrement curieux de voir comment ces réponses évoluent à mesure que les équipes grandissent et que de nouvelles personnes les rejoignent.

Article issu de mon post LinkedIn.