Agile smells – Sprint planning

Suite de la série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd’hui, parlons du Sprint Planning…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

• Agile smells – Management visuel
• Agile smells – Sprint daily stand-up meeting
• Agile smells – Sprint review
• Agile smells – Sprint retrospective
• Agile smells – Backlog et user stories
• Agile smells – Pratiques de développement et de test
• Agile smells – Rôles et motivation

« 4h c’est un peu long non ? »

La situation

L’équipe organise à chaque début d’itération un Sprint Planning dont la durée est au minimum d’une demi-journée.

Pourquoi ça sent mauvais ?

Les participants sortent généralement lessivés après de telles cérémonies. Au fur et à mesure des itérations, ils verront cela comme une contrainte supplémentaire.

L’intérêt premier du Sprint Planning est la discussion, mais lorsqu’elle devient interminable elle ne sert à personne. La principale explication de la durée est la méconnaissance du sujet : l’équipe cherche à comprendre pendant la réunion et débute des investigations techniques. Un sujet complexe multiplié par un nombre de personnes important cherchant à le résoudre vous donnera forcément un temps de traitement élevé.

Concrètement on fait quoi ?

Trois axes pour réussir l’objectif de cette cérémonie :

• L’organisation

Le temps de concentration maximum d’une personne ne dépasse généralement pas une heure. Par conséquent, plutôt que d’avoir une seule grosse réunion, il suffit de la découper en plusieurs petites de maximum une heure :

• • Une Backlog Review lors de l’itération N-1 ou N-2, qui permettra au Product Owner de présenter les stories de l’itération N. L’équipe se contentant de poser des questions pour comprendre les fonctionnalités, et de nommer une personne ou un binôme qui fera l’analyse technique de son côté.
  • Un Sprint Planning, en début d’itération N, qui servira à débattre sur la base des analyses techniques, découper en tâches et estimée.

• La préparation

Pour certaines équipes, le découpage en tâches techniques se ressemble souvent. Pourtant elles vont passer du temps à réécrire ces post-it lors de la cérémonie. Un conseil bête mais qui pour certaines équipes leur ont fait réduire la durée de 10% : préparez les post-it à l’avance, ou mieux, récupérez les anciens.

Venez également avec un panel de stories déjà implémentées et représentatives des différents niveaux de complexité. C’est une aide non négligeable à l’estimation qui peut vous éviter des débats inutiles.

• La facilitation

Lors de l’estimation, ne laissez pas les discussions aller trop loin. De même, ne recherchez pas à tout prix un consensus. Contentez vous de deux tours durant votre planning poker et la deuxième fois prenez le chiffre qui est le plus représenté. Ce ne sont que des estimations et leur valeur n’est donc pas primordiale.

« Oui c’est normal c’est elle l’experte »

La situation

Durant le Sprint Planning, l’équipe passe son temps à écouter l’expert(e) technique. Que ce soit lors de l’analyse, du découpage en tâches ou de l’estimation, ses commentaires et décisions sont rarement remis en question.

Pourquoi ça sent mauvais ?

Cette situation peut cacher différentes choses :

• Equipe non pluridisciplinaire

Une équipe agile idéale se caractérise par des individualités pluridisciplinaires, pouvant donc aborder différents sujets sans pour autant en être l’experte absolue. Si la voix d’un(e) expert(e) ne trouve aucune réponse, c’est certainement qu’il manque des contrepoids techniques au sein de l’équipe.

• Manque de préparation

Il existe deux types de personnes : celles qui ont besoin de préparer un sujet afin de pouvoir exprimer une opinion par la suite, et celles qui sont à l’aise avec l’improvisation. Si vous avez des personnes compétentes qui ont besoin de se préparer mais qui ne le font pas ou n’ont pas le temps de le faire, elles se contenteront d’écouter sagement durant le Sprint Planning si elles ne sont pas sûres de maîtriser le sujet abordé. D’autant plus si c’est un(e) expert(e) qui s’exprime.

• Personnalité trop forte

La personnalité des équipiers joue également un rôle primordial dans la manière dont se déroule ce genre de réunion. Une personnalité forte peut, au fil du temps, écraser toutes les autres. Parler plus fort, remettre en cause les compétences sous un trait d’humour, rappeler des erreurs passées, ou avoir une communication agressive sont autant de signes indiquant un problème.

Concrètement on fait quoi ?

Une nouvelle fois, un Sprint Planning ça s’organise. Comme indiqué dans le smell précédent, la mise en place d’une revue de backlog doit vous permettre de répartir les analyses au sein de l’équipe. Il n’y aura donc plus d’excuse pour ne pas s’exprimer.

Analyser c’est bien mais si cela se fait en dehors du domaine de compétence de chacun, c’est complexe. C’est dans ce cadre, il est important de mettre en place des pratiques comme le pair programming, les revues de code ou les coding dojo. Au fil du temps, les compétences devraient se lisser de manière à rendre autonomes les membres de l’équipe.

Enfin une idée radicale mais qui peut porter ses fruits dans certains cas : demandez à l’expert(e) de venir en simple observateur. Le but est qu’il ne parle que dans le cas extrême d’un oubli remettant en cause entièrement ce qu’il s’est dit pendant la réunion. Cela n’a pas pour but de régler les problèmes de personnalité, mais plutôt de redonner confiance au reste de l’équipe sur ses capacités à prendre des sujets et à les responsabiliser davantage.

« Normalement ils vont nous livrer le bon catalogue cette semaine »

La situation

La story que présente le Product Owner est dépendante de la livraison d’un catalogue de données par une autre équipe. Cette équipe s’est engagée à livrer ce catalogue quelques jours après le début de l’itération, ce qui normalement laisse largement le temps à l’équipe de l’intégrer et de réaliser sa story.

Pourquoi ça sent mauvais ?

Les choses ne se passent généralement pas comme prévu. Commencer l’itération en dépendant du travail d’une autre équipe est un risque non négligeable car il équivaut à s’engager sur un périmètre que l’on ne maîtrise pas. Si l’équipe gérant le catalogue a un changement de priorité suite à un problème de leur côté ou si le catalogue qu’elle livre n’est pas de bonne qualité et qu’il y a d’innombrables allers-retours, alors c’est autant de chances de ne pas avoir le temps de terminer la story qui en dépend.

Concrètement on fait quoi ?

Dans le cas de dépendance entre équipes, il existe deux choix immédiatement applicables :

• Attendre que la dépendance soit livrée avant d’intégrer la story dans une itération : il suffit alors d’allouer un certain temps pour effectuer quelques tests afin de valider la qualité de la dépendance.
• Si le besoin d’avoir la fonctionnalité est urgent, intégrer physiquement dans l’équipe une personne de l’équipe gérant la dépendance : cette personne ne sera pas polluée par ce qu’il pourrait se passer dans son équipe initiale et sera donc totalement dévouée à la bonne réalisation de la fonctionnalité.

De manière plus générale, l’organisation est certainement à revoir. Y a-t-il besoin d’une équipe dédiée ou les compétences peuvent-elles être réparties au sein des équipes ? En résumé « component team » vs « feature team ». Une petite lecture sur Feature teams : au service de la transformation digitale permet déjà d’y voir plus clair.

« Si nous n’avons pas fini cette story c’est parce qu’on n’avait pas pu anticiper les nombreux impacts »

La situation

Nous avons tous déjà entendu ce genre d’explication pour justifier le fait qu’une story n’ait pas pu être terminée lors d’une itération. En plein développement, de gros impacts sont détectés et vont remettre considérablement en cause les développements effectués jusqu’à présent et par la même occasion le bon déroulement de l’itération.

Pourquoi ça sent mauvais ?

Afin de dissiper tout doute, si l’on considère cette situation seule, cela n’a rien d’un smell. Le travail d’analyse et d’estimation devant rester approximatif et ne devant pas trop peser sur le temps d’un sprint, une erreur peut alors survenir et cela est parfaitement acceptable. En revanche, si ces erreurs sont récurrentes, elles soulèvent un problème sur la manière dont l’itération est préparée mais également sur une probable méconnaissance de l’équipe sur son produit.

Concrètement on fait quoi ?

Lorsque ce genre d’erreur se répète, il faut changer la manière d’aborder le problème. Et quoi de mieux qu’une solution simple et radicale. Pour chaque story, prenez au maximum deux heures pour investiguer plus en profondeur, et ce, même si vous étiez sûr de vous concernant la solution à mettre en place. Cela peut prendre la forme de spike si c’est anticipé sur l’itération précédente, ou simplement d’une bande passante entre deux itérations.

N’oubliez pas qu’en fonctionnement normal, il est exagéré d’en arriver là, mais dans ce cas extrême, mieux vaut perdre une demi-journée à analyser, plutôt que deux jours à refaire un développement. Au fil du temps, l’équipe devrait mieux maîtriser son produit et ne plus être forcée à faire ce genre d’analyse.

Conclusion

Au travers de quatre situations, nous avons découvert comment le Sprint Planning pouvait révéler des pratiques contre-productives, mais également, comment il pouvait être une aide d’une grande efficacité pour améliorer de nombreux aspects de la vie d’une équipe. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci au sprint daily stand-up meeting.