Quand laisser l’équipe échouer?

« Nous devrions dorénavant communiquer uniquement par courriel, comme ça on arrêtera de nous déranger pour rien et nous pourrons nous concentrer sur le code. »

Nous sommes dans une rétrospective du sprint. Cette proposition vient d’un des développeurs de l’équipe Scrum. Elle est vite applaudie par d’autres développeurs. Même les autres membres de l’équipe semblent y voir un avantage. Il est vrai que dans une discussion on manque parfois de préparation, c’est mieux de rassembler ses idées au propre après tout.

Vous, le Scrum Master, êtes perplexe face à cette ‘solution’. Vous avez envie de brandir le manifeste Agile, de parler de l’efficacité des canaux de communication, de vanter les avantages de la collaboration… Mais avant de dire quoi que ce soit, posez-vous la question suivante : « Et si je laissais l’équipe se planter? »

La valeur de l’expérience

Un des premiers éléments à considérer est la valeur de l’apprentissage que l’équipe en retirera. En effet, si l’application de cette solution montre de façon évidente à tout le monde la valeur ajoutée de la collaboration ainsi que la perte d’efficacité reliée à l’utilisation du courriel au sein d’une équipe, la valeur de cet apprentissage peut justifier le temps que l’équipe investit à essayer cette ‘solution’.

De plus, comme il s’agit d’une solution qui émane de l’équipe, cette dernière se mobilisera pour la respecter. Elle fera tout ce qui est possible pour que cette solution ait du succès. Toutefois, sachant d’avance que malgré tous ces efforts il sera difficile d’être plus efficace qu’en communication directe, les résultats seront d’autant plus parlants pour l’équipe l’ayant expérimentée.

Le coût de l’expérience

C’est très bien de considérer la valeur de l’apprentissage, tout a un coût. Ce coût comporte divers volets. Un aspect évident est financier : l’argent dépensé en salaires des membres de l’équipe. Au-delà de l’évidence, il faut aussi considérer le coût humain. Quel effet va avoir cet échec potentiel sur la dynamique de l’équipe? Risque-t-il de mettre en péril la participation et l’auto-organisation? Quel est le niveau de maturité de l’équipe? Est-elle prête à cet apprentissage ou se sentira-t-elle blessée par le fait que le Scrum Master n’a pas agi au moment de la rétrospective ?

Et au niveau du travail à réaliser, est-ce que cette expérience va avoir un impact négatif sur une livraison prévue par le Product Owner? Est-ce que l’équipe pourrait être blâmée par une partie prenante d’avoir pris cette tangente ?

Échec ou non?

Une des principales responsabilités d’un Scrum Master est de renforcer les rôles de Scrum. Au niveau de l’équipe de développement, cela se traduit par favoriser l’empirisme et l’auto-organisation. Lorsqu’il s’agit de comment l’équipe s’auto-organise, par le biais de cette responsabilité le Scrum Master devrait observer un rôle passif. D’un autre côté, le Scrum Master est également invité à être un agent de changement qui augmente la productivité de l’équipe. Finalement, il est responsable des bloqueurs au bon fonctionnement de Scrum. Cela apporte des nuances de gris dans la définition très noir et blanc ci-dessus.

Pour aider à naviguer dans ce gris – surtout face à l’échec anticipé – je fais souvent l’analogie suivante : ma fille de deux ans se balance sur sa chaise. Malgré quelques avertissements parentaux (« attention, si tu tombes tu vas avoir un bobo… »), elle semble vouloir continuer. Si elle est sur sa toute petite chaise (à 50 cm du sol) et que la chaise est sur un tapis mou, en tombant elle ne se fera qu’un peu mal. Elle va pleurer, mais rien de potentiellement grave. La valeur de l’apprentissage (je suis tombée en me balançant, c’est dangereux) vaut le coût (impact très léger et une petite douleur). Si elle le fait sur une chaise plus haute positionnée sur le bord de l’escalier, la valeur du même apprentissage ne vaut certainement pas le coût de débouler en bas de l’escalier.

On peut associer ici l’image de l’enfant à l’équipe Scrum : essayer des choses et apprendre en vivant le résultat de ces essais. Si elle est privée des apprentissages plus difficiles par un Scrum Master trop protecteur, l’équipe va avoir du mal à encaisser et à se responsabiliser face à des échecs ultérieurs – un peu comme un enfant trop protégé. Soyez protecteur de votre équipe Scrum, mais laissez-la apprendre. Les petits échecs vécus en équipe forgent le caractère et ont souvent un impact positif à long terme.