Rétrospective sur SCRUM, 2ème partie🔗

Cet article fait suite à mon article précédent sur Scrum, il y a plus d'un an déjà. Cette fois, je vais vous présenter ce que j'ai mis en place comme conduite de projet sous Scrum. Mon objectif n'est pas de servir de référence, juste de donner les grandes lignes pour illustrer les concepts et donner une proposition. Sachez qu'en plus de ces éléments, j'applique tout un tas de recettes apprises sur le tas pour faciliter ou mieux gérer les réunions et les réactions humaines. Ces recettes influencent fortement la réussite ou l'échec d'un projet en mode SCRUM.

Globalement SCRUM est une méthode qui suit les préceptes du manifeste Agile (je vous laisse le lire ici). Mais comme c'est une méthode qui vise principalement à surmonter des problèmes humains (SCRUM ça n'est pas fait pour vous faire progresser individuellement dans votre pratique du C par exemple), il faut toujours l'adapter au groupe dans lequel vous évoluez.

Pour résumer, SCRUM consiste à travailler en plusieurs sessions de période courte (de 5 à 15 jours ouvrés) avec une équipe à taille humaine (de 6 à 8 personnes, pour mieux gérer les interactions) en forte interaction avec les clients (selon le manifeste Agile). Chaque session est une itération sur le projet et s'intitule "Sprint". L'ensemble des Sprints permet de séquencer le projet en petites phases de travail concentré. Le travail s'auto-organise par, pour et avec les membres de l'équipe. L'équipe est une entité morale qui dispose de règles de gestion internes et qui définit, en lien avec le client, sa feuille de route et son plan de travail. C'est aussi l'équipe qui prend les décisions techniques qui s'imposent, à la lumière de ses réalisations et de ses compétences.

SCRUM a peu de documentation, tout se gère principalement avec de grands tableaux en physique ou en virtuel pour donner une vue d'ensemble ou détaillée. D'abord, il vous faut un backlog, c'est-à-dire un ensemble de fiches qui décrivent rapidement les besoins et les attentes du client. Ces fiches sont nommées User Story: elles racontent ce que le client fait quand il utilise le produit. Ça sert de cahier des charges léger mais toujours actualisé et toujours fil conducteur (pas le pavé de 500 pages que personne ne lit et qui moisi dans un coin de fichier). C'est un document de référence qui prend la forme d'un tableau papier avec des feuilles collées dessus. On peut aussi utiliser un "truc" en ligne, du moment qu'on a une vision d'ensemble et que tout le monde puisse lire ce qu'il y a dessus.

Ensuite, il vous faut un scrumboard: un tableau matriciel avec 4 colonnes: US, A faire, En cours, terminé. C'est ce qui va permettre de tracer l'avancement quotidien de l'équipe. Il offre une vue détaillée de l'action sur un Sprint.

En dehors de ces documents, il faudra prévoir un stock de post-its, de feutres, de papier blanc, etc. SCRUM par mon expérience, ça consomme pas mal de papier. Au final, je suis sûr qu'on obtient les 500 pages de cahier des charges mais présentées très différemment.

En termes de rôles, on trouve (succinctement):

• le Product Owner (PO) ou responsable produit qui a en charge de porter la relation privilégiée avec le client. Il connaît bien le client et ses besoins et il est capable de négocier et discuter avec lui. Par ailleurs, c'est lui qui garde la vision produit à long terme et d'un point de vue macro. Il sert également à faciliter la priorisation du travail dans le projet.
• Le client pour lequel l'équipe travaille. Dans l'idéal, il est intégré dans l'équipe et on peut le mobiliser comme on veut pour lui montrer l'avancement ou pour lui poser des questions, avoir des retours. Dans SCRUM, le client doit dédier une partie de son temps de travail au projet. En mode Agile, on a fortement besoin de lui mais en contre-partie, il doit s'engager à être présent pour l'équipe qui va travailler à couvrir son besoin.
• le Scrum master est la personne qui est chargée de mener l'équipe pour qu'elle puisse suivre la méthode SCRUM correctement. Oui, SCRUM c'est compliqué, il y a plein de règles à suivre, plein de facteur humain à prendre en compte donc avoir une personne responsable, c'est indispensable. En revanche, le Scrum Master n'a pas de lien hiérarchique avec son équipe: il ne distribue pas le travail car, je le rappelle, c'est important: l'équipe s'auto-organise pour déterminer ce qui est le plus efficace en fonction de ses disponibilités, de ses compétences et de son environnement. De fait, le Scrum Master, en tant que membre de l'équipe bosse avec elle aussi. Son travail ne peut pas se limiter à l'animation, il doit mettre les mains dans le cambouis pour pouvoir se rendre compte des difficultés.

Dans ce qui va suivre, je vais vous présenter les différents éléments qui constituent une itération SCRUM. C'est très précis et il faut absolument mettre en place ces réunions et livrer les documents qui en découlent. Ces éléments sont calibrés pour une équipe de 6 à 8 personnes avec un backlog déjà rempli et une durée d'itération de 10 à 12 jours ouvrés.

C'est une réunion qui consiste à gérer le backlog et à sélectionner les US qui seront jouées dans la prochaine itération.

Chez moi, c'est une réunion assez longue de 3 à 4h. Oui, ça peut sembler long mais c'est la réunion importante qui sert à partir sur de bonnes bases. Si on la foire, c'est là qu'on produit des choses inutiles, qu'on travaille pour rien. Donc il ne faut pas hésiter à y passer beaucoup de temps. Elle se prépare en amont avec le Product Owner et la réunion de fin d'itération précédente, pour déminer les sujets. Elle réunit les membres de l'équipe et le Product Owner ainsi que les clients. Si ces derniers ne sont pas disponibles, il faut que le Product Owner ait suffisamment de billes pour parler au nom des clients (mais c'est rare sur un projet complexe).

Dans la pratique, avoir le client sous la main à cette étape est aussi indispensable que de l'avoir à la démonstration, car c'est à cette étape qu'on se dit, tous ensembles ce qu'on doit faire. Très souvent, on a besoin du client pour se faire expliquer ce qu'il veut, ce qu'il voit. Il faut aussi, après ces clarifications, avoir l'avis du client sur les possibilités ou les impossibilités techniques pour faire un meilleur choix ou prendre une décision de ne pas faire telle ou telle partie d'US. De toute manière, si le client n'est pas là, vous allez finir par faire une phase où vous allez lui poser des questions pour faire avancer les US ou les comprendre correctement. Donc, lors d'un Backlog grooming, le client est là. Point.

Je la sépare en quatre phases:

1. Lecture/Débât sur les US à traiter dans le Sprint. Elles ont déjà été mâchées par le Product Owner, notamment en lien avec les clients. Cette étape sert à se familiariser avec le vocabulaire global, à prendre la température et à lever les ambiguïtés. Elle est vraiment indispensable et il faut y passer du temps, surtout dans les premières itérations.
2. Estimation de la priorité et de la complexité. Cette étape consiste à prioriser les US et estimer globalement leur complexité. Ici, je sépare les participants en 2 ou 3 groupes, je leur file plusieurs US et ils utilisent la technique du planning poker (ou tout ce qui va bien pour estimer ça collectivement) pour déterminer priorité et complexité. L'idée c'est de faire débat sur ce qui fait débat et pas d'obtenir un truc avec une note précise.
3. Mise en commun des priorités et complexité. La complexité est exprimée dans une échelle qui tient compte de la charge, du temps à y consacrer et des inconnues techniques. Au bout de quelques itérations, on doit savoir combien l'équipe est capable de gérer comme points de complexité dans une itération. Ensuite, on classe les US par priorité et complexité et on rassemble ce qui est prioritaire par colonne. Ça permet de voir ce qui peut être traité et qui est important. À la fin de cette phase, on sait quelles US seront traitées dans le ou les Sprint(s) à venir.
4. Pour conclure, on essaye de synthétiser les US à traiter en une phrase pour communiquer vers les clients et la hiérarchie.

Parfois, on peut faire un backlog grooming pour plusieurs itérations, par exemple en rassemblant plusieurs US qui concernent un même sujet. Mais en règle générale, plus il y a d'US à intégrer plus la réunion est longue et comme elle est intense, on finit par s'épuiser et à ne plus distinguer ce qui amène de la valeur ajoutée.

Chez moi, c'est une réunion assez longue de 4 à 5h. Oui, c'est encore long, mais c'est la réunion qui détermine en détail ce que l'équipe va faire. Donc, il n'y a pas à couper, ça prend du temps. Si vous avez une équipe qui sait bien communiquer et travailler, ça peut aller plus vite. Mais surtout, ne bâclez pas cette étape car cela conduirait à des soucis tout au long du Sprint et qui viendront polluer vos mêlées.

Si le backlog grooming a été correctement réalisé, il n'y a pas forcément besoin des clients. Mais, c'est mieux s'ils sont disponibles pour cette réunion, car il restera des questions et également des prises de décision technique qui pourront être facilitées et arbitrées plus facilement avec le client.

Je la sépare en quatre phases:

1. Lecture/Débât sur les US à traiter dans le Sprint. Elles ont déjà été mâchées lors du backlog grooming (la veille parfois), donc c'est assez rapide.
2. Travail en groupes de 3/4 personnes sur l'éclatement de la User Story en tâches. C'est l'étape où on remplit et affine la User Story et où on rentre dans le détail et on imagine comment répondre techniquement au besoin.
3. Mise en commun sur le scrumboard: on prend toutes les US et les tâches, on les colle sur le scrumboard et on prend du temps pour repartager le travail en groupe en commun. Ça permet de lever les ambiguïtés des groupes de travail qui, à force de discuter le sujet en détail, finissent par développer leur propre signification/vocabulaire incompréhensible pour le commun des mortels.
4. Estimation de la charge de travail pour voir si on va dans le mur. Lors du backlog grooming, on a estimé une complexité. À l'issue du Sprint Planning, on doit être en capacité d'estimer la charge en jour homme de chaque tâche et doc de chaque US. À la fin, on voit si on va dans le mur ou non et on retire les tâches en trop ou infaisable.

En sortie de réunion, on a un scrumboard prêt à être utilisé pour la première mêlée qui commence forcément le lendemain.

Tous les matins, on réunit toute l'équipe autour du scrumboard pour faire le point sur:

• ce qui a été fait depuis la veille.
• ce qui va être fait aujourd'hui.
• ce qui pose problème, va dans le mur, dérape, les appels à l'aide.

Ça dure 20 à 30 minutes de réunion debout (pour que ça dure moins longtemps). Et les gens s'expriment tous, les uns après les autres. Les gens doivent être efficaces et concentrés et ne pas raconter leur vie. Ils doivent aller à l'essentiel car maintenir une attention pendant plus de 20 minutes, c'est quasi impossible.

La mêlée c'est l'outil de pression interne et auto-alimenté de l'équipe. Si un mec ne branle rien, ça se voit tout de suite. Même sans rien dire, passer à l'oral devant tout le monde en étant le seul à dire: je n'ai rien fait, ça met la pression.

À l'inverse, la mêlée ne doit pas servir à gérer les problèmes, juste les évoquer et monter un binôme ou une réunion dédiée pour les gérer. La tentation va être grande de discuter des solutions aux problèmes pendant la mêlée mais ce n'est pas le lieu pour ça: tout le monde n'est pas forcément concerné et résoudre un problème ça prend généralement plus de 20 minutes. C'est pour ça qu'en tant qu'animateur, il faut constamment gérer et indiquer qu'on doit monter une réunion ad-hoc externe à la mêlée.

En règle générale, j'aime bien commencer ma journée par la mêlée: ça fixe le cap pour la journée et je ne suis pas tenté de faire autre chose avant.

Se voir tous les jours, s'entraider, voir chacun ses progrès et ses difficultés, ça soude une équipe, très clairement.

Voilà, l'équipe a travaillé pendant une itération complète (10 à 12 jours ouvrés). C'est le moment de faire le point avec le client et de lui mettre en main l'outil/le produit pour qu'il puisse juger de l'avancement pendant que l'équipe note ses réactions, notamment ce qui va et ce qui ne va pas. Voilà, ça c'est le principe.

Dans la pratique, suivant le produit que vous concevez, ça ne se passera pas forcément de la même manière et ce sera aussi relatif à l'état de maîtrise du produit par le client.

Par exemple, si vous avez un projet de remplacer une application simple par une autre en conservant le même workflow, vous pouvez mettre en place une démonstration simple en direct avec le client où ce dernier manipule lui-même immédiatement. C'est sans doute ce qu'il faut viser parce que si votre client, normalement l'expert du sujet, n'a, au bout de 2 ou 3 itérations, toujours pas compris comment utiliser son produit, c'est mauvais signe.

Souvent, si vous concevez un truc plus complexe ou qui change un peu le fonctionnement ou le workflow, il faudra généralement faire une introduction où c'est l'équipe qui fait une présentation au client dans un premier temps, avant la manipulation.

D'autres variantes consistent à séquencer les évolutions étape par étape, souvent par User Story. C'est ce que nous faisions parce que ça permet de faire le tour du produit et de faire vérifier directement chaque avancement.

Pour faciliter la récupération des réactions du client, il faut toujours préparer des personnes dont c'est le rôle de noter ces éléments. Le faire en direct et de reformuler chaque remarque pour lever les ambiguïtés est important. Attention, un retour client, ça va très vite, il faut être attentif. Dans cette phase, il ne faut pas hésiter à engager une discussion entre l'équipe de dev et le client sur chaque point qui peut poser problème.

Encore une fois, ça dépend du client, attendez-vous à avoir des retours déstabilisants. Certains clients se focalisent sur ce qui ne va pas et ça peut vite sembler négatif alors qu'en fait il est très content. Le conducteur de la réunion doit aussi accompagner le client pour lui faire remonter et surtout valider ce qui va bien et sur lequel on n'aura pas à revenir dans le futur. Et puis, c'est du manifeste Agile, on doit accepter le fait que le client puisse dire: "Après coup, maintenant que je le vois, je pense qu'il aurait fallu faire autrement". Ou pire: "finalement, après mûre réflexion, je crois qu'on va revenir à ce qui a été fait la dernière fois, c'est beaucoup mieux". Rassurez-vous, c'est du manifeste Agile, le tâtonnement ne dure jamais plus de deux ou trois itérations, vous n'allez pas travailler pour rien. Sinon, on peut aussi engager le débat pour savoir ce qu'il faut faire.

Globalement, dans mon cas, c'est une réunion active qui peut prendre facilement 3 heures suivant le niveau de détail sur lequel vous avez besoin d'aller. C'est stressant, c'est intense, à la fin on est HS car en plus, c'est à la fin de l'itération donc tout le monde est tendu.

Et bien entendu, c'est l'occasion de célébrer la fin de l'itération et le travail de l'équipe. Grâce à SCRUM vous avez accompli plus qu'avant, les gens ont donné le meilleur d'eux-mêmes, les clients ont bien travaillé aussi, donc c'est le moment de faire la fête, de prendre un bon goûter ou un apéro (sans alcool forcément).

C'est une réunion qui permet de faire le point sur le fonctionnement de l'équipe et aussi sur les différents artefacts et réunions de la méthode. Ça permet à l'équipe de s'exprimer ouvertement sur ce qui va et ce qui ne va pas.

Je la casse en quatre phases:

1. Les membres de l'équipe écrivent sur des post-its ce qu'ils ont envie de dire sur 5 points qui sont toujours les mêmes: - ce qui a bien marché, ce qui constitue une force. - ce qui a moins bien marché et qu'on doit améliorer. - ce qu'on devrait faire davantage. - ce qu'on doit arrêter de faire. - ce qu'on doit commencer à faire, les nouveautés à lancer.
2. Les membres de l'équipe s'expriment à l'oral individuellement sur ces 5 points. C'est le moment du débat et de la discussion.
3. On fait le point sur les pistes d'amélioration du fonctionnement de l'équipe, lancées lors de l'itération précédente et on extrait 3 pistes d'amélioration nouvelles, par écrit en nommant des responsables de ces actions.

Globalement, on a une phase importante de célébration de la fin du projet et c'est important de se dire les choses qui vont bien. Certes les gens sont payés pour ça mais c'est important de faire remarquer que ça s'est bien passé. C'est également intéressant de marquer les succès car ça aide l'équipe à savoir ce qu'elle est capable d'accomplir et ça lui permettra de mieux estimer la charge, la complexité et la faisabilité de telle ou telle tâche d'US. Donc, il faut

Attention, une rétrospective, ça peut aussi être sanglant. Concrètement si vous avez quelqu'un qui est à la ramasse ou qui fait chier le reste de l'équipe, c'est là qu'il faut le dire et l'exprimer. L'objectif est bien de remonter le problème plutôt que l'enterrer et si on a un problème de personne, c'est là qu'il faut le dire. C'est préférable de se dire les choses (toujours avec un minimum de bienveillance quand même) plutôt que de laisser l'équipe pourrir en interne et faire de la merde lors des prochaines itérations.

Compter au moins une heure pour cette réunion.

C'est la dernière étape qui consiste à nettoyer le backlog tous ensemble. En effet, la rétrospective a dégagé des pistes d'amélioration dans l'équipe. On les affiche sur le scrumboard.

Ensuite, la démonstration a réglé un certain nombre de problèmes, fait avancer la construction du produit final, donc on peut retirer (pour les trucs abandonnés) ou archiver ces entrées et ces éléments du backlog (les ranger dans la partie qui est réalisée). C'est aussi le moment de faire le debriefing de la démonstration pour voir ce qui est à virer du scrumboard et aussi du backlog.

Enfin, on prend quelques minutes pour préparer le futur Sprint planning en conservant ce qui n'a pas été fait et en le répartissant sur les User Stories restantes.

C'est un exercice qui dure 15 à 30 minutes maxi mais qui permet de gagner du temps pour la prochaine itération, notamment le Sprint Planning. Je la fais toujours juste après la rétrospective, histoire que les idées restent fraîches.

A la fin d'un cycle, les gens sont fatigués. Il faut relâcher la tension et la pression en les laissant faire autre chose de léger. Donc, quelques jours de pause avant de reprendre le cycle sont indispensables.

Si les gens sont volontaires et n'ont que ça à faire que de bosser sur le projet, ils peuvent prendre de l'avance ou faire du travail de préparation ou de la documentation ou de la propagande.

C'est aussi dans ces 3 jours que le Scrum Master et le Product Owner doivent préparer le cycle suivant. Il faut peut-être déminer des sujets en amont avec les clients ou identifier ce qui peut poser problème dans le planning à venir ou encore pour ceux qui ne font pas la démo avec les managers, refaire un point hiérarchique. Ces 3 jours ne sont donc pas du luxe.

Si 3 jours ne sont pas possible, il faut au moins une journée pour préparer le cycle suivant. Si vous ne faites pas cette pause en tant que Scrum Master, vous allez vite vous épuiser et faire du caca.

Avant de partir sur le projet, vous devez constituer le backlog. En effet, si Agile veut dire plus lâche sur la documentation et la contractualisation avec le client, ça ne veut pas dire qu'on peut partir les mains dans les poches.

La première itération doit être absolument consacrée à recueillir les besoins des clients. Car le backlog doit être constitué avant de lancer la première itération (pas de backlog grooming sans backlog !).

Dans cette phase, le product owner joue un rôle indispensable ainsi que le client. Mais c'est déjà dans cette phase que l'équipe de dev s'imprègne du produit, regarde ce que le métier veut, ce que le métier fait, ce qui se passe dans l'environnement, etc.

Si vous négligez cette phase, vous allez galérer à reprendre les éléments au fur et à mesure des sprints. Par ailleurs, si vous n'êtes pas rompu à SCRUM, c'est dans cette phase que vous allez découvrir la méthode donc, prenez le temps de faire un Sprint 0.

Voilà en quelques lignes ce que je fais quand je travaille en mode Agile avec SCRUM. J'ai fait ça pendant 5 ans et, de mon point de vue, ça a changé ma vie professionnelle.

Bien entendu, ça peut sembler lourd de prime abord: un Sprint, c'est au minimum une vingtaine d'heures de réunions et de discussions pour une équipe de 8 personnes, c'est long. Plus long que de travailler seul dans son coin sans communiquer. Par ailleurs, SCRUM ce n'est carrément pas la fête du slip, bien au contraire. Un sprint, c'est très cadencé. L'intérêt c'est que ça peut se programmer longtemps à l'avance sur plusieurs itérations. Mais si vous pensiez que les méthodes Agiles sont des trucs légers sans réel processus, où on peut faire un peu ce qu'on veut, vous vous trompez.

SCRUM me semble au contraire bien adapté aux équipes qui ont besoin de suivre une règle et s'y raccrocher en cas de problème, comme un guide permanent. Le fait d'avoir des rôles distincts lève beaucoup d'ambiguïté aussi sur qui fait quoi.

D'un point de vue organisation, je dirais que SCRUM c'est essentiellement une méthode anarchiste au sens où il n'y a pas vraiment de maître ou de dirigeant. C'est l'équipe et le client (qui en fait partie dans les meilleurs scénarios) qui définissent ensemble la route qu'ils tracent et les travaux qui sont effectués. Et l'intérêt de SCRUM dans cette vision anarchiste, c'est de proposer un pool de protections via une méthode à conduire pour éviter que le groupe subisse les pièges de toute auto-organisation (prises de pouvoir par des membres, migration vers une oligarchie, affrontements sans fin, etc.).

Dans le prochain article j'exposerai en quoi SCRUM m'a permis de surmonter les problèmes que j'ai pu rencontrer dans le cours de ma vie professionnelle.