Pourquoi je n'enseigne pas la gestion de projet.

Cette histoire commence au détour d'un café avec le responsable de la filière informatique d'une école d'ingénieur-e-s. Il m’informe ce jour-là qu'il prolonge d’une année mon mandat d’enseignement pour le cours de développement d’App Web. Nous discutons alors des différents nouveaux projets de l’école. Puis la conversation dévie sur les méthodologies agiles et les problématiques rencontrées dans la majorité des entreprises adoptant ces pratiques.

Le problème des méthodologies agiles

Les méthodologies agiles ne font pas l'unanimité: il y a trop de réunions, certains rituels semblent inutiles, il n'y a pas de cahier des charges, les user-stories sont mal documentées, les équipes passent du temps à surestimer des story points pour diminuer la pression qu'ils subissent par le management, etc.

Je ne partage pas cette vision.

Je pense que de nombreuses entreprises prétendent être "Agile" mais appliquent un processus de gestion de projet en cascade (waterfall) dont seule l'étape de conception du produit est Agile. Imaginez-vous dans la cuisine d'un restaurant, votre rôle consiste à ajouter petit à petit une pincée de sel sur le plat cuisiné juste avant qu'il soit apporté au client. Vous avez en théorie la possibilité de saler parfaitement le plat en fonction du client. Mais lorsque le plat est brûlé, vous ne pouvez plus agir sur la réussite de ce dernier et votre rôle dans la chaîne perd tout son sens.

De plus, beaucoup d'équipes pensent être "Agile" mais que trop peu appliquent et comprennent les 4 valeurs agiles qui sont pourtant les fondements sur lesquels reposent l’agilité. C'est comme si l'on s'efforçait d’inspirer et d’expirer sans comprendre les raisons pour lesquelles on le fait. Les rituels et pratiques agiles devraient être adoptés petit à petit et seulement si ceux-ci permettent d'appliquer les 4 valeurs tout en tenant compte du contexte de l'équipe Agile. Je suis intimement convaincu que c'est de cela que découlent les incompréhensions et les mauvaises applications des pratiques agiles dans de nombreuses équipes. Ces équipe se voient infliger des rituels et pratiques par leur management. Pourtant dans le manifeste agile, il n’est fait aucune mention de pratiques ou de rituels.

A ce moment-là de la discussion, je me dis que j'apprécierais beaucoup enseigner ces notions avec une vision différente de ce que l'on peut voir dans la conception logicielle et de ce qui est instruit dans les formations de gestion de projet.

Et si c'était possible ?

Le non étant toujours acquis, je me lance et je pose la question à mon interlocuteur. Contre toute attente, le responsable de filière m'informe qu'il cherche en effet quelqu'un pour le cours de gestion de projet. Sans attendre, je demande quelles sont les notions à enseigner et s' il y a un programme à suivre. Sa réponse dépasse toutes mes attentes.

Fais comme tu veux.

Je te donne carte blanche.

Comme le disait si bien Peter Parker, un grand pouvoir implique de grandes responsabilités. Je suis surexcité à l'idée de pouvoir construire le cours sans aucune restriction mais aussi désemparé par la quantité de choses que j'ai envie de partager: les méthodologies agiles bien sûr, mais aussi les approches lean, le Design Thinking, la vision et le cadrage produit, etc.

Par où commencer ? Et comment sensibiliser les étudiants sur des pratiques permettant de résoudre des difficultés auxquelles ils n'ont pas été confrontés ? Je sais... commençons par le marshmallow challenge!

Le marshmallow challenge

Cet exercice a été popularisé par Tom Wujec lors d'un Ted Talk. Il expose lors de cette présentation les résultats surprenants de ses recherches sur l'exercice du marshmallow challenge. Il s'agit d'un simple exercice de construction en équipe de 3-4 personnes, qui implique des spaghettis secs, un mètre de scotch, un mètre de ficelle et un marshmallow. La structure en spaghettis doit surélever le marshmallow le plus haut possible. Tom a effectué cet atelier avec de nombreuses personnes aux profils variés et en retire de surprenant résultats.

Qui construit la plus haute tour, avec ces ingrédients ? Et pourquoi un groupe inattendu fait-il toujours mieux que la moyenne ?

Cet exercice est excellent pour démontrer aux étudiants le conditionnement que l'on a tous lorsqu'on adresse une problématique complexe. On applique naturellement une approche orientée gestion de projet telle qu'elle est effectuée aujourd'hui dans bon nombre d'entreprises. J'ai animé cet atelier des dizaines de fois et le résultat est sans appel.

Au cours des 18 minutes à disposition, les premières sont consacrées à l'orientation au sein de l'équipe. Les membres échangent sur les idées et un leader émerge au sein de l'équipe. Les minutes suivantes sont dédiées à l'élaboration d'un plan accepté par tous (ou presque). Les rôles sont définis et l'équipe s'attèle à la construction de la tour. Les minutes passent et le stress commence à monter au fur et à mesure de l'exercice. L'assemblage touche bientôt à sa fin et dans les dernières secondes du temps imparti, l'équipe place soigneusement le marshmallow tout en haut de la structure.

Les dernières secondes, la majorité des équipes est confrontée à un petit problème... le marshmallow est plus lourd que prévu et les spaghettis plus souples qu'attendu. L'ensemble de la tour se brise et tombe sur la table.

Hauteur de la structure: 0 cm.

Tom Wujec explique lors de son Ted Talk que fort heureusement, les architectes réussissent plutôt bien cet exercice. De plus, il déclare qu'un groupe inattendu arrive à construire des tours majoritairement stables et intéressantes en termes de design.

Il s'agit des enfants de 2 à 4 ans ! Ceux-ci adoptent en effet une approche diamétralement opposée à celle des adultes.

Une approche itérative

Les enfants ne suivent pas un plan, ils construisent petit à petit. Dès les premières minutes, une structure simpliste supporte le marshmallow. Les enfants effectuent un prototype qu'ils améliorent au fur et à mesure. Ils entrent ainsi dans une boucle de feedback leur permettant d'apprendre à chaque essai effectué et ainsi d'agrandir continuellement la structure. Contrairement aux adultes, ils achèvent souvent l'exercice avec une tour qui tient debout et au-dessus de la moyenne.

Les enseignements tirés de cet exercice sont parfaits pour démontrer les problématiques que l'on retrouve dans la gestion de projet IT en waterfall. Et permettent d'introduire en opposition la gestion de produit.

La gestion de produit à la rescousse

La gestion de produit est une approche itérative se reposant sur les concepts issus du Design Thinking, de l'UX design, du Lean Startup et de l'Agilité. Dans son livre Inspired, Marty Cagan décrit 3 principes essentiels:

1. Définir et concevoir le produit en collaboration

Dans la majorité des cas, les idées sont imaginées par les parties prenantes ou l'équipe de vente de l'entreprise. Malheureusement, ceux-ci ne sont pas les meilleures sources d'idées de produits. Les designers et ingénieurs devraient être intégrés plus tôt dans le processus car ils sont la principale source d'innovation. En les faisant intervenir trop tard dans la conception du produit, ceux-ci se contentent de suivre le plan établi et tentent de sauver les meubles. L'entreprise en fait des mercenaires plutôt que des missionnaires.

En gestion de produit, l'équipe de conception se repose sur une problématique et une vision produit. L'équipe pluridisciplinaire est autonome et responsable de concevoir une solution dans le cadre défini par la vision produit et selon les expérimentations qu'elle a effectuées et qu'elle continue d'effectuer pendant la conception du produit. En se reposant sur une problématique, l'équipe peut identifier la meilleure solution et l'adapter en fonction des résultats de ses expérimentations.

2. Adresser les risques en premier

Dans de nombreuses entreprises, un projet démarre sur une idée et la construction d'un plan ou d'une roadmap pour concevoir cette idée. Parfois, une analyse de rentabilité ou étude de marché est réalisée, afin d'estimer les coûts et les revenus que l'on peut espérer. Très franchement, vu la façon dont ces études sont réalisées, on aurait tout aussi bien pu appeler le marabout qui laisse des prospectus dans les boîtes aux lettres du quartier. Les ressources mises en place sont rarement suffisantes pour pouvoir réellement répondre aux questions initiales. En définitive, c'est seulement à la livraison du produit que l'on déterminera le succès de la solution.

En gestion de produit, l'équipe de conception doit identifier la meilleure solution sur la base de prototypes permettant de confronter une multitude d'idées à la réalité du marché. Les équipes les plus expérimentées sont capables de tester plus d'une dizaine d'idées par semaine ! L'objectif de ces expérimentations consiste à valider dès le départ l'adoption par les utilisateurs, la viabilité financière pour l'entreprise et la faisabilité technique.

3. Se focaliser sur la résolution d'un problème

En gestion de projet, le processus est centré autour du projet: l'entreprise initie des projets, finance des projets, staffe des projets et finalement livre des projets. Avec cette approche, on met l'accent sur ce qui est délivré et non pas sur l'apport d'une solution à un besoin.

En gestion de produit, on va mesurer le succès de l'équipe de conception non pas sur le nombre de fonctionnalités réalisées, mais sur le résultat commercial. L'équipe doit s'assurer avant tout que la solution règle le problème identifié. Il est nécessaire de définir des objectifs sur quelques métriques clés et d'évaluer le succès du développement du produit sur l'atteinte de ces objectifs.

Engendrer un changement de l'intérieur

Contrairement à un projet, la gestion de produit n'a pas de limite dans le temps. L'équipe est constituée autour du produit qu'elle crée et qu'elle doit maintenir. Elle prend ses responsabilités du début à la fin et gère tout le cycle de vie du produit. Par ailleurs, la gestion de produit ne se limite pas à la création d'un produit tangible. Par exemple, la migration d'un data center est vue comme un projet, mais la nouvelle infra peut être vue comme un produit et conçue comme telle.

Voici les raisons qui m'ont poussé à enseigner la gestion de produit à mes étudiants dans le cours de gestion de projet. Je pense que ceux-ci auront tout le loisir de découvrir le fonctionnement interne et spécifique des entreprises dans lesquelles ils vont évoluer. J'ai espoir qu'en leur inculquant les principes de gestion de produit, ils puissent agir dans le futur pour améliorer les approches de conception de logiciel de l'intérieur et initier dans leur contexte la petite graine du changement. Le succès d'une équipe ou d'un produit au sein d'une entreprise peut rayonner suffisamment pour inspirer d'autres équipes à suivre le pas.

Vous l'avez compris, quand on se confronte à une problématique complexe, il faut y aller petit à petit.

--

Un grand merci aux relecteur-e-s: Laura Costa, Romain Felden, Arnaud Beguin, Jonathan Gianfreda et Paul Albuquerque.

À propos de moi

Actif dans différents domaines durant ces 10 dernières années j'accompagne mes clients dans la conception logicielle en facilitant l'intégration des technologies et approches méthodologiques.

Mes expériences pluridisciplinaires me permettent d’avoir un regard critique et transverse, dans l'intégralité du processus de conception logicielle.

https://craftslab.ch