Coopération : agile à l’échelle – Mary Popendieck

Comment équilibrer coopération entre équipes et autonomie des équipes pour que l’agilité survive au « passage à l’échelle » ? Article inspiré de la keynote de Mary Poppendieck lors du Scrumday 2015 (FSUG).

Coopérer : l’échec des bonnes intentions

Nos projets sont compliqués, urgents, contraints. Notre environnement est changeant, chaotique, complexe. Alors nous, pour y voir plus clair, on s’organise. L’équipe projet est un repère simple et efficace. Scrum prône l’autonomie pour réussir et en effet à l’échelle d’un « scrumteam » de 10 personnes, c’est très efficace. Mais quand on passe à l’échelle ? L’autonomie reste essentielle pour réussir, mais la coopération devient un levier capital. Que faire pour dépasser les deux écueils que représentent cette confrontation entre autonomie et coopération ?

Ecueil n°1 : puisqu’on favorise l’autonomie au sein des équipes, l’autonomie a tendance à avoir plus de poids que la coopération quand il faut coopérer entre équipes. Ce qui fonctionnait localement est contreproductif à l’échelle :

IMG_20150722_090845

Pour apporter une première réponse à ce dilemme, Mary évoque Yves Morieux et sa conférence TED à propos de « Smart Simplicity« , qui propose 6 règles pour favoriser la coopération. En particulier, il  cite directeur général du groupe Lego, Jorgen Vig Knudstorp : « on ne blâme pas pour l’échec, mais pour ne pas avoir aidé ou demandé de l’aide ». Un remarquable lâcher-prise par rapport aux logiques classiques des objectifs à atteindre. Et Yves Morieux enfonce le clou : « Soudain, il devient dans mon intérêt d’être transparent quant à mes vraies faiblesses, mes vraies prévisions, car je sais que je ne vais pas être blâmé si j’échoue, mais plutôt si je n’ai pas aidé ou demandé de l’aide ».

La deuxième affirmation de Mary, c’est que les simplifications hâtives ne fonctionnent pas. Oui, ces organisations idéales, vous savez ?
Lorsque l’entreprise grandit, on s’organise par domaines de compétences. Puis les gourous de l’agile arrivent et affirment qu’il faut absolument s’organiser en « cross-functionnal teams ». Mary Poppendieck illustre ainsi le passage entre des silos « par compétence » et … les silos fonctionnels :

IMG_20150403_092136391-mod
Mary Poppendieck : les « cross-functional teams » sont des silos comme les autres !

C’est le deuxième écueil : l’organisation idéale toute faite, les raccourcis-clavier du management, ça n’existe pas. Il existe une foule de modèles pour équilibrer besoin d’autonomie et besoin de coopération, aucun n’a toutes les réponses.

Théorie de la coopération… Scrum but ?

Comme le rappelle M. Poppendieck, la coopération au sein des groupes humains fait l’objet d’études basées sur la théorie des jeux. Elinor Ostrom, prix Nobel d’économie en 2009 étudie la question de la coopération dans le cadre de le préservation des biens communs. Elle met en évidence huit principes qu’on retrouve dans tous les exemple de coopération pour la gestion efficace et durables de biens communs :

  1. Des limites sont clairement établies, tant sur les personnes ayant accès à la ressource que sur la définition de la ressource elle-même ;
  2. L’adaptation aux conditions locales ;
  3. L’existence de dispositifs de choix collectifs qui incluent la plupart des membres de la communauté ;
  4. Une surveillance par la communauté du comportement de ses membres ;
  5. Des sanctions graduelles quand les règles sont transgressées ;
  6. Des mécanismes de résolution de conflits rapides et bon marché ;
  7. La reconnaissance explicite du droit à l’auto-organisation ;
  8. L’imbrication efficace des institutions locales avec celles à plus grande échelle.

Le parallèle avec les projets SI en mode agile est intéressant n’est-ce pas ? Essayons de pousser la métaphore un peu plus loin que le propos de Mary en comparant aux principes du manifeste agile :

  1. Un périmètre de projet clair avec une équipe clairement identifiée incluant toutes les parties prenantes ;
  2. Des règles ajustées aux contraintes et aux capacités du projet et de l’équipe (comme la « Definition of Done » par exemple) ;
  3. Des cérémonies favorisant l’émergence collective des idées et des règles communes (autonomie, confiance) ;
  4. Un climat de confiance mutuelle et de transparence ;
  5. À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence ;
  6. Des réunions « timeboxéées », un engagement mesuré pour être capables de maintenir indéfiniment un rythme constant ;
  7. Les meilleures architectures, spécifications et  conceptions émergent d’équipes auto-organisées ;
  8. … Et bien c’est un sujet que le manifeste n’aborde pas !

Toutes les institutions stables observées cumulent ces huit conditions, et toutes les institutions ayant échoué dans leur mission manquaient d’au moins une des huit. Et nous constatons aisément dans les situations de « ScrumBut » combien l’articulation, la coopération, entre l’équipe et le reste de l’organisation est important. La question du passage à l’échelle de Scrum (et de l’agilité en général) est donc capitale pour la réussite durable des projets et transformations agiles.
Qu’en dites-vous ? Avez-vous des exemples en tête qui confirment ou infirment cette vision des choses ? Quels sont vos scrumbuts quotidiens et comment les contournez-vous ?

L’observatoire du Management Alternatif (HEC Paris) souligne par ailleurs que les règles proposées par E. Ostrom permettent de répondre à la question des modalités dans lesquelles les individus sont collectivement incités à se comporter de manière à gérer efficacement le bien commun. Mais elles ne répondent pas au « dilemme de second ordre » qui consiste à se demander ce qui peut inciter les individus à mettre en place un tel système. La réponse est un ajustement incrémental de l’organisation.  Un individu peut être incité à faire un « petit pas » en collaborant d’avantage. Il en tire un avantage individuel immédiat, et la collectivité aussi. Différents « petits pas » peuvent aboutir à la mise en place d’institutions complètement adaptées à la préservation durable de la ressource commune. Pour plus de détails, voir détails la fiche de lecture de l’OMA.

A propos de petits pas justement, et ce n’est certainement pas si fortuit, je vous recommande l’excellent petit livre de Nicolas Gouy « Le plus petit pas »1. Il y raconte son vécu dans la transformation agile d’un grand groupe, ses discussions avec son mentor expert en lean management et cette astucieuse idée d’imaginer l’avenir en grand et de chercher à l’atteindre le jour même… en faisant un premier « petit pas ».

Le plus petit pas, histoire d’une transformation Agile, Scrum et XP à grande échelle. Nicolas Gouy.

Exemples de groupes coopératifs efficaces

Voici maintenant quelques considérations sur la taille d’une équipe efficace et ce qui la mène le plus sûrement au succès.

Selon l’anthropologue Robin Dunbar, la taille de notre neocortex ne nous permet d’établir des relations interpersonnelles stables qu’avec, au maximum, 150 personnes environ.  Au-delà, le temps et les capacités intellectuelles mobilisées pour entretenir des relations sociales devenait trop important pour maintenir la cohésion du groupe2. L’histoire et l’observation de nos comportements usuels montre converge avec cette hypothèse. Les tailles classiques de nos groupes coopérants sont :

  • Le cercle familial : 3 à 5 personnes ;
  • Notre réseau de sympathie proche : 7 à 10 ;
  • Groupe de chasseurs, relations professionnelles denses : 30-50 ;
  • Clan : 100-150 ;
  • Tribu : 500-2500

La taille du « clan » se retrouve aussi bien dans les villages pré-industriels, les communautés Amish, une compagnie militaire, que dans une équipe chez Gore & Associates (10 000 associés au total, avec une organisation réticulaires ans chaîne de commandement, ni canaux de communication prédéterminés).

De même, la taille du « hunting group » s’observe dans les groupes de commandos militaires, les « product teams », startups, projets opensource. A cette échelle, la coordination est portée par un leader en qui tous ont confiance et qui donne une orientation d’ensemble à l’action du groupe.

Intention claire et pleine conscience de la situation : le modèle militaire
Intention claire et pleine conscience de la situation : le modèle militaire

Chris Fry,  SVP de Twitter explique le succès de la croissance stable des équipes de Twitter pendant son développement très rapide par l’application de ce type de modèle réticulaire. « Une des organisation la plus capable de changer d’échelle dans l’histoire humaine était l’armée romaine. Son unité de base : le groupe de combat (squad), soit 8  personnes. Juste la capacité d’accueil d’une tente »3. Il préconise de rechercher une bonne alchimie dans la création de ces squads, puis, seulement après, de les affecter à un projet, de les laisser ensemble et de préserver la modularité de toute l’organisation en supprimant au maximum les dépendances.

Chez Pixar, la clé du fonctionnement, dans des groupes de 200 personnes est la création d’un environnement dans lequel chacun est investi dans l’aide au profit des autres. Tiens, on retrouve encore l’injonction du patron de Lego citée par Yves Morieux… Les autres principes à l’oeuvre sont :

  1. Un but partagé : les sous-équipes ne peuvent réussir que si tout le groupe réussit. D’ailleurs qu’un but partagé, c’est un destin commun qui se dessine-là.
  2. Une responsabilité partagée : décidement, on retrouve la proposition d’Yves Morieux de réduire l’ombre du futur en exposant les acteurs aux conséquences de leurs actions. Très agile aussi n’est-ce pas ?
  3. Pleine conscience collective de la situation. Mary cite ici Wayne Gretzky, joueur de Hockey originaire du Canada « Je patine vers où le palet se dirige, pas là où il était ».

Décidément très riche, une keynote de Mary Poppendieck. Nous garderons donc pour un (peut-être) prochain billet la fin de son allocution, dans laquelle elle propose quelques recommandations pour gérer la complexité (microservices et product mindset).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *