Ça me trottait dans la tête depuis un moment et il fallait que je fasse un retour d’expérience et tant qu’à faire autant que ce soit la mienne… d’expérience.
Je suis actuellement en mission dans un grand groupe où la gestion de projet dite classique est profondément implantée, dans une équipe qui n’a pas été biberonnée au Scrum. Comment alors amener l’outil dans un tel environnement ? Pas simple…
Cet article sera découpé en plusieurs billets que je posterai régulièrement dans le déroulement de la mission.
D’abord décrivons l’équipe en question :
· 1 premier MOA peu intéressé par les méthodes agiles puis un 2nd MOA très curieux des méthodos et prêt à tenter
· 1 MOE rôdé aux méthodes (normal il est de CLT !)
· 4 développeurs :
o 1 dev formé et déformé au Scrum, moi-même
o 1 autre non formé mais flexible donc bon candidat
o 1 dev non formé plutôt rôdé au cycle en V
o 1 dernier désirant une assignation totale de chaque tâche
Voilà une équipe bien disparate mais n’est-ce pas ce qui rend la chose intéressante ?
1ère difficulté
Nous avons mis en place directement la totale, scrum board, burndown chart, post-it qui piquent les yeux, nous n’avons pas poussé le vice jusqu’à utiliser le planning poker mais pas loin. Notre première difficulté fût le refus de l’affichage du burndown chart aux passants.
Un trop de plein de transparence avait créé un malaise dans l’équipe de peur que la première réaction des managers voyant une courbe qui ne voulait décidément pas descendre fût cinglante. Selon moi, une bonne communication à l’intérieur de l’équipe et de façon montante permet d’éviter justement une mauvaise interprétation du burndown chart. Nous avons tout de même décidé de ne pas l'afficher.
2nd difficulté
Difficile de créer un backlog quand le MOA ne semble pas convaincu par l’outil scrum ? Les nombreuses tentatives d’explication et d’implication n’ont pas suffi à lui faire changer d’avis, obligés de faire sans… Nous avons donc tenté de créer des sortes de backlogs virtuels (non pilotés par le client et le PO) qui volaient en éclat à chaque changement dans le planning.
Résume très bien l'agile dans notre environnement
Points positifs et ce qui a rapidement fonctionné
Dans tous ces obstacles, il faut bien voir les points positifs qui ont été amenés.
Tout d’abord et l’un des plus importants, le test unitaire provenant de l’extrême programming lui-même faisant partie des méthodes agiles. L’équipe est aujourd’hui totalement indépendante sur les tests. Chaque développement fait l’objet d’un ou plusieurs tests unitaires. Notre couverture de code a explosée.
De ce fait, nous avons mis rapidement en place l’intégration continue. Nous travaillons avec ClearCase pour le versioning, Hudson pour l’intégration continue. Chaque stream ClearCase possède sa chaîne d’intégration et sa base de données (les tests cependant, codés dans les règles de l’art ne laissent aucune donnée dans la base). Ce fonctionnement convient actuellement à tout le monde et a permis d’éviter bon nombre de bugs lors des phases de test voir de production.
Conclusion
Ce que je retiens de ces deux premières difficultés est qu’il faut faire très attention à ne pas arriver avec une gestion clef en main car les gens avec qui on travaille ne sont pas forcément sensibles à une méthode nouvelle. De même, vérifier que tout le monde est à l’aise avec les aspects de la méthode
Le Scrum est une méthode où toute partie doit adhérer du développeur au client ou tout du moins le MOA sous peine d’essuyer quelques plâtres.
Lorsque le Scrum Board explose et ne tiens pas la route, trouver une autre méthode de gestion des tâches et des sprints