Les douze principes

Travailler ensemble au quotidien

Deux principes du Manifeste portent sur la façon dont les personnes d'un projet se parlent. Le quatrième demande que ceux qui connaissent le besoin et ceux qui réalisent le produit travaillent ensemble chaque jour. Le sixième affirme que le dialogue en face à face est le moyen le plus efficace de transmettre une information. Écrits en 2001, ils demandent à être relus maintenant que beaucoup d'équipes travaillent à distance.

Deux minutes de conversation, ou trois mois d'attente

Une librairie en ligne refait son système de commandes. Le document de spécifications, rédigé par le service client, contient cette phrase : « Le client peut annuler sa commande. » Karim, le développeur chargé de cette partie, se demande jusqu'à quel moment l'annulation reste possible. Hélène, qui a écrit la phrase, travaille dans un autre bâtiment et s'occupe déjà d'un autre dossier. Karim lui envoie un courriel. La réponse arrive neuf jours plus tard et renvoie au paragraphe qu'il a déjà lu. Il tranche donc seul et retient la solution la plus simple à programmer : l'annulation est possible à tout moment.

Trois mois plus tard, pendant les essais de validation, Hélène découvre qu'un client peut annuler un colis déjà parti. L'entrepôt n'a aucun moyen de le rattraper. Il faut trois semaines pour reprendre le travail.

Reprenons la scène dans une autre organisation, où Hélène passe ses matinées dans la salle de l'équipe.

« Annuler, cela veut dire jusqu'à quand ? » demande Karim.

« Jusqu'à l'expédition, répond Hélène. Après, c'est un retour, et le circuit n'est pas le même. Venez, je vous montre l'écran que nous utilisons pour les retours. »

L'échange a duré deux minutes. Karim a obtenu sa réponse, et il a appris au passage une chose qu'il n'avait pas demandée : les retours existent et suivent leur propre circuit. Les principes 4 et 6 du Manifeste cherchent à rendre cette seconde scène ordinaire.

Ce que disent les deux principes

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Manifeste agile, principe 4

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Manifeste agile, principe 6

Le quatrième principe désigne deux groupes. Le texte anglais parle des « business people », les gens du métier, et des développeurs. La traduction française officielle a choisi « les utilisateurs ou leurs représentants », ce qui est un peu plus étroit : l'anglais englobe toute personne qui connaît le besoin, qui finance le produit ou qui s'en servira. Deux précisions de temps suivent. Le mot « quotidiennement » fixe la fréquence, et l'expression « tout au long du projet » s'oppose à un usage répandu, celui où le métier apparaît au début pour rédiger ses besoins, puis à la fin pour valider le résultat.

Le sixième principe distingue deux trajets de l'information. Le premier va de l'extérieur vers l'équipe : ce sont les besoins, les contraintes et les priorités. Le second circule à l'intérieur de l'équipe, entre ses membres. Pour les deux, le texte désigne le dialogue en face à face comme la méthode « la plus simple et la plus efficace ». C'est une comparaison, et elle ne déclare pas les autres moyens inutiles. La première valeur du Manifeste suit la même logique quand elle place les interactions avant les processus et les outils, sans supprimer ces derniers (voir Les individus et leurs interactions).

Pourquoi l'écrit seul ne suffit pas

Un document ne répond qu'aux questions que son auteur a prévues. Hélène savait parfaitement qu'un colis expédié ne s'annule pas. Cette connaissance lui paraissait si évidente qu'elle ne l'a pas écrite. Les spécialistes d'un métier portent beaucoup de savoirs de ce genre, que personne ne songe à formuler tant qu'une question ne les fait pas sortir.

Le lecteur, de son côté, ne sait pas toujours qu'il a mal compris. Karim aurait pu ne se poser aucune question et programmer de bonne foi une règle fausse. Dans une conversation, celui qui explique voit le visage de l'autre et peut reformuler, et celui qui écoute peut dire ce qu'il a compris et se faire corriger aussitôt.

Le délai compte aussi. Quand chaque question coûte un courriel et plusieurs jours d'attente, les développeurs cessent d'en poser et devinent. Chaque supposition est un petit pari, et un projet en accumule des centaines.

Extreme Programming (XP) en a tiré une pratique. Le besoin est noté en une phrase sur une fiche, appelée user story (récit utilisateur), et les détails sont réglés de vive voix au moment de la réaliser. Ron Jeffries a résumé cette pratique en trois mots : la carte, la conversation et la confirmation. La carte sert surtout à rappeler qu'une conversation doit avoir lieu (voir User stories, backlog et estimation).

La richesse des canaux selon Cockburn

Alistair Cockburn, l'un des signataires, a donné à ce sixième principe son illustration la plus connue. Dans Agile Software Development (2002), il trace un schéma qui classe les moyens de communication selon leur richesse et leur efficacité. Une première courbe réunit les moyens qui ne permettent pas de poser de questions : le papier, puis l'enregistrement sonore, puis l'enregistrement vidéo. Une seconde courbe, placée plus haut, réunit ceux qui le permettent, comme l'échange de courriels ou le téléphone, avec tout en haut deux personnes devant un tableau blanc.

Deux personnes au tableau disposent de tout à la fois. Elles entendent le ton de la voix, voient les gestes et les signes d'incompréhension, posent leurs questions à l'instant où elles surgissent et dessinent ensemble ce dont elles parlent.

Cockburn a aussi nommé, dans Crystal Clear (2004), la « communication osmotique » : dans une salle commune, chacun entend en arrière-plan les conversations des autres et relève sans effort ce qui le concerne. Hélène, assise près de l'équipe, aurait pu intervenir sans même qu'on l'interroge, en entendant deux développeurs discuter de l'annulation.

Ces idées ont des précédents dans la recherche. Thomas Allen, au MIT, a montré dans Managing the Flow of Technology (1977) que, dans des laboratoires de recherche et développement, la fréquence des échanges entre deux ingénieurs chute rapidement quand la distance entre leurs bureaux augmente : elle est déjà faible à quelques dizaines de mètres. Richard Daft et Robert Lengel ont proposé dans les années 1980 une théorie de la richesse des médias, selon laquelle un message ambigu demande un canal riche, alors qu'un message sans équivoque se contente d'un canal pauvre. Le schéma de Cockburn reste un dessin de praticien et ne résulte pas d'une mesure, et la théorie de Daft et Lengel a reçu des confirmations empiriques partagées. On peut en retenir une règle de bon sens : plus un sujet est ambigu, plus il vaut la peine d'en parler de vive voix.

Le métier dans l'équipe

Le quatrième principe demande une présence quotidienne, et les méthodes agiles ont cherché à l'organiser. XP a proposé la pratique du « client sur site » : un utilisateur réel du futur produit s'installe avec l'équipe et reste disponible pour répondre aux questions. Kent Beck, dans Extreme Programming Explained (1999), reconnaît que cette disponibilité coûte cher à l'organisation, et il soutient que des réponses immédiates valent davantage que ce coût.

Scrum confie un rôle proche au Product Owner, la personne qui ordonne le backlog (la liste de ce qui reste à faire) et qui porte la voix des utilisateurs auprès de l'équipe (voir Scrum en bref). La formule du Manifeste, « les utilisateurs ou leurs représentants », admet cette délégation. Elle a un risque : un représentant qui ne connaît pas l'usage réel répond vite, mais il peut répondre faux. Dans ce cas, l'équipe gagne à aller voir elle-même ceux qui se serviront du produit.

Hors du logiciel : la relève à l'hôpital

Et les équipes à distance ?

En 2001, la visioconférence était rare et coûteuse. Les signataires comparaient le face à face au document, au courriel et au téléphone. Depuis 2020 surtout, une grande partie des équipes travaille à distance, au moins quelques jours par semaine, et le sixième principe est souvent cité contre elles ou jugé dépassé.

Quelques études donnent des éléments. Longqi Yang et ses collègues ont analysé les échanges de plus de 61 000 salariés américains de Microsoft pendant le premier semestre 2020 (Nature Human Behaviour, 2022). Avec le passage au télétravail généralisé, les réseaux de collaboration sont devenus plus figés et plus cloisonnés, avec moins de liens entre groupes différents, et la communication en direct a reculé au profit des messages différés. Melanie Brucks et Jonathan Levav ont montré de leur côté (Nature, 2022) que des binômes réunis par visioconférence produisent moins d'idées créatives que des binômes réunis dans une même pièce, mais qu'ils ne choisissent pas moins bien l'idée à retenir. Le premier résultat porte sur une seule entreprise pendant une pandémie, et le second sur une tâche particulière. Ils ne permettent pas de conclure que le travail à distance échoue.

Il existe d'ailleurs un contre-exemple de taille. De grands logiciels libres, comme le noyau Linux, sont développés par des contributeurs dispersés dans le monde, qui communiquent surtout par écrit. Ces projets réunissent des conditions particulières : un travail très découpé, des contributeurs expérimentés et une forte culture de l'écrit.

Pour une équipe à distance, le raisonnement de Cockburn garde sa valeur si on le lit comme une échelle. À défaut du tableau blanc, on choisit le canal le plus riche dont on dispose quand le sujet est ambigu : dix minutes de visioconférence avec un écran partagé plutôt qu'un fil de quinze messages. Beaucoup d'équipes réparties prévoient aussi des rencontres en personne à intervalles réguliers, pour construire la confiance que les écrans entretiennent ensuite.

Limites et pièges

La parole ne laisse pas de trace. Une décision prise devant un tableau et jamais notée sera oubliée ou racontée de deux façons différentes un mois plus tard. Les personnes qui rejoignent l'équipe ensuite n'ont aucun moyen de la retrouver. Le dialogue en face à face est le meilleur moyen de se comprendre, et il faut ensuite écrire ce qui doit durer.

Le face à face avantage aussi ceux qui parlent facilement. Dans une réunion, les plus assurés occupent la parole, et dans une réunion mixte, les personnes présentes dans la salle l'emportent sur celles qui sont à distance. L'écrit différé laisse le temps de réfléchir et donne une chance égale à ceux qui s'expriment moins vite, par exemple dans une langue qui n'est pas la leur.

Le mot « quotidiennement » ne veut pas dire « à tout instant ». Tom DeMarco et Timothy Lister ont insisté, dans Peopleware (1987), sur le coût des interruptions pour un travail qui demande de la concentration. Une équipe peut travailler ensemble chaque jour en réservant des plages de calme, et le principe ne justifie pas à lui seul le bureau paysager bruyant.

Le quatrième principe a enfin un prix que beaucoup d'organisations refusent de payer. Les personnes qui connaissent le mieux le métier sont aussi les plus occupées, et les libérer pour un projet coûte cher. Quand elles manquent, l'équipe devine, comme Karim. À l'autre extrémité, un projet de deux cents personnes ne peut pas reposer sur le seul dialogue direct, et l'écrit y reprend une place importante.

Il faut ajouter que la supériorité du face à face est une conviction de praticiens, cohérente avec quelques travaux de recherche, et non un fait mesuré projet par projet (voir Que valent les preuves ?).