Dans mon précédent exposé, j’ai amorcé une réflexion sur les habitudes problématiques qui peuvent s’installer au sein d’une équipe Scrum et mener, inéluctablement, à un échec de livraison. Je souhaite ici approfondir cette thématique, en me concentrant cette fois sur les dynamiques opérationnelles au sein de l’équipe.
Ces dynamiques sont tout aussi cruciales que l’excellence technique des membres de l’équipe. Même avec des professionnels hautement qualifiés, certains aspects peuvent compromettre leurs efforts vers la perfection. Cela ne relève pas tant de leur responsabilité individuelle, mais plutôt des décisions de gestion de projet et de la capacité à doter l’équipe de processus adaptés, soutenant une intention claire et des activités prévisibles.
Équipes aux compétences cloisonnées
Imaginons une équipe composée de développeurs compétents, autonomes et capables de tenir leurs engagements en livrant le contenu du sprint dans les délais impartis. Même dans ce cas de figure idéal, l’équipe aura des difficultés à gérer un backlog de fonctionnalités en constante augmentation si les compétences sont strictement sectorisées entre les membres.
Exemples Concrets
- L’équipe compte un ou deux ingénieurs DevOps chargés de modifier les pipelines automatisés ou de gérer les services de la plateforme, tandis que le reste de l’équipe n’a aucune expertise dans ce domaine. Dès lors, les discussions sur ces sujets lors des cérémonies Scrum s’avèrent chronophages pour la majorité, qui se contente d’assister sans participer. Réciproquement, le développeur DevOps n’aura que peu d’intérêt pour les récits axés sur les fonctionnalités, et le temps des réunions sera ainsi en partie gaspillé.
- Un seul expert en bases de données est présent dans l’équipe. En fonction de la complexité et de l’usage des solutions de données, cette personne peut être surchargée de demandes, sans pouvoir les honorer dans les temps, compte tenu des priorités. Pire encore, d’autres tâches seront retardées, dépendantes des données fournies.
- Lorsqu’un produit est principalement orienté vers le backend, le seul développeur frontend est présent par précaution, même si des modifications mineures de l’interface sont parfois nécessaires. De nouveau, les cérémonies Scrum sont souvent inutiles pour ce membre, dont les compétences se limitent au front-end.
Conséquences
Dans tous ces cas, on constate une perte de temps ou une incapacité à répondre à la demande en attente. Des membres de l’équipe empêchent les autres de commencer de nouvelles tâches, ou l’efficacité globale de l’équipe Scrum est réduite en raison du temps non exploité durant le sprint.
L’équipe est toujours composée du même nombre de développeurs. Il n’est pas évident que certains membres ne peuvent pas prendre en charge certaines tâches, car trop spécialisés. Ils ne peuvent donc pas aider leurs collègues, malgré leur disponibilité, et même si les priorités le justifieraient.
Le Product Owner a des difficultés à construire un contenu de sprint pertinent, car il doit constamment anticiper le nombre de personnes capables de travailler sur chaque tâche, et si des tâches similaires sont ajoutées au sprint en même temps. Au final, la capacité de l’équipe est dépassée, même s’il y a des personnes disponibles, mais non compétentes pour ces tâches.
Comment surmonter ce défi
Il s’agit d’un défi à relever, et les chefs de projet doivent être conscients des options. Le choix se résume à :
- Disposer de nombreux développeurs full-stack capables de gérer un contenu plus large, mais sans expertise approfondie dans divers domaines. La livraison peut être rapide, mais la qualité peut en souffrir.
- Privilégier des experts dédiés pour chaque technologie, en acceptant la limitation de contenu et en travaillant sur un contenu mieux adapté. L’équipe peut ainsi approfondir les sujets et créer des réalisations de qualité, mais la progression peut être plus lente.
Un Product Owner déficient
Ce point n’est pas forcément un « problème de processus » à proprement parler, mais je le traite comme tel car la création de user stories solides peut être vue comme un processus que l’équipe doit maîtriser et adapter au rythme de l’équipe de développement.
Le terme « déficient » ne fait pas référence aux connaissances de la personne, mais à la capacité du Product Owner à fournir des user stories que les développeurs peuvent comprendre et qui ont une cohérence avec la roadmap du produit. Ces deux aspects sont indispensables à la réussite d’une équipe Scrum.
Si les user stories manquent de détails pour que les développeurs comprennent clairement l’objectif, la valeur fonctionnelle ou les exigences techniques, deux scénarios peuvent se présenter :
- Les développeurs créent un produit différent de celui souhaité par le Product Owner. Ce problème est difficile à déceler pendant le sprint, car le PO n’a pas toujours la possibilité de suivre la progression des tâches en détail, et attend souvent un résultat « magique ».
- Les développeurs passent trop de temps à clarifier les user stories et à les discuter, plutôt qu’à les mettre en œuvre. Cela se traduit par des appels supplémentaires, des négociations répétées et un report du travail vers la fin du sprint. Les estimations initiales deviennent alors caduques, et les tâches ne peuvent être clôturées dans le sprint et sont reportées aux sprints suivants. Cette situation peut se répéter à l’infini.
Moment d’introspection
Il est souvent difficile de l’admettre, mais le Product Owner doit prendre le temps de réfléchir, d’examiner les user stories et de les confronter à la vision de la roadmap produit, si un lien cohérent existe. Dans le cas contraire, il s’agit de la première chose à résoudre. La solution est parfois d’admettre que le Product Owner est trop éloigné de l’équipe et de son objectif.
Dans ce cas, la partie Product Owner de l’équipe doit être remaniée. Une option possible, même au prix d’une augmentation des coûts, est de faire appel à un analyste métier orienté vers le contenu de l’équipe plutôt que vers les aspects commerciaux (puisque l’équipe a déjà un Product Owner).
Processus de test sans calendrier précis
Qu’advient-il lorsque les activités de test ne sont pas limitées dans le temps pendant un sprint Scrum ?
A première vue, cela peut sembler une bonne chose pour une équipe agile / scrum. La flexibilité est toujours bienvenue et flatteuse vue de l’extérieur.
Mon expérience montre que cette liberté engendre plus de chaos que de flexibilité. Il ne s’agit pas pour autant de créer des « cascades au sein du sprint » avec des phases de test dédiées suivant la phase de développement. Ce n’est absolument pas la bonne approche. Vous pouvez en savoir plus dans mes articles sur la stratégie de test Scrum et le cycle de vie des tests agiles.
Il est possible de garder une certaine flexibilité et d’adapter le calendrier de test aux besoins de l’équipe et du produit. Toutefois, il faut poursuivre deux objectifs principaux :
- Minimiser l’impact des activités de test sur la progression du développement.
- Assurer une activité solide (contenu), fiable (régularité) et répétée (prévisibilité) au sein de l’équipe.
Si ces conditions sont respectées, l’équipe s’adaptera naturellement au processus et le calendrier de livraison ne sera pas affecté par des activités de test prolongées et imprévues.
Au final, la publication du sprint doit être fiable et prévisible, ce qui m’amène au dernier point de cet article.
Processus de publication non défini
Ce point semble évident pour toute équipe Scrum. Pourtant, c’est aussi l’un des processus les plus sous-estimés.
Il est courant qu’une équipe Scrum annonce que la publication aura lieu après chaque sprint, sans pour autant avoir mis en place un processus solide. Dans les faits, cela se traduit par de nombreuses activités chaotiques et imprévues au moment de la publication. Tout le monde est soudainement occupé par des « tâches de publication » et personne ne peut se concentrer sur le développement de nouvelles user stories. Les indicateurs de sprint sont faussés et la publication ressemble à une activité aléatoire vue de l’extérieur (par exemple, du client).
Les membres sont tellement focalisés sur le backlog, le contenu du sprint, le développement, les tests et la présentation des résultats, qu’ils en oublient que le sprint suivant est déjà en cours et qu’ils perdent du temps.
Quel est le bon moment pour publier ?
Quand l’équipe doit-elle effectuer la publication proprement dite ? C’est la seule chose qui compte en fin de compte.
La réponse à cette question réside dans le processus, si vous en avez un. En fonction de :
- la complexité du contenu produit par l’équipe,
- la durée d’un sprint,
- le nombre de composants concernés,
- le nombre d’utilisateurs et leurs attentes,
un processus de publication régulier doit être défini et suivi à l’avenir. Les règles exactes peuvent être flexibles. Toutefois, comme c’est le cas pour les activités de test, il est essentiel de mettre en place une habitude solide, prévisible et planifiée pour des jours précis.
Options envisageables
Les formes possibles d’un tel processus pourraient être :
- Tester les fonctionnalités du sprint en cours durant le sprint suivant et publier le contenu à la fin de ce sprint (une fois le test terminé). Chaque publication n’inclura donc pas le contenu du dernier sprint, mais celui des 2 sprints précédents.
- Le dernier sprint avant la publication est toujours dédié au test du contenu des deux sprints précédents.
- Cela ne signifie pas que le développement s’arrête durant le « sprint de test ». Simplement, le contenu développé pendant ce sprint ne sera pas inclus dans la prochaine version.
- Si les tests automatisés sont suffisants, la publication peut avoir lieu à la fin de chaque sprint. Dans ce cas, le processus doit être rigoureux et des personnes dédiées doivent se concentrer à 100 % sur cette activité pendant quelques jours. Cette activité ne doit pas impacter le reste de l’équipe de développement.
- Il est également possible de publier une fois par mois ou une fois tous les N mois, si cela convient aux utilisateurs finaux. L’effort de test sera plus important pour chaque sprint (car le contenu de chaque version sera plus important). Cela signifie moins d’activités répétées, ce qui peut être avantageux. L’équipe pourra ainsi créer plus de fonctionnalités entre les publications, malgré la cadence plus lente de leur mise en production.
Il est moins important de choisir un processus qu’une routine solide et durable.
Vous pouvez également consulter ce guide sur le processus et les pratiques de gestion des versions.