le W3C = “review then commit”
le WHATWG = “commit then review”

Je ne vois pas l’application de cette expression au niveau d’un individu mais plutôt au niveau du entité.
Elle prend d’autant plus de sens que l’entreprise est enlisée dans une succession de couches hiérarchiques qui freine l’innovation et la réactivité.

En cette période estivale où les vacances commencent pour plusieurs, faire une pause professionnelle pour quelques (ou plusieurs) jours permet de rétablir l’équilibre et de re-donner l’énergie nécessaire. Ironiquement, ralentir permet souvent d’avancer plus rapidement par la suite.

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

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 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.