Les problématiques Agile – Interview de Jon Ward

Avec plus de vingt ans d’expérience, Jon intervient dans un contexte international de changement Agile et organisationnel dans les secteurs des services financiers, de la banque, des assurances, des produits de grande consommation, de la télévision et de la vente au détail.

 

Quelle est votre fonction actuelle ?  

Je suis coach agile en entreprise. Qu’est-ce que cela signifie ? Je suis responsable de la planification et de l’accompagnement des équipes lors de la mutation de leurs  méthodes de travail traditionnelles vers les nouvelles méthodes de travail Agile. Je joue le rôle de catalyseur en fournissant formation et coaching aux équipes et aux cadres supérieurs lorsqu’ils changent de méthode projet. Je conçois et implémente un nouvel écosystème de gestion de projet afin que les équipes de projet soient en mesure de fournir des solutions de haute qualité plus rapidement.

 

Quelles sont vos missions ?

Je consacre environ 30% de mon temps à corriger les «mythes» Agile des cadres moyens et supérieurs. Par exemple, vous ne pouvez être Agile que si vous livrez un client à chaque sprint, si vous avez des équipes co-localisées, si vous intégrez le client dans l’équipe, etc. Les partisans de ces points de vue essaient généralement de trouver le moyen d’établir une exemption des nouvelles méthodes de travail – ils offrent parfois des pauses-café intéressantes!

Ensuite, je passe une bonne partie de mon temps à mesurer et à prévoir. La haute direction veut toujours connaître l’impact de la transition vers Agile. Je suis obligé de répondre continuellement aux questions telles que; les projets vont-ils plus vite, sommes-nous plus efficaces, si j’investis davantage dans des outils de test automatisés, quels seront les retombées probables?

Enfin, je travaille avec les équipes: Enseigner et encadrer des pratiques Agile et essayer d’éviter de devenir «fake Agile». Agile est un plat composé de nombreuses épices et certaines personnes pensent que si une équipe utilise Scrum, elle est Agile. C’est loin d’être le cas, car trouver la bonne solution relève autant de la modélisation des exigences Agile et des pratiques de qualité Agile que de Scrum. «Fake Agile» consiste à éviter de faire de l’Agile – les meetings, etc., mais de devenir Agile – pouvoir livrer plus rapidement, pivoter rapidement et travailler avec des équipes collaboratives affichant un contrôle de projet empirique.

 

Comment êtes-vous arrivé à effectuer une carrière en gestion de projet Agile?

Je pense que la gestion de projet Agile est venue à moi plutôt que l’inverse. J’ai commencé ma carrière en travaillant sur le Concorde et le Harrier jump jet. J’ai travaillé dans le contrôle de la production, nous avons utilisé un tableau pour planifier les étapes de production des composants, d’assemblage, de test, etc. Par la suite j’ai découvert que le terme Kanban décrivait ce processus efficace de planification et de contrôle.

Je me suis dirigé vers une carrière traditionnelle en gestion de projet, puis j’ai créé un cabinet de conseil en gestion de projet. Nous avions un peu plus d’une centaine de consultants basés à New York, Francfort et Londres, principalement concentrés sur les services financiers. Au fil du temps, j’ai constaté que les compétences traditionnelles en gestion de projet étaient devenues monnaie courante et que la demande de conseil en gestion de projet avait diminué.

Puis en 2007, on m’a demandé d’introduire Scrum dans une entreprise de logiciels au sud de Londres. J’ai vu les résultats exceptionnels de cette équipe en termes de contrôle et d’efficacité. À partir de ce moment-là, j’ai commencé à utiliser certaines techniques Agile dans le cadre de projets traditionnels. Par exemple, en travaillant pour une banque américaine mondiale à Chicago, j’ai introduit BDD (Behavour Driven Development) dans les exigences des processus en cascade. Nous avons réduit de moitié le temps nécessaire pour passer au stade des exigences et, ce qui est plus important encore, nous avons réduit le nombre d’absence d’exigences de l’UAT (test de validation utilisateur), qui est passé d’environ 70% de défauts à moins de 10%. À partir de là, j’ai suivi une formation scrum master en ligne, j’ai assisté à une « Discipline Agile Masterclass » et je me suis certifié en tant que consultant de programme SAFe. Au cours des deux dernières années, j’ai assumé les fonctions de directeur de la transformation Agile en dirigeant une équipe de coachs pour améliorer les performances de l’entreprise.

 

Quel est le plus gros problème / changement que vous voyez dans la communauté de Agile en ce moment?

Je pense que la communauté Agile a un défi majeur à relever pour mettre en œuvre Agile à l’échelle de l’organisation. Certaines personnes pensent que cela signifie «Agile à l’échelle», ce qui est loin de la vérité. Les frameworks Agile à l’échelle (SAFe, LeSS, S @ S, Nexus, etc.) permettent de combiner une équipe Scrum de 5 à 9 personnes afin de leur permettre de réaliser des tâches plus volumineuses. Les référentiels fournissent des conseils sur les processus d’organisation, de planification et de contrôle pour les grandes équipes utilisant Scrum ou Kanban comme mécanismes de contrôle. On croit à tort qu’un cadre Agile à l’échelle définira des mécanismes au niveau organisationnel pour lui permettre d’être Agile. Ils ne le font pas! Comme pour les référentiels du PMI ou la méthode PRINCE2, une organisation doit adapter les processus et pratiques Agile fournis par un cadre de référence afin de les adapter à son contexte organisationnel. Cependant, il faut prendre soin d’éviter de retirer les contraintes des méthodes traditionnelles pour les remplacer par celles Agile ! Agile s’appuie sur l’énergie, la créativité et les connaissances de l’équipe pour définir et proposer des solutions appropriées. Toute approche Agile à l’échelle de l’entreprise doit maximiser l’impact de ce potentiel humain.

 

Quels conseils donneriez-vous à la communauté Agile ?

J’ai un mantra :

Agile sans métriques est anarchie

Agile sans qualité est inutile

Mon conseil est le suivant: concentrez-vous sur les chiffres utilisés dans les évênements Agile. Assurez-vous que les chiffres de planification, de prévision et de contrôle s’additionnent. Laisser les chiffres illustrer que le contrôle empirique est efficace. Publiez les chiffres à la haute direction (pas de comparaisons inter-équipes, s’il vous plaît!) afin qu’ils puissent constater les améliorations apportées.

Deuxièmement, concentrez-vous autant sur les bonnes exigences que sur celles que vous appliquez aux évênements Agile. Les solutions de qualité ne se produisent pas par accident, elles se produisent par conception. Utilisez des techniques «shift-left» (test plus en amont) pour gérer la qualité.

 

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

Albert Einstein a un jour prononcé la célèbre phrase: “Dès que tu cesses d’apprendre, tu commences à mourir”. Comme je ne souhaite pas commer à mourir, je cherche à apprendre autant que je peux. Selon moi, à la différence d’un voyage, il n’y pas de fin à l’apprentissage. Comme je l’ai dit, Agile est un plat avec plein d’épices, Je veux toujours en savoir plus afin d’aider les organisations à devenir plus efficaces. Mon approche est donc Apprendre – Tester – Développer.

Je souhaite en savoir plus sur l’utilisation de l’intelligence artificielle pour soutenir les entreprises et les équipes Agile. Il est très clair que certains aspects de l’agilité ne peuvent pas être améliorés «les individus et les interactions plus que les processus et les outils». Cependant, il existe des domaines dans lesquels l’IA peut ou devrait être appliquée pour augmenter la productivité. Le test en est clairement un, la gestion et la préparation du backlog en sont un autre.

Le deuxième domaine sur lequel je souhaite en savoir plus est l’assurance qualité Agile. De nombreuses équipes pensent que, parce qu’elles utilisent Scrum, elles sont Agile. Je veux en savoir plus sur la façon de changer le comportement en matière de qualité. Nous parlons souvent de l’expertise du domaine Agile qui peut aider l’équipe. Nous parlons également de problèmes de qualité et de test, de trouver la solution parfaite «du premier coup», etc. Je suis intriguée par les compétences techniques et comportementales nécessaires pour devenir un coach qualité Agile.

Enfin, comme mentionné précédemment, j’ai utilisé un tableau Kanban à des fins de contrôle de production dans l’industrie aéronautique. Je connais donc bien la technique. Cependant, je veux en savoir plus sur la planification et l’organisation en utilisant Kanban. En particulier, comment intégrer une équipe produisant des petits travaux pour de nombreuses équipes Scrum. Là où l’échelle et l’expertise spécialisée signifient que ces compétences ne peuvent pas être intégrées à l’équipe Scrum à court terme. Je souhaite utiliser la méthode PDCA selon la roue de Deming,  pour voir si nous pouvons faire plus que simplement traiter l’équipe Kanban en tant que fournisseur externe. Je souhaite également en savoir plus sur l’utilisation de Kanban pour améliorer l’agilité organisationnelle. Je parle du concept de portefeuille Kanban.

 

Pouvez-vous nous en dire plus sur votre livre « The Agile Coaches Cookbook » ? 

En lisant et en apprenant toujours plus sur l’agilité, j’ai réalisé qu’il y avait beaucoup d’écrits sur l’Agile au niveau de l’équipe. Cependant, une fois que vous commencez à regarder Agile au niveau organisationnel, les ouvrages deviennent plus rares.

“The Agile Coaches cookbook” répond exactement à cette problématique et comme un livre de cuisine, il fournit diverses recettes pour les coachs Agile.  Il y a 4 sections:

 

• Le Master chef : outils et techniques pour le coaching Agile, comment créer un journal de coaching, déterminer quel type de coach Agile vous êtes, en utilisant un modèle de bilan de santé en équipe pour déterminer les interventions de l’équipe, etc.
• Recettes pour les équipes – explique comment lancer les équipes, passer des méthodes en cascade à Agile, parvenir à un backlog, gérer les risques en souplesse et illustrer le contrôle de projet.
• Recettes pour l’organisation – explique pourquoi l’adoption de l’agilité est si difficile, l’identification des défis systémiques, le coaching des sponsors et les changements du PMO.
• Le dîner de la transformation – réunissant tous les éléments, étapes de la transformation Agile, préparation d’un plan de transformation basé sur les objectifs, utilisation du PMO en tant que catalyseur Agile, solutions de rechange à la mise à l’échelle Agile, gestion de portefeuille Agile, utilisant des métriques pour démontrer le succès.

 

L’objectif de ce livre est d’aider les scrum masters et les coachs Agiles à être plus efficaces. Une transformation Agile est rarement le domaine d’un seul coach Agile. Ce livre permet aux équipes de coachs Agiles de décider de leurs «grandes règles» et d’orchestrer leurs actions en harmonie plutôt que d’agir en tant qu’individus discordants.

 

 

 

Jon Ward

Pratiquant Agile Agnostique, directeur de la transformation, coach, directeur de programme et responsable du changement. Avec plus de vingt ans d’expérience, Jon intervient dans un contexte international de changement Agile et organisationnel dans les secteurs des services financiers, de la banque, des assurances, des produits de grande consommation, de la télévision et de la vente au détail. Il est également certifié Disciplined Agilist and Certified Scrum Master.

Suivez Jon sur Linkedin ou consultez son site internet.