Plusieurs mauvaises pratiques peuvent rendre une équipe moins efficace. D’abord faut-il être bien outillé pour les reconnaître. Les anti-patrons présentés dans cet article peuvent faire partie des pratiques actuelles de votre équipe. Dans cet article, d’une série de 2, nous explorerons les anti-patrons qui rendent la collaboration avec le Product Owner difficile et mettent en danger la réalisation du projet.
1. Être réfractaire au changement
Le meilleur moyen de tuer la créativité et l’efficacité d’une équipe est de la contraindre à respecter un cadre strict défini d’avance. Le Product Owner se doit d’émettre le besoin et d’être ouvert aux propositions de solutions que l’équipe lui apporte. Le meilleur exemple est la réécriture d’une application. Il peut être très tentant de calquer les mêmes fonctionnalités à nouveau et d’être non négociable sur la solution proposée, mais cela est contre-productif.
Une bonne équipe Agile saura tirer profit des opportunités techniques pour réduire le temps de développement et simplifier une fonctionnalité. Faut-il encore leur en donner l’opportunité en restant ouvert d’esprit.
2. Ne pas laisser le droit à l’erreur
Un des principes de base de l’Agilité est d’admettre que le développement informatique débute toujours par une hypothèse qui ne sera validée que lorsque la fonctionnalité sera disponible en production. C’est aussi un concept bien connu que l’erreur est source d’innovation.
À partir de ces préceptes, une équipe Agile, ainsi que les parties prenantes entourant l’équipe, doivent accueillir les erreurs comme des opportunités d’apprentissage. L’idée est de capitaliser sur des échecs rapides en validant rapidement nos hypothèses auprès des utilisateurs finaux et en se réajustant constamment.
3. Tout déléguer
Le rôle d’un Product Owner est de donner la vision à l’équipe ainsi que d’émettre les besoins des utilisateurs auxquels l’application doit répondre. Son apport au quotidien est primordial afin d’éviter que l’équipe de développement priorise ou prenne des décisions à sa place.
Il est tout à fait réaliste de demander à l’équipe de développement d’accompagner le Product Owner dans certaines de ses tâches (par exemple, la rédaction des items du carnet de produit), mais la responsabilité lui revient quand il est temps de valider, de décider et de trancher.
4. Ne pas se tenir à l’essentiel
Lorsqu’on commence le développement d’un besoin, d’une fonctionnalité, la créativité s’active et de nouveaux besoins émergent. Il peut être tentant de faire grossir la portée initiale de l’item sur lequel on est en train de travailler ou de la phase de projet en cours. Cependant, cela vient évidemment impacter les prévisions qui ont été émises quant à la réalisation de l’itération, au budget ou à la date de livraison du projet.
On peut aussi penser à plusieurs solutions pour répondre au besoin émis par le Product Owner . L’idée est de s’en tenir à la solution la plus efficace et la mieux alignée et de se concentrer sur l’aspect fonctionnel plutôt que de rechercher la perfection.
En développement informatique, il faut toujours garder en tête une vision MVP (Minimum Viable Product) et s’en tenir à l’essentiel. Quitte à créer des items dans le carnet de produit représentant ces nouveaux besoins et les identifier clairement comme étant hors de la portée initiale (ex : dans une catégorie post mvp dans le carnet de produit).
5. Avoir une solution ne répondant pas au besoin
Le développement informatique est un domaine complexe, il est normal de se tromper, mais la solution doit minimalement répondre au besoin énoncé, même si elle n’est pas parfaite ou optimale du premier coup.
Plusieurs techniques peuvent aider à s’assurer que la solution retenue par l’équipe réponde au besoin de l’utilisateur. Par exemple, on peut produire des maquettes et les faire valider par le Product Owner.
Personnellement, la technique que j’affectionne particulièrement, est de faire de petites démonstrations fréquentes pendant le développement, directement sur le poste du développeur au Product Owner. Le produit devient alors réalité et c’est un moment approprié pour recueillir les commentaires puisqu’il n’est pas trop tard dans le processus de développement.
Il est moins coûteux et frustrant de changer d’idée en cours de route qu’une fois la fonctionnalité déployée en production et l’itération terminée.
6. Considérer l’erreur de conception comme un bug
Il est important, autant pour le moral de l’équipe, la perception du client, les statistiques, de bien faire la part des choses entre une anomalie et une erreur de conception. Il faut admettre qu’il arrive, même aux meilleures équipes, de faire de mauvais choix de solution ou de mal interpréter le besoin, on parle alors d’une erreur de conception.
D’un autre côté, une anomalie est plutôt une fonctionnalité comportant une erreur de traitement rendant la fonctionnalité inutilisable. Par exemple, une validation manquante permettant de faire une transaction erronée qui se termine en erreur.
En résumé
Les anti-patrons énoncés ci-dessus sont tout de même monnaie courante dans une entreprise de service où le Product Owner est aussi notre client. Il fait partie de la culture de l’échec de se remettre sans cesse en question et de toujours tendre vers la perfection. Si plusieurs de ces situations s’appliquent à votre projet, rien ne sert de vous taper sur la tête, l’erreur est humaine. Maintenant que vous en êtes conscient, choisissez une action à prendre, celle qui paraît la plus prioritaire pour l’équipe et faites des tests. L’amélioration continue est aussi un processus itératif nécessitant de l’inspection fréquente et de la transparence.
Cependant, il existe bien d’autres anti-patrons qui sont un risque pour la réalisation du projet, et c’est dans la prochaine série de cet article que seront présentés ceux qui impactent dans l’organisation du travail en équipe.
