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

pawel mysliwiec

Détenteur d’un Master en Informatique depuis 2003, Pawel a joué divers rôles depuis le début de sa carrière: programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et architecte d’affaires; dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et d’affaires.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s’est joint à Pyxis en 2015 pour continuer à aider les individus et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client. Il a joué le rôle de coach Agile et Lean dans des organisations de diverses tailles et à divers niveaux. Il est également formateur certifié par Scrum.org et offre les formations de Professional Scrum Master et Professional Product Owner publiques et privées au niveau international.

Billet précédent

Comment plus d’amour authentique pourrait-il nourrir votre leadership?

Billet suivant

Journal d’un stagiaire

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.