Faire Évoluer l’Agilité à Grande Échelle (Avec Giovanni Asproni De Zuhlke Engineering Limited)

Lisez la transcription :

Nous expérimentons la retranscription de nos podcasts à l’aide d’un logiciel. Veuillez excuser toute faute, car le bot n’est pas fiable à 100%.

Ben Aston :

Bienvenue sur le podcast DPM, où nous allons au-delà de la théorie pour donner des conseils concrets permettant de mieux piloter vos projets digitaux. Merci de votre écoute, je suis Ben Aston, le fondateur du Digital Project Manager. Tout le monde parle d’agilité, mais comment la faire fonctionner à grande échelle, entre plusieurs équipes ou projets ? Comment aller plus vite et quels sont les pièges ? Et comment éviter que ça tourne mal dès le départ ? Continuez à écouter l’épisode du jour pour comprendre comment nous pouvons accroître la livraison Agile et réussir une agilité à grande échelle. Ce podcast est sponsorisé par Clarizen, le leader des logiciels de gestion de projets et de portefeuilles en entreprise. Rendez-vous sur clarizen.com pour en savoir plus.

Aujourd’hui, je suis accompagné de Giovanni Asproni. Il est consultant principal chez Zuhlke Engineering Limited. Je prononce sûrement mal son nom, mais il est basé à Londres. C’est un architecte logiciel, un programmeur, un coach, un consultant, avec une grande expérience dans de nombreux secteurs, y compris les télécommunications, la banque, le pétrole et le gaz. Il a participé à de nombreuses conférences et collaboré à différents ouvrages. Giovanni, merci d’être avec nous.

Giovanni :

Bonjour, merci de m’avoir invité.

Ben Aston :

Et comment faut-il prononcer le nom de votre société ?

Giovanni :

C’est en fait un nom suisse, il se prononce Zuhlke.

Ben Aston :

Ah voilà. J’avoue que je ne l’aurais pas deviné !

Giovanni :

Je le prononce mal moi aussi, donc ne vous en faites pas.

Ben Aston :

C’est top. Dites-nous un peu sur quoi vous travaillez actuellement, à quoi ressemble une journée type pour vous ?

Giovanni :

Ma journée type en ce moment est plutôt chargée. J’ai commencé en juin un nouveau projet dans lequel je mets en application mes propres conseils, ce qui n’est pas si mal. Après avoir travaillé avec un grand client de Zuhlke, moi et quelques collègues avons mené une évaluation sur un programme de très grande ampleur : on parle de 500 personnes, 57 à 60 équipes, et maintenant nous mettons en œuvre une partie des recommandations, à savoir leur fournir un système pour collecter les métriques projets et programmes afin que l’ensemble soit mieux piloté. Je fais donc beaucoup de leadership technique, de cadrage des besoins, de reporting à tous les niveaux de management du client, et aussi un peu de code quand il le faut.

Ben Aston :

Super, parlez-nous du processus d’évaluation que vous mettez en place. Je trouve intéressant que vous ne vous contentiez pas de préconiser du scrum en arrivant chez un client, mais qu’il y ait une véritable évaluation faite en amont, non ?

Giovanni :

Oui.

Ben Aston :

Qu’est-ce que c’est concrètement ?

Giovanni :

Dans l’évaluation, l’idée est de comprendre ce qu’il se passe concrètement.

Ben Aston :

Oui.

Giovanni :

On parle avec les gens, les représentants des équipes, du management à tous les niveaux et on essaie de comprendre ce qui se passe sur le terrain. On fait des revues de code, on observe les processus suivis, la manière dont ils committent le code dans le dépôt, tout ce qui touche à la qualité…

Ben Aston :

Oui.

Giovanni :

On s’entretient aussi avec le management pour avoir leur point de vue. Au final, on dresse donc un tableau de la situation. Ces grands projets ont beaucoup de points communs mais les détails varient beaucoup selon les contextes.

Ben Aston :

Et côté recommandations, après avoir fait ces évaluations, est-ce que vos préconisations sont toujours semblables ou varient-elles d’une fois sur l’autre ? Giovanni : Non, ça dépend de ce qu’on découvre. Mais je dois dire qu’il y a des constantes, car…

Mm-hmm (acquiescement).

Giovanni :

…on fait souvent les mêmes erreurs.

Ben Aston :

Oui.

Giovanni :

Par exemple, dès qu’une entreprise cherche à grandir ses programmes à très grande échelle (100, 200 voire 500 ou 1300 personnes sur un seul produit), elle le fait pour aller plus vite mais n’a généralement pas les instruments nécessaires pour vérifier si cela apporte un réel bénéfice.

Ben Aston :

Vous mentionnez des instruments : comment évaluez-vous si le passage à l’échelle fonctionne vraiment ?

Giovanni :

On regarde plusieurs critères. Dans mon article sur les prérequis de la mise à l’échelle, on vérifie si tout le monde sait ce qu’il doit faire, si tous tirent dans le même sens. Vous seriez surpris du nombre de personnes qui ne sont pas d’accord sur les objectifs du projet.

Ben Aston :

Mm-hmm (acquiescement)

Giovanni :

Au final ils vont dans des directions différentes. On cherche donc l’usage de métriques : comment savoir objectivement si l’avancée est réelle, au-delà des impressions ?

Ben Aston :

Mm-hmm (acquiescement). Oui.

Giovanni :

On examine aussi l’architecture système pour voir si elle correspond à la structuration des équipes, les canaux de communication qui ont souvent tendance à se figer et devenir trop formels dans les grands projets, ce qui ralentit la résolution des problèmes.

Ben Aston :

Oui, oui… Au-delà du post, parlez-nous un peu de vous, et de votre expérience sur la mise à l’échelle Agile ou en équipes Agile : pouvez-vous partager votre plus grosse erreur, ce que vous en avez tiré comme leçon, pour aider nos auditeurs à éviter ce genre d’écueil ?

Giovanni :

Il y en a une récente : ce n’était pas un échec dramatique, mais une erreur quand même. J’étais appelé pour régler des soucis chez nous et chez un de nos clients. Chez Zuhlke, on travaille souvent chez le client aussi.

Ben Aston :

Oui.

Giovanni :

Pas mal de choses se sont bien passées mais un souci politique a stoppé le projet pour de mauvaises raisons. Donc, la leçon c’est que même en pensant être lucide, il arrive qu’on rate certaines signaux.

Ben Aston :

Oui.

Giovanni :

On a connu des jeux politiques internes et on s’est retrouvé au cœur du problème.

Ben Aston :

Mm-hmm (acquiescement).

Giovanni :

La politique compte toujours, qu’on le veuille ou non.

Ben Aston :

Oh oui.

Giovanni :

Dès qu’il y a des humains, il y a de la politique. Cela dépend comment on l’utilise.

Ben Aston :

Tout à fait. Pour revenir de façon générale et haut niveau, si vous deviez donner un conseil à quelqu’un qui veut se lancer dans l’Agile (parfois parce que le client exige cela), quel serait votre meilleur conseil pour quelqu’un qui n’a jamais travaillé en Agile mais doit aider à l’implémenter chez un client novice ?

Giovanni :

La première chose serait de clarifier les attentes. Quand on veut faire un projet Agile, de quoi a-t-on besoin vraiment ? Quel problème cherche-t-on à résoudre ?

Ben Aston :

Oui.

Giovanni :

L’agilité n’est pas un objectif en soi, c’est un moyen. Souvent, on veut être agile parce qu’on a entendu que d’autres entreprises le sont et que ça leur réussit, mais ce n’est pas la question principale.

Ben Aston :

Mm-hmm (acquiescement)

Giovanni :

Au final, il s’agit de gérer les attentes et de clarifier tout cela.

Ben Aston :

Exactement. Ce n’est pas le processus le but, mais la valeur livrée.

Giovanni :

Exact.

Ben Aston :

Livrer de la valeur, plus efficacement et obtenir des résultats. Le processus sert, mais ce n’est pas le but ultime. Merci pour vos conseils. Dites-nous ce qui compose votre boîte à outils : avez-vous des outils de prédilection, logiciels ou analogiques, pour évaluer et accompagner les équipes vers plus d’agilité ?

Giovanni :

J’utilise beaucoup mon carnet (un Moleskine). Quand je rencontre des gens pour évaluer un projet, généralement je ne suis pas derrière mon ordinateur car cela crée une barrière. Prendre des notes papier, c’est beaucoup moins intimidant. Donc stylo et Moleskine.

Ben Aston :

Oui.

Giovanni :

Ensuite, je saisis mes notes dans un logiciel, Scapple, qui me permet de mettre en relation les idées, sans structure hiérarchique strict. J’y note toutes sortes d’observations. Aussi, il ne faut pas seulement écouter ce que les gens disent, mais lire leur attitude, leur posture, voir s’ils sont tendus ou à l’aise, s’ils sont cohérents avec ce qu’ils disent…

Ben Aston :

Mm-hmm (acquiescement)

Giovanni :

Autre astuce : mener les entretiens dans un cadre sécurisant, sans présence hiérarchique si je parle avec des développeurs, afin qu’ils puissent s’exprimer librement. Je fais pareil côté managers, car la réalité est souvent plus complexe qu’affirmée.

Ben Aston :

Oui.

Giovanni :

Donc la sécurité psychologique est cruciale.

Ben Aston :

Et côté outils logiciels pour le pilotage Agile, avez-vous une préférence ? Ou cela dépend-t-il du contexte ?

Giovanni :

Cela dépend vraiment. Si tout le monde est au bureau, un simple tableau blanc suffit, puis on prend des photos. Dès qu’il y a du télétravail ou des équipes distribuées, il vaut mieux passer à des outils électroniques. Un outil courant est Jira, même si je ne l’apprécie pas particulièrement (trop lent et perfectible), mais il reste préférable à un tableau blanc si les gens ne sont pas sur site.

Ben Aston :

D’accord.

Giovanni :

Donc, c’est contextuel.

Ben Aston :

Mise à part votre Moleskine et Scapple, avez-vous découvert d’autres outils récemment ?

Giovanni :

Pas vraiment, non. Je ne suis plus en quête du dernier outil révolutionnaire. Parfois, rester simple est le choix le plus efficace.

Ben Aston :

Oui.

Giovanni :

Je recommande de choisir l’outil le plus simple possible adapté à votre contexte.

Ben Aston :

Parlons de votre article sur l’Agile à grande échelle. Il est bien connu qu’ajouter des personnes à un projet ne rend pas forcément l’organisation plus productive, et que cela génère souvent de la confusion et des difficultés d’intégration. Mais alors comment produire plus efficacement ? Votre article donne des règles sur la mise à l’échelle, les prérequis, la structuration des équipes… Si vous ne l’avez pas lu, je vous invite à consulter thedigitalprojectmanager.com.

Pourquoi est-il important de s’intéresser à la mise à l’échelle de l’Agilité ? Pouvez-vous nous éclairer ?

Giovanni :

C’est une question incontournable, surtout dans les entreprises moyennes ou grandes. Les projets grossissent soudainement en nombre de personnes. Ce que je recommande, c’est d’abord de s’assurer que la situation actuelle fonctionne avant de vouloir grandir. Pourquoi voulez-vous grandir ? Êtes-vous certain que c’est nécessaire ? Sans les prérequis, oubliez la mise à l’échelle, ce sera juste un chaos plus vaste. Dans tous les projets géants que j’ai croisés, il aurait suffi de 20 à 30 personnes pour un travail de qualité… Rappel d’un ami à moi : le nombre de personnes dans votre projet doit être le minimum entre le nombre disponible et le temps imparti !

Ben Aston :

Oui.

Giovanni :

Mais il faut travailler efficacement et commencer petit avant de grossir.

Ben Aston :

En bref, garder une équipe aussi petite et légère que possible maximise l’efficacité, la clarté des objectifs et la livraison de valeur. Mais au-delà, quand il s’agit de choisir les processus et systèmes pour organiser 500 personnes, pouvez-vous appliquer le même schéma partout ou chaque équipe a-t-elle des besoins spécifiques ?

Giovanni :

Le « one size fits all » ne marche jamais, surtout pour de gros projets. Quand il y a cinquante, cent équipes, la population est telle que les styles et besoins divergent forcément. Il est cependant nécessaire d’apporter une forme d’uniformité, notamment pour le reporting et la transparence, afin que la direction puisse suivre l’ensemble.

Ben Aston :

À quoi ressemble ce reporting ? Comment garder l’uniformité avec des modes de fonctionnement différents ?

Giovanni :

Il existe plusieurs méthodes. Plutôt que d’imposer Scrum à tous, certains doivent fonctionner de façon événementielle (ex avec support utilisateur). On ne peut pas planifier ce type de support, donc l’équipe doit rester flexible. L’important est de se concentrer à haut niveau sur la livraison : stories, features, épiques, etc. Même si certains utilisent Sprint, d’autres Kanban, on peut garder une analyse transverse. On peut aussi analyser le code pour observer comment les équipes interagissent… ou interfèrent.

Ben Aston :

Quels sont pour vous les signes d’une bonne ou mauvaise mise à l’échelle ?

Giovanni :

La mauvaise pratique la plus courante est d’ajouter des effectifs dans l’idée d’accélérer, ce qui ne marche pas. Autre piège : planifier les efforts comme une simple addition de ressources. Il faut au contraire vérifier que chaque équipe comporte des personnes expérimentées pouvant guider les plus jeunes. Impliquer les équipes et les référents techniques pour décider s’il faut plus de ressources est bien plus efficace.

Ben Aston :

C’est une question de lucidité et de conscience alors…

Giovanni :

Oui, il faut en être conscient. Je vais ajouter une idée un peu polémique : dans un projet logiciel, les seuls vraiment indispensables sont ceux qui écrivent le code et les utilisateurs. Tous les autres (managers, consultants, testeurs) sont optionnels selon le contexte. Leur rôle doit donc être de rendre les développeurs plus efficaces. Un chef de projet devrait donc demander à son équipe comment il peut les aider à mieux travailler !

Ben Aston :

Très intéressant. En termes de réussite Agile à grande échelle, selon votre expérience, à quoi ça ressemble quand ça fonctionne vraiment ?

Giovanni :

Je ne l’ai vu parfaitement fonctionner qu’une ou deux fois, sur des systèmes moyens (cinq-six équipes, une cinquantaine de développeurs/testeurs). Ils savaient ce qu’il fallait faire, leur place, comment collaborer, à qui s’adresser… Les très gros projets restent très difficiles et souvent surdimensionnés.

Ben Aston :

Et sur les frameworks « tout prêt » type SAFE, Scrum@Scale : quel est votre avis ? Marchent-ils ?

Giovanni :

Je sais qu’ils ont marché dans certains cas très spécifiques, rarement. Je n’aime pas ces frameworks prêts-à-l’emploi car ils supposent un contexte qui n’est pas toujours au rendez-vous. Ils mettent l’accent sur la structure mais pas assez sur l’humain. Ma plus grande critique de SAFE : il donne une illusion de contrôle au management, mais n’aide pas assez ceux qui font vraiment le travail.

Ben Aston :

C’est pareil avec Scrum : ces cadres présupposent un contexte, qui n’est pas forcément le nôtre. On suit le processus, mais sans tenir compte du projet réel, des équipes, du client, des contraintes. On peut aussi se perdre dans la rigidité du framework alors qu’il vaut mieux adapter la méthode à notre environnement.

Respecter la méthodologie ne veut pas dire livrer plus de valeur, plus vite, ou plus efficacement.

Giovanni :

Tout à fait. Longtemps, j’ai introduit l’Extreme Programming en démarrant petit, étape par étape, en choisissant les pratiques qui apportaient de la valeur et en les adaptant au fil du temps. Si l’on force d’emblée tout un framework, on noie les équipes sous sa complexité. L’idéal, c’est d’apprendre progressivement, en grandissant petit à petit.

Ben Aston :

Quand un framework est imposé soudainement, on risque de tomber dans une superficialité, où les équipes suivent les rituels sans y croire, tout en revenant à leurs anciennes habitudes. Cela crée du théâtre plus que du sens.

Giovanni :

Je le constate souvent : des équipes qui « font du Scrum », mais les réunions quotidiennes ne sont que des formalités, les rétrospectives deviennent des séances de plaintes sans action concrète… Il manque alors le sens, la valeur. Beaucoup d’entreprises copient le modèle Spotify, mais même Spotify adapte continuellement son dispositif.

Ben Aston :

Ce qui séduit dans le modèle Spotify, c’est qu’il semble simple et logique. Mais la réalité, c’est qu’il faut créer une organisation qui colle à son équipe, son contexte. Voilà ce qui ressort pour moi : le contexte est absolument clé. Il ne faut pas l’ignorer, mais vraiment en tenir compte si on veut mettre en place quelque chose d’efficace.

Giovanni :

C’est essentiel. Un livre très utile à ce sujet, que je recommande, c’est « Six Simple Rules », dont la première règle est : avant toute transformation, il faut comprendre ce que font réellement les gens. Pas de présupposés, il faut observer de près, puis adapter en conséquence.

Ben Aston :

Mm-hmm (acquiescement)

Giovanni :

Plutôt que d’arriver avec une solution toute faite…

Ben Aston :

Pour un chef de projet, producteur ou product manager qui doit accompagner une équipe sans coder, quel est votre conseil essentiel pour être utile sans gêner l’équipe ?

Giovanni :

Le plus important, c’est de comprendre ce dont l’équipe a besoin de vous. Demandez-leur comment vous pouvez les aider. Je fais partie des agilistes qui aiment les chefs de projet, car ce rôle est primordial, surtout sur des projets de taille moyenne ou grande : il faut quelqu’un pour piloter. Mais il faut considérer que vos équipes font de leur mieux dans leur contexte… ne les jugez pas, posez-leur la question. Vous trouverez vite de quoi leur être utile : peu d’entre eux aiment s’occuper de budget, planning, ou paperasses indispensables.

Ben Aston :

Personne n’a envie à devoir porter la responsabilité du budget, du planning ou du statement of work. On en parle rarement mais c’est central : si un client paie un projet, il veut savoir quand ce sera livré, combien cela coûtera et ce qu’il aura. Or, ces sujets sont souvent éludés dans les discours Agiles alors qu’ils sont fondamentaux.

Giovanni :

C’est ce que je reproche aussi à certains tenants du « no estimate » : le client veut savoir combien, quand, et ce qu’il aura. Il faut donc faire au mieux pour estimer, demander aux équipes qui vont réaliser le travail. S’ils annoncent un délai ou un coût qui semblent élevés, ne demandez pas une meilleure estimation juste parce que ça ne vous arrange pas. Demandez plutôt : pourquoi aussi long, aussi cher ? Posez des questions sincères. Mais si c’est la meilleure estimation, votre rôle est alors de défendre votre équipe face au client ; vos équipes vous seront reconnaissantes.

Ben Aston :

Tout à fait. Il ne faut pas découper arbitrairement le budget ou le planning, mais bien partir des estimations de terrain, puis décomposer les tâches, questionner, clarifier… Le rôle du chef de projet dans l’Agile, c’est la communication : être le pont entre équipe, client, fournisseurs, clarifier la vision, les objectifs, les moyens, coûts, délais…

Merci beaucoup Giovanni d’avoir été avec nous aujourd’hui !

Giovanni :

Merci à vous, c’était un plaisir.

Ben Aston :

Et vous, avez-vous tenté de faire évoluer l’Agilité à grande échelle ? Quels ont été vos succès ou difficultés ? Partagez vos expériences dans les commentaires ci-dessous. Pour aller plus loin, rejoignez la communauté DPM sur thedigitalprojectmanager.com/membership pour accéder à notre équipe Slack, nos templates, ateliers, permanences, eBooks et bien plus. Si l’épisode vous a plu, abonnez-vous, laissez-nous un avis honnête sur Apple Podcasts. À très vite, et merci de votre écoute.