Le gestionnaire agile dans les lignes de tir
Coincé entre sa direction qui ne comprend pas encore les enjeux et les répercussions de la mise en place d’une approche de gestion de projet agile et son équipe qui maintenant prend ses responsabilités, le manager d’une équipe agile reçoit des balles de toute part.
Bien entendu, tout le monde ne souhaite qu’une chose, réussir le projet. Cependant, les 3 protagonistes n’ont pas le même point de vue sur ce projet. Ils n’ont pas les mêmes connaissances de l’ampleur, du détail et de la difficulté de l’ouvrage. Ils n’ont pas non plus les mêmes besoins aux mêmes moments pour se rassurer (ou être rassurer) sur les chances de réussite ou sur la santé du projet.
Le gestionnaire agile dans les lignes de tir (photo by http://www.flickr.com/photos/mashleymorgan)
Lorsque qu’après avoir convenu qu’une première livraison de 2 mois permettrait de lever les risques et d’obtenir une ‘tranche’ verticale de logiciel fonctionnel, afin estimer de façon plus sereine le reste du projet, la direction décide de demander à l’équipe de réestimer la totalité du backlog après seulement 1 mois de travail, la fusillade éclate et le gestionnaire ou manager agile se retrouve dans les lignes de tir.
Satisfaire la demande de la direction ou soutenir l’équipe qui est tout à fait d’accord de réestimer le backlog, mais seulement après la release, une fois qu’elle aura l’information pertinente qu’elle cherche à obtenir.
C’est à ce moment là que le manager « au service de l’équipe » devrait faire son apparition. Être au soutient de l’équipe et l’éducateur de la direction.
Il doit être en mesure de répondre clairement aux interrogations des uns et des autres et d’expliquer à chacun les besoins de l’autre comme par exemple :
- Pourquoi la direction veut-elle une réestimation maintenant? Y a-t-il un besoin concret qui échappe à l’équipe comme par exemple une communication stratégique ou bien est-ce simplement une crainte, une insécurité générée par les nouvelles façons de faire, le nouveau reporting?
- Peut-on patienter encore quelques semaines? Admettons que les estimés préliminaires sont faux. Normal, ce sont des estimés! Ceux d’aujourd’hui, réalisés avec des connaissances encore incomplètes sur des risques identifiés, ne seront-ils pas aussi faux? Seront-ils plus pertinent s’ils sont établits dans 4 semaines une fois les risques levés?
- Pourquoi l’équipe ne souhaite-t-elle pas réestimer maintenant? A-t-elle peur? Refuse-t-elle de communiquer, d’être transparent vis-à-vis de la direction? Pense-t-elle que l’investissement à ce moment donné n’est pas rentable? Manque-t-il des informations nécessaires?
Les arguments de tous seront valables. Alors que doit faire le manager? Rester au milieu et prendre les balles? Ne satisfaire personne? Ou bien se positionner et prendre le risque de décevoir sa direction ou son équipe?
Pour ma part, je pense que le calcul à faire est celui du succès de l’équipe. Est-ce qu’une journée d’estimation rapporte plus qu’une journée à coder pendant laquelle on apprend sur les risques techniques que l’on doit affronter? À certains moments peut-être, à d’autres non. Ce qui est certain c’est qu’une équipe frustrée qui ne se sent pas soutenue, est moins productive et performante.
Faire le calcul de répondre à la demande de la direction sans tenir compte de l’équipe est peut-être bon pour la carrière, mais n’est pas le meilleur moyen d’aboutir à une équipe auto-organisée, performante, motivée et responsable. Il est plus pertinent d’éduquer la direction, de la rassurer, de lui expliquer que l’équipe ne juge pas pertinent de réévaluer maintenant mais qu’elle le fera dès que possible et qu’il faut lui faire confiance. Il est aussi judicieux d’expliquer qu’en Scrum cette (ré)estimation est permanente et fait partie du cadre.
—
Vous serez peut-être intéressés par ce précédent billet :
- Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?. N’hésitez pas à voter, votre avis m’intéresse
Loading ...
Excellente description de la réalité quotidienne des gestionnaires de premier niveau. Les équipes s’imagine souvent que l’auto-organisation n’a pas d’impact sur leurs gestionnaires alors qu’ils les exposent à plusieurs défis – incluant la relation que le gestionnaire a avec ses supérieurs.
Une approche systémique est grandement recommandée pour assurer le succès d’une intiative agile.
Bravo Tremeur pour un autre excellent poste.
Cas intéressant qui montre, à mon avis, un manque de communication et de transparence de l’équipe qui est en train de perdre la confiance de la direction ou du client.
La réestimation du Backlog ne devrait pas être longue: passer en revue rapidement les estimations des items du backlog et recalculer le tout en prenant en compte une éventuelle nouvelle vélocité. Alors pourquoi refuser ?
Si la direction fait sa demande, c’est qu’il y a une réelle inquiétude à propos de l’avancement du projet. Cette inquiétude ne peut venir que d’une situation peu claire. Qu’en est-il ? Sont-ils en retard ? De combien ? Le suivi de l’avancement est-il bien fait ?
Si le retard est tel que le projet risque de faire un x4 et d’être annulé, il est normal que la direction demande à ce qu’on prenne une journée pour éventuellement économiser un mois de travail inutile.
Probablement qu’un délai de 2 mois pour la première livraison était trop long.
Enfin, demander un mois de délais pour réestimer le backlog, est-ce vraiment être Agile ?
Bonjour @Renaud Choné
Merci pour ton commentaire. Je vais essayé de répondre à tes questionnements.
Dans le cas qui nous intéresse il y a effectivement un manque de communication, mais selon mon interprétation de la situation, plutôt des gestionnaires vers l’équipe. En effet l’équipe travaille depuis plusieurs mois en Scrum et est très transparente sur son avancement, ses difficultés et ses apprentissages.
L’estimation du backlog a eu lieu un mois auparavant, en considérant la vélocité connue de l’équipe, les risques techniques du projet, les besoins du client. Cette estimation a été présentée au client qui a donné son accord pour une première livraison, dans 2 mois (4 sprints) dont le but est d’évacuer la complexité technique, de démontrer la faisabilité du projet, de permettre de clarifier le besoin et de mesurer la vélocité de l’équipe qui a légèrement changée.
L’ampleur du backlog et la vélocité de l’équipe ne permettait pas à l’équipe d’atteindre l’objectif de date de la direction, ce qui effectivement inquiétait les gestionnaires. Cependant au moment de la demande de réestimation, aucun élément nouveau ne permettait à l’équipe de modifier son pointage. Un mois de délai est long pour donné une nouvelle estimation, mais c’est dans ce cas, ce dont l’équipe avait besoin, c’était la réalité de l’équipe.
Je suis d’accord avec toi que 2 mois est un délai long, mais pour une l’équipe, c’était le temps de livrer une ‘tranche’ verticale de l’application en levant les risques techniques liés à l’infra-structure et aux connaissances de l’équipe.
L’équipe a finalement réestimé, baissé quelques points, créé de nouvelles user story, pour un périmètre global similaire.
À la suite de cette demande, le gestionnaire est venu à la revue de sprint, à constater le travail réaliser et mieux compris la façon de travailler. Le PO a réexpliqué comment était suivi le projet.
Ce que je voulais levé ici c’est la difficulté du gestionnaire d’une équipe confronté à des demandes antagonistes.
J’ai trouvé votre témoignage intéressant. Je l’ai ressenti comme un point de vue subjectif sur un malentendu.
J’ai l’impression en lisant votre article que le malentendu pour sur le mot «réestimation».
Voilà ce que j’ai lu entre les lignes:
De votre point de vue, il s’agissait de réestimer en Points le backlog (ce qui prend du temps et est inutile), alors que ce que demandait probablement le gestionnaire était de réestimer les Délais et les Coûts en mettant simplement à jour l’hypothèse de vélocité (ce qui est rapide et nécessaire).
Concernant la communication, dans tous les référentiels de gestion de projet (PMBoK, Prince2…), il y a une obligation de la part de l’équipe projet d’alerter et de rendre compte au niveau supérieur lorsque certains seuils sont dépassés. C’est une communication proactive qui éviterait au Gestionnaire de s’inquiéter.
Dans le cas de SCRUM, on pourrait définir ces seuils sur la Vélocité .
My 2 cents…
Merci @Renaud Choné
Éffectivement, je suis très conscient qu’il y a toujours une part de subjectivité. Je travaille en tant que coach a être conscient de mes filtres et à les enlever.
Pour ce qui est de l’estimation, la date et le coût était bien fixé. Nous travaillions sur le périmètre fonctionnel (‘scope’). Lors de la première estimation le périmètre souhaité, ne ‘rentrait’ pas dans la date et le coût fixé. La date et le coût en relation avec l’estimation de l’équipe avait été clairement communiquées, de même que des options possibles.
La direction demandait clairement au gestionnaire de l’équipe de revoir l’estimation, de façon à s’assurer que l’équipe ne s’était pas trompée. Il y avait à l’époque un manque de confiance en l’équipe qui s’est résolu depuis.
L’équipe mesurait à l’époque sa vélocité et celle-ci n’avait pas d’incidence sur les éléments fournis préalablement.
J’ai su depuis qu’en travaillant de façon permanente sur le backlog, en continuant à être transparente, l’équipe a livré le besoin en trouvant des alternatives et a aussi gagné la confiance du directeur en question.
Concernant la communication, dès l’estimation initiale, partant de ses connaissances du moment, l’équipe était claire et transparente sur les hypothèses, sur son mécanisme de réévaluation au fil du projet (via les maintenance de backlog et les plannings aux 2 semaines) ainsi que sur sa volonté de faire aboutir le projet en trouvant des solutions innovantes au fur-et-à-mesure que sa connaissance augmenterait.
Cette transparence inhabituelle a peut-être inquiété le gestionnaire, celui-ci voulant sans doute être rassuré avant même que l’équipe ait pu faire ses apprentissages.
Merci beaucoup de challenger ma reflexion sur le sujet, cela me permet d’être plus attentif à mes perceptions et à la façon de les exprimer. J’apprécie votre feed-back constructif