Rétrospective sur SCRUM, 3ème et dernière partie🔗

Cet article est le dernier de cette série sur SCRUM. Cette fois, je vais prendre le temps de vous présenter comment la méthode a réussi à dépasser les problèmes d'équipe que j'avais listé dans le 1er article. Je reprends un à un les points que j'avais évoqué en reprenant les mêmes titres.

Encore une fois, c'est mon vécu avec ses limites et son contexte. Néanmoins, ça reste mon analyse.

Ce que j'ai pu mesurer c'est que SCRUM permet de faire fi de la peur du changement. Dès le départ, l'équipe se rend compte qu'elle peut, mieux, doit faire des erreurs pour progresser. Affiner une vision du client vers le produit qu'il souhaite vraiment, c'est source d'erreur. On va forcément se planter à un moment où un autre. Mais ce qui est rassurant c'est qu'au pire, on aura perdu une ou deux itérations au maximum. Ça fait toujours mal mais ce n'est pas deux ans (et la galère des corrections qui s'étalent derrière).

Le fait aussi de travailler tout le temps le backlog ou le scrum board fait qu'on n'hésite pas à ajuster les premières sorties. En mode itératif, on construit quelque-chose au fur et à mesure et, très souvent, on doit ajuster les paramètres ou revenir sur des choix initiaux, quand on s'est rendu compte que ce n'était pas une bonne idée. Dans SCRUM, les phases de préparation des Sprints sont dédiées à ça. Mieux, la démonstration viendra valider ou non les évolutions et le client sera forcément entendu, devant toute l'équipe qui ne pourra pas faire semblant de ne pas l'avoir écouté (car on note devant lui ce qu'il remonte). Ce n'est pas un contexte où on peut facilement botter en touche passivement en écoutant poliment les gens.

Ce que j'ai constaté c'est que si on peut avoir quelques craintes au début, après deux ou trois itérations, on n'hésite plus à faire des ajustements quand c'est nécessaire. C'est même la base du travail en itération, par couches successives où on ne peut jamais définir dès le départ la totalité des opérations ou des fonctionnalités à mettre en place.

Par exemple, si le client veut un programme en ligne de commande avec des options pour réaliser des travaux complémentaires, il ne sera jamais capable de définir tout depuis le départ. Pire, l'équipe va peut-être se dire au départ qu'il y aura un jeu limité d'option mais finalement se retrouver à devoir revoir complètement cette gestion d'options au beau milieu du projet parce qu'on se sera rendu compte que gérer autant d'options que dans curl, c'est trop complexe pour le client, qu'il veut finalement plutôt utiliser un fonctionnement par sous-commande comme dans git.

En mode projet classique (en V), on se débrouillera pour limiter le plus possible ces options. En mode SCRUM, si le client est convainquant et si cette action a été correctement priorisée, on n'hésitera pas à revoir le truc. Et comme en plus on se sera aperçu par soi-même lors de plusieurs démos qu'il semblait y avoir un problème avec la gestion des options, je suis certain que des membres de l'équipe auront déjà quelques idées de refonte adaptée à la commande du client.

Dans SCRUM, quand on fait ça bien, il y a le sprint 0 qui est, pour le coup, indispensable. Ça consiste à passer une première itération du projet à travailler avec les clients pour définir et comprendre ce qu'ils veulent dans les grandes lignes. Ça permet de préparer une espèce de cahier des charges mais surtout, de pouvoir alimenter les premiers sprints en éléments de travail et de fixer les grandes lignes du projet, son contour.

Ne vous lancez pas sans cet impératif, sans cette étape initiale: ce sera très dur de remonter la pente et ce sera source de frustration. En mode Agile, on n'a pas besoin d'un cahier des charges ultra-précis qui prend du temps à rédiger. On peut se satisfaire de choses plus légères au départ. Mais partir de rien, c'est pratiquement l'échec assuré.

L'intérêt principal de Scrum, c'est de considérer que les besoins des clients évoluent au fur et à mesure du projet, essentiellement parce qu'ils avaient au départ une vision simple et trop abstraite ou virtuelle des choses, du contexte. Peut-être aussi avaient-ils simplement des idées qui se révèlent fausses ou pas adaptées à leur réel besoin. Un besoin de client, ça prend du temps à maturer et partir tout de suite sur une idée figée comme on l'a dans la méthode en V, c'est pratiquement s'assurer qu'à la fin du projet, le client verra son besoin réel non couvert (par contre, son faux/non besoin sera assurément couvert).

Ce que j'ai bien aimé dans Scrum, c'est cette adéquation à toujours travailler directement au plus proche du client pendant plusieurs heures pour toujours recalibrer son besoin et voir comment y répondre de la manière la plus efficace possible, par petites itérations. Cela permet vraiment d'évacuer les biais de projets tels que les besoins qui ne font pas consensus (quand on a un groupe comme client), les caprices (des choses qui coûtent cher pour peu d'efficacité) ou les fausses bonnes idées. Scrum permet réellement, selon mon expérience de se reposer très fréquemment des questions sur la pertinence de tel ou tel point. La conséquence, c'est que quand c'est bien fait et avec des clients non malveillants, on évite très souvent de travailler sur des choses inutiles, pour aller à l'essentiel, pour se concentrer sur ce qui apporte de la valeur ajoutée.

Et ça, pour l'avoir vécu, ça fait du bien, ça fait du sens. Personne ne se pose plus de question pour savoir si tel ou tel point est vraiment nécessaire ou pas. Une fois débattu, pas de remise en question constante. On sait ce qu'on a fait et on sait où on va, sans supposer ou sans réfléchir à la place du client, sans devoir imaginer ce qu'il veut et finalement, passer à côté de l'essentiel. La conséquence la plus directe, c'est que l'engagement des travailleurs est maximisé, car on ne s'investit pas autant si ce sur quoi on va passer plusieurs heures n'est pas réellement justifié.

Bon, attention, Scrum, ça n'est pas magique, ça n'exclue pas les fausses routes ou l'exploratoire: le client peut toujours vouloir faire une chose, réussir à la vendre à l'équipe qui aura bien compris ce qu'il fallait faire pour qu'au final, après une itération et une présentation au client (ou une période d'essai de prototype), ce dernier se rende compte qu'en fait, cette chose est finalement inutile. Au pire, on passe une itération (15 jours max) et on réajuste. En cycle en V, ça se voit uniquement à la fin du projet: on a travaillé beaucoup de temps pour un truc inutile.

En appliquant avec discernement la méthode Scrum on évite très certainement l'écueil de mobiliser des efforts pour des coups d'épée dans l'eau. Et ça, c'est bien !

Dans SCRUM, la documentation reprend une place plus équilibrée que dans les projets à cycle en V: c'est un écrit d'un état de connaissance et pas un bouclier comme je le citais dans mon article précédent. Dans une équipe qui se parle, on n'a pas besoin de matérialiser par écrit toute la gestion au millimètre près pour se dédouaner de tout incident.

Au contraire, dans Scrum, il y a des documents/artefacts dédiés (scrumboard/vision globale et surtout le backlog) qui donnent un aperçu des avancées de l'équipe d'un point de vue macro. On considère que tout ce qui relève du détail de l'implémentation technique ou des décisions techniques repose sur une connaissance partagée de l'équipe de conception qui gère ces éléments de détails en direct, à l'oral. Cela permet de pouvoir présenter une vision d'ensemble au client sans le perdre dans des sujets sur lesquels il n'a pas forcément la maîtrise.

Mieux, cela renforce la résolution des problèmes par l'oral plutôt que de laisser ça moisir dans un écrit, à moitié masqué parce que laissé à la bonne volonté du lecteur. Et puis, les gens ne peuvent plus se dédouaner en disant: ce n'est pas écrit dans la documentation, donc je ne le fais pas. Au contraire, on repose les bases d'une gestion plus saine:

• tu as un rôle, à toi de le remplir dans sa totalité d'action. Un rôle donne les grandes lignes d'un travail à réaliser, des objectifs. Ça ne donne pas la totalité des tâches que la personne doit effectuer.
• pour t'aider, la documentation macro est à ta disposition.
• en plus, tu vas rapidement la maîtriser car elle est légère.

Et puis surtout, avec Scrum, terminé les documents de 500 pages que personne ne lit et qui me désolent, qui mobilisent du temps de cerveau pour rien. Et ça, ça fait aussi du bien.

Dans SCRUM, il n'y a pas de repos sur la bonne volonté. Il y a une méthode à suivre, avec quelques ajustements sur la gestion des relations humaines et voilà. Pas de groupe projet volatil, bien au contraire. D'ailleurs, si je peux vous donner un conseil, c'est de vous assurer en tant que Scrum Master que les membres de votre équipe vous sont bien dédiés.

Scrum ça soude une équipe. Le fait de travailler tous les jours ensemble, d'échanger au quotidien une fois par jour, d'avoir une vision commune toujours à jour, de savoir exactement qui fait quoi à quel moment, de s'entraider, de surmonter des épreuves ensemble, de se réinterroger tous les 15 jours sur la gestion de l'équipe, de voir les progrès accomplis, ça ne peut pas laisser indifférent.

Dans ces conditions, Scrum renforce l'aspect positif de la bonne volonté (on est tous ensemble vers un but unique) sans donner la possibilité de se barrer à la première difficulté (c'est une équipe vraie, dédiée).

Par expérience, les gens qui ne sont pas à 100% dans votre équipe ne devraient pas y être: SCRUM c'est trop engageant factuellement pour s'y consacrer à moitié, invariablement ce qui finira par se produire c'est que la personne à temps partiel dans l'équipe finira par s'investir à 100% et devra faire le reste de son travail sur un temps supplémentaire. Bien souvent, j'ai vu des gens à temps partiel dire à la fin d'un ou deux sprints qu'ils ne pourraient plus suivre et qu'ils devraient quitter l'équipe. Donc, mon seul conseil c'est de négocier en amont les ressources pour qu'elles soient à 100% dans l'équipe SCRUM. Si ce n'est pas possible, ne lancez pas le projet tout simplement, les conditions de base ne sont pas réunies, autant ne pas aller dans le mur dès le départ.

Par ailleurs, assurez-vous aussi que les membres de votre équipe restent pendant la majorité des sprints prévus. Comme je l'ai déjà écrit, SCRUM c'est engageant et ça améliore le fonctionnement intrinsèque d'une équipe avec la mise en place de liens de rôles non écrits, de fait. L'équipe s'auto-organise et le moindre départ vient la déstabiliser, parfois durement. Donc, autant s'assurer que les gens seront disponibles sur toute la durée du projet. Si ce n'est pas possible, encore une fois, mieux vaut ne pas lancer le projet.

Dans mon expérience, SCRUM favorise plutôt le silo. J'ai pu remarquer que tout est centré sur l'équipe et le client. Tout ce qui vient en dehors est complètement hors clou, invisible. Les gens sont concentrés sur le travail et la méthode leur rappelle souvent où ils doivent porter leur attention. Ça veut dire que de-facto l'équipe Scrum est un silo. Pire encore, Scrum, ça automatise le centrage de l'attention aussi sur les besoins du client. Tout ce qui vient en dehors de cette sphère est pratiquement invisible.

Ça a l'avantage certain que SCRUM réduit la procrastination et permet aussi une meilleure efficacité et une meilleure productivité de l'équipe qui n'est pas perturbée par autre chose.

Toutefois, ça a un certain nombre d'inconvénients dont il faut être conscient:

• les gens en dehors de l'équipe sont tous à l'ouest par rapport à ce qui s'y passe.
• l'équipe est seule et ne peut pas du tout avoir de soutien externe, à moins d'internaliser ce soutien (c'est ce que je recommande).
• les gens en dehors de l'équipe peuvent venir vous faire chier et il vaut mieux le prévoir que de le subir.
• si vous devez passer le flambeau à une autre équipe, ce sera difficile, même en prévoyant une phase de transition.

Donc, il faut en tenir compte dès le départ: tout ce qui est en dehors de l'équipe ne devrait pas du tout avoir voix au chapitre, en dehors des clients. Même (et surtout en fait) les managers. SCRUM c'est de l'auto-organisation à la base. C'est complètement obtus de faire prendre des décisions techniques à des gens extérieurs à l'équipe, car les personnes extérieures n'ont absolument pas le contexte ni l'historique sur les choix. Si tu veux décider, tu fais partie de l'équipe, sinon autant refaire du cycle en V.

Si vous devez regrouper des interactions avec d'autres équipes, il vaut mieux les intégrer au processus SCRUM, voire à l'équipe, ce sera beaucoup plus efficace. Par exemple, si à un moment vous avez besoin de compétences particulières pour monter votre prototype (genre mise en place d'une config générique de VM pour déploiement automatisé réalisé par un dieu d'Ansible), ce sera toujours mieux d'intégrer cette personne dans l'équipe pour un ou plusieurs Sprints, le temps que le travail soit fait: elle verra ce qui avance et comprendra mieux ce qu'on attend d'elle.

Dans SCRUM, on dit tout, on ne cache rien sous le tapis: il y a des moments pour gérer cette parole et pour la laisser s'exprimer (la rétrospective mais aussi les sprint plannings). Et comme le fonctionnement de groupe est fort et interactif, la parole se libère facilement, car c'est elle qui est la principale vectrice des progrès de l'équipe.

Dans Scrum, soit tu parles au moment opportun, soit, c'est trop tard. On n'a plus les comportements qui viennent tacler tout le monde en mode: je vous l'avais bien dit que ça ne marcherait pas ! Au contraire, dans un Sprint planning, on passe un temps non négligeable à arbitrer ce qu'on doit faire et aussi à détailler comment on va le faire et cette étape, c'est une décision collective qui oblige les membres de l'équipe à discuter et débattre pour trouver ensemble la meilleure solution. Donc quand une fiche de User Story sort, c'est qu'elle a été soupesée, débattue et arbitrée et qu'elle représente un consensus. C'est l'anti-royaume du non-dit où chacun ferme sa gueule pour se couvrir. Au contraire, ici, on va au contact, on se met à nu, dès le départ pour éviter de couler tous ensemble.

Pire encore, comme je l'ai déjà écrit dans l'article précédent, tout est fait pour que l'équipe se parle, notamment lors des mêlées qui ne sont qu'un exercice de synchronisation à l'oral où chacun rend compte. Quand quelqu'un ne fait pas son travail (parce qu'il s'en fout ou parce qu'il fait autre chose), ça se voit tout de suite. Et comme c'est visible, ça pose tout de suite un problème qui sera au pire traité en rétrospective, au mieux, pendant la mêlée.

De plus, lors des rétrospectives, on se dit ce qui ne va pas. C'est un temps dédié à ça. Le simple fait que ça existe permet de libérer la parole: on va passer une heure à se dire les choses. À comparer avec la résolution des problèmes en équipe en mode non SCRUM où on doit monter une réunion ad-hoc ou dans un passage de couloir entre deux portes de bureau. La rétrospective c'est là qu'on peut se lâcher et pointer les dysfonctionnements, parfois même pointer vers une personne qui pose problème. Le fait d'avoir des temps dédié à cette parole renforce assurément le rôle du collectif. Et donc, au lieu d'avoir un groupe de personnes avec des liens faibles qui peuvent s'opposer, on a un ensemble qui essaye de tracer un horizon commun.

Très clairement, essayer de faire passer des trucs sous le tapis c'est compliqué avec la méthode SCRUM.

Vous l'avez sans doute compris, j'ai plutôt un bon retour d'expérience sur SCRUM. Pour la première fois de ma vie, j'ai vu une méthode qui sans être parfaite tente de remédier à tous les problèmes sus-cités. Elle y parvient même assez facilement, je dois l'avouer.

Pourtant, tout n'est pas parfait, loin de là. À ce stade de l'aventure, j'ai bien compris que comme tout ce qui a trait au facteur humain ou au travail en groupe, l'attitude, le comportement des individus joue un rôle clef. Si vous avez dans votre groupe des sceptiques de la méthode ou des gens qui ne veulent pas, il y a des chances que ça ne se passe pas très bien ou que ce soit un échec.

De mon point de vue sans doute un peu trop rationnel, c'est quand même assez dingue de se dire que l'état d'esprit des individus qui constituent une équipe a un tel poids sur le destin d'un projet. Néanmoins, c'est ce point qui m'invite toujours à prendre garde lors d'un échec, car je sais maintenant que même avec les bonnes conditions réunies, même avec les moyens adéquats, même avec la bonne méthode de gestion de projet, même avec la meilleure volonté du monde, il suffit de peu, d'un rien presque insignifiant, pour rater une seule marche et voir s'écrouler un édifice. Comme on dit "haters gonna hate".

Dans tous les cas, j'ai vraiment bien aimé mon rôle de Scrum Master pendant ces 5 années. Ça m'a beaucoup coûté d'un point de vue personnel parce que j'apprécie beaucoup les temps où je peux travailler seul en concentrant mon cerveau sans être perturbé. Mais ça a été une véritable révolution de constater que j'arrivais à piloter une équipe sans lien hiérarchique avec un relatif brio et d'avoir des retours positifs de tout le monde. C'est lié à la méthode mais aussi à mon engagement à m'y atteler pleinement. De fait, ça a complètement brisé les quelques appréhensions que je pouvais avoir par rapport au monde du travail et des relations entre les personnes: je sais que je sais gérer ça à peu près correctement.