Un coach ou un scrumMaster trop bavard est un problème qui arrive fréquemment lors des mêlées quotidiennes. Il n’y a rien de mal à ce qu’ils prennent la parole pendant la réunion, mais si nous voulons que l’équipe se l’approprie, ce sont les développeurs qui doivent faire la majorité des échanges.

Les coachs veulent généralement bien faire, mais certains d’entre eux ont souvent un ancien parcours managérial dans des organisations où les informations et le travail étaient donnés aux développeurs par l’encadrement. Cela contribue à la mise en place d’un modèle dans lequel les développeurs s’attendent à ce que les problèmes soient résolus par l’encadrement. Nous voulons créer un nouveau modèle, dans lequel les développeurs résolvent eux-mêmes la plupart des problèmes.

Les coachs doivent coacher les développeurs à travers ce changement de modèle. Cela requiert du courage de leur part et cela crée parfois un vide qu’ils doivent eux-mêmes remplir.

Une bonne pratique que je conseille aux coachs est de poser des questions - même des questions auxquelles ils ont les réponses - et d’attendre la réponse. La pratique consiste à compter 10 secondes en silence après avoir posé la question. Ne soyez pas surpris si cela prend 6-7 secondes avant que quelqu’un prenne la parole … de longs silences peuvent être inconfortables pour un développeur qui connaît la réponse, mais qui est un peu timide pour prendre la parole. Si vous êtes arrivé à 10 secondes et que personne n’a parlé, posez une question bateau ; une question qui est plus facile à répondre et qui vous amène à mi-chemin.

Exemple :

Coach : “Sommes-nous dans les clous pour atteindre l’objectif du sprint cette semaine ?”

Comptage silencieux jusqu’à 10.

Coach : “OK, y’a t’il quoi que ce soit qui vous inquiètes ?

Après quelque secondes, un développeur prend la parole : “Je ne suis pas sûr si je suis en train de créer les bonnes animations pour ce sprint.”

Un autre développeur prend la parole : “Je peux venir à ton poste de travail après la réunion et voir avec toi ce dont nous avons besoin.”

Bénéfices

Créer un modèle de résolution de problèmes au sein des développeurs sans supervison directe de l’encadrement vous donnera un des plus grands bénéfices de l’auto-organisation. Avoir huit personnes résolvant 90% des problèmes est bien plus efficient et efficace que vous seul - faisant office de goulot d’étranglement - .

Auteur : Clinton Keith
Source : AGD Practice - The Silent Count
Date de parution originale : 22 Décembre 2016

Traducteur : Nicolas Mereaux
Date de traduction : 02/01/2017

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.