Le tempo du Coach Agile

Le coaching Agile m'a toujours fait penser à la musique, rythme, émotion, tension et résolutions... d'où ce titre "tempo" et ces deux questions : - Quel est le meilleur moment pour coacher l'équipe ? - Dois-je prévoir dans le sprint du temps pour le coaching ? C'est dans le livre "Coaching Agile Teams" de Lyssa Adkins que j'ai trouvé des réponses à ces questions ainsi que des réponses à des questions que je ne m'étais pas encore posées ! Comme...

Qui est vraiment ce Coach Agile ?

Ce qui me paraît le mieux définir la nature profonde du Coach c'est l'Inspect & Adapt. C'est bien évidemment la nature même de l'Agilité mais transportée au sein de l'individu. Le coach est quelqu'un qui a su faire évoluer son propre logiciel d'un modèle de "Command & Control" à une philosophie basée sur l'introspection et l'adaptation. Peut-on coacher une équipe Agile en lui donnant des directives et en contrôlant leur exécution ? bien sûr que non... Le coach doit créer le cadre qui va permettre l'émergence des bonnes pratiques au sein de l'équipe. Le modèle Cynefin en est une bonne illustration.  

Le style de Coaching

L'Inspect & Adapt fait appel à la maturité de l'équipe, à sa connaissance de l'Agilité, à son degré de pratique et à sa capacité à mettre oeuvre l'introspection. Partant de là le coach va devoir adapter son style de coaching pour qu'il suive la progression de l'équipe et soit toujours au plus près de leurs besoins. C'est d'ailleurs un point essentiel, le coach n'applique pas une recette, il permet à l'équipe de créer sa propre recette. Lyssa Adkins propose trois styles de coaching associés aux trois niveaux de compétences de l'équipe SHU/HA/RI.

"Teaching style" pour une équipe SHU

Une erreur fréquente et que j'ai commise est d'initier une équipe à l'Agile en omettant ou en transformant certaines règles ou cérémonies par ce qu'on ne les estime "pas adaptées" à l'entreprise ou au projet. Seule l'équipe par ses rétrospectives successives peut faire évoluer la pratique du Framework... alors pour le moment il faut suivre les règles en disant par exemple :

• Suivez les règles, je sais qu’elles donnent les résultats attendus, pour le moment, suivez les
• Les règles fonctionnent, le reste génère des obstacles
• Tout ce dont vous avez besoin est dans le Framework, donc regardez de ce côté d’abord.

"Coaching style" pour une équipe HA

L'équipe applique les règles depuis quelques temps et il est temps de les aider à comprendre ce qui se passe pour eux, ce qui marche, ce qui ne marche pas en leur posant des questions comme :

• A votre avis, comment cette façon de faire fonctionne ?
• Qu’est qui fait que ça ne marche pas ?
• Comment les principes Agile sont liés à votre vie ?

"Advising style" pour une équipe RI

L'équipe a compris en quoi Agile les aide au quotidien, elle est désireuse de faire évoluer le Framework pour mieux coller à ses besoins, le coach lui, va petit à petit s'effacer afin de laisser l'équipe s'exprimer et à ce moment elle n'a plus besoin que de conseils :

• Je ne sais pas, qu’en pensez-vous ?
• Je peux faire une observation ?
• Ça peut marcher, essayez !

Nous avons évoqué un aspect de la psychologie du coach ainsi que le style de son coaching, passons maintenant au sujet principal de cet article qui est : "Je coach qui et quand ?"

Coacher l'équipe

L'équipe est dans son sprint, elle travaille sur des fonctionnalités, elle s'est engagée, elle ne doit donc pas être dérangée. Le coach se fait discret durant le sprint, son rôle va surtout être d'écouter l'équipe, de prendre des notes afin de préparer la rétrospective. Cependant il peut être judicieux d'apporter à l'équipe des connaissances théoriques ou pratiques au moment opportun car elles seront ainsi toujours mieux comprises. Il va aussi se faire le relais des bonnes pratiques émergentes afin de s'assurer qu'elles sont communiquées à tous les membres de l'équipe. Mais c'est la rétrospective qui est le moment préféré du coach, il va aider l'équipe à consolider les bonnes pratiques et à communiquer l'envie de progresser dans l'Agilité. Durant ma présentation la question s'est posée de savoir si le coach devait garder une certaine distance vis à vis de l'équipe au niveau du métier et aussi de savoir si il devait les laisser échouer ou non le cas échéant. Dans les faits la connaissance métier est souvent indispensable pour le coach simplement pour se faire accepter par l'équipe, et l'idée de "laisser échouer" est à prendre avec des pincettes car au-delà de l'aspect éducatif de l'échec il y a la réalité d'une entreprise, d'un produit, d'une culture... alors plutôt que "laisser échouer" nous avons préférés dire que le rôle du coach est de créer un cadre dans lequel l'échec est possible. J'ai aussi posé la question des différences de salaire et de métier entre les membres de l'équipe Agile, cela peut-il être source de conflit ? La réponse est oui et la solution qui consiste à attribuer le poste de Scrum Master aux Chefs de projets techniques afin de conserver une justification salariale est mauvaise. Les Scrum Master, développeur, Product Owner sont des rôles en Agile, ce ne sont pas des métiers. Les métiers, les salaires appartiennent à l'entreprise avec tout ce qu'ils ont d'objectif ou de subjectif... mais dans le cadre de l'équipe Agile les individus vont prendre des rôles sans aucune considération de leur métier d'origine mais simplement de leurs compétences et de leurs désirs. D'ailleurs une bonne pratique serait de laisser l'équipe décider du casting de ces rôles.  

Coacher les personnes

"Un ami vous aime comme vous êtes, un coach vous aime trop pour vous laisser là où vous êtes" Je trouve que cette phrase résume bien le rôle du coach vis à vis de l'individu et pour la mettre en pratique elle nécessite de rencontrer les personnes là où elles en sont dans leur vie (professionnelle, Agile, personnelle) bien avant qu'elles viennent au coach pour lui faire part de leurs difficultés. Une question pratique s'est posée, le Coach doit-il convoquer tous les membres de l'équipe un par un pour discuter de leur parcours ? Doit-il faire semblant de les croiser par hasard et leur proposer un café ? Ne risque-t-il pas de créer la suspicion ? Une bonne pratique là aussi serait d'ouvrir sa porte une fois par semaine sur un créneau de temps précis en laissant aux personnes la liberté de venir ou non parler avec lui. Le but est d'installer des valeurs comme la confidentialité, la sécurité, l'écoute et aussi de créer un environnement qui va les rendre courageux car du courage ils vont en avoir besoin pour tenir leurs engagements et délivrer un produit de qualité. Le coach va aussi inciter les personnes à se définir des objectifs et à faire des rétrospectives individuelles ce qui est une bonne pratique Agile.

Coacher le Product Owner

C'est probablement avec le PO que le coach va passer l'essentiel de son temps, il va l'aider à définir la priorité des story en fonction de la Business Value et pour cela il va l'aider à lever quelques sources de perturbations :

• A t’il promis une fonctionnalité à une personne en particulier ?
• Quels sont ses critères d’évaluations, influent-ils sur ses choix ?
• Est-il personnellement attaché à des fonctionnalités ?

Le coach va aussi aider le PO à être disponible pour l'équipe, à ne pas trop aller dans le détail des story, à savoir dire non... Détecter les sources de pression et les neutraliser... ils ne seront pas trop de deux coach et PO pour réaliser cela ! Concernant le "laisser échouer" la même question se pose que pour l'équipe, encore une fois le PO doit se sentir en confiance car il aura à prendre des décisions importantes concernant le produit.

Coacher le management

Cet aspect du coaching ne m'était pas apparu clairement lors de mes précédentes expériences et pourtant en y réfléchissant c'est probablement là que se trouve une des clés de la réussite d'Agile dans une entreprise. Le management peut-être déstabilisé par l'arrivée d'Agile, la notion d'auto-organisation de l'équipe peut lui laisser penser qu'il perd une de ses prérogatives de plus importantes "Commander et contrôler". C'est un tout nouveau rôle que celui de manager d'une équipe Agile ou alors un rôle qui n'existe pas... quoiqu'il en soit ces métiers existent et le coach doit faire avec en expliquant :

• Que eux seuls peuvent aider l'équipe à lever les blocages
• Que leur contrôle ne s'exerce pas sur les individus mais sur les difficultés qu'ils rencontrent
• Qu'ils doivent apprendre à donner aux individus des objectifs en phase avec les principes Agile
• Qu'ils doivent surtout apprendre à mener les problèmes à l'équipe plutôt que de les régler eux même

Il n'y a pas de meilleur moment pour Coacher le management, c'est probablement un effort de tous les jours.

Coacher les Stakeholder

Toutes les parties prenantes du projet vont devoir apprendre à travailler avec une équipe Agile et pour cela il va falloir :

• Les aider à comprendre pourquoi le projet est important
• Les aider à fixer la barre haut
• Les faire réfléchir sur la motivation qu'ils donnent à l'équipe.

C'est avant et après les rencontres prévues avec l'équipe (la démo par exemple) que le coach va rencontrer les Stakeholders pour discuter avec eux de ces points.

Conclusion

Après cet atelier le rôle de coach m'est apparu plus clair d'abord sur cet aspect basique du calendrier mais ensuite sur le style du coaching et plus finement sur le rôle du coach dans l'entreprise. Le coach est indispensable au succès de la mise en place de l'Agilité et son rôle ne serait être cumulé avec celui de PO ou SM car l'importance de coacher au-delà de l'équipe s'avère crucial pour le succès de l'équipe.

Tempo du coach agile from bduplessis