Coopération plus que collaboration
La coopération est une quête de connaissance partagée
Cet article fait suite au commentaire d’Aurélie sur Twitter à propos du manifeste agile radical. Elle nous dit :
… le lien entre le réchauffement climatique et la collaboration avec le client n’est pas clair pour moi
Je tente donc de contribuer à plus de clarté.
D’autres retours nous indiquent que la formulation n’est pas limpide et que le texte d’accompagnement mérite d’être amélioré. Merci à celles et ceux qui nous ont apporté du feedback.
Rappelons ce que nous disons sur cette partie du Manifeste :
la collaboration avec le client plus que la négociation du contrat, mais l’impact sur le vivant encore plus que la collaboration avec le client
Dans notre interprétation du Manifeste agile de 2001, après la façon de travailler (avec qui ? ce qui nous a amenés à l’auto-organisation) et la façon de produire (comment ? avec les boucles de feedback), il est question ici du quoi ?, autrement dit quel produit (ou service) réaliser.
Dans un premier article, je vais m’efforcer de montrer ce qui s’est passé depuis la publication du manifeste et pourquoi en rester à collaboration avec le client n’est pas le reflet actuel de l’agilité sur le terrain. Le 2e article tentera d’expliquer pourquoi nous avons écrit impact sur le vivant dans le manifeste agile radical et, éventuellement, proposera une autre formulation.
Mais revenons d’abord au manifeste de 2001.
De la négociation du contrat à la collaboration avec le client
Quel produit développer ?
La négociation du contrat suppose que l’équipe qui développe dispose d’un document contractuel qui lui dit quoi faire. Des négociations sont possibles mais ont un caractère exceptionnel et portent sur le contenu du document.
Bien avant le manifeste on savait déjà que cette façon de procéder n’était pas efficace. Dans les années 90 je donnais des cours sur la spécification en mettant en avant l’importance de l’implication du client, qui était reconnue comme le premier critère de succès.
Les problèmes causés par une spécification détaillée faite au début étaient connus :
- il est impossible de spécifier à l’avance ce que sera le produit final,
- c’est même contre-productif car cela pousse à développer des fonctionnalités qui ne seront pas utilisées,
- la séparation en deux entités (une qui écrit le contrat, l’autre qui l’exécute) entretient une défiance néfaste.
En mettant en avant la collaboration avec le client, le manifeste agile a pris position sur l’intérêt d’une communication directe entre l’équipe de développement et le client. En 2001, c’était ce qu’il y avait à faire.
Le problème avec “la collaboration avec le client”
Sur le terrain, cela n’a pas changé grand chose. Les personnes en charge de définir (spécifier) le logiciel (le produit) ont continué à faire des use-cases, le formalisme en vogue à l’époque.
Les équipes qui ont essayé de collaborer avec le client se sont rendu compte qu’il n’était pas toujours facile d’identifier ce client et encore moins de le faire collaborer.
On pourrait aussi évoquer la différence entre le client (celui qui paie) et l’utilisateur. Je renvoie à un dessin que Fabrice a traduit, il est très parlant et je ne vais pas développer plus ici.
Donc collaboration avec le client —Customer collaboration— c’est resté un voeu pieux. Ce qui a été décisif c’est l’émergence du rôle de Product Owner.
L’émergence du rôle de Product Owner
Après 2001 un rôle a émergé et pris de l’importance avec la diffusion de Scrum, celui de Product Owner.
C’est avec ce représentant des clients et utilisateurs que s’est développée cette collaboration tant souhaitée. Initialement hors de l’équipe, on s’est vite rendu compte que, pour plus d’efficacité, il fallait qu’il en fasse pleinement partie.
Depuis environ 2005, il est devenu évident que la place du Product Owner est dans l’équipe. Il en est membre, avec son rôle particulier sur le backlog, sur les priorités qui lui donne la responsabilité du quoi, c’est-à-dire ce que va faire le produit.
Le PO coopère quotidiennement avec les membres de l’équipe. Car au sein d’une équipe agile, on fait plus que simplement collaborer, on coopère.
Voyons la nuance entre collaboration et coopération.
Coopération plus que collaboration
L’économiste Eloi Laurent fait une distinction nette entre collaboration et coopération 1. Examinons les 3 points de différence qu’il propose, à l’aune de l’agilité radicale.
la collaboration s’exerce au moyen du seul travail, tandis que la coopération sollicite l’ensemble des capacités et finalités humaines
Cette approche holistique est congruente avec la valeur sociale de l’agilité radicale.
la collaboration est à durée déterminée, tandis que la coopération n’a pas d’horizon fini
Cela résonne avec l’agilité qui s’applique sur des produits plus que sur des projets. On collabore sur un projet classique, mais dans une équipe agile qui reste stable et développe régulièrement des produits ou services, on coopère.
la collaboration est une association à objet déterminé, tandis que la coopération est un processus libre de découverte mutuelle
Cela renvoie à l’auto-organisation des équipes agiles.
Nous partageons donc cette position, en phase avec l’agilité radicale :
… c’est la coopération – autrement dit l’intelligence collective ou la capacité de penser et rêver ensemble – et non la simple collaboration (la capacité de faire ensemble) qui est la source de la prospérité humaine.
Pour illustrer la différence entre collaboration et coopération, je vous propose un exemple sportif, inspiré par le Tour de France cycliste qui se déroule en ce moment :
- les membres d’une échappée collaborent (ponctuellement, pour ne pas être repris par le peloton),
- alors que les coureurs d’une équipe coopèrent.
Redéfinir la valeur
Nous aurions pu dire dans le manifeste agile radical :
la collaboration avec le client plus que la négociation du contrat, mais la coopération avec les utilisateurs (représentés par le PO) encore plus que la collaboration avec le client
Mais cela n’est pas suffisant pour l’agilité radicale.
En effet, il est tout à fait possible que :
- le Product Owner oriente le produit vers le bénéfice de parties prenantes (par exemple les actionnaires), au détriment de son utilité sociale et écologique,
- que les membres de l’équipe participent à un développement dont le résultat va à l’encontre de leur éthique personnelle.
Une équipe pourrait donc être considérée comme très agile avec un Product Owner super efficace alors qu’elle contribue à la destruction des ressources de la biodiversité et à l’augmentation du réchauffement climatique !
C’est pourquoi nous allons poursuivre en redéfinissant la notion de valeur. Vers plus de symbiose avec le vivant. Ce sera dans un prochain article.
À lire dans cet article de Philonomist ↩︎
