Pitié, ne construisez pas le nouveau pont Champlain en Agilité…

L’Agilité est maintenant un incontournable du développement de services et de produits. Incontournable ? Vraiment ? Peut-être pas toujours. Les approches Agiles ne sont pas la réponse à tous les maux, et il est intéressant de se questionner dans quels contextes elles sont les plus pertinentes.

Pourquoi construire un pont à l’aide d’une approche Agile n’est pas une bonne idée ?

Parce qu’un pont est une construction monolithique, dont la portée est peu flexible et où la valeur n’est obtenue qu’une seule fois, à la fin de sa construction. C’est pourquoi on aurait tendance à construire le pont à partir d’un plan détaillé qui assure l’intégrité de la structure.

De plus, il est possible de cerner l’incertitude associée au pont Champlain sans avoir à le construire. Je crois qu’en 2016 les ingénieurs maîtrisent bien la construction d’infrastructures. Nous avons une bonne compréhension du fleuve Saint-Laurent et du climat de Montréal et qu’il est possible de prévoir l’utilisation future du pont.

Dans un contexte comme celui-ci, où les informations initiales sont fiables, où il n’y a rien à apprendre pendant la construction, où la portée du projet est peu flexible, ce sont les méthodes en cascade qui sont les mieux adaptées.

Une méthode en cascade est efficace dans les contextes certains et dans ceux où on n’a pas le droit à l’erreur. Cela commence par une analyse préliminaire exhaustive, qui mesure toute la complexité et l’incertitude d’un problème, se continue par la conception détaillée du produit, prenant en compte tous les aspects du problème. Une fois la solution conçue, le risque devient maintenant de livrer cette solution efficacement, dans le respect d’un budget et d’un échéancier. Pour cela, on utilise un plan par activité, comme un diagramme de Gantt, coordonnant l’effort de tous les contributeurs avec la plus grande efficacité possible.

À quels contextes les méthodes Agiles sont-elles les mieux adaptées ?

Il n’est pas toujours possible de réduire l’incertitude d’un problème par la conception d’une solution détaillée. Lorsque les informations de départ ne sont pas suffisantes et que le produit est suffisamment malléable pour permettre l’expérimentation, les approches empiriques, comme les méthodes Agiles, sont les plus efficaces. Les méthodes Agiles abordent l’incertitude d’un problème par la production rapide d’un incrément, le plus révélateur possible, pour valider ou infirmer une hypothèse importante. Cette validation faite, on peut ensuite passer à une prochaine hypothèse avec plus de certitude. D’un incrément à l’autre, on tend de plus en plus vers une solution la plus optimale possible.

Cela dit, on a parfois l’impression que nos projets sont plutôt de natures certaines qu’incertaines, comme celui du pont. Voici quelques perspectives personnelles qui bousculeront peut-être vos convictions et vous aideront à mieux choisir entre une approche en cascade et une approche Agile.

L’implantation d’un ERP (incertitude sur la faisabilité)

De la perspective du fournisseur, l’implantation d’un progiciel de gestion d’entreprise (ERP) est probablement plus certaine qu’imprévisible, car celui-ci maîtrise parfaitement les rouages de sa plateforme. Un fournisseur aurait donc tendance à proposer une approche en cascade pour livrer efficacement.

Ce qui est incertain, c’est la personnalisation pour le client. Plus les besoins du client s’écartent de la version vanille de la plateforme, plus il serait intéressant de valider certaines hypothèses. Par exemple, est-ce qu’il est vrai que la nouvelle plateforme sera plus utile que l’ancienne ? Que les nouveaux tableaux de bord seront plus fiables ? Que l’efficacité des opérations sera améliorée ?

Configurer une seule opération utile ou fréquente permettrait d’à la fois valider que la plateforme ERP et l’environnement du client s’intègrent bien et que les avantages attendus sont bien obtenus.

Les résultats de cette expérience permettraient au fournisseur de mieux estimer la personnalisation requise et au client de mesurer le rendement de son investissement ainsi que l’effort requis à l’adaptation de ses processus, à l’intégration de la plateforme, au nettoyage de ses données et à la gestion du changement à organiser.

D’une opération à l’autre, le client et le fournisseur amélioreraient leur collaboration et tendraient ensemble vers la configuration la plus optimale qui soit.

Une campagne de marketing (incertitude quant à l’impact sur le marché)

Parce que l’image est précieuse et les campagnes publicitaires coûteuses, les entreprises n’accordent pas beaucoup le droit à l’erreur aux agences. En conséquence, les agences peuvent croire qu’une conception en cascade leur permettra de créer des campagnes à grand déploiement, qui ne laisse rien au hasard. Malheureusement, il est très difficile de prévoir l’impact réel d’une campagne et la réception du public cible.

Un incrément de la campagne, testant les messages auprès du marché cible, pourrait réduire l’incertitude liée aux concepts importants de la campagne et permettrait, un incrément à la fois, de produire la campagne la plus percutante possible.

Le devoir de science de ma fille (incertitude sur l’expérience et la compétence)

Dans le cadre d’un cours de science au secondaire, ma fille de 13 ans devait construire un véhicule qui avance seul avec des moyens de traction ou propulsion. Le professeur a guidé la classe à concevoir leur véhicule avec une approche en cascade : d’abord apprendre les concepts physiques de transfert d’énergie (ressorts, engrenages, essieux), ensuite dessiner un véhicule utilisant ces concepts, prévoir l’achat des matériaux et exécuter les étapes de construction. La dernière étape serait le concours en classe du véhicule parcourant la plus grande distance.

Ma fille, qui avait une confiance complète dans son plan, a été surprise quand je lui ai proposé d’essayer la voiture avant le concours :

Pourquoi ? Le professeur a validé le plan et je l’ai bien respecté.

L’essai fut cependant un échec. L’hélice qu’elle avait construite elle-même n’offrait aucune traction ; alors, la voiture n’avançait pas du tout. Catastrophe, il ne restait plus que le week-end pour modifier la voiture avant la compétition.

Ensemble, nous avons premièrement changé le mode de propulsion : nous avons remplacé l’hélice par un système à élastique. Notre incrément de base assurait maintenant une première distance pour le concours. Ensuite, nous avons fait des modifications d’un incrément à l’autre pour faire avancer le véhicule de plus en plus loin. Cela donnait l’option à ma fille d’arrêter la construction de la voiture dès qu’elle serait satisfaite de la performance. Résultat, le véhicule a terminé 2^e, à la grande satisfaction de ma fille.

Normalement, l’ingénierie est une science plutôt exacte, et il est possible de croire que la conception du véhicule aurait pu suffire. Cependant, le manque de connaissance de ma fille favorisait une approche par incréments, qui lui garantissait une certaine performance pour le concours.

Un travail de session en équipe (incertitude sur la dynamique d’équipe)

Avez-vous de bons souvenirs de vos travaux de session en équipe ? Il n’est pas rare que les étudiants, habitués de travailler en solo, n’aient pas une bonne dynamique lors de travaux d’équipe. Souvent, une personne se retrouve responsable de l’intégration de tous les contenus la veille de la date de remise. Du café et des nuits blanches sont parfois requis pour y parvenir.

Dans ce contexte, une approche par incréments permet non seulement à une équipe de réduire l’incertitude autour du produit final, mais surtout d’améliorer la collaboration entre les membres la constituant, en comparant fréquemment leur contribution à celle des autres.

L’incertitude n’est donc pas toujours liée au domaine d’affaires ou technique, elle peut aussi être liée à nos processus de travail.

Agile ou pas Agile, telle est la question

Les approches Agiles ne sont pas la solution à tous les problèmes. Lorsque les informations initiales sont suffisantes, lorsque le produit n’est pas très malléable ou lorsque nous n’avons pas de souplesse pour l’expérimentation, les approches Agiles sont moins performantes.

Par contre, un domaine dont la complexité nous semble certaine peut s’avérer plus hypothétique que prévu :

• Est-ce que la valeur d’affaires ou l’impact de notre produit est garanti ?
• Maîtrisons-nous le domaine technique du produit ?
• La dynamique de l’équipe sera-t-elle efficace ?

Lorsque des incertitudes ne peuvent pas se vérifier par l’analyse, mais plutôt par l’expérimentation, les méthodes Agiles sont alors très pertinentes.

Utiliser ou non une méthode Agile n’est donc pas, selon moi, un choix par défaut ; c’est plutôt une décision à prendre avant chacun de nos projets.