Cela fait une douzaine d'années que je travaille quasi-exclusivement selon les principes de l'agilité, pour différents clients et différents environnement.
Quand il est bien mené, le développement agile est bénéfique pour tout le monde, aussi bien pour le produit que les clients ou les équipes en charge. Mais mal mené, on peut se retrouver dans des situations de blocage catastrophiques à enchaîner des réunions stériles où personne ne comprend personne.
L'agilité, ce n'est pas pour tout le monde !
Une histoire d'échanges et de communication
Pour moi, l'agilité (et toutes les valeurs/principes/méthodes qui en découlent) c'est avant tout de la communication. C'est une volonté de faire avancer tous les acteurs d'un projet vers une direction commune en les invitant tous à échanger, partager, discuter.
Les méthodes agiles (puis le manifeste agile) sont une réponse aux méthodologies traditionnelles qui étaient jusque là en vigueur dans l'industrie. Dans le cycle en V par exemple, à partir d'une demande client, on a des personnes qui pensent d'abord le produit, puis d'autres qui développent puis d' autres qui testent. La communication se fait par livrables interposés (cahier des charges, spécifications détaillées, code source, rapport de test) et il y a finalement assez peu d'échanges entre les équipes.
Ceux qui produisent utilisent ce qui a été spécifié mais échangent rarement en amont avec les personnes qui rédigent les spécifications. De la même façon, le client ne pourra faire ses retours qu'une fois le produit fini et ne pourra pas vraiment modifier sa demande en cours de route. Quitte à générer des quiproquos entre les équipes tout au long du projet et se rendre compte que rien ne va au bout de deux ans lorsque le client a le produit entre les mains (bon, j'exagère, il y a moyen de repérer de grosses erreurs plus tôt quand même mais ça peut arriver).
L'agilité prend pour partie de limiter ces quiproquos (qui sont coûteux à résoudre) en favorisant la communication et les échanges entre les acteurs. Plutôt que d'avoir des personnes qui se parlent peu ou uniquement par documents interposés, agissant les uns à la suite des autres, on met au contraire tout le monde autour de la même table le plus régulièrement possible. Objectif : échanger sur le projet.
Client, développeur, testeur, analyste, designer, etc., l'idée est qu'à tout moment du projet, tout le monde sache ce qu'il en retourne, que tout le monde ait le même niveau de communication et que le projet avance dans la bonne direction. Et que très vite on puisse repérer les incompréhensions : une mauvaise specification, des erreurs de développement, une fonctionnalité mal comprise, un écran difficilement utilisable.
Tout découle de ça : d'une volonté de mieux faire échanger les différents acteurs d'un projet, dans l'intérêt de celui-ci. Je pense que comprendre ça, c'est déjà faire un grand pas.
Le découpage en Sprint prôné par Scrum n'est qu'un moyen de déclencher des échanges réguliers. On pose un objectif et toutes les 2 à 4 semaines, il y a une livraison par les développeurs. Les autres acteurs (clients, testeurs) vont alors avoir des nouveautés à appréhender sur le projet et vont pouvoir faire des retours. Soit positifs (ça va dans la bonne direction), soit négatifs (il y a des bogues, des problèmes dans ce qui a été demandé). On adaptera alors les Sprints suivants en fonction des retours, et ainsi de suite.
Quelle que soit la façon dont ils se déroulent, les grands rendez-vous d'un sprint sont de la communication entre les équipes.
Le daily meeting, ce n'est qu'un moyen pour les équipes concernées de faire un point de synchro quotidien sur l'avancée du projet. Parce qu'on n'a pas l'occasion de tous se voir ou d'échanger dans la journée ou parce qu'on a besoin de savoir si quelqu'un est disponible pour un coup de main. On est vraiment là encore sur de la communication et de l'échange.
Il en est de même pour les rétrospectives qui sont un temps dédié pour communiquer sur les choses qui vont et celles qui ne vont pas. Plutôt que de ne rien dire pendant 6 mois et se rendre compte qu'on aurait pu simplifier des choses ou éviter des conflits avant qu'ils s'enveniment.
Le pair programming est un moyen pour deux développeurs de confronter leur façon de faire et d'apprendre les uns les autres. Là encore, on est sur de l'échange entre les personnes.
L'agilité, in fine, ce n'est que ça : essayer de mieux communiquer et d'échanger. Ce n'est pas suivre aveuglément une méthode ou un processus.
Quand la communication ne passe pas
C'est d'ailleurs souvent ça qui péchait dans les équipes que j'ai pu rencontré où ça ne fonctionnait pas bien. Il y avait souvent une volonté d'appliquer l'agilité parce que "c'est mieux que le cycle en V et c'est ce qu'il faut faire" mais sans vraiment comprendre le réel intérêt derrière, sans comprendre qu'on essaye de faciliter les échanges, pas de les rigidifier.
Pour qu'une communication fonctionne et pour qu'il y ait un échange productif, il faut à minima deux personnes qui :
- aient envie d'échanger
- acceptent de présenter leur point de vue mais acceptent aussi d'écouter celui des autres
- acceptent de faire des compromis
- se fassent confiance et se respectent
Si ces conditions ne sont pas réunies, on va droit dans le mur.
C'est comme ça que je me suis parfois retrouvé dans des daily meetings d'une heure sans fil conducteur où la plupart des gens perdaient leur temps. Mais comme on devait justifier la mise en place de l'agilité sur le projet, on devait faire un daily/stand-up meeting, même si ça n'apportait rien.
Je me suis aussi retrouvé dans des rétrospectives où personne n'avait rien à dire. Non pas parce qu'il ne s'était rien passé d'intéressant (ça peut arriver) mais parce que les participants ne voulait pas "faire de vagues" et se faire reprocher de ne pas vouloir travailler par le chef de projet.
Aussi, vous pouvez mettre en place tous les rituels du monde, faire toutes sortes d'ateliers, si les personnes avec qui vous travaillez ne veulent pas échanger, si elles n'acceptent pas la discussion ou de suivre ce qui peut être dit parce que ce n'est pas comme ça qu'elles veulent que ce soit fait (bref, elles n'en font qu'à leur tête), ça ne prendra pas.
C'est une des limites d'ailleurs de l'agilité : de nombreuses personnes freinent énormément pour ne pas avoir à changer leurs habitudes. Elles ont peur du changement et attendent qu'on leur prouve que ça fonctionne avant de s'y mettre.
Le problème, c'est que c'est un travail de groupe. Si vous avez une ou deux personnes qui ne jouent pas le jeu, qui ne veulent pas essayer d'avancer ensemble et d'échanger pour progresser, ça va sérieusement entamer le moral du reste et la dynamique de groupe.
Les profils sont variés. Cela peut aussi bien être un développeur qui veut absolument le détail de toutes les spécications avant de commencer comme un client qui refuse de tester tant que tout ce qu'il n'a pas demandé n'est pas complet. Des profils qui ne sont pas dans une volonté d'échanger et de progresser ensemble mais dans des rôles bien cloisonés où toutes les cases doivent être cochées.
À l'inverse, vous pouvez vous retrouver avec des personnes qui prennent une méthode au pied de la lettre et passent à côté de l'apect des échanges productifs (en général, ces personnes prononcent des phrases comme "ça ne respecte pas la méthode agile" ou "il faut respecter le processus").
C'est comme ça que je me suis retrouvé avec un Scrum Master qui refusait d'embarquer une demande de changement de libellé de bouton de "Ok" vers "Valider" dans un Sprint. Pour la bonne et simple raison que le Product Owner n'a pas rédigé la User Story dans le bon format et que le designer n'a pas eu le temps de modifier les maquettes. Pas sûr que faire perdre 2h à chacune de ces personnes pour 10 minutes de modification effective produise un bon retour sur investissement.
Là encore, des problèmes de communication. Une personne n'accepte pas le compromis et ne fait pas confiance dans les autres, ce qui se traduit par du travail superflu pour tous.
Des échanges productifs
Parce qu'au final, pourquoi est-ce qu'on essaye de favoriser les échanges ? Pourquoi est-ce qu'on essaye de se voir régulièrement, de dialoguer ? De valider ou infirmer des hypothèses ?
Pour ne pas avoir à perdre plusieurs jours dans la rédaction de documents de 150 pages là où un point de 10 minutes aurait suffit. Pour ne pas se rendre compte au bout d'un an qu'on faisait fausse route alors qu'on aurait pu le voir au bout de 3 semaines. Pour ne pas perdre du temps à faire des choses inutiles, tout simplement.
Et là, on aborde une des difficultés de l'agilité : quel est le bon niveau de communication à adopter ? Quel est le juste milieu pour avoir les échanges les plus constructifs possibles et ne produire que ce qui est nécéssaire et suffisant ? Comment communiquer sans oublier de dire des choses mais sans non plus tomber dans la réunionite ?
Un des plus gros piège quand on se lance dans l'agilité, c'est celui de tout faire par oral et de ne rien écrire. Si vous débutez, vous allez forcément tomber dedans, c'est un classique. On se pose un petit réunion informelle de vingt minutes rapide, on échange 5 minutes sur le sujet à la machine à café ou quand on se croise dans un couloir. Et effectivement, c'est plus direct et moins contraignant que de faire des réunions plus formelle et de rédiger des documents (des fois c'est aussi par fainéantise, il faut bien l'avouer).
En pratique, ça ne fonctionne pas. Parce que les gens ont une mémoire limitée, parce que les gens dorment, parce que les gens ont une vie en dehors. Au bout de quelques jours, il est impossible de se rappeler de tout ce qui a pu être dit.
Et finalement, on retombe sur la problématique des quiproquos et de la mécommunication qu'on cherchait à éviter au départ : parce que les personnes ont oubliés certaines choses, elles ont fait différemment ou n'ont pas tout réalisé ce qui devait être fait.
C'est pour ça que l'utilisation d'éléments comme les User Stories est important. C'est la mémoire de ce qui a pu être dit. On démarre par un petite trame qui permet d'enclencher une réunion (les fameux "en tant que, je veux que") et des échanges. Puis la story est complétée parce que qui s'est dit, ça permet à tout le monde de se rappeler de ce qui a été échangé et validé.
À la différence des grand cahiers des charges rédigés en début de projet que l'on pouvait retrouver dans les cycles en V, les User Stories sont plutôt courtes, rédigées au fur et à mesure de l'avancement et contiennent le descriptif de ce qui est attendu (les fameux tests d'acceptance). On n'y raconte pas sa vie, on ne sur-détaille pas. On est sur une communication minimaliste et qui va droit au but.
Et la qualité des échanges et la communication n'est pas impactée. C'est pour ça que des réunions comme des grooming existent : le product owner présente ce qu'il veut, il y a des échanges et tout le monde se met d'accord. À partir de ce moment là, on peut "stabibiliser" tout ça dans la User Story et s'en servir dès qu'on doit se référer à quelque chose.
C'est quand même plus efficace que de refaire des réunions tous les 2 jours pour se redemander "au fait, on avait dit quoi sur ce sujet ?" !
De bons échanges, ça passe donc aussi par l'écrit. Que ce soit par des User Stories , de la documentation utilisateur ou de la documentation de développement, il faut toujours évaluer quel est le meilleur canal de communication pour obtenir l'échange le plus pertinent.
Souvent c'est par l'oral mais quand il s'agit de répéter plusieurs fois la même chose, communiquer des documents par écrits s'avère plus efficace.
(Note en passant : je vois souvent des User Stories caricaturales où le format "en tant que/je veux que/afin de" est très forcé. Si ce format n'est pas adapté à votre travail, il existe d'autres formats. Par exemple, les Job Stories sont plus adaptées à des traitements batch. Si vous ne voulez que des ajustements minimes sur un existant, regardez les Improvements stories. N'hésitez pas à explorer pour trouver ce qui vous conviendrait le mieux ou à inventer les votres)
Être agile avec l'agilité
Si on poursuit ce raisonnement, on peut même légitimement se demander si tous les rituels d'agilité (daily, spint review, etc.) sont pertinents et adaptés à la situation. Après tout, si l'agilité n'est qu'une histoire de communication où il faut trouver le meilleur moyen d'échanger, qu'est ce qui garantit que les rituels sont ce meilleur moyen ?
Rien du tout.
Au contraire, il est même intéressant de se questionner sur la pertinence des rituels.
D'abord, parce qu'ils n'existent pas dans toutes les méthodologies agiles. Tout ce qui est daily, rétrospectives, sprint planning sont très marqués par Scrum, la méthode dominante (statistique issue de mon expérience et de mon doigt mouillé). Mais on peut aussi très bien faire de l'agilité selon les principes de la méthode Kanban, sans aucune notion de sprint.
Ensuite, faire de la réunion pour le plaisir d'en faire ou parce qu'une méthode le dit, c'est un peu contraire au principe d'agilité. Plus haut, j'indiquais que je m'étais retrouvé quelques temps dans des daily meetings d'une heure qui ne débouchaient sur rien de constructif. Pas vraiment de dialogue ni d'échanges, juste des gens qui justifiaient leur activité à un chef de projet qui demandait des comptes. LA réunion non productive par excellence.
À l'inverse, j'ai travaillé pendant une année sur un projet en agilité où il n'y avait aucun daily meeting. Nous n'en avions pas besoin. Parce que nous n'étions que deux développeurs qui étions en contact continu toute la journée. Quel était l'intérêt de se faire un point de synchronisation chaque matin alors qu'on savait très bien ce que l'autre faisait ?
Les autres acteurs (designer, product owner, testeur) étant à mi-temps (voir moins) sur le projet, une réunion par semaine nous permettait de tous nous synchroniser mais on n'en faisait pas plus. Si on avait vraiment besoin, on s'appelait, on échangeait directement, on posait une réunion mais uniquement quand c'était nécéssaire.
Malgré ce non respect strict des rituels, on livrait toutes les 3 semaines, avec une recette toutes les 3 semaines, des mises en production régulières. Tout ça de façon fluide et constructive. On faisait de l'agilité.
Comme le disait une ancienne cheffe de projet :
Il faut être agile avec l'agilité
C'est probablement là la clé des équipes qui fonctionnent bien en agilité. La méthodologie, quelle qu'elle soit, est un guide, une ligne directrice, indispensable pour s'orienter et mettre en place. Mais une fois qu'on commence à avoir acquis un peu d'expérience, il faut savoir prendre un peu de recul.
Est-ce que ce rituel est pertinent pour nous ? Qu'est ce qu'il nous apporte ? Est-ce qu'il nous permet de fluidifier la communication entre les gens ? Ou au contraire, c'est redondant ?
Il n'y a pas de méthode miracle. Ce qui fonctionne bien avec une équipe peut produire l'effet inverse avec une autre. Il faut savoir garder cette souplesse, cette agilité. C'est un équilibre subtil à trouver : ne pas en faire trop, savoir lâcher du lest au bon moment sans pour autant tout abandonner et se diriger vers la R.A.C.H.E. Se questionner par le prisme de la communication et des échanges constructif est, à mon sens, un bon moyen d'aborder l'agilité et de réussir.
Parce que si tout le monde souhaite avancer dans la même direction, il n'y a pas de raisons que ça se passe mal ;)