Adopter l’Agilité avec la Métagilité (Avec David Bishop d’Agile Worx)

Lisez la transcription :

Nous testons la retranscription de nos podcasts par un logiciel. Merci de pardonner les éventuelles fautes, l'outil n’est pas toujours parfait.

Ben Aston : Alors, laissez-moi deviner, vous travailliez en mode Waterfall, et ça ne fonctionnait pas, puis vous avez essayé l’Agile et, là encore, ce n'est pas vraiment concluant.

Alors maintenant, vous mélangez les deux. Vous avez un peu d’Agile, un peu de Waterfall et vous cherchez à parsemer le tout de trouvailles. Restez à l’écoute de ce podcast sur la métagilité. Vous apprendrez sûrement deux ou trois choses sur la façon dont un guide agile peut permettre d’allier le meilleur des deux mondes.

Merci de nous écouter. Je suis Ben Aston, fondateur du Digital Project Manager. Bienvenue sur le podcast DPM. Notre mission est d’aider les chefs de projet à réussir, et d’aider ceux qui gèrent des projets à mieux les livrer. Nous sommes là pour élever votre pratique de la gestion de projet. Découvrez thedigitalprojectmanager.com pour en savoir plus sur nos formations et nos ressources réservées aux membres. Ce podcast est sponsorisé par Clarizen, le leader des logiciels de gestion de projets et de portefeuilles pour les entreprises. Rendez-vous sur Clarizen.com pour plus d’informations.

Aujourd’hui, je reçois David Bishop. Le Dr David Bishop est technologue, consultant, entrepreneur en recherche et formateur, avec plus de 25 ans d’expérience dans les secteurs des télécoms, du transport, des administrations et des services publics. Il est PDG et fondateur d’Agile Worx, LLC. Vous pouvez visiter leur site sur Agile-worx.com. Leur entreprise propose des outils logiciels de gestion de programmes et projets, de la formation et du conseil. Il est aussi l’auteur de Metagility : Gérer le développement agile pour un avantage concurrentiel. Merci beaucoup d’être avec nous, David.

David Bishop : Merci de m’accueillir.

Ben Aston : J’aimerais explorer cette idée de bâtir un cadre à partir de rien. Pouvez-vous nous parler de votre parcours et de ce qui vous a amené à penser qu’il fallait un nouveau framework ? Quelle est l’expérience qui vous a conduit à ce point ?

David Bishop : Bien sûr. J’ai travaillé dans le développement technologique depuis environ 25 ans, principalement en tant qu’architecte et ingénieur système, en développant des solutions avec de nouvelles technologies. Dans le secteur informatique, mais aussi en IATA, dans les cellulaires, les télécoms, etc. Comme vous l’avez mentionné, il y a une dizaine d’années, j’ai rejoint une entreprise profondément investie dans l’IoT industriel. L’un de leurs objectifs était d’adopter les méthodes agiles.

Ben Aston : D’accord.

David Bishop : La raison ? Leurs clients l’exigeaient, car ils évoluaient dans un secteur émergent – ou plutôt basé sur une technologie nouvelle. Ils cherchaient à s’intégrer à ce secteur, où de nombreux concurrents développaient de nouvelles technologies smart grid avec toutes sortes de communication RF.

C’était tout l’enjeu de cette technologie. Ce fut une succession de tentatives pour adopter l’Agile, c’était vital pour sortir leurs produits plus rapidement. Ils ont engagé de nombreux consultants hautement qualifiés, sans succès. Échec sur échec. J’étais intégré à cette équipe, à la fois pour développer les produits et pour accompagner l’adoption Agile. Je me suis dit qu’il devait exister une autre façon de faire.

Pourquoi autant de consultants brillants échouaient-ils ? J’ai réalisé qu’aussi efficace que soit l’Agile — et cela a bien sûr connu de grands succès — il y a aussi des limites, notamment avec les équipes distribuées, les grands groupes, les environnements de développement complexes ou les produits compliqués. Cela représente de vrais obstacles pour appliquer l’Agile pur.

Ben Aston : Tout à fait. Parlez-nous de votre implication dans ces projets. J’aimerais savoir, concrètement, quels étaient les défis au quotidien lors de l’implémentation Agile ? Quels étaient les signaux d’alerte qui vous indiquaient que quelque chose n’allait pas ?

David Bishop : Il y avait une résistance énorme, et pas juste une résistance symbolique, non, de véritables rejets, des plaintes que le processus ne fonctionnait pas, ne pouvait pas fonctionner. Et cela car on était dans un environnement de systèmes embarqués. Ils développaient des produits IoT industriels, qui ne sont pas que du logiciel, mais des appareils. Ces appareils réunissent du hardware, du firmware et du software, souvent réalisés par des équipes ou entités différentes.

Mais il faut tester et livrer ces composants ensemble en un produit cohérent. C’est ce que faisait cette entreprise. C’est ce qui rend ce contexte important aujourd’hui : c’est là que se produit l’innovation. Avant, c’était centré sur le logiciel. Aujourd’hui, tout est objet connecté, compteur intelligent, véhicule intelligent, smartphone… et ces sociétés, qui développent ces objets, rencontrent beaucoup de difficultés avec l’agilité, à cause de la complexité.

Au jour le jour, les consultants mettaient les équipes logicielles sur des sprints de 2 semaines avec meetings quotidiens, mais impossible de faire pareil avec le hardware. Eux, estimaient cela inutile.

Ben Aston : Je comprends.

David Bishop : Et c’était pareil pour le firmware. Cela ne leur convenait pas. Ce n’est pas adapté : les équipes logicielles allaient plus vite, travaillaient en itérations. Pour le hardware, cela prenait 12 à 18 mois entre deux versions.

Il fallait du temps pour intégrer un chipset et tout tester. De plus, la plupart des entreprises spécialisées dans les systèmes embarqués travaillent dans des secteurs très réglementés, sous supervision étatique.

Pensez aux compteurs intelligents pour les électriques, aux voitures intelligentes, à l’avionique… Selon les risques — pertes humaines ou échecs catastrophiques —, le niveau d’exigence et de qualité doit être beaucoup plus élevé que pour une application web ou un simple site e-commerce.

Ben Aston : En effet.

David Bishop : Ce sont pourtant les industries qui ont adopté le plus rapidement l’Agile.

Ben Aston : Pour en savoir plus sur la genèse de la Métagilité, consultez l’article sur thedigitalprojectmanager.com. L’évolution y est racontée, tout comme la création du livre. Plutôt que de creuser l’histoire, intéressons-nous au framework lui-même et voyons ce qu’on peut y appliquer à nos projets. Je crois que c’est pertinent, car beaucoup d’entre nous avons testé des éléments du Waterfall.

On mène des étapes successives, parce que cela semble logique pour nos parties prenantes, ou selon la structuration du projet. Mais on applique aussi des pratiques Agiles : collaboration, itérations. On puise un peu partout, on adhère à la philosophie : « itérer », « livrer de la valeur rapidement ».

On construit, on teste, on apprend. Puis, il faut tout de même fonctionner de façon séquentielle. Je veux parler de la Métagilité et de son application. En réalité, l’Agile est populaire, accepté partout pour la gestion logicielle. Mais qu’est-ce que cela signifie, concrètement ? Cela reste ouvert à interprétation.

Nous avons vu à quel point cette hybridation, même si rarement considérée optimale, est en fait le résultat par défaut de beaucoup qui cherchent à composer avec les contraintes en interne. Par exemple, le hardware a un tempo de développement plus lent que le logiciel, et le middleware se situe entre les deux.

Il s’agit donc de coordonner pour sortir au même rythme. C’est aussi le cas sur des sites web : UX et design vont vite, mais le dev prend du temps. Parlons donc plus précisément des limites que vous décrivez dans votre livre sur les méthodes Agile actuelles.

Quelles sont ces limites ? Pourriez-vous développer sur ce point, à la fois sur les cycles de sortie, mais aussi par rapport à Scrum ou Kanban ?

David Bishop : Avec des frameworks comme Scrum, Kanban, DSDM, LeSS ou DA (Disciplined Agile, racheté récemment par PMI), ils essaient chacun d’adresser la problématique sous différents angles.

Ben Aston : Oui, je ne vais pas acheter un framework, c’est sûr…

David Bishop : Ils s’y prennent de façons variées. Il y a souvent un malentendu sur les raisons d’adopter l’Agile : on pense que c’est pour améliorer l’efficacité d’équipe, renforcer le leadership, les processus. Tout ceci est positif.

Mais l’Agile, c’était d’abord pour la compétitivité. Être numéro un sur son marché. Le manifeste Agile vient du Lean manufacturing, inspiré du système Toyota dans les années 70, qui avait fait de cette entreprise un leader auto mondial.

Tout l’enjeu de l’agilité, c’est de viser ce type de succès. Or, certains frameworks, selon moi, l’oublient. SAFE, par exemple, cible l’ensemble de l’entreprise (niveau 30 000 pieds !) : tout agiliser, que ce soit les RH ou le service juridique.

Mais cela finit parfois par opposer process à process, multipliant procédures là où, autrefois, des docs SOP à rallonge soutenaient nos mainframes et systèmes légacy. SAFE rappelle un peu cela, accumulant processus lourds au lieu de se concentrer sur l’essentiel de l’Agile.

Ben Aston : Je comprends.

David Bishop : La métagilité, elle, se concentre sur le moteur du développement produit : gestion de projet, de produit, développement, test, collaboration avec le client, anticipation des besoins, qualité maximale. C’est comme construire une voiture de course : on travaille sur le moteur, la transmission, pas sur la climatisation.

Beaucoup de frameworks s’attardent sur les périphéries, alors qu’il faut viser ce qui fait gagner la course. Métagilité capture donc ce que les entreprises leaders ont fait de mieux, pour le rendre reproductible.

Ben Aston : Vous le décrivez comme une approche globale pour le management d’une nouvelle génération d’organisations. Mais la Métagilité, c’est un cadre de livraison ? Une méthodologie ? Un guide ? Comment la définissez-vous ?

David Bishop : C’est un cadre méthodologique. Le livre commence par inviter à penser différemment—utiliser la recherche et la méthode scientifique pour prendre des décisions business.

Il y a un passage sur l’évolution du manifeste Agile à travers la recherche récente. Mais quand il s’agit de transformation Agile, un des premiers pas est de choisir quel type d’Agilité vous adopterez. Peut-être du pur Agile, peut-être du hybride, ou même rester en Waterfall, ça dépend.

Il existe toute une littérature scientifique, des recherches de dirigeants, sur la façon de faire ce choix — souvent méconnue des consultants. Dans mon livre, j’inclus un diagramme (issu d’un article de Barlow) montrant que la méthode d’implémentation doit dépendre de la complexité de vos produits, de vos équipes et de leurs interdépendances.

Dans les cas très complexes et avec des équipes distribuées, le pur Agile échouera souvent, alors qu’une approche hybride, conçue sciemment, peut donner d’excellents résultats.

Les approches hybrides ont une mauvaise image, souvent perçue comme l’échec d’une transformation. Mais si le mélange est assumé, motivé par la science et la recherche, c’est la bonne direction pour votre organisation.

Ben Aston : Pour ceux qui n’ont pas lu le livre, comment fonctionne ce framework et quelles en sont les composantes ?

David Bishop : Dans le livre, j’ai un grand schéma qui synthétise tout cela. Globalement, la première étape de la Métagilité, c’est le choix de l’approche de transformation.

Ben Aston : Et comment mesurer / évaluer ce choix ?

David Bishop : Avec le diagramme de Barlow — inclus dans le livre —, qui explique que tout se joue sur la taille des équipes et la complexité des produits ainsi que les interactions nécessaires entre équipes ou filières de développement pour créer un produit.

En présence de forte complexité, il vaut mieux opter pour le modèle hybride. Voilà ce que défend la Métagilité. Elle inclut des étapes pour installer l’Agile par défaut ; elle décrit à quoi ressemble ce modèle hybride. Par exemple, les équipes logicielles font des sprints deux semaines avec daily stand-ups, le firmware sur 30 jours avec un stand-up hebdomadaire, et les équipes hardware, au cycle plus long (12-18 mois), travaillent parfois en Waterfall et intègrent des techniques itératives comme le prototypage rapide pour rester dans le flux.

L’essentiel est de maintenir le flux global à toutes les étapes.

La Métagilité définit aussi les métriques à surveiller, ainsi que les interactions, divisées en six catégories, issues des études de cas les plus performantes. On détaille ces interactions, leur gestion et leur implémentation, fournissant ainsi un guide précis pour gérer l’Agile hybride.

Ben Aston : Comment déterminer la combinaison idéale de caractéristiques Agile dans l’entreprise, alors que le changement fait souvent peur ? Comment savoir si l’état actuel est satisfaisant ou s’il faut évoluer ?

David Bishop : Il faut appliquer une démarche scientifique et de la recherche business engagée. Trop souvent, on s’appuie sur l’intuition, les best practices, ou la collecte de consensus. Ce n’est pas fondamentalement mauvais, mais pour des transformations aussi complexes — Agile, DevOps ou numérique — il faut employer des méthodes robustes.

J’ai vite vu que l’échec venait de consultants qui calquaient partout les recettes d’un poste précédent. Or, la recherche montre que les milieux informatiques sont hautement contextuels. Ce qui marche ici ne fonctionnera pas forcément ailleurs.

En utilisant méthodes scientifiques, études de cas interprétatives, ethnographies, on identifie ce qui est généralisable ou non selon les contextes spécifiques.

Ben Aston : Ce n’est donc pas un cadre unique, mais personnalisable. Mais alors, comment savoir si une implémentation est vraiment Métagilité, et comment en mesurer le succès ?

David Bishop : Voilà une excellente question. La Métagilité inclut la théorie de la Vorticité Agile. Au-delà de l’approche hybride et des interactions, cette théorie s’attache à mesurer l’agilité d’une organisation. C’est le point crucial, longtemps resté sans réponse : comment prouver la valeur de la transformation, où se situer, comment s’améliorer ?

La vorticité agile répond à cela. C’est complexe, j’en détaille le concept dans le livre, mais c’est un progrès majeur, car cela manquait cruellement dans le secteur.

Ben Aston : Donc, dans les organisations que vous avez accompagnées, quels sont les impacts de ce cadre ? Voyez-vous une augmentation de la compétitivité, du leadership marché ? Avez-vous des exemples concrets ?

David Bishop : Beaucoup d’études de cas concernaient l’embarqué, secteur très dynamique et difficile. Là où la Métagilité a été adoptée, les entreprises ont pu devenir leaders, ou presque, sur leur marché.

Cela s’est souvent traduit par la prise de parts de marché—plus d’appareils smart écoulés, plus rapidement que leurs concurrents. En particulier sur les nouveaux marchés, la clé est de décrocher vite ce « morceau » critique avant la concurrence, en lançant des innovations sans sacrifier la qualité ni la satisfaction client.

Ben Aston : A contrario, où avez-vous vu la Métagilité échouer ? Quels sont les points de blocage ?

David Bishop : Deux points : l’adhésion de la direction, et la gestion des exigences. Sans sponsoring exécutif, une transformation — Agile ou digitale — stagnera. Il faut convaincre avec un business case solide, montrer l’impact sur les résultats.

Le second point, c’est la gestion des exigences : souvent, l’attention porte sur les équipes de développement et de test, mais il faut aussi accompagner la mutation des analystes business (product owners) dans leur manière d’établir les besoins. Dans le monde Waterfall, on « collecte » des exigences, alors qu’en Agile, on « développe » les exigences.

Là où les analystes restent dans l’ancienne approche, ils multiplient le nombre d’exigences, ce qui ralentit tout, complique la priorisation, génère du bagage technique… et fait échouer la transformation. J’aborde cette différence dans le livre et lors de formations.

Ben Aston : Effectivement, la collecte d’exigences peut vite se transformer en tunnel interminable. Pour une organisation qui découvre la Métagilité et souhaite l’appliquer, quelle est la première étape qui aura le plus d’impact ?

David Bishop : Il faut d’abord nouer de nouvelles relations client, comme l’énonce aussi un des principes du manifeste Agile (collaboration client plutôt que négociation contractuelle). Selon la recherche, négociation et collaboration sont une seule et même dynamique, à tous les niveaux de l’organisation.

Il s’agit d’impliquer le client tout au long du processus, notamment lors des tests d’un produit innovant, et de le considérer comme un partenaire du projet. Un vrai succès se bâtit sur une vision partagée : choisir les bons clients, ceux qui acceptent cette collaboration ; quitte à en écarter, même si cela va à contre-courant du réflexe de vouloir tout accepter pour maximiser le chiffre d’affaires.

Ben Aston : C’est très juste. Pour véritablement délivrer de la valeur, il faut le bon modèle d’engagement, propice à la collaboration et à la confiance, seule garante de la valeur livrée. Merci David pour cet échange éclairant sur la Métagilité.

David Bishop : Merci à vous.

Ben Aston : N’hésitez pas à nous dire ce que vous pensez du livre Métagilité dans les commentaires. Nous ajouterons un lien dans la transcription. David, si l’on souhaite en savoir plus sur la Métagilité et votre livre, où peut-on vous trouver ?

David Bishop : Googlez Métagilité, vous trouverez plein de ressources. Sinon, visitez Agileworx.com (Agile-worx.com) pour découvrir la société, nos formations — actuellement mises en pause jusqu’à l’automne. À partir d’août jusqu’à novembre, nous espérons maintenir des sessions en présentiel, sinon certaines basculeront en virtuel.

Le planning à jour est sur metagility.technology, où vous pouvez vous inscrire. Vous pouvez aussi me joindre à David@agileworx.com (Agile-worx.com). J’apprécie de lire vos messages, que je consulte très régulièrement.

Ben Aston : Excellent. Si vous voulez progresser dans votre carrière, rejoignez notre communauté. Devenez membre DPM sur thedigitalprojectmanager.com/membership : accès à nos échanges Slack, templates, ateliers, sessions AMA, heures de bureau, e-books et bien plus encore. Si ce podcast vous a plu, abonnez-vous et restez connecté sur thedigitalprojectmanager.com. À très bientôt, et merci de votre écoute.