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 sur les contextes dans lesquels 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. Ils ont une bonne compréhension du fleuve Saint-Laurent et du climat de Montréal et il est possible de prévoir l’utilisation future du pont.

Dans un contexte comme celui-là, 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 de gestion en cascade qui sont les mieux adaptées.

Une gestion en cascade est efficace dans les contextes certains et lorsque l’on n’a pas droit à l’erreur. On commence par une analyse préliminaire exhaustive, qui mesure toute la complexité et l’incertitude d’un problème, on 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 alors 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 informer 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 petit à petit vers la solution la plus optimale.

Cela dit, on a parfois l’impression que nos projets sont plutôt de nature certaine qu’incertaine, 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é

Du point de vue 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 effcacement.

Contextes similaires :
• le développement de produit ;
• l’amélioration des processus;
• la conception d’un bâtiment à l’aide du Building Information Modeling (BIM).

Ce qui est incertain, c’est la personnalisation pour le client. Plus les besoins du client s’écartent de la version standard 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 à la fois de 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 pour l’adaptation de ses processus, l’intégration de la plateforme, le 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 cofiguration 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 de 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 laissent 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.

Contextes similaires :
• un programme de formation ;
• un programme de gestion du changement ;
• le réaménagement d’un espace ;
• une stratégie d’embauche ;
• la rédaction d’un livre ;
• le développement d’un nouveau produit ;
• une stratégie de vente.

Un incrément de la campagne, qui teste 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 sciences de ma fille : incertitude sur l’expérience et la compétence

Dans le cadre d’un cours de sciences 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 était 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 s’est cependant avéré un échec. L’hélice qu’elle avait construite elle-même n’offrait aucune traction ; la voiture n’avançait pas du tout. Catastrophe, il ne restait plus que la fin de semaine pour modifier la voiture avant la compétition.

Contextes similaires :
• la recherche et développement ;
• l’adoption d’une nouvelle technologie.

Ensemble, nous avons d’abord changé le mode de propulsion en remplaçant 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é 2e, à 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.

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.

Contextes similaires :
L’intégration des biens livrables produits par différentes personnes ou équipes.

L’incertitude n’est donc pas toujours liée au domaine d’affaires ou technique, elle peut aussi être liée aux 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.

Et vous, comment faites-vous pour choisir entre les approches Agiles et en cascade dans vos projets ?

Cet article est tiré de la première édition du magazine Savoir Agile. Téléchargez votre copies afin de lire tous les articles.