Binôme PM / Tech Lead

Ref: Meetup Binome PM/Tech Lead - Thérapie de couple.

Mots clés

Communication, confiance.

PM vers Tech Lead

Transmettre la vision à court/moyen/long terme. La vision à long terme permet au technique d’avoir plus de contexte.

Une plus grande visibilité se fait via la planification, et la définition d’un nombre déterminé d’objectifs (typiquement, à peu près trois objectifs par sprint). Le PM doit aussi apporter de la visibilité sur les enjeux business.

Le technique a besoin d’une vision cohérente du produit.

L’implication des techniques doit se faire le plus tôt possible dans un objectif de sensibilisation.

Commun PM / Tech Lead

Il doit y avoir échange d’informations dans les deux sens.

Penser à des outils comme la communication positive.

Les deux partenaires du binôme doivent se connaître : par exemple, la façon d’être de l’autre (afterwork?).

Ils doivent partager un désir de progresser.

l’écriture des stories doit se faire à deux.

Tech Lead vers PM

Communiquer les problématiques technique au PM : schémas, graphiques, etc. Le tech devrait viser un objectif de vulgarisation et communiquer sur les problématiques techniques de la solution envisagée.

Scrum/Agile Master : garant du respect de l’agilité au sein de l’équipe. Un peu arbitre entre les deux parties. En l’absence de S/AM, ça retombe souvent entre les mains du tech lead.

Priorisation : s’assurer que les User Stories sont suffisamment affinées, découpage technique. Équilibrage entre les sujets du sprint (run, dette technique, innovation, etc.). Le S/AM s’assure également que la tech ne parte pas trop dans des délires expérimentaux au détriment des délais de réalisation.

Danger lead scrum master : du fait de sa position de lead, il peut être amené à imposer un modèle qui, au final, ne fonctionne pas.

Scrum et Kanban permettent de définir des priorités par sprint (du genre 3 priorités par semaine).

Tip entretien : avec le PM et le tech lead de l’équipe, être capable de présenter le produit en <½h.

Gestion délai : savoir prioriser les tâches, surtout celles permettant d’identifier les éventuels problèmes (i.e. le cœur de métier du produit). Ref: “How to measure anything”. L’idée est de faire une estimation min/max + répartition. Ensuite, réajuster et reprioriser au fil des sprints, ou plus fréquemment, à l’occasion des stand-up (vive l’Agile). Il faut savoir ce que le client veut en premier. En cas de besoin, il faut communiquer au plus tôt sur l’incertitude. Un découpage fin des tâches contribue à une bonne estimation.