Retrouver la connexion entre l’équipe et le sponsor

Une formulation dans mon dernier article La démonstration n’est pas un stand up meeting m’a valu une réaction intéressante sur Twitter.

@av
[@…] mouais. Voir la revue d’itération comme un moment de reporting efficace, ça me gratouille un peu (beaucoup en fait).

@bm
[@…] perso je préfèrerais aussi ‘communication’ ou un truc comme ça certes, et efficace est sûrement trop fort (cc @duquesnay )

@duquesnay
[@…] ‘communication’ ne donne pas l’intention du meeting, ‘reporting’ ça gratte mais on sait ce qu’on vient faire là

@av

[@…] moi dans une revue de sprint, je viens pas faire du reporting. Ce qui m’intéresse, c’est le feedback. [@…]

 

Ces échanges me donnent envie de creuser un point qui me tient à coeur : le rapport des développeurs au reporting et au sponsor.

Je ne débattrais pas ici des buts d’une démonstration de fin d’itération. Admettons simplement que montrer l’état d’avancement du projet et mettre à jour les indicateurs d’avancement en fait partie.

Ce qui m’intéresse, c’est la gêne des développeurs quant on intègre le mot reporting aux pratiques agiles.

Avancement du projet, notion anxiogène

La mesure d’avancement est mal aimée chez les développeurs, et ça se comprend. D’un côté, elle s’appuie sur des estimations de tâches qu’on sait relativement aléatoires. Un développement évalué à une journée peut finalement prendre 1 semaine, une semaine devenir un mois.

De l’autre on est pris dans un système qui pousse à l’engagement, parfois contraint. La pression au résultat existe et s’accentue avec le poids de la hiérarchie ; on en vient souvent à confondre la réponse à laquelle on croit avec la réponse qui plaît. En atelier d’estimation, les développeurs s’inquiètent souvent :

Lâcher une estimation, oui, mais qui fera des nocturnes et des week-end si ça dérape ?
Qui voudra bien entendre qu’on ne maîtrise pas telle ou telle partie majeure du projet ?
Qui acceptera que l’enjeu est difficile à atteindre ?

Même si des approches existent pour limiter ce problème (l’agile en fournit un certain nombre), le sujet réveille des expériences douloureuses chez beaucoup d’entre nous. J’en ai connu mon lot : notre session Agile en projets courts êtes-vous prêts ? avec Jonathan Scher était à l’origine une session sur un projet que nous avions échoué. Je comprends qu’on serre les mâchoires lorsque la question de l’avancement arrive.

“Ce sera livré quand ce sera livré”, posture sourde

Ce qui me choque, c’est d’entendre certains au sein de la communauté agile réfuter la question elle même, et la pertinence d’une direction de projet à la poser. Pire exemple entendu entre pratiquants :

« Ce sera fini quand ce sera fini, on va pas leurrer le client avec une estimation… s’il ne comprend pas on devrait pas signer avec lui »

Je trouve cette posture nombriliste, aveugle au cadre. La situation d’une équipe de développement découle d’une relation d’intérêt avec l’organisation qui l’emploie.

Lorsque le premier jour du projet des développeurs, experts métier, graphiste / UX et Product Owner sont assis sur des chaises confortables devant des bureaux modernes supportant des ordinateurs double écrans dans un espace propre, chauffé et bien éclairé, tandis que la machine à café ronronne, c’est que quelqu’un a déjà mis de l’argent sur la table.

Version MasterCard :

8 chaises : 480€
8 bureaux : 2960€
8 ordinateurs : 15920€
8 prestataires : env. 4600€ / jour
1 salle 8 personne : 2900€/mois
Initier une bonne dynamique d’équipe : ça n’a pas de prix.

Certaines choses ne s’achètent pas.
Pour tout le reste, quelqu’un a sorti sa carte bleue.

Ce quelqu’un est le sponsor du projet.

Une équipe se trouve réunie sur un projet parce que le sponsor poursuit un objectif. C’est un risque financier, il aurait pu ne rien tenter, ou miser sur un autre projet. Son inquiétude est légitime. Je pense que s’en déconnecter amène une situation déséquilibrée.
Imaginons qu’il propose lui aussi de se déconnecter de l’intérêt des développeurs :

Ok pour ne faire ni estimation ni reporting, mais je ne sors pas un euro, aucun intervenant ne sera payé avant la livraison.

Ca gratouille côté compte courant chez les équipiers, non ? Vous sentez la relation d’intérêt réciproque ?

L’échange sur twitter m’a fait réagir pour cette impression de déconnection. En lisant « […] dans une revue de sprint, je viens pas faire […]. Ce qui m’intéresse, c’est […] », je vois beaucoup de « je ». Comme si la démonstration de fin d’itération était à l’initiative des développeurs et à leur usage principal, alors que c’est un point de rencontre avec un but collectif

Un projet agile performant est articulé autour d’une relation d’intérêt équilibrée. Le sponsor et l’équipe sont solidaires. Ils se parlent, ça cause enjeux et avancement.

Alors, pourquoi en est-on encore là ?

Dans mes observations la déconnection de l’équipe vis-à-vis des enjeux du projet va souvent de pair avec une distance entre le sponsor et l’équipe. Il est tentant d’accorder la faute au sponsor  mais je pense qu’en fait les torts sont partagés. En tout cas c’est dommage, car le sponsor est l’ami le plus puissant de l’équipe. Il ou elle a du pouvoir, des ressources, apporte une vision élargie du contexte et se montre souvent pragmatique… s’il est suffisamment informé.

Comment réduire la distance entre sponsor et équipe ?

Dès que je fais une session où j’évoque la présence du sponsor j’entends cette question, preuve s’il en est que le problème est habituel. Lorsque la situation est installée, je pense qu’on a des leviers de résolution des deux côtés de la relation -comme je l’ai dit je pense que les torts sont partagés. Je vous propose quelques questions qui piquent pour commencer à les actionner.

Levier côté sponsor : réserver du temps régulier avec l’équipe

Quand avez-vous assisté à une démonstration pour la dernière fois ?
Avez-vous déjà essayé le produit ?
Quel est votre vision sur la performance de l’équipe ?

Levier côté équipe : questionner le sponsor sur les enjeux, se partager la tâche de reporting

Qui a déjà adressé la parole au sponsor ?
Connaissez-vous de tête ses 3 premiers enjeux sur ce projet ?
Qui a déjà vu la synthèse d’avancement envoyée à la direction ?

Pour aller titiller l’une ou l’autre des parties, tout acteur facilitant le projet peut intervenir : les managers directs, le scrum master, le coach s’il y en a un. Cependant, l’accès au sponsor est souvent plus délicat. Disponibilité rare, niveau hiérarchique intimidant, barrage des assistantes, on a pas toujours l’accès qu’on aimerait.

A mon humble avis, n’hésitez pas à mouiller le management sur le problème. Vous pouvez faire remonter formellement une demande, par exemple la présence du sponsor à une démo toutes les 4 semaines. J’écris “management” au sens large : le réseau des managers de l’organisation, ces gens dont le rôle est de graisser les rouages de la machine. Si plusieurs directions sont impliquées sur le projet, un autre directeur concerné par le projet peut passer le message, par exemple.

La présence régulière du sponsor est une clé pour la réussite du projet. Cette sensibilisation mérite vos efforts et votre insistance.

Le dernier levier est pour ma pomme, le coach. Je l’ai intégré depuis plusieurs années à mes pratiques, mais ça ne me fait pas de mal de le réécrire noir sur blanc. Je dois inclure dès le départ le sponsor et sa relation avec l’équipe dans le périmètre de l’accompagnement. Se plaindre de son absence et n’intervenir qu’auprès de l’équipe est un non sens.

Auto-questions qui piquent :

Ai-je évoqué l’accompagnement du sponsor lors du cadrage de l’intervention ?
Ai-je demandé un rendez-vous avec lui/elle avant le démarrage du projet ?
Lui ai-je proposé un reporting régulier sur mon accompagnement ?
Quand lui ai-je demandé des nouvelles du projet pour la dernière fois ?

Tags: Agile Coaching, Agile Management, Communication, Contrôle, Démonstration, Feedback loop, Management agile, Pilotage, Sponsor