Les projets Deeptech présentent des contraintes spécifiques pour les équipes Agile
Lorsqu’à l’hiver 2001, 17 experts en développement logiciel se retrouvent à la station de Snowbird, dans l’Utah, c’est le doute qui prévaut.
Leur objectif ? Trouver une alternative aux gestions de projet en cycle en V, trop rigides. Poser les bases d’une méthode pour des environnements incertains, pour tirer parti des « surprises » plutôt que de les subir et toujours rester en phase avec les attentes des clients / utilisateurs.
Pour cela, il faut tirer la quintessence de leurs approches respectives — alors empirique — set opérer une synthèse. Comme le relate Alistair Cockburn, un des participants : « I personally didn’t expect this particular group of agilites to ever agree on anything substantial. ».
Pourtant, de cette rencontre naîtra le « Manifeste Agile ». Tellement « substantiel » que, presque 20 ans après, il est devenu une référence en matière de programmation… et au-delà !
En effet, sous les noms de « Agile », « Test & Learn », ou encore « Effectuation », la démarche s’étend au-delà de l’univers logiciel, notamment dans les projets Deeptech.
Sous les noms de « Agile », « Test & Learn », ou encore « Effectuation », la démarche s’étend au-delà de l’univers logiciel, notamment dans les projets Deeptech.
La Deeptech désigne les projets d’innovation reposant sur une technologie de rupture. Par exemple, une nouvelle technologie de stockage de l’électricité par air comprimé, un électrolyseur pour créer des postes à souder à base de flamme hydrogène ou encore un procédé d’irradiation ionique qui démultiplie la capacité de stockage des disques durs. Avec des caractéristiques propres : le développement technologique prend la forme d’un très long tunnel. La réussite de ces projets est assez binaire : quand tout repose sur la technologie, « ça marche ou ça ne marche pas ! ». Et contrairement aux innovations purement digitales, la Deeptech mobilise des concepts mécaniques, électroniques, issus des sciences du vivant, etc. avec des réalisations industrielles / hardware contraignantes et d’emblée gourmandes en capital.
Appliquer les méthodes Agile aux projets Deeptech ne va donc pas sans difficultés.
Appliquer les méthodes Agile aux projets Deeptech ne va pas sans difficultés.
Nous présentons 10 leviers pour les circonscrire, à travers une série de quatre épisodes.
Episode 1 – On voudrait des équipes projet unies autour d’une vision commune et éviter que la roadmap technologique soit dissociée des enjeux business, marketing, etc. … mais il existe souvent une frontière marquée entre des équipes de développement très pointues et des profils plus généralistes, qui présentent les produits au marché sans forcément maîtriser tous les sous-jacents technologiques.
Episode 2 – On voudrait avoir très vite un produit à tester, mais ce dernier peut être très long à réaliser dès lors qu’il faut lever des verrous technologiques et/ou réglementaires.
Episode 3 – On voudrait montrer ce produit à des clients potentiels, mais ces derniers font partie d’un écosystème complexe de clients finaux, distributeurs, partenaires, et restent souvent mal connus ou peu accessibles.
Episode 4 – Enfin, on voudrait modifier le produit, pivoter en fonction des réactions, mais modifier une roadmap de développement hardware est infiniment plus compliqué que dans l’univers logiciel, où quelques lignes de code peuvent suffire à changer de business model.
Et pourtant…
De nombreuses missions effectuées aux côtés d’ingénieurs, chefs de projet et entrepreneurs pionniers nous montrent qu’appliquer l’Agile à la Deeptech est largement possible. Pour limiter les contraintes initiales, nous avons identifié dix leviers, issus de nos propres retours d’expérience ou bien de témoignages publics.
De nombreux exemples nous montrent qu’appliquer l’Agile à la Deeptech est possible.
Ni martingale, ni « checklist » à valider, nous sommes convaincus que ces leviers ouvriront des perspectives au chef de projet Deeptech soucieux de mener des développements vraiment itératifs et d’en récolter les bénéfice, en tant que startup ou grand groupe.
EPISODE 1 : assurer une coopération permanente entre les équipes « techniques » et « business »
En Agile, le rôle de chacun est souvent plus vaste et moins clairement délimité que dans les méthodes traditionnelles. Et pour cause : c’est le résultat et l’objectif du projet qui priment sur les prérogatives. Ceci suppose de partager une vision et une compréhension commune sur tous les aspects du projet (technologie., business, etc.), au-delà de son périmètre initial.
Or, dans la Deeptech, la complexité technologique engendre souvent une dichotomie entre les fonctions technique et business. D’autant plus que ces dernières sont souvent issues du monde de la recherche, avec une expérience moindre sur les aspects commerciaux.
La complexité technologique engendre une dichotomie entre les fonctions technique et business.
Alors, quand il faut expliquer que tel laser pulsé possède quatre longueurs d’onde et produit des impulsions de 200 picosecondes avec des cadences de répétition de 20Mhz, cela peut donner lieu à de beaux moments de partage… ou bien à des dialogues de sourds !
Pour l’ingénieur, si un client remet en cause l’aspect novateur de tel ou tel produit, c’est qu’il ne l’a pas compris. Par exemple, parce que le commercial n’a pas donné la bonne explication…
Pour le commercial, les fonctionnalités annoncées tardent toujours à être réalisées. Et encore, quand elles fonctionnent !
Alors, comment faire pour que les équipes appréhendent les aspects technique et business dans un seul et même élan ?
Levier n°1 : utiliser la gamification pour que les équipes d’ingénierie intègrent les enjeux business… et réciproquement
Notre client était un équipementier dans l’énergie, fournissant des systèmes de contrôle-commande (les capteurs et logiciels qui servent à piloter les centrales électriques).
Notre mission était renforcer le plan commercial pour les activités de maintenance et de mise à niveau des systèmes. Nous avons rapidement constaté que les équipes commerciales et techniques ne parlaient plus le même langage, avec un impact très négatif sur la performance de la division : les clients (les directeurs de centrales électriques) attendaient plus de maîtrise technique de la part des commerciaux. Quant à l’ingénierie, elle percevait mal l’impact « business » des développements demandés par les équipes commerciales (par exemple, pouvoir se « brancher » sur des systèmes concurrents. C’était un puissant levier pour élargir son marché).
Notre proposition a été d’organiser des ateliers de formation conçus à partir de méthodes de gamification (l’apprentissage par le jeu).
Ainsi, les équipes R&D ont endossé l’habit du commercial dans des jeux de rôles, face à des clients particulièrement retors et même en l’espèce un peu caricaturaux. Pas si facile d’aller sur le terrain !
Quand aux équipes de vente, nous leur demandions, à partir d’un jeu de construction simplifié, de reconstruire l’architecture d’un système de contrôle-commande. Etre impliqué dans la résolution d’un problème limite les injonctions un peu faciles comme « Cela doit fonctionner, c’est ton rôle, pas le mien ! ».
Levier n°2 : s’appuyer sur le « chef de produit » pour conserver une vision partagée, y compris dans les équipes de grande taille
Les projets Deeptech partent souvent d’une équipe unie par une vision autour de laquelle ses membres se sont rassemblés. Chacun apporte ses compétences propres (technique, marketing, finance, etc.), mais au service du projet envisagé comme un tout.
Or, quand ce dernier grandit, on finit par se spécialiser. Chacun, dans son périmètre (plutôt « technique » ou « business »), recrute ses propres équipes et le risque est grand qu’une division des rôles bien comprise se transforme peu à peu en travail en silo.
C’est à ce moment-là que la fonction de « chef de produit » prend tout son sens. Quelqu’un qui, tel un chef d’orchestre, est capable de saisir ensemble toutes les facettes du projet : technique, fonctionnalités, marketing, etc.
Le chef de produit est comme un chef d’orchestre.
Mais il ne suffit pas de créer la fonction pour que la magie opère. Tous les chefs de produit ne se valent pas.
Parmi tous ceux que nous avons rencontrés, les plus efficaces étaient capables de trouver un équilibre entre une démarche formelle (réunions d’alignement, communications sur le produit, etc.) et le fait d’installer un état d’esprit, une culture de collaboration, moins immédiatement visible, mais dont les effets se feront sentir tout aussi sûrement.
Bien sûr, une grande curiosité et d’une double compétence technique / business sont des pré-requis non négociables.
Enfin, il ne s’agit pas forcément d’un « poste » mais plutôt d’un « rôle », éventuellement exercé à temps partiel.
Levier n°3 : regrouper l’équipe sur un plateau projet
A l’heure du nomadisme digital, regrouper des équipes durablement en un même lieu peut apparaître comme un retour en arrière.
Et pourtant, ce sont les projets les plus innovants qui recourent à de tels dispositifs, avec un impact significatif sur l’efficacité des équipes.
Les projets les plus innovants mettent en place des plateaux projet.
Un « plateau projet » est un lieu multidisciplinaire sur lequel travaille l’ensemble de l’équipe, parfois élargie aux principaux prestataires. Simple, mais extrêmement efficace pour assurer des interactions fluides sur la base d’une vision commune.
Le développement du concept car Symbioz par Renault, relaté dans l’Usine Digitale, nous en donne un excellent exemple, avec :
- Une communication plus fluide : informelle, débarrassée de la peur de déranger, elle fait place aux rencontres impromptues entre des profils de spécialités différentes, à la sérendipité.
- Un fort sentiment d’appartenance…
- … potentiellement renforcé par la présence d’une maquette physique : à la fois outil technique pour tester rapidement de nouvelles options / solutions et emblème fédérateur du groupe.
Levier n°4 : faire que chaque collaborateur se sente d’abord membre du projet plutôt que d’un département fonctionnel (ingénierie, commerciale, etc.)
En cet hiver de décembre 2016, l’heure est grave : au volant de son véhicule Tesla, un entrepreneur français de la Silicon Valley — Loïc le Meur — constate que des emplacements prévus pour la recharge sont occupés par des véhicules qui ne font qu’y stationner, alors même que leurs batteries sont déjà chargées.
Quelques heures plus tard, il tweete son désarroi à Elon Musk qui promet de prendre des mesures…
Et il le fait ! Six jours plus tard, une tarification incitative est mise en place, renchérissant le tarif du stationnement sans recharge.
A cette occasion, beaucoup ont commenté la capacité de l’entreprise à écouter ses clients et répondre à leurs attentes.
Mais le plus étonnant est — nous semble-t-il — sa capacité à résoudre rapidement un problème qui nécessite la coordination d’un nombre important de départements : le département commercial pour concevoir une solution, le département IT pour mettre à jour les algorithmes de tarification, le département juridique pour les enjeux contractuels, etc.
Pour réaliser cela, les entreprises comme Tesla, mais aussi ING ou Spotify, ont des modes d’organisation très différents de ceux rencontrés classiquement dans les grands groupes.
Les collaborateurs font partie de groupes de compétences, les « Chapitres », mais c’est au sein de « Squads » qu’ils exercent ces dernières. Les Squads sont des équipes rassemblant les différentes compétences (conception, production, etc.) chargées d’une mission long terme. Par exemple, faire de Spotify la meilleure plateforme de streaming musical.
C’est donc la dimension « projet » / « mission » qui est première dans l’organisation. Le rattachement à une entité / un département par type de compétence est secondaire. Ceci permet une coopération plus fluide parce que le dénominateur commun d’une Squad est la fonctionnalité visée, le but, l’ « output ».
Ces pratiques sont une source d’inspiration non négligeable pour les grands groupes technologiques, qui doivent en permanence faire collaborer l’ingénierie, les équipes de développement logiciel, le département commercial, etc.
Dans le deuxième épisode de cette série, nous verrons comment produire rapidement un produit à tester dans les projets Deeptech.