Comment Git nous rend agiles – ou pas

Moi.

Publicité

Dans mon travail avec les équipes de développement, j’ai eu l’impression que nous travaillons de manière agile lorsque nous travaillons comme Jira le souhaite. Je ne suis pas d’accord. Le dicton s’applique à moi dans ce contexte : Un imbécile avec un outil reste un imbécile.

Je ne pense pas qu’un outil puisse rendre une équipe agile. Cependant, la manière dont les outils sont utilisés peut fournir des indices sur le niveau d’agilité de l’équipe. Cela s’applique également aux outils qu’un coach agile ou un Scrum Master ne surveille souvent pas ; Cela est particulièrement vrai pour les Scrum Masters qui n’ont pas de formation technique. À ce stade, les développeurs doivent prendre les devants afin que l’équipe puisse se développer davantage. Je voudrais expliquer ce que je veux dire par là en utilisant un exemple réel.

Dans une équipe avec laquelle je travaillais, la réalisation des objectifs et l’engagement au sprint n’allaient pas bien. L’équipe était souvent incapable de réaliser ce qu’elle avait prévu au début du sprint. Les tickets sont passés d’un sprint à l’autre. Le temps de cycle était élevé. Aucun problème inhabituel ; Il ne restait plus grand chose à voir de l’idée agile.

Même si les causes étaient multiples, Git a joué un rôle central. Il est progressivement devenu évident que le niveau d’expertise de l’équipe dans l’utilisation de Git variait considérablement. Il y avait de jeunes développeurs qui avaient toujours travaillé avec Git, et il y avait des développeurs plus âgés qui avaient travaillé avec des systèmes comme CVS ou Subversion avant d’entrer en contact avec Git.

Ces derniers n’avaient jamais travaillé de manière intensive avec Git et essayaient de travailler en grande partie comme ils en avaient l’habitude avec les outils plus anciens. En particulier, avec Git, il leur manquait la fonctionnalité de blocage du paiement pour éviter les conflits de fusion. Ils n’étaient pas doués pour résoudre les conflits de fusion. Lorsqu’ils se produisaient, les développeurs évitaient la résolution des conflits et commençaient à travailler sur le ticket suivant. Comme il s’est avéré plus tard, l’idée derrière tout cela était “Je ferai le travail désagréable plus tard avec tous les billets en une seule fois”.

Trop de tickets dans le sprint final

Un effet n’était pas visible : plus quelqu’un attendait pour fusionner dans le sprint, plus le conflit était grand. Bien entendu, la branche master a continué à se développer. Lorsque la fusion a eu lieu peu avant la fin du sprint, la tâche était devenue si grande que l’équipe n’était plus en mesure de terminer la plupart des tickets au cours du sprint. Puisqu’il était considéré comme normal que des tickets inachevés se glissent dans le prochain sprint (« c’est comme ça que nous procédons toujours »), il n’y avait aucune impulsion à remettre en question la question.

Une analyse des délais dans Jira n’a pas facilement révélé la cause du problème. C’était parce que

1. que les statuts utilisés (colonnes du tableau) n’étaient pas suffisamment différenciés pour pouvoir identifier “où” un ticket de longue durée était bloqué,
2. que les développeurs ont parfois traité les tickets concernés sur le tableau de la manière la plus opaque possible ; probablement pour dissimuler le problème, et
3. que l’utilisation de sous-tâches dans Jira a encore plus obscurci la cause du problème. En passant, il faut préciser que je ne suis donc pas fan des sous-tâches. Les sous-tâches ont également empêché les tentatives d’identification de la cause du problème via les limites des travaux en cours.

En résumé, c’était une situation qui rendait très difficile pour moi, en tant que coach agile, de me rapprocher de la cause du problème.

Au final, c’est l’un des « Git native locuteurs » qui a reconnu que certains coéquipiers avaient des déficiences majeures dans l’utilisation de Git et que donc les tickets restaient longtemps à traîner. Il a proposé à ses collègues quelques heures de programmation en binôme. Il a vu quel savoir-faire manquait. Une fois le problème identifié, trouver une solution était relativement facile.

L’équipe a décidé d’effectuer régulièrement des exercices Git. En fait, il n’a fallu qu’un sprint pour que le problème disparaisse. Cela a été possible parce que les « Git juniors » ont demandé de l’aide aux « Git seniors » pour la fusion ; remarquable car les juniors passent plus de temps à développer des logiciels que les seniors. Il s’est avéré que l’expérience n’est pas unidimensionnelle et n’est pas nécessairement liée à l’âge. La diversité et la reconnaissance au sein de l’équipe sont importantes, mais ce sont des sujets pour un autre article de blog.

Conclusion

Le passage au travail agile n’est pas une tâche du Scrum Master ou du coach, mais plutôt un changement que l’équipe ne peut réaliser qu’ensemble. Lorsque les développeurs assument leur rôle de leadership, ils peuvent réaliser des améliorations qui sont hors de portée du Scrum Master.

Au revoir. Stéphane

(moi)