Standup

A la Devoxx2018, A.Hélaïli interroge l’audience avec des questions qui ont fait echo à ce que je vis acutellement au travail:conférence

Est-ce que les meetings sont utiles ? Est-il utile d’avoir toute l’équipe au même endroit au même moment ? Est-ce qu’on ne peut pas le faire de manière asynchrone ?

Puis il finit par expliquer que chaque semaine, le développeur chez Github ouvre une issue dans un radar pour décrire ce qu’il a fait cette semaine et ce qu’il va faire.

A. Hélaïli montre ainsi qu’il est simple de faire du standup asynchrone où chaque membre de l’équipe peut consulter le standup quand bon lui semble.

Cette façon de faire du standup m’a paru tellement évidente que je me suis demandé:

Pourquoi ne fait-on pas comme ça au boutlot ?

Je me dis qu’il y a sûrement une bonne raison de ne pas faire comme chez Github.

Revoyons les bases.

Supposons que nous développons en suivant la Méthodologie Scrum, à quelles questions dois-je répondre lors d’un daily standup ?

• Qu’ai-je fait hier qui aide l’équipe a atteindre l’objectif du sprint ?
• Que vais-je faire aujourd’hui pour aider l’équipe à atteindre l’objectif du sprint ?
• Y-a-t-il des problèmes qui empêchent l’équipe d’atteindre l’objectif ?

Source: wikipedia

Si je comprends correctement la conf, le standup façon Github permet donc de répondre facilement aux deux premières questions, mais pas la troisième. En effet, il est préférable d’évoquer des problèmes de façon synchrone avec les autres membres de l’équipe, surtout lorsqu’il s’agit d’un problème bloquant, car un autre membre pourrait proposé son aide pour comprendre le besoin puis arriver à une solution.

A chaud je me dis que un standup asynchrone ne peut pas remplacer un standup synchrone.

Ensuite, je tombe sur le remote-manifesto de gitlab. Le 5ème point offre une piste de résolution:

Don’t talk about what you did yesterday, this is not a reporting moment where everyone tries to look busy. Rather, kickstart the day with some bonding, solve anything blocking and share future plans so people can plan and act and ultimately save time.

Je me reconnais dans la première phrase. Ayant une mémoire de poisson rouge, j’arrive à retrouver 1-2 issues traitées la veille et après je cherche à combler pour paraître aussi occupé que les autres membres de l’équipe.

Gitlab suggère ainsi de remplacer la première question par un moment d’échanges entre membres de l’équipe. Je trouve cette façon de standup aussi cool que celle de Github. Ne pourrait-on pas avoir un bon standup en tirant le meilleur de chacunes des préconisations ?

Nous pourrions éclater le standup façon Scrum en extrayant la question Qu'ai-je fait hier pour le sprint ? pour ne pas que celle-ci vienne polluer le standup meeting. Nous devrions répondre à cette question de façon asynchrone, et cela se fait naturellement via l’outil de tracking des issues utilisé.

Ensuite pour le standup synchrone, nous le réservons pour échanger entre membres de l’équipe:

• discuter, créer des liens.
• trouver la resource pour résoudre après les problèmes bloquants éventuellement évoqués.
• évoquer ce que l’on va faire

Cela me paraît être un bon compromis au standup Scrum vanialla. D’autres astuces comme le “take if offline” sont à piocher.