7-6. Obstacles

Voici quelques obstacles que vous pourrez rencontrer.

Le client ne sait pas ce qu'il veut
Si le client n'a pas préparé la réunion, alors la première partie de la réunion prendra beaucoup de temps pour définir les user stories. Cela peut être utile de convenir d'une réunion préparatoire à la réunion de planification avec un petit groupe de gens pour obtenir un premier jet des stories. Cela marche mieux si vous faites venir au moins une personne de l'équipe pour donner un avis technique et vérifier que les stories sont bien faisables et pas trop grosses pour pouvoir être livrées en une seule itération.

On demande à l'équipe de s'engager encore plus
Quelquefois, on demande à l'équipe de s'engager à prendre plus de travail qu'elle ne pourra concrètement livrer. Cela arrive souvent lorsque le client a une date butoir et qu'il y a beaucoup de pression sur l'équipe. Si vous voyez que l'équipe est sur le point de s'engager plus loin alors que sa vélocité montre que cela ne sera très probablement pas possible, avertissez-les qu'il y a un risque très grand sur le fait que les stories ne seront pas toutes livrées.

Si l'équipe insiste en disant qu'elle peut le faire alors assurez-vous qu'elle a bien découpé finement les stories de telle façon qu'elle aura quelque chose à livrer pour chaque fonctionnalité, même si ce n'est pas la version complète envisagée au départ.

Le temps qu'il faisait hier
par Lasse Koskela, Reaktor Innovations

Une fois j'ai travaillé avec une très petite startup qui avait récolté une bonne publicité; on parlait beaucoup d'elle comme étant le futur MySpace… Le client était le fondateur de l'entreprise qui avait construit lui-même la première version du service en ligne pendant son temps libre en un peu plus de deux mois. Il était très engagé et enthousiaste de voir son entreprise grossir.

Après quelques mois de mise en route de l'équipe et de refonte du service pour les besoins du marché mondial, ils décidèrent d'adopter Scrum car leur méthodologie projet montrait déjà des signes de faiblesse. Plus de discipline et de visibilité étaient nécessaires.

Au début de leur seconde itération - après avoir livré 25 points de fonctionnalités dans la première itération - l'équipe parlait de se baser sur cette mesure du “temps qu'il faisait hier”. Le client, toutefois, était optimiste sur le potentiel de l'équipe et essaya d'embarquer l'équipe sur 35 points. Ils s'engagèrent sur 35; ils livrèrent 24.

Une fois de plus, le client prononça un laïus d'encouragement à la réunion de planification de l'itération, soulignant qu'ils “commençaient tout juste” et que l'équipe était constamment en train d'apprendre et de s'améliorer. L'équipe s'engagea sur 35 et livra 25.

Quatrième itération, même chose. Ils s'engagèrent sur 35 points parce que le client “savait qu'ils pouvaient le faire” et livrèrent encore moins.

A ce stade, le client accepta finalement ce que moi et d'autres coachs avions essayé de lui expliquer : la productivité de l'équipe ne s'améliorera pas avec des vœux pieux et “essayer plus fort”. Au pire, elle dégringole sous une pression excessive.

Changement de planning durant l'itération
Soyez attentif au fait que les tâches sur le tableau de l'équipe changent radicalement dans les premiers jours d'une itération. C'est signe que les réunions de planification ont été faites à la hâte. Nous avons vu des équipes passaient au travers de la planification, du découpage en tâches et des estimations sans vraiment se rendre compte de ce qu'il allait arriver. Si bien que lorsque le travaille débutait réellement sur la story, il devenait manifeste que les tâches du tableau ne reflétaient pas la réalité du travail à réaliser.

Attendez-vous à ce que l'équipe crée quelques tâches supplémentaires sur une story au fur et à mesure que sa compréhension du problème est meilleure, mais si les tâches changent du tout au tout c'est signe que l'équipe ne vient pas à bout de ce qui doit être nécessairement fait durant la planification. Encouragez l'équipe à passer plus de temps lors de la prochaine session de planification pour travailler sur ces tâches et encouragez aussi l'équipe à réaliser quelques études de fond¹⁾.

La réunion soulève des conflits ou des tensions
Mener des réunions de planification peut être un vrai défi. Les développeurs ont souvent des vues opposées sur la conception. Les clients ne comprennent pas forcément pourquoi ils doivent changer ou découper les stories.

Le premier sujet de tension qui peut apparaître lors de la première partie de la réunion, peut être sur la façon de découper les stories ou de choisir celles qui sont importantes. Encouragez l'équipe à expliquer leurs idées et intérêts au client. Soyez clair avec le client : il doit écouter. En fin de compte, le choix des stories qui figurent dans le planning est une décision conjointe.

La seconde partie de la réunion peut également être tendue, parce que l'équipe doit se mettre d'accord sur la façon de construire le logiciel afin de livrer les stories. Un certain niveau conflictuel est ici probablement utile pour tester et améliorer les idées, mais trop de conflit est tout simplement désagréable et inefficace.

Si plusieurs solutions sont proposées et qu'elles semblent aussi bonnes (ou mauvaises) les unes que les autres, alors rappelez à l'équipe d'évaluer la simplicité de développement de chaque solution. L'équipe peut essayer de développer deux solutions à la fois. Cela les aidera à en apprendre plus sur le problème. Bientôt il deviendra évident qu'une solution est meilleure que l'autre ou que la combinaison des deux idées est la meilleure. Bien que cela semble du gaspillage de coder deux solutions, cela peut se révéler le moyen le plus rapide pour apprendre, et cela peut aussi fournir une meilleure solution.

La vélocité de l'équipe diminue
Il est relativement normal que la vélocité d'une nouvelle équipe prenne quelques itérations pour se stabiliser et donner une mesure fiable, mais une fois stabilisée, l'équipe doit encore la suivre. La vélocité de l'équipe ralentit souvent un peu au fur et à mesure que le projet grossit et que le logiciel met en jeu davantage de user stories. En même temps, l'équipe est peut être devenue plus optimiste puisque leur confiance en l'Agile a augmenté. Aidez l'équipe à noter tout ralentissement et essayez de faire ressortir les causes racines²⁾, même si cela peut prendre plusieurs itérations pour mettre le doigt dessus. Pendant ce temps là, la planification doit être basée sur la nouvelle vélocité mesurée plutôt que de continuer à planifier avec l'ancienne vélocité en espérant que la magie reviendra.

La planification n'a pas de sens
Vous constaterez que parfois exécuter la cérémonie de planification n'a aucun sens, par exemple lorsque plusieurs membres de l'équipe sont absents du bureau, en vacances ou en formation, ou sur un paquet de bugs à corriger. La résolution des bugs ne peut être aisément estimée parce qu'il s'agit d'un travail de détective à la recherche de l'origine des problèmes.

Plutôt que de perdre du temps à planifier des itérations durant ces périodes troubles, créez une file d'attente du travail priorisée sur le tableau de l'équipe. A partir de ce moment, l'équipe peut trouver son chemin et prioriser son travail de la journée lors du daily standup. Continuez à travailler sur de petits éléments jusqu'à ce que l'équipe soit de retour ou que les bugs aient été traités.

Si cela arrive souvent alors envisagez d'adopter un style de développement kanban, qui ne repose pas sur des itérations de taille fixe pour limiter le travail en cours³⁾.