Les conversations autour de l’agilité sont souvent centrées sur le cadre Scrum, avec ses réunions programmées et ses rôles définis. Cependant, à mesure que la philosophie agile mûrit, cette attention est-elle en train de changer ? Dans cet entretien, Jon Fazzaro, coach agile Full-Stack, aborde cette question et bien d’autres.
Avec brio, Jon remet en question le recours exclusif à Scrum comme tremplin vers l’agilité. Il prône plutôt une approche agile plus organique.
Au fil de la discussion, la rétrospective occupe une place centrale et le rôle du coach est examiné.
Enfin, des éclairages sur la santé des équipes agiles sont partagés, ainsi que de précieux conseils pour accompagner votre équipe.
C’est parti !
Une perspective évolutive sur Scrum
J’ai lu votre article sur Medium « La Rétrospective est le cœur du projet ». Pensez-vous toujours que c’est le cas ou diriez-vous qu’il y a un point plus important à considérer maintenant ?
Depuis la rédaction de cet article, j’ai définitivement cessé de penser que Scrum est la meilleure façon de commencer à être agile, si ce n’est pas déjà le cas.
Je vais reprendre une métaphore que Joshua Kerievsky, notre directeur, a utilisée il y a quelque temps lors d’une conférence.
Pour apprendre à faire du vélo, il faut utiliser des petites roues d’entraînement. Du moins, c’est comme ça que la plupart des enfants le font ; ils ont de petites roues d’entraînement boulonnées sur le côté de leur vélo. Ils apprennent d’abord à pédaler. Du coup, lorsqu’on retire les petites roues d’entraînement, la première chose qu’ils font, c’est tomber. Ils ne se rendent pas compte qu’ils doivent pédaler en avant. Ils n’ont pas appris à garder l’équilibre.
Il existe une autre façon d’apprendre aux enfants à faire du vélo : la draisienne. C’est très simple. Il n’y a même pas de pédales. C’est un vélo, avec deux roues et une selle. On leur dit simplement de marcher ; on avance et on voit s’ils peuvent se déplacer en trottinette et garder l’équilibre.
C’est la meilleure façon d’apprendre à un enfant à faire du vélo. L’équilibre est le plus difficile, pas le pédalage.
De la même manière, Scrum est le moyen le plus courant pour les équipes de dire : « OK, il faut devenir agiles, on adopte Scrum !» Puis, elles se lancent et s’équipent de leurs petites roues Scrum. Elles disent : « Voilà les réunions, voici les rôles, et voilà ce qu’on fait.»
Malheureusement, en pratique, Scrum n’en fait pas assez.
Ne vous méprenez pas. Sur le papier, le guide est très bon. Il regorge de très bonnes idées. Mais Scrum n’en fait généralement pas assez pour enseigner à une équipe ce dont elle a vraiment besoin pour être agile.
Le rôle des rétrospectives dans les équipes agiles
Votre position sur Scrum et son lien avec l’Agile ayant évolué, qu’en est-il de la rétrospective ?
Je continue de penser qu’il est important de s’arrêter de travailler et de discuter de la façon dont on travaille. C’est le plus important, à mon avis. J’aime l’idée d’avoir des rétrospectives plus fréquentes, pour accélérer le rythme.
L’équipe n’a pas besoin de faire une rétrospective intense de deux heures chaque jour. En revanche, si vous consacriez une demi-heure chaque jour à un moment précis, un rythme cardiaque, vous pourriez découvrir plus tôt des éléments importants. Plutôt que d’attendre deux semaines pour corriger le problème et d’accumuler un retard sur d’autres tâches à traiter, l’équipe peut s’y attaquer presque immédiatement.
Franchement, c’est plus agile. Plutôt que de tout mettre en lot et d’attendre.
Que pourrait signifier ce rythme cardiaque régulier, voire plus rapide, pour l’équipe de direction d’une organisation ?
Apparemment, ils se soucient du bon fonctionnement de l’équipe et de sa performance à un rythme prévisible. En tant que personnes responsables des activités des équipes, elles souhaitent pouvoir compter sur elles pour produire ce dont elles ont besoin afin d’atteindre leurs objectifs commerciaux.
Si une équipe ne se réunit pas régulièrement et ne s’accorde pas, elle risque de devenir imprévisible. Elle peut avoir connu une semaine exceptionnelle grâce aux heures supplémentaires effectuées par tous, mais elle est épuisée. Elle crée alors des bugs et des bêtises pendant les trois semaines suivantes.
C’est donc ce qui m’importerait dans un poste de direction. Je pense que c’est très précieux de le savoir.
Le coach agile et les rétrospectives efficaces
Quels indicateurs, pas nécessairement des données, un Scrum Master pourrait-il rechercher, sachant que tous n’ont pas d’expérience en développement ?
Eh bien, dans la rétrospective, un Scrum Master est fondamentalement leur coach.
Si l’on applique une métaphore sportive, un coach est généralement un expert du jeu. Peut-être un ancien joueur. Pour être utile, il doit partir du principe qu’il ne peut pas aider les joueurs en jouant lui-même.
La personne qui anime la rétrospective doit sortir du sujet de la conversation. Elle doit en observer le contenu.
Il peut donc être utile qu’elle ne comprenne pas certains points abordés, car ils pourraient la distraire. Cela pourrait détourner son attention de l’observation des interactions au sein de l’équipe. Imaginons que quelqu’un se fasse constamment interrompre. C’est là que le coach peut intervenir. Il peut aider à ajuster la conversation.
Si le contenu de la conversation appartient à ceux qui l’ont, il arrive que la mécanique de celle-ci déraille. Il faut une personne qui observe simplement son déroulement. On peut les inciter à mieux « jouer » ensemble.
Contribuent-ils à optimiser ce « jeu » ?
Oui.
S’ils souhaitent aller plus loin, que pourrait faire le coach ?
L’expression qui me vient à l’esprit est « maintenir l’espace » issue de la technologie Open Space.
Maintenir l’espace est une mission à part entière. C’est ce que ferait un facilitateur de rétrospective, qu’il soit coach ou Scrum Master, quel que soit son titre. Ce rôle consiste à faciliter la conversation. Vous n’êtes pas impliqué dans le contenu, mais vous créez le cadre et surveillez le déroulement de la conversation.
Cela implique de communiquer sur la manière dont vous allez mener la conversation. Vous avez défini les points clés de cette conversation. Vous avez fixé les limites. Cela demande un travail de conception important.
D’après mon expérience, lorsqu’une rétrospective ne se déroule pas bien, c’est généralement parce que la personne qui l’anime n’a pas pris le temps de la concevoir. Ils improvisent un peu.
Ce n’est pas utile.
Ce qui est utile, c’est de fixer un créneau horaire, disons 10 minutes. Une fois ce délai écoulé, ils ne sont pas trop superficiels, mais fermes. « Bon, on a fini d’en parler, il est temps de prendre une décision et de passer à autre chose.»
Ces paramètres sont donc très importants pour un espace efficace. Qu’avez-vous observé de problématique qu’une simple solution aurait pu résoudre ?
En matière de rétrospectives, l’erreur courante est de dire : « Ayons une conversation ouverte.» Ensuite, le groupe discute de ce qui les préoccupe. Bien que ce soit important dans certains espaces, il est essentiel de tirer profit du temps consacré à une rétrospective.
N’oubliez pas : nous ne travaillons pas sur le travail. Nous travaillons sur l’équipe. Nous travaillons sur notre façon de travailler.
Ce qu’on oublie souvent, lorsqu’on discute de nos ressentis, c’est de retracer ce qui s’est réellement passé. Il faut s’assurer que tout le monde dans la salle a une représentation mentale similaire de ce dont on parle.
Donc, un alignement. Un calibrage pour savoir si nous sommes d’accord sur les faits.
Souvent, pour moi, un outil pratique pour y parvenir est de prendre quelques minutes et de demander à l’équipe d’établir une chronologie des événements. Tracez une ligne horizontale sur un tableau et commencez à y noter des notes. « Au début du sprint, ceci s’est produit, puis il y a eu ceci. »
Cela permet d’éviter tout biais de récence. Les participants ne se contenteront pas de penser aux événements survenus au cours des deux derniers jours, des deux dernières heures. C’est important, surtout s’il s’agit d’une itération de deux semaines, d’un mois ou plus. Il y a beaucoup de choses dont on ne se souviendra pas.
Leur laisser le temps de se souvenir activement est très utile.
Certains membres de l’équipe n’ont peut-être pas ressenti la même chose ou ne se sont pas souvenus aussi clairement de certaines choses. Ils ont peut-être entendu parler de quelque chose, mais n’y ont pas participé. Cela leur donne une vision plus globale et partagée.
À partir de là, une fois que l’équipe s’est mise d’accord sur ce qui s’est passé, ils peuvent discuter de ce que cela signifie, de leurs sentiments et des améliorations possibles.
L’amnésie peut être abordée en premier.
Ou simplement des points de vue totalement différents. Des modèles mentaux complètement différents de ce qui s’est passé peuvent être abordés avant le début de la rétrospective.
Imaginez donc l’alternative. Passer directement à la question : « C’était bien ou mal ? » Chacun a sa propre version des faits. Ces histoires sont toutes complètement différentes. Cela signifie que les mots utilisés pour décrire les choses seront totalement inappropriés du point de vue de l’autre personne. Il n’y aura aucun lien. Aucune compréhension ne pourra en découler.
Les équipes agiles comme systèmes vivants : explorer la métaphore
Maintenant, pour approfondir votre maîtrise de la métaphore, si la rétrospective est le battement de cœur, qu’est-ce que l’équipe ?
C’est un système. Un ensemble d’organes travaillant ensemble. Exécutant différentes tâches. Il essaie de continuer, de grandir, d’apprendre. Il essaie d’être en bonne santé.
Cela nous amène parfaitement à la question de la santé d’une équipe. Avez-vous déjà rencontré une équipe dysfonctionnelle mais efficace ? Il y a des personnes très performantes qui ont de vrais problèmes.
Bien sûr, elles s’en sortent. C’est pourtant l’expression : « s’en sortir ». Si vous surmontez quelque chose, vous savez qu’il y a probablement une difficulté que les personnes en meilleure santé ne trouvent pas difficile. Il y a des occasions manquées.
Cela nous ramène à la prévisibilité. Je pense que l’un des aspects les plus dévastateurs d’une maladie grave est le caractère imprévisible que cela rendrait ma vie. Je ne pouvais pas vraiment faire de projets, car je ne savais pas si je allais tomber subitement. J’aurais peut-être besoin d’une ambulance et d’aller à l’hôpital. Et voilà ma semaine.
Je pense que c’est ça, la santé et la métaphore de la santé. On fait des efforts supplémentaires pour améliorer les choses et rendre le monde plus facile.
D’après mon expérience personnelle, je suis plutôt nulle pour faire de l’exercice et maintenir une routine. Mais il y a eu des périodes dans ma vie où j’y arrivais bien pendant quelques mois. Je faisais un exercice minimal, disons 10 pompes par jour. Et j’y suis restée bonne pendant une longue période.
Lorsque j’y arrivais bien, mon observation la plus précise sur ce que je ressentais, ce n’était pas que je me sentais plus grande ou plus forte. J’avais plutôt l’impression que le monde était devenu plus facile. La difficulté était repoussée.
Cette fluidité. Cette aisance de mouvement quand on est en bonne santé. C’est pourquoi je pense que c’est ce qu’on recherche avec une équipe quand on l’adapte correctement. L’effet sur les personnes pour lesquelles cette équipe travaille, c’est que l’équipe est prévisible, comme une horloge, fiable, vous savez ?
Il y a une idée de la dose minimale efficace dans « The 4-Hour Body » de Tim Ferriss. Il n’est pas nécessaire d’être en forme olympique, c’est le minimum pour avoir un effet positif. Quel est le minimum que nous pouvons faire pour avoir un effet positif sur l’équipe ? Ce qui est suffisant dans bien des cas.
Symptômes d’une équipe agile en bonne santé
Que pourrait observer un animateur d’une rétrospective pour évaluer la santé de son équipe ?
Eh bien, il devrait absolument voir les décisions prises. Le paysage change au sein d’une équipe saine. Ils peaufinent leurs stratégies. Ils s’ajustent. Ils expérimentent librement.
La responsabilité n’incombe pas à un individu. Elle incombe à chacun. Il règne une sorte d’atmosphère irréprochable, du genre : « Tiens, ça ne s’est pas si bien passé ». Ils peuvent identifier que quelqu’un a fait quelque chose et que cela a posé problème, mais on ne leur dirait pas : « Quand tu as fait ça, ça a vraiment tout gâché, et qu’est-ce que tu vas faire pour y remédier ?» Il s’agit plutôt de se demander : « Que pouvons-nous faire de mieux pour réagir ? » On sait que la responsabilité incombe à toute l’équipe, même lorsque les actions d’une seule personne ont pu causer un problème.
En général, il existe une notion d’irréprochabilité.
Ils gèrent bien les conflits.
Le symptôme d’une bonne équipe est qu’elle ne se tait pas, qu’elle se plaint. Parce qu’ils bénéficient d’une atmosphère de sécurité fondamentale dans laquelle ils se sentent capables de faire remonter les choses qui les dérangent.
Une dernière perle de sagesse agile
À 30 secondes de la fin et sans préavis, quel est votre conseil ultime pour quiconque se lance dans une démarche agile ?
Arrêtez-vous pour faire une rétrospective avant d’en avoir besoin.
Beaucoup d’équipes ne se réunissent pour discuter d’un problème que lorsqu’il devient problématique, et il est facile de sauter la rétrospective quand tout semble aller pour le mieux. Si vous avez fait cela, vous n’avez pas inspecté attentivement et découvert l’élément susceptible de poser problème. Dans quelques semaines ou quelques jours.
Merci!
Un grand merci à Jon Fazzaro pour sa participation à cet entretien.
Jon est coach Agile Full-Stack et travaille dans le développement logiciel depuis plus de vingt ans. Il est un fervent défenseur des pratiques agiles modernes comme la programmation d’ensemble, le développement piloté par les tests et la collaboration quotidienne avec les parties prenantes. Il est également un fervent défenseur du Lean Product Management et de la pensée systémique.
Jon intervient régulièrement lors de conférences sur les logiciels depuis 2015. Vous pouvez consulter « Oh! The Humanity », un aperçu de sa réflexion professionnelle actuelle.