Entrevue avec Maël Rieussec, Président, Agile Montréal
L'équipe de Homeric a eu la chance de recevoir Maël Rieussec, Président de Agile Montréal.
Merci Maël d’avoir accepté de nous rencontrer!
Pour commencer, peux-tu nous en dire un peu plus sur toi et ton cheminement. Qui es-tu, que fais-tu?
J'ai plus d’une vingtaine d’années d’expérience en T.I, avec un Bachelor en informatique de gestion à l’UQAM. J’ai commencé ma carrière comme programmeur, pour ensuite entamer une transition vers l’agilité en 2008 dans un rôle de Scrum Master. Depuis ce temps, j’accompagne des équipes de différentes tailles, dans différents domaines d’affaires et à différents paliers de gestion
J’ai vécu ma première transformation agile au sein de la compagnie pour laquelle je travaillais à l’époque. Nous avons eu la chance d’avoir un coach, Alain Chaput, qui a su bien nous guider dans cette aventure. Il m’a démontré les avantages de cette façon de penser. Ça me rejoignait beaucoup, je trouvais que c’était le “gros bon sens”. C’est surtout cet aspect qui m’a transmis la piqûre de l’agilité.
J’avais alors le double rôle de Développeur/Scrum Master, mais je me suis vite aperçu que je devais choisir entre les 2, car les niveaux d’interaction et domaines d’intérêt sont différents. Je suis reconnu pour avoir un bon contact humain, en plus d’être un bon vulgarisateur. J’étais également reconnu pour ma capacité à faciliter la communication entre les gens d’affaires et les équipes techniques. Ça m’a amené à choisir l’agilité pour la suite de ma carrière. Je me suis beaucoup auto-formé et à force de m’intéresser à tout ce qui touche à l’agilité, j’ai trouvé la Communauté Agile de Montréal. J’ai commencé par assister à leurs événements, avant de m’impliquer comme membre du Conseil d’Administration en 2014, et maintenant à titre de Président depuis 2021.
Peux-tu nous en dire un peu plus sur Agile Montréal et sur votre mission?
Agile Montréal est une OBNL qui existe depuis 2011 et qui a pour mission de promouvoir l’agilité dans la grande région de Montréal. On offre des événements de réseautage, plusieurs conférences par mois, un programme de mentorat pour les gens qui recherchent de l’accompagnement, etc. On est notamment reconnus pour nos événements signature (l’Agile Tour, le Devops Day, Agile Open, Spark the Change, etc.). Autre volet important, Agile Montréal supporte le démarrage de communautés de pratique en lien avec l’agilité. Si des personnes avec un intérêt commun ont besoin d’une structure, d’outils, de visibilité, etc, ils peuvent nous approcher et nous les accompagnerons dans leur mise en place et leur développement.
Tu as commencé à toucher à l’agilité en 2008. Peux-tu nous parler des différences que tu as pu constater entre cette époque et aujourd’hui?
Ce qui a beaucoup changé, c’est qu’aujourd’hui tout le monde parle d’agilité, mais sans nécessairement comprendre de quoi il est question. Beaucoup d’entreprises ont accaparé l’agilité en essayant de suivre des recettes toutes faites et de les amener à l’échelle. C’est presque devenu une méthode de gestion et/ou de livraison, avant même de comprendre le pourquoi et les valeurs en arrière de ça.
Personnellement, j’aime bien commencer la relation avec les personnes que j’accompagne par une discussion sur les valeurs et le pourquoi. Je leur demande: “Pourquoi voulez-vous être agiles? Qu’est-ce que vous essayez de régler? Parce que, peut-être que l’agilité, ce n’est pas la solution dans votre contexte, et c’est correct!”.
D’ailleurs, j’essaie d’être pragmatique, même au sein de la communauté. Il y a des agilistes purs et durs qui ne jurent que par ça, et qui considèrent le reste comme le diable ou comme dépassé, alors que ça n’est pas vrai du tout. Chaque contexte est particulier. D’où la nécessité d’être bien conseillé et accompagné.
Tu as accompagné beaucoup d’équipes à travers ta carrière. Quels sont les enjeux que tu constates le plus souvent?
J’ai notamment constaté que les problèmes les plus importants sont rarement au niveau des équipes. On peut assez rapidement déployer une mécanique simple et efficace au sein des équipes. L’important est de mettre en place un bon processus d’amélioration continue, et ça les met sur les rails pour progresser.
Par contre, là où j’observe beaucoup de résistance dans les transformations agiles, c’est surtout dans les autres sphères des organisations. Par exemple, du côté des ventes (NDLR: dans un contexte de vente de service logiciel). Si les équipes de vente ne comprennent pas bien l’agilité, ils ne sont pas capables de bien vendre ses avantages non plus. Les vendeurs vont signer des ententes qui ne sont pas alignées sur la manière de fonctionner des équipes. Ça fait en sorte que dès le jour 1, il y a un clash avec le client sur la gestion du projet, ce qui crée de l’insatisfaction et des frustrations des deux côtés.
Autre exemple: La planification des budgets. Une entreprise qui fait son budget sur 2 ans, sur 5 ans, alors qu’on demande aux équipes de s’inspecter en continu pour potentiellement changer de direction. On ne peut pas fonctionner efficacement et sereinement dans ce type d’environnement.
Lorsque les organisations ne sont pas agiles dans leurs fondamentaux, mais qu’elles veulent que leurs équipes travaillent de manière agile, ça crée un clash. Pour que ça fonctionne bien au niveau de l’équipe, il faut que l’agilité dépasse le cadre de l’équipe.
Tu me dis avoir constaté que plusieurs entreprises mettent en place des pratiques agiles, mais sans pour autant être agiles. Peux-tu élaborer?
J’arrive à le constater rapidement, juste avec leur façon de communiquer. Je vois s’il y a des concepts qui ne sont pas maîtrisés. Par exemple, l’adaptation au changement, la livraison de valeur, etc. Tu prends les 4 valeurs du manifeste agile, ou les 12 principes sous-jacents, et tu t’aperçois qu’ils en sont loin. Cas typique, ils prennent un BRD (Business Requirement Document) et ils essaient de l’exploser pour le faire entrer dans des tickets, et “ça y est, on est agiles parce qu’on fait des Daily Scrum et qu’on a des tickets Jira”.
Pour moi, l’agilité, c’est mettre le client au centre de toutes tes réflexions et de toutes tes décisions. Tu t’assures que chacune de tes activités crée de la valeur ajoutée pour le client. Ça ne doit pas être pour satisfaire tes patrons ou pour la rentabilité. Évidemment, la rentabilité, c’est ce qui est recherché en bout de ligne par les entreprises. Mais ça doit être la résultante, pas le point de départ. Premièrement, prends soin de tes équipes, qui vont prendre soin de tes clients, qui vont te payer et te générer ton succès financier. Pas l’inverse.
Pour bien fonctionner en agilité, ça prend une culture d’entreprise axée sur la confiance. Mais ce n’est pas toujours facile à créer ou à maintenir.
Il faut également que le contexte s’y prête. Les méthodologies agiles, Scrum par exemple, sont des cadres de travail qui s’appliquent bien au développement de produit, mais pas tant au développement de projet. Sans rentrer dans le débat de l’un vs. l’autre, c’est vrai que ça s’applique beaucoup mieux quand on a un produit et qu’on peut faire des expérimentations, aller chercher du feedback et le faire évoluer avec des petits incréments basés sur des retours d’expérience. C’est adapté aux domaines complexes, avec beaucoup d’inconnues. Il faut approcher ça avec une méthode scientifique. On va émettre une hypothèse, rouler une expérience, regarder le résultat, valider ou invalider les hypothèses, adapter le produit et recommencer. C’est ce qu’on appelle l’empirisme.
Pour construire le pont Champlain, les paramètres sont connus. C’est un projet compliqué, certes, mais il n’y a pas vraiment d’inconnues. On connaît les lois de la gravité, le prix des matériaux, les règles d’ingénierie, etc. On est mieux de ne pas le faire en Scrum. Le Waterfall est parfait pour ça. Mais si tu veux envoyer une fusée sur Mars, c’est beaucoup d’inconnues. Il est préférable d’utiliser des approches plus agiles, plus itératives pour éviter d’avoir un gros problème à la fin.
En tant qu’organisation, comment est-ce que tu sais que tu as réussi à bâtir une culture agile qui fonctionne?
Il faut regarder si les équipes (pas juste les équipes de développement!) ont mis en place un processus d’amélioration continue efficace. Est-ce qu’on cherche à s’améliorer? Est-ce qu’on apprend de nos erreurs? Selon moi, c’est là qu’est l’agilité. S'il n’y a pas de processus d’amélioration continue, il n’y a pas d’agilité. C’est fondamental. On doit constamment se demander ce que l’on peut faire aujourd’hui pour ne pas répéter les erreurs d’hier, et livrer encore plus de valeur à nos clients, pour le même temps ou le même budget
Évidemment, il faut s’améliorer sur les bonnes choses. L’amélioration continue des équipes doit notamment être alignée sur les principes agiles. La livraison est l’un des principes, mais la livraison sans création de valeur pour le client ou pour l’entreprise n’a pas de sens.
Un autre principe, la communication. Être honnête, transparent, se parler des vraies choses et ne pas laisser les choses s’envenimer. Même si ça n’est pas drôle d’admettre qu’on est en retard ou qu’on a fait une erreur, si on est honnête, qu’on le communique rapidement, on peut réagir et gérer en conséquence. Autre principe important, il est critique de créer un cadre avec des individus motivés, des gens qui comprennent ce qu’on essaie d’accomplir, pour qu’ils soient en mesure de prendre les meilleures décisions possibles dans le contexte et en fonction des informations qu’ils ont.
Un dernier mot?
On constate une corrélation importante entre la maturité agile des organisations et le bien-être des équipes.
L’entreprise doit créer un cadre de travail psychologiquement sécuritaire, qui part du management, et qui offre la possibilité à tous les membres des équipes de dire qu’ils se sont trompés sans passer pour des incompétents ou altérer leur image dans l’organisation.
Ça ne veut pas dire qu’on peut faire tout et n'importe quoi, mais c’est acceptable de se tromper si on met en place des processus d’amélioration continue pour s’améliorer. C’est de cette manière qu’une organisation pourra retirer un maximum des bienfaits de l’agilité.
Merci encore Maël d'avoir accepté de partager ton expérience avec nous! À très bientôt! 🙏😃
Ce sujet vous intéresse? Consultez notre série d'articles sur la mise à jour de 2020 du guide Scrum:
