Anthony
22 sept. 2023
Aujourd’hui la question de l’utilisation des méthodes agiles pour les implémentations Salesforce ne se pose plus guère, tout du moins lorsque celle-ci est de taille suffisamment conséquente pour être traitée en plusieurs itérations. Il faut dire que la philosophie de la plateforme Salesforce s’y prête bien : une plateforme robuste mais évolutive, orientée no code, qui permet de mettre en place une approche d’implémentation basée sur des itérations rapides et une bonne réactivité aux besoins changeants des utilisateurs. On peut ainsi facilement éprouver des processus métiers sur la base du standard et délivrer rapidement de la valeur et rajouter progressivement de la complexité et de l’automatisation via des développements spécifiques.
Cependant avant de se lancer dans l’agilité tête baissée il y a quelques pré-requis et bonnes pratiques à respecter que nous allons traiter dans cet article.
L’agile est il fait pour mon projet ?
J’ai assez coutume de dire que l’on confond trop souvent agilité et contorsionnisme. Je me souviens d’un client qui m’avait dit au détour d’un nième revirement sur un projet vendu au forfait (et donc sur un mode, certes itératif, mais borné) : « mais on est en mode agile, on peut changer d’avis quand même ? » . Oui bien sur, sauf que changer d’avis dans un périmètre figé contractuellement ça s’apparente plus à de la contorsion que de la flexibilité.
Cela veut-il dire qu’agilité et mode forfaitaire sont incompatibles ? Pas forcément, les budgets open bar ça n’existe de toute façon nul part. Mais à budget égal, il sera plus sain pour la réussite d’un projet agile de partir sur un mode capacitaire dans une temporalité donnée que sur un périmètre fonctionnel et technique figé. Pourquoi ? Tout simplement parce que s’engager sur un périmètre fonctionnel figé ajoute du stress dans la relation entre les parties prenantes, et que cette relation sera majoritairement basée sur le contractuel : le métier va essayer de faire passer un maximum de besoins tout en restant dans le cadre contractuel et l’équipe de build va au contraire tout faire pour minimiser les écarts de périmètre par rapport aux hypothèses prises en avant vente. Deux objectifs antinomiques, alors qu’une équipe agile est supposée avancer dans le même sens et dans un objectif commun : celui de délivrer rapidement un produit qui correspond aux attentes des utilisateurs finaux et qui leur apporte le plus de valeur possible.
En résumé, à moins d’avoir une idée très détaillée de ce que l’on va construire (c’est à dire disposer d’un backlog de user stories plutôt mature construit lors d’une bonne phase de cadrage préalable), mieux vaut plutôt constituer une bonne équipe et embarquer celle ci sur un nombre borné de sprints.
L’autre case à cocher avant de se lancer est de valider avec votre organisation (Direction métier, DSI) , si celle-ci n’est pas déjà dans le cadre d’une transformation agile, qu’elle en est sensibilisée aux concepts, qu’elle y adhère et qu’elle jouera le role de sponsor. Sur ce point l’accompagnement d’un coach agile pour favoriser l’acculturation et l’adhésion s’avère indispensable. Si vous ne sentez pas d’adhésion, on ne va pas se mentir, mieux vaudra s’en tenir à une méthodologie plus classique.
Human after all …
A l’heure ou l’intelligence artificielle toque à la porte des Administrateurs et Développeurs, on aurait tendance à penser que la place de l’Humain dans les projets informatique va se réduire comme peau de chagrin. Je ne suis pas de cet avis, et bien que nos outils et façon de travailler vont se trouver profondément bouleversés dans les années à venir, il est plutôt rassurant de voir que le succès d’un projet repose avant tout sur des valeurs humaines. A savoir :
Une équipe harmonieuse
Alors oui, dit comme ça on a l’impression de sortir un poncif mais quand voit le nombre de projets qui se plantent pour cause d’erreurs de casting, autant rappeler les fondamentaux. La dream team sur un projet agile c’est avant tout :
Un(e) vrai(e) scrum master
Et pas un PMO. Le scrum master il est vraiment là pour faciliter le travail et surtout la progression de l’équipe. C’est lui ou elle qui va faire sortir les axes de progression et d’action en retrospective, qui va vous aider à trouver votre vélocité, qui va vous challenger sur vos définitions de ce qu’est une User Story prête à être développée et User Story terminée. Il saura faire de la calinothérapie lorsque l’équipe en a besoin mais aussi rappeler les règles en cas de laisser aller. Il est là avant tout pour favoriser l’émergence de la parole.Si votre Scrum Master se contente juste de planifier les cérémonies agiles et prendre des notes, virez le !
Un PO qui connait bien son métier et son produit :
Sans lui pas de vision du produit final, pas de priorisation, pas de challenge des besoins métiers. C’est le casting le plus compliqué. Comme il doit parler à la fois au métier et à l’équipe de build, il doit à la fois maitriser le métier et les concepts de la plateforme Salesforce. Souvent on a soit l’un, soit l’autre. Alors la bonne idée c’est le duo : un PO qui connait le métier sur le bout des doigt et un PO adjoint qui maitrise la plateforme et les clouds déployés.
Une équipe de Build pluridisciplinaire qui aime jouer aux chaises musicales.
Cela ne veut pas dire qu’elle est composée uniquement de « moutons à 5 pattes » ou de « couteaux suisses », mais la clé d’une équipe performante réside dans le partage des savoirs, des compétences et des responsabilités. Bien sur que l’on aura besoin d’expertise d’un bon architecte ou d’un bon tech lead sur un projet. Mais attention à ne pas concentrer toute l’expertise du projet auprès de quelques uns. Déjà parce que cela crée des goulets d’étranglements (oh zut on ne peut pas tester cette US sur ce sprint parce que le tech lead a la gastro et c’est le seul qui maitrise la livraison en environnement de test …) , ensuite parce que cela peut générer des frustrations au sein de l’équipe, les juniors se voyant systématiquement confier les tâches les plus basiques ou peu valorisantes et les experts les plus gratifiantes. Aussi, même si tout le monde ne peut pas tout faire (on ne va pas non plus demander à un business analyste de coder), il faut toutefois développer au sein de l’équipe une appétence à sortir de sa zone de confort, bien évidemment sous l’égide des sachants. Et cela va bien au delà de la montée en compétences techniques : un développeur doit pouvoir aider à valider une US si le PO manque de temps pour terminer ses tests ou parler en direct avec le métier s’il a un doute sur un cas fonctionnel qu’il est en train de coder. Un Business Analyst doit pouvoir packager et livrer une US si le tech lead est affairé à débugger un problème en production … La bonne nouvelle c’est que c’est gagnant / gagnant. Pour l’équipe c’est passionnant et valorisant, et pour le client c’est l’assurance d’en avoir pour son argent. Parce qu’une équipe qui travaille en harmonie et en pleine responsabilité délivre bien plus et délivre bien mieux qu’en mode client / fournisseur.
La communication et la transparence, clé de voute de la sérénité
Et oui la communication dans un projet, c’est comme dans un couple, si c’est bancal, si on se cache des choses, ça ne fonctionne pas. Si au sein de l’équipe la communication est généralement plutôt fluide (les différentes cérémonies agiles facilitent grandement cette communication), c’est entre l’équipe et le métier qu’il faut soigner la communication. Et là il ne faut pas hésiter à tout dire, tout expliquer. La sprint review reste trop souvent cantonnée à la démonstration de cas fonctionnel, mais derrière cette démo, il y aura aussi des US techniques, des études, des imprévus. Et bien parlez en, en vulgarisant bien évidemment les sujets techniques. Expliquer tout ce que l’on a fait pendant un sprint, même ce qui n’a pas fonctionné permet de montrer la face immergée de l’iceberg et ainsi éviter des ressentis du type « ben dis donc ils ont pas produit grand chose sur ce sprint » ou bien « ça avance pas des masse ».
Ne pas hésiter également à donner de la visibilité sur ce qui arrive dans les prochains sprint en prenant les pincettes de rigueur (car le contenu des sprints à venir n’est jamais gravé dans le marbre) et en mettant en lumière les prochaines features à anticiper en terme de change management coté métier.