L'entreprise Agile avec Luc Taesch

L’entreprise Agile avec Luc Taesch

Si vous êtes dans l’informatique, vous avez très certainement entendu parler de loin en loin de la méthode de développement Agile. Pour un non-informaticien, l’Agile avec une majuscule n’est pas forcément quelque chose de familier. Cependant cela pourrait bien le devenir. Si, comme moi, vous n’êtes pas à proprement parler un IT guy, prenez donc une approche proactive et découvrez ce qui pourrait bien régir le développement de toutes sortes de produits très prochainement.

Regarder l’interview

Comment réussir dans un environnement chaotique ?

De tous les invités que j’ai reçu ici, Luc Taesch est peut-être le plus difficile à présenter. Il a codé et commercialisé son premier software à l’âge de 16 ans. Étudiant l’informatique, il est devenu ingénieur réseau, a eu l’occasion de développer des structures IT pour plusieurs banques de trading, a fait du conseil en management, s’est vu promouvoir directeur exécutif junior à 29 ans, et a beaucoup voyagé avant de s’établir comme consultant en management et coach Agile indépendant. Un chemin de vie qui n’aide guère à présenter Luc comme ceci ou cela exclusivement, étant donné qu’il a touché tant à l’ingénierie IT qu’au management et à l’aspect entreprise, mais qui lui a très certainement permis de vivre l’agilité avant d’en parler.

« Quand je suis devenu manager », dit-il, « je me suis rendu compte qu’il y avait un gros problème. Le management ne change pas vite du tout. La dernière frontière, c’est de changer le management, pas d’aller sur la Lune mais de transformer la façon dont les choses sont faites en informatique. » Autant les non-informaticiens tendent à percevoir le domaine comme évoluant très vite, autant Luc a vu au sein de plusieurs compagnies axées autour de l’informatique un réel problème de lenteur. Les livraisons y prendraient trop de temps ! Et ce, pas parce que les développeurs ou les ingénieurs IT seraient incompétents ou paresseux, mais à cause d’une façon de faire sous-optimale.

En tant que secteur professionnel, l’informatique a beaucoup évolué. Au départ, elle n’était qu’un support ou une aide pour d’autres secteurs. L’information n’existe qu’en faisant référence à quelque chose d’autre – comme le transport n’existe, à la base, que pour déplacer des biens produits par des entreprises d’autres domaines. Cependant, l’informatique a pris de l’ampleur, au point de devenir en elle-même un pivot. Beaucoup d’entreprises qu’on ne considère pas comme informatiques ont mis les contenus digitaux au cœur de leur activité, quand elles ne s’y consacrent pas à cent pour cent. Les librairies ont des e-boutiques et font des livraisons comme Amazon. Les vidéoclubs en dur sont devenus des Netflix. Comme le dit Luc, « la principale différence entre Amazon et Carrefour réside dans leur informatique ». Et ce qu’Amazon a construit pour elles-même a changé la vie de tous les autres.

Le monde est aujourd’hui interconnecté. Il fonctionne beaucoup plus vite et change à un rythme bien plus rapide que cela n’a jamais été le cas. Et tout laisse penser que cette tendance va encore s’accroître exponentiellement. Plus nous avons de possibilités et plus les choses deviennent chaotiques. Ici, Luc et moi sommes parfaitement d’accord.

Si vous avez une idée, vous pouvez sortir votre carte de crédit, acheter un peu d’espace sur Internet et créer un site web clé en main. En théorie, vous pouvez faire ça en vingt minutes, en pratique je dirais deux ou trois heures, vous existez sur Amazon et vous pouvez commencer à vendre. Il faut que vous sachiez le faire, bien entendu… mais l’important, c’est que vous n’avez pas besoin de négocier ou de discuter avec les managers de votre département IT pendant six mois avant de commencer.

La méthode Agile hors de l’informatique

Quand on a découvert la roue en Égypte, les innovations majeures étaient très rares. Il y en avait peut-être une tous les deux siècles. Quand la Renaissance est arrivée, des inventions qui changaient la donne apparaissaient peut-être tous les 50 ans. Au XIXe siècle et avant 1914, ces inventions apparaissaient désormais tous les 10 ans. Aujourd’hui, selon certaines estimations, un tel bouleversement aurait lieu toutes les 6 heures !

Prédire l’avenir devient difficile, voire irréaliste, lorsqu’aucune règle basée sur le passé ne débouche sur des prévisions exactes et que de nouveaux moyens disruptifs peuvent survenir n’importe quand. Les échelles de temps raccourcissent. Les projets sont redéfinis ou modifiés en cours de route pour s’adapter à telle ou telle nouveauté. C’est ici que la méthode Agile entre en jeu. En effet, l’agilité consiste à pouvoir résoudre des problèmes complexes dans un environnement particulièrement instable. En raison de son rythme d’évolution particulièrement rapide, le domaine informatique a été le premier réellement confronté à ce problème et à y répondre par l’agilité.

Qu’est-ce que la méthode Agile ? En général, on l’explique en la comparant à une autre méthode de développement plus ancienne dite « en cascade » (waterfall), où les étapes sont suivies selon un schéma rigide prédéfini. Plutôt que de reprendre cette explication classique, Luc préfère l’analogie suivante.

Avant 1908, si vous vouliez acheter une voiture, il vous fallait être riche. Quand vous achetiez, vous deviez attendre longtemps, des mois sinon des années, pour que votre voiture soit planifiée puis assemblée à la main. La Ford Company produisait un modèle standard, noir, pour tous ses clients. 2 millions de voiture étaient ainsi produites chaque année. Puis on s’est mis à diversifier les couleurs. Puis on a fait différentes séries. Puis, on a proposé des options. Les séries se sont aussi différentiés. Et ainsi de suite. Toyota a alors inventé la méthode Lean, caractérisées par de plus petit lots de production, des stocks juste-à-temps et une plus grande adaptation.

Ce n’est pas encore exactement de l’Agile, mais beaucoup de fonctionnalités importantes sont déjà là : le cycle de production de la voiture s’est raccourci, les boucles de rétroaction sont venues de plus en plus vite, de nouveaux modèles et de nouveaux projets ont dû être entrepris encore et encore. La plupart des entreprises automobiles sont ainsi passées d’un produit standard, à longue durée de vie, à un modèle de produit personnalisé à courte durée de vie.

Ce changement de paradigme a inspiré des chercheurs en sciences cognitives, qui comprennent le cerveau en le considérant comme un système de traitement de l’information semblable à un ordinateur, en les conduisant à examiner comment les humains découvrent et apprennent, tant à l’école qu’au travail ou ailleurs dans la vie. Ce qui, en retour, a amené de nouvelles idées sur la manière de faire en informatique.

La méthode et l’esprit Agile peuvent être résumés ainsi :

• Apprentissage continu. Vous découvrez de nouvelles choses tout le temps. Rien n’est jamais complètement statique ou gravé dans la roche. Il y a toujours quelque chose à comprendre.
• Les processus ne sont pas linéaires mais itératifs. Non seulement vous agissez plutôt que de recevoir passivement, mais quand vous agissez, il vous arrive obligatoirement de faire des erreurs ou de rencontrer des imprévus. Les deux sont un aspect normal du processus et vous permettent d’apprendre par expérience.
• Les choses doivent être faites petit à petit. Si quelque chose, projet, objet, construction… n’est pas flexible ou modulable, c’est qu’il est rigide et par conséquent fragile. Pour être Agile, vous devez diviser votre projet, ses éléments et ses étapes de réalisation en parties de petite taille. Vous pouvez alors reconfigurer les parties, en rajouter de nouvelles, en retrancher, en modifier, et ainsi de suite.
• Les clients et tous ceux qui déterminent le cahier des charges doivent garder un œil sur le développement.  Au cours du développement du projet, on fournit des petites parties, des prototypes, du partiellement achevé mais déjà livrable et ce bien avant la fin. Les clients ou autres parties prenantes doivent s’y intéresser, s’assurer que les produits développés correspondent bien à leurs souhaits et donner un avis en retour. Ils peuvent aussi changer certaines spécifications en cours de route. L’équipe de développement livre sur des cycles de temps courts et cela implique que les parties prenantes s’impliquent davantage qu’avant. En fait, les deux parties, spécificateurs et développeurs, doivent s’impliquer plus en communiquant davantage.

Au départ, Agile a été pensé et développé comme une méthode d’amélioration de la production. Les « agilistes » visaient à moins gâcher, à produire mieux et davantage, dans un environnement qui les obligeait à repenser et à refaire parfois des pans entiers de leur projet en cours de route. Cependant, au-delà de l’adaptation productiviste, l’adoption de la méthode Agile a eu d’autres effets : « les ingénieurs IT, les équipes de développement ont commencé à se sentir mieux », précise Luc, et les clients ont eu l’impression de prendre un rôle beaucoup plus important quand on a commencé à les consulter plus souvent.

Si vous cherchez un peu, vous trouverez très facilement des compagnies IT qui ont délaissé l’approche en cascade et « agilisé » leurs méthodes de développement. Mais quid des compagnies hors IT ? Est-il possible pour quelqu’un qui rend des services en dur d’agiliser ses approches et d’en tirer un avantage réel ? Selon Luc, oui. Et mon invité de poursuivre en donnant deux exemples connus mais souvent oubliés :

1. Amazon. Dans les années 1990, l’actuel géant de l’e-commerce était un petit réseau de distribution de livres. Amazon stockait des volumes et les envoyait aux clients finaux. Une activité plutôt simple. Puis, avec la bulle Internet, non seulement Amazon a beaucoup grossi, mais l’entreprise a aussi retravaillé son site en permanence pour l’adapter aux volumes de commande et aux intérêts des clients. En changeant sa structure informatique, Amazon a aussi changé son business model en passant de la seule distribution à une activité de plus en plus orientée services. Les développeurs Amazon ont inventé des programmes de gestion de contenus que l’entreprise s’est mise à vendre comme services intégrés. Par la suite, Amazon n’a cessé de s’aventurer dans de nouveaux territoires, et livre aujourd’hui de la nourriture. Les artisans de ce succès ont l’esprit Agile depuis le tout début : ils ont transformé leurs produits, encore et encore, bien au-delà des limites habituelles de chaque domaine.
2. Netflix. Au départ, tout comme Amazon, Netflix se contentait de gérer et de distribuer des objets physiques, en l’occurrence des DVD. Internet n’était qu’un moyen de recevoir les commandes client plus vite. Et puis, l’aspect physique de l’activité a été complètement abandonné. Netflix est passée au tout-digital, avant de se mettre à négocier des parts en coproduction sur les contenus distribués ainsi que des contrats d’exclusivité. « Avant, la majorité des employés de Netflix étaient dans la logistique. Ils bougeaient des cartons. Maintenant la plupart des gens de chez Netflix sont des informaticiens. »

Les deux entreprises ont montré leur agilité en sachant glisser de changement en changement quand il le fallait. Ce que Ford a fait sur plusieurs décennies, Amazon et Netflix l’ont fait encore bien plus et bien plus vite. À force de redéfinitions, de restructuration et de modifications de leur activité, ces entreprises ont aujourd’hui tout juste un écho de leur champ d’activité originel – et quand vous êtes Agile, cet écho n’est même pas une nécessité.

Avant, se souvient Luc, j’avais ma musique sur des cassettes. Ensuite j’ai eu des CDs. Puis je me suis mis à copier numériquement mes CDs, puis à télécharger des fichiers musicaux. Ensuite, mon téléchargement est devenu beaucoup plus simple via iTunes, et maintenant je suis sur Spotify. Pour le prix d’un seul album CD par mois, Spotify me permet d’accéder à des titres illimités et de découvrir des nouveautés. Spotify créée pour moi une liste de découvertes de la semaine, soit un produit unique, éphémère et personnalisé, fait pour moi seulement. Au bout d’une semaine, ce mélange disparaît pour être remplacé par un autre.

Agilisez-vous !

Une start-up est obligée d’avoir l’esprit Agile. Elle commence avec une idée. Le ou les startuppers doivent avoir des compétences au départ, mais ils doivent aussi apprendre sur le terrain. S’ils parviennent à se maintenir en jeu, à apprendre ce qu’il faut et à rester financièrement hors de l’eau, ils vont peut-être se rendre compte qu’ils pourraient faire un meilleur produit que celui qu’ils imaginaient au départ. Et là, le cycle de développement reprend… « Ce n’est pas forcément ajouter des options », précise Luc. « Ça peut consister à changer le cœur même de votre activité. Mettons, vous commencez à développer une voiture, ensuite vous passez à un scooter, et au bout d’un moment vous vous retrouvez à vendre un vélo électrique avec une appli. »

Puis, en continuant sur le même exemple, peut-être que la startup va complètement délaisser la fabrication du véhicule, la délocaliser en Chine et consacrer ses propres efforts de développement à son application smartphone et à ses ventes. Cette longue série de changements et d’itérations survient parce que les options disponibles, le marché et les dernières technologies varient très vite.

Néanmoins, les startups ne sont pas au cœur de l’activité de Luc. Ces petites entreprises sont plus qu’Agiles. Elles sont « lean » et utilisent une approche allégée pour amorcer une activité, ce qui leur permet de changer complètement d’activité tous les 3 à 6 mois.

En tant que consultant, Luc travaille avec des compagnies plus larges et moins flexibles – des entreprises habituées aux budgets établis pour un an et qui trouvent l’approche lean inapplicable, ou la réduisent à une méthode purement axée sur la productivité. Si vous êtes plus gros, voire beaucoup plus gros qu’une startup,

vous ne pouvez pas changer toute votre chaîne de production et l’activité de vos employés aussi vite. Plus important, même si vous pouviez, vous devriez aussi votre conception de la gestion, et c’est là le problème le plus sérieux. Le management est généralement organisé comme une structure de contrôle et non de régulation. Vous n’allez pas dire pas à votre contrôleur de budget qu’il doit réviser ses vues, particulièrement quand votre bonus et les sien dépendent de la cible a un an durement négociée il y a six mois pendant plusieurs semaines.

Ce qu’une startup peut faire presque instinctivement, une grande entreprise ne peut pas le faire sans entrer dans un casse-tête insoluble. Un système qui héberge des milliers d’employés, voire plus, ne peut pas se réorganiser tout le temps. Or, cette vaste structure empêche l’innovation et l’agilité. « L’essentiel de L’Europe travaille toujours avec un système contrôlé centralement pour les grosses entreprises… mais dès les années 1950, on avait déjà mesuré que les grandes entreprises centralisées produisaient moins et réussissaient moins que les plus petites, parce que le processus de production devient rigide et ne plus plus évoluer assez vite. » Si l’informatique était restée sous un tel contrôle, elle n’aurait jamais pu évoluer comme elle l’a fait.

Comment agiliser une organisation beaucoup plus grande qu’une startup ?

Luc distingue entre ce qu’il appelle l’agilité à l’échelle, qui consiste à avoir beaucoup d’équipes Agiles, et l’agilité d’entreprise, où il s’agit d’agiliser toute la superstructure. Le premier type d’agilité serait largement plus facile à réaliser que le second. Et les deux sont encore souvent confondus. Si vous êtes une entreprise d’un millier de personnes, vous pouvez agiliser assez rapidement des équipes de 4 à 10 personnes. Il est toujours possible d’embaucher des coach Agile ou même d’appliquer des recettes simplifiées comme SCRUM, « assez basique, mais les principes clés sont ici », ajoute Luc. « Et puis les valeurs commencent à changer. C’est plus qu’un slogan. En 6 à 18 mois, les développeurs faits à l’agilité gagnent un nouvel état d’esprit, et ils l’expriment eux-mêmes. »

Cependant, même si vous agilisez vos équipes, « la pyramide du management au-dessus ne sera pas transformée pour autant ». Les directeurs ne la vivent pas. L’esprit Agile viendrait beaucoup plus facilement aux développeurs qu’à ceux qui les contrôlent.

Les gestionnaires au sommet de la pyramide doivent partager leurs stratégies, infuser les développeurs avec elles, plus directement qu’auparavant. Les interactions doivent être aplaties. Mais les hauts dirigeants doivent également accueillir les points de vue divergents de la part des acteurs et en faire sens, transformant ainsi des signaux faibles en opportunités, plutôt que de le supprimer.

Les cadres moyens, dit Luc, sont les plus touchés par l’agilité. Cela ressemble a un paradoxe : un manager est supposé être en position de contrôle, alors qu’une équipe Agile est censée être autonome. Que peut faire le manager alors ? Pour quelqu’un qui est censé être (toujours) responsable, comment peut-on être manager sans contrôle et porter une responsabilité quand on n’a plus le pouvoir ?

Luc me rassure, le manager Agile ne perd pas tout son pouvoir. « Son équipe peut être autonome, elle n’est pas indépendante. » Cependant, le rôle du manager change à coup sûr. Le chef d’équipe doit développer deux nouveaux rôles : d’abord, celui de coach, en sachant écouter, inspirer, soutenir, et aider les développeurs et les ingénieurs à se transformer ; ensuite, celui de relais de vision, qui peut s’engager dans la vision partagée et également y contribuer. Sa posture sera « réceptif, assertif et bienveillant ».

Tout cela tend à compliquer les interactions et oblige l’entreprise à passer par une période d’adaptation potentiellement désordonnée. Auparavant, la chaîne de management était plus simple ; désormais, les employés, mais aussi les managers et les parties prenantes, doivent parler davantage, partager davantage, et expliciter davantage ce qu’ils veulent ou font.

Selon Luc, le plus gros défi consiste désormais à passer de l’agilité à l’échelle à l’agilité d’entreprise. « Si les développeurs IT s’agilisent, cela change leurs relations avec les autres départements et avec les autres entreprises aussi. » Les fournisseurs – internes et externes –, les clients, tous se retrouvent dans une position d’implication accrue. Ils doivent rejoindre la boucle et prendre le rythme Agile eux aussi. Qui que vous soyez, « vous ne pouvez pas devenir Agile tout seul ».

Trois conseils pour le futur

Inutile de le préciser, l’esprit Agile est fait spécialement pour parer à toute éventualité. Il pourrait sembler redondant de demander à Luc s’il a, à ce propos, des conseils supplémentaires à donner. Cela dit, dans un monde où tant de choses changent si vite, je mets un point d’honneur à ne pas varier sur ma façon de terminer un entretien – en demandant à mon invité ce qu’il conseillerait pour être prêt. Et en effet, Luc a encore quelques conseils à donner. Les voici :

1. Méditez. L’agilité implique d’être à l’écoute de soi-même et des autres. L’écoute de soi vient en premier. « Méditer, ce n’est pas se dire “je médite” mais se laisser méditer… Méditez n’est pas une action. C’est comme quand vous bronzez, vous ne vous dites pas “je bronze”, vous allez là où le Soleil brille et vous vous laissez bronzer. » La méditation serait d’autant plus nécessaire dans un monde qui nous veut « obsédés par les smartphones, la connectivité, les news d’untel et untel, l’actualité ». Parfois, il s’agit simplement de se déconnecter pour pouvoir se retrouver soi-même. « C’est une capacité à développer. »
2. Cultivez l’empathie et l’authenticité. Une fois à l’écoute de vous-même, vous pouvez passer à celle des autres. « Il s’agit de s’exprimer honnêtement, en étant assertif et pourtant attentif… c’est assez basique en fait, mais déjà beaucoup mieux que juste dire ce que vous pensez, sentez, jugez, aller avec d’autres qui pensent, sentent, jugent pareil, et vous sentir mal à l’aise avec ceux qui perçoivent différemment. »
3. Co-construisez ! « Être à l’écoute de soi et d’autrui, c’est joli, mais vous êtes quand même supposé faire quelque chose. Comment construire une vision, un rêve, et le faire partager ? Et puis que ça donne quelque chose avec des plans et des tâches ? Le thème est à la mode et il y a beaucoup de théories douteuses, mais je conseillerais de l’approfondir quand même. »

Pour en savoir plus sur les travaux de Luc Taesch en tant que coach et expert Agile, retrouvez-le sur son site personnel et professionnel, Taesch.com.