Comment (ré)concilier Agilité et e-Commerce ?

La transparence qu’elle crée entre les parties prenantes limite la friction et la frustration, tout en permettant une résolution plus en amont des problématiques, tandis que l’autonomie apportée à l’équipe technique la rend plus responsable et plus apte, sur le long terme, à s’engager sur les produits livrés.

Mais alors, quel est le problème ?

De nombreux projets e-Commerce sont freinés par des contraintes, comme un budget fixe, une deadline imposée ou encore un cahier des charges figé. Alors comment l’équipe technique peut-elle estimer ses user stories au fil des sprints, si tout est déjà gravé dans le marbre ? Cela nuit à la notion même de souplesse métier et risque de conduire indirectement la gestion du projet vers un cycle en V et ainsi de provoquer la frustration des équipes. Une autre erreur fréquemment commise par des équipes novices est de penser que réaliser un projet de « manière Agile », implique que ce dernier se déroulera sans embûche.

Or, il ne suffit pas de dire que l’on pratique l’Agilité pour faire un projet agile. Il dépend de certaines conditions préalables telles que l’engagement et la maturité de toutes les parties prenantes, aussi bien celles de l’équipe projet que celles inscrites dans votre écosystème (supérieurs hiérarchiques, chefs d’équipe, autres équipes etc.)

Faut-il pour autant renoncer à l’Agilité dans les projets e-Commerce ?

Rassurez-vous, il est tout à fait possible de pratiquer l’Agilité au sein des projets e-Commerce ! Le premier réflexe à adopter est d’analyser au plus tôt, dès le kick-off du projet si possible, les frictions encourues et trouver une solution à chacune d’entre elles. Cela peut passer par une formation à l’Agilité d’une ou plusieurs personnes, l’établissement par écrit des grands principes qui accompagneront l’équipe de production (autonomie, transparence, engagement, …), ou encore la désignation d’un Scrum Master (dans le cas de SCRUM) présent et expérimenté pour le début du projet, si l’équipe en ressent le besoin.

OK, mais j’ai un cahier des charges à respecter…

S’il est vrai qu’une équipe technique a besoin de visibilité sur le projet pour mieux adapter les développements, gardons malgré tout à l’esprit qu’un besoin exprimé en début du projet a de fortes chances d’évoluer au fil des développements. Un besoin peut se préciser, ou au contraire être dépriorisé, voire même… abandonné. Pourquoi ne pas simplement donner les grandes lignes du besoin pour que chacun ait une vision globale du produit fini, et attendre que le besoin se précise et que le projet avance suffisamment pour établir des spécifications concrètes ? Ce parti pris évite à l’équipe de défaire pour refaire, ce qui induit également des dépassements de budget et de délai.

En travaillant en Agilité, il n’est pas nécessaire de cadrer la totalité des fonctionnalités dès le début du projet, de manière précise et définitive, afin de pouvoir suivre l’évolution du besoin. A noter également qu’un développeur qui passe du temps sur une fonctionnalité et voit celle-ci abandonnée quelques semaines plus tard par l’équipe métier, peut subir une frustration qui entame sa motivation pour les sprints à venir. Garantir la motivation et la mobilisation des effectifs est nécessaire pour assurer le déroulement du projet dans les meilleures conditions.

J’ai aussi une deadline et un budget…

Une chose est sûre, l’équipe technique sera toujours la mieux placée pour estimer les différentes fonctionnalités à développer. Plus elle communiquera avec le Product Owner, plus elle gagnera en autonomie, affinera ses estimations, et maîtrisera sa vélocité (capacité à produire). Pour le métier, l’important est de prioriser au maximum les différentes fonctionnalités. Il doit remettre sincèrement en question la nécessité de la présence de chacune d’entre elles dans la première version du produit fini.

Il est préférable de déprioriser les idées les moins matures et de prévoir une V2 dès le début du projet pour étaler certains besoins moins capitaux après la première mise en production d’un MVP fonctionnel, voire même de revoir et adapter certaines spécifications en fonction des retours de la première version. C’est un pari gagnant-gagnant : il apporte un gain de temps à l’équipe technique en lui permettant de peaufiner ensuite sa conception technique, la documentation, les tests unitaires, les performances, etc. et garantit aussi un meilleur time-to-market au client.

Ma DevTeam / Mon Product Owner ne me comprend pas

Il est important qu’à chaque sprint, chacun connaisse son rôle, ses responsabilités, ainsi que les responsabilités des autres membres de l’équipe. L’équipe de développement doit faire preuve d’engagement, de transparence et accompagner le Product Owner lorsque le besoin s’en fait sentir (rédactions de specs, soutien technique, tests). Pour un Product Owner, faire le lien entre l’équipe métier et l’équipe technique n’est pas une position facile à tenir sur toute la durée d’un projet. Il doit se rappeler que c’est l’équipe de développement qui dispose de la meilleure connaissance du projet, il doit donc faire preuve d’écoute, respecter les décisions prises et mises en garde soulevées par l’équipe.

Et cela passe aussi par savoir dire non aux équipes métier si cela s’avère nécessaire. Enfin, il est toujours bon de rappeler que l’équipe de développement et le Product Owner sont membres de la même équipe projet, et font avancer la barque ensemble. Sans l’un, l’autre ne peut rien faire.  

Si un budget fixe, un cahier des charges figé ou encore une deadline imposée peuvent apparaître comme des freins à l’application des principes Agile, il ressort en pratique que ces trois contraintes s’allègent souvent le long du projet grâce à la maturation de la réflexion métier et à l’engagement des équipes. Les connaître et les anticiper permettent donc d’aborder plus sereinement le projet et de mettre le cap vers le succès, en toute Agilité !