Avant qu'il existe un Management
Auteur : Mary Poppendieck
Source : Before There Was Management
Date : 07/02/2011
Traducteur : Fabrice Aimetti
Date : 10/06/2011
Traduction :
Sommaire
Le nombre magique cent cinquante
Tôt dans sa carrière, l'anthropologue britannique Robin Dunbar s'était retrouvé à étudier la taille des colonies de singes, et il remarqua que les différentes espèces de singes préféraient avoir des colonies de taille différente. Fait intéressant, la taille d'une colonie de singes semblait être liée à la taille du cerveau des singes ; plus le cerveau était petit, plus la colonie était petite. Dunbar a élaboré une théorie précisant que la taille du cerveau limitait le nombre de contacts sociaux que le primate pouvait maintenir à un moment donné. En pensant à la façon dont les humains semblent avoir évolué à partir des primates, Dunbar se demanda si, puisque le cerveau humain est plus grand que le cerveau du singe, l'homme aurait tendance à vivre dans de grands groupes. Il calcula la taille maximale du groupe dans lequel des humains seraient susceptibles de vivre en se basant sur la taille relative du cerveau humain, et il arriva à un nombre d'approximativement 150[1] . Dunbar a donc élaboré la théorie selon laquelle les humains pourraient avoir une limite sur leur capacité à conserver des canaux sociaux (le nombre de personnes avec qui une relation stable inter-personnes peut être maintenue) d'environ 150[2] .
Pour tester sa théorie, Dunbar et d'autres chercheurs ont commencé à examiner la taille des groupes sociaux des personnes. Ils ont constaté que la taille de communauté de 150 a constitué une limite maximale très fréquente dans les sociétés humaines à travers le monde en remontant aussi loin dans le temps que possible. Et le nombre de Dunbar (150) ne se constate pas uniquement dans l'Antiquité. Les Huttériens, un groupe religieux qui a formé des communautés agricoles auto-suffisantes en Europe et en Amérique du Nord, a conservé des colonies de moins de 150 personnes pendant des siècles. Au-delà des communautés religieuses, Dunbar a constaté que durant le dix-huitième siècle, le nombre moyen de personnes dans les villages de chaque comté anglais, était d'environ 160 (sauf le Kent, pour lequel c'était 100.) Aujourd'hui encore, les milieux universitaires qui se spécialisent sur une discipline particulière, ont tendance à être d'une taille comprise entre 100 et 200, et lorsque la communauté s'agrandit, elle tend à se diviser en sous-disciplines[3] .
On peut également trouver dans le monde des technologies quelque chose s'approchant du nombre de Dunbar. Quand Steve Jobs dirigeait le département de Macintosh chez Apple, son numéro magique était 100. Il pensait qu'il ne pourrait pas se souvenir de plus de 100 noms, de sorte que la taille du département était toujours limité à 100 personnes à un instant donné. Une équipe qui n'a donc jamais dépassé 100 personnes a réussi à concevoir et développer à la fois le matériel et le logiciel voués à devenir le légendaire Macintosh d'Apple[4] . Un autre exemple : dans un billet de 2004 "Le Nombre de Dunbar en tant que Limite de la Taille des Groupes", Christopher Allen a remarqué que les communautés en ligne avaient tendance à être composées de 40 à 60 membres actifs à un moment donné. Vous pouvez voir deux pics dans le graphique d'Allen traçant la satisfaction du groupe en fonction de la taille du groupe : un pic pour une taille de l'équipe de 5 à 8, et un pic aussi élevé lorsque la taille de l'équipe est d'environ 50 :
La limite de Steve Jobs à 100 personnes était probablement un dérivé du nombre de Dunbar, mais le pic d'Allen à 50 est quelque chose de différent. Selon Dunbar, "Si vous regardez la configuration des relations au sein de... notre monde social, un certain nombre de cercles intimes concentriques peuvent être identifiés. Les groupes les plus secrets se composent d'environ trois à cinq personnes... Au-dessus, on a un groupe légèrement plus grand qui se compose généralement d'une dizaine de personnes supplémentaires. Encore au-dessus, on a un cercle légèrement plus grand d'une trentaine de personnes supplémentaires..."[5] . Dans le cas où vous auriez arrêté de compter, les tailles des cercles intimes sont de 5, 15, 50, 150, ... chaque cercle ayant une taille environ trois fois plus grande que le cercle qu'il contient. Le nombre de 50 que Allen trouve dans de nombreuses communautés en ligne, est le nombre de personnes que Dunbar trouve dans de nombreux groupes de chasse de l'Antiquité, et trois de ces groupes de 50 formeraient typiquement un clan.
Est-ce-que ça fonctionne dans les entreprises ?
Cent cinquante est certainement un nombre magique pour W.L. Gore & Associates. Gore est une entreprise privée qui se spécialise dans le développement et la fabrication de produits innovants à base de PTFE, le polymère fluoré dans les tissus Gore-Tex. Gore a des revenus dépassant 2,5 milliards de dollars, emploie plus de 8000 personnes, et fait des profits depuis plus d'un demi-siècle. Elle a occupé une place permanente dans les "100 meilleures entreprises pour lesquelles travailler" aux États-Unis depuis sa création en 1984, et figure en bonne place sur des listes similaires dans de nombreux pays d'Europe. Ce parcours étonnant pourrait être lié au fait que Gore n'a pas de managers. Il y a beaucoup de leaders chez Gore, mais on ne donne pas de travail aux leaders, ils gagnent leurs vies en attirant des partenaires.
Vous devez vous demander comment une grande entreprise peut conserver un tel niveau de performance sur une aussi longue période sans l'aide des structures traditionnelles de management. La réponse semble avoir quelque chose à voir avec le fait que Gore est organisé en petites unités limitées à environ 150 personnes. "Nous avons constaté à maintes reprises que les choses devenaient lourdes à cent cinquante" selon le fondateur Bill Gore. Ainsi, lorsque la société construit une nouvelle usine, on y met un parking de 150 places, et quand les gens commencent à stationner sur l'herbe, ils savent qu'il est temps de construire une nouvelle usine.
Puisque les associés chez Gore n'ont pas de responsables, ils ont besoin de différents mécanismes pour coordonner les travaux et, fait intéressant, l'un des mécanismes clés est la pression des pairs. Voici une citation de Jim Buckley, un associé de longue date dans une usine de Gore : "La pression qui est générée lorsque nous ne sommes pas efficaces dans l'usine, lorsque nous ne produisons pas d'assez bons résultats pour l'entreprise, cette pression des pairs est incroyable... C'est ce que vous obtenez lorsque vous avez de petites équipes, où tout le monde connaît tout le monde. La pression des pairs est beaucoup plus efficace que le concept d'un patron. Beaucoup, beaucoup plus puissante."[6]
Comme beaucoup d'entreprises qui dépendent de la capacité des employés à travailler ensemble et à prendre les bonnes décisions, Gore est très attentif à embaucher des personnes qui s'intègrent bien dans sa culture. Les leaders créent des environnements où les gens ont les outils nécessaires pour réussir et les informations nécessaires pour prendre les bonnes décisions. Les groupes de travail sont relativement stables afin que les gens apprennent à connaître les aptitudes et les motivations de leurs collègues. Mais à la fin, les groupes sont organisés autour de la confiance et l'obligation mutuelle, donc finalement un retour à des petites communautés où les humains ont prospéré pendant une majeure partie de leur histoire.
La culture du management chez Google a pas mal de similitudes avec celle de Gore. Google a été conçu pour fonctionner plus ou moins comme une université - où les gens sont encouragés à décider eux-mêmes (en étant guidée) ce qu'ils veulent étudier. Google est très prudent sur l'embauche des personnes qui vont s'adapter à sa culture, et il crée des environnements où les gens peuvent s'adonner à leur passion, sans trop d'ingérence de la part du management. Pour une plongée profonde dans la culture de Google, regardez cette vidéo : Eric Schmidt au Management Lab Summit.
Culture par les pairs
Avant qu'il y ait des managers, c'est la culture par les pairs qui créait et unissait l'ensemble des sociétés. Dans les clans et les hameaux autour du monde et à travers les siècles, l'intérêt du groupe social était étroitement lié à l'intérêt personnel des individus et des unités familiales ; et donc les obligations fondées sur des liens familiaux et de réciprocité ont été essentielles dans la création des communautés.
Il existe de nombreux exemples de culture par les pairs aujourd'hui : organisations bénévoles, développement des logiciels libres, forums de discussion et réseaux sociaux sur le web. Dans ces communautés, les gens sont membres de leur propre choix, ils veulent contribuer à une bonne cause, améliorer leurs compétences personnelles et se sentir bien lorsqu'il contribue. Dans une culture par les pairs, les leaders offrent une vision, une manière pour les gens de contribuer facilement, avec juste assez d'indications pour être sûr que la vision sera atteinte.
Sans nul doute, les cultures par les pairs fonctionnent beaucoup mieux que le management pour obtenir des résultats, parce qu'elles créent un réseau social et un réseau d'obligations qui soutiennent la motivation du groupe. Alors peut-être ferions-nous mieux de prendre une page du livre de Gore, de Google ou de l'Open Source et remettre en question des milliers d'années de l'évolution humaine. Nous sommes par nature des êtres sociaux et nous ressentons tous le besoin impérieux de protéger notre unité sociale et de veiller à son essor.
Exemple : les produits matériels / logiciels
"Nous avons constaté par expérience que la taille idéale de l'équipe se situe entre 30 et 70", nous a dit la direction. Au début, nous avons été surpris. Les équipes ne sont-elles pas censées être limitée à environ 7 personnes ? Les équipes ne doivent-elles pas commencer à se découper lorsqu'elles grossissent ? Il est clair que la direction parlait d'une équipe de nature différente de celle que nous rencontrons généralement dans le développement agile de logiciel. Mais son entreprise a été l'une des entreprises les plus fructueuses que nous ayons rencontrées récemment, donc nous avons pensé qu'il devait y avoir quelque chose d'important dans son observation.
Nous avons passé une matinée dans l'entreprise avec un directeur de projet senior ; cette personne a coordonné 60 personnes sur le développement d'un produit spectaculaire en un temps record. Le produit résultant a été en avance sur son temps et a donné à l'entreprise un avantage concurrentiel significatif. Il nous a expliqué comment il a organisé le travail : "Tous les 2 ou 3 mois, nous avons produit un prototype fonctionnel, chaque fois plus sophistiqué que le précédent. Alors que nous approchions de la fin du développement, une nouvelle puce électronique (plus rapide, meilleure et moins chère) est arrivée sur le marché. L'équipe a décidé de retarder la sortie du prochain prototype de deux mois afin qu'ils puissent intégrer la nouvelle puce. De toute évidence nous n'avons pas respecté le calendrier initialement prévu, mais dans ce métier, vous devez être prêt à saisir les opportunités qui se présentent."
Ce n'est pas que cette entreprise n'avait pas de petites équipes à l'intérieur d'équipes plus grandes ; bien sûr que c'était le cas. C'est juste que la coordination était faite au niveau de la plus grande équipe, et que les membres des équipes plus petites communiquaient régulièrement avec tout le monde dans la plus grande équipe. Tous les membres de l'équipe étaient bien conscients de la nécessité de respecter les délais du prototype et ils n'avaient pas besoin d'une structure ou d'un encouragement supplémentaire pour comprendre et répondre aux besoins de leurs collègues.
Un autre exemple : la construction
Le Lean Construction Institute a développé une approche similaire pour organiser efficacement les travaux de construction. La première chose qu'ils font est de découper de très grands projets en plusieurs plus petits de sorte qu'un nombre raisonnable d'entrepreneurs peuvent travailler ensemble (rappelez-vous le nombre de Dunbar). Par exemple, ils peuvent tout à fait séparer le projet de création de la structure de stationnement de celui de l'aménagement paysager du bâtiment principal ; dans un grand bâtiment, l'extérieur serait probablement un projet distinct de celui de l'intérieur. Chaque sous-projet est divisé en phases de quelques mois ; par exemple, fondations, structure, systèmes d'intérieur, etc. Avant qu'une phase démarre, une réunion est tenue avec tous les entrepreneurs et toutes les choses qui doivent être faites pour terminer cette phase sont affichées sur des cartes au mur par les entrepreneurs. Les cartes sont organisées dans un calendrier qui prend en compte les dépendances, et tous les entrepreneurs conviennent que le mur représente une simulation raisonnable du travail à réaliser. Ce n'est pas vraiment un planning, mais plus un accord entre les entrepreneurs qui réalisent le boulot, sur ce qui doit être fait pour terminer la phase.
Chaque semaine, tous les "Derniers Planificateurs"[7] (chefs d'équipe, contremaitres, etc.) se réunissent et examinent ce qu'ils DOIVENT faire, et aussi ce qu'ils PEUVENT faire, compte tenu de la situation sur le chantier. Ensuite, ils s'engagent les uns les autres sur ce qu'ils VONT terminer d'ici la semaine prochaine. Les entrepreneurs prennent des engagements face-à-face entre pairs qu'ils connaissent personnellement. Cet engagement mutuel fait tout simplement bouger les choses plus rapidement et plus sûrement que toute autre technique d'organisation, y compris toutes les approches classiques d'ordonnancement que vous trouverez dans les livres.
Le nombre magique sept
George Miller a publié "Le nombre magique sept, plus ou moins deux" dans la revue The Psychological Review en 1956. Miller ne parle pas de taille d'équipe dans cet article ; il parle de la capacité des gens à choisir parmi plusieurs options. Par exemple, la plupart des gens peuvent se souvenir d'une chaîne de 7 numéros, et ils peuvent diviser les couleurs ou les sonorités musicales en environ 7 catégories. Demandez aux gens de distinguer plus de 7 catégories, et ils commencent à faire des erreurs. "Il semble y avoir une certaine limitation dans chaque individu, due soit à notre apprentissage soit à la conception de notre système nerveux, une limite qui maintient notre capacité à transmettre de l'information dans cet intervalle (de sept)", a écrit Miller.
Cette capacité de transmission semble affecter notre interaction directe avec les autres personnes : nous pouvons tenir une conversation avec à peu près 7 personnes, mais quand un groupe devient plus grand, il est difficile de maintenir un dialogue unique et de petits groupes ont tendance à lancer des discussions séparées. Donc, pour les groupes en face-à-face qui doivent maintenir une conversation simple, le nombre magique de 7 ± 2 est une bonne limite de taille. Et historiquement, la plupart des équipes de développement agile de logiciel ont été à peu près de cette taille.
Au-delà de sept
Le problème c'est que 7 personnes ce n'est pas suffisant pour accomplir la plupart des projets. Prenez par exemple le projet de mettre sur le marché un nouveau produit à fort contenu logiciel. Le produit n'est presque jamais uniquement le logiciel en lui-même - le produit est un dispositif médical ou une voiture ou un téléphone mobile ou peut-être une application financière. Invariablement, le logiciel est un sous-système d'un système plus global, ce qui signifie que l'équipe de développement logiciel est invariablement une sous-équipe d'une équipe système plus large.
Dans le livre Dimensionner le développement Agile & Lean, Craig Larman et Vodde Bas militent pour des [/Equipe%20Feature équipes features], c'est-à-dire des équipes multifonctionnelles qui livrent au client des fonctionnalités de bout en bout. Ils sont contre des équipes composants, des groupes formés autour d'un seul composant ou d'une couche du système. Je suis d'accord avec ces conseils, mais il me semble que le logiciel est toujours une composante d'un système que nous construisons. Nous pouvons toujours créer des logiciels pour automatiser un processus ou un logiciel pour contrôler un produit, un logiciel pour fournir des informations ou un logiciel de divertissement, mais nos clients ne se soucient pas du logiciel, ils se soucient de la façon dont le produit ou le processus fonctionne, de la pertinence de l'information, du caractère divertissant du jeu. Et si un logiciel est une composante d'un système, alors les équipes logiciel sont des équipes composants. Ce que nous voulons dire, c'est que de réelles équipes features sont missionnées pour atteindre un objectif métier et qu'elles devront donc, dans la majorité des cas, prendre en compte plus que le simple développement logiciel.
Le développement Agile a commencé comme une pratique pour de petites équipes logiciel, mais aujourd'hui on voit souvent des équipes de 40 ou 50 développeurs appliquant les pratiques agiles pour traiter une unique problématique métier. Dans presque tous les cas, nous remarquons que les développeurs sont organisés en plusieurs petites équipes qui travaillent séparément, et dans presque tous les cas, le plus grand problème semble donc être la coordination entre ces petites équipes. Il existe de nombreux mécanismes : l'utilisation d'une architecture système divisible de sorte que les équipes puissent être véritablement indépendantes ; puiser dans une liste commune de tâches, ce qui rend les équipes hautement interdépendantes ; envoyer des représentants des petites équipes pour se coordonner lors de réunions hebdomadaires, etc. Mais il est rare que nous voyions à l'œuvre le mécanisme de coordination le plus puissant de tous dans des groupes de cette taille : créer un sentiment d'obligation mutuelle à travers des engagements par les pairs.
Obligation mutuelle
Si vous voulez, vous pouvez renommer "obligation mutuelle" par "pression des pairs", mais quel que soit le nom que vous utilisiez, lorsque les individus d'une grande équipe s'engagent envers des gens qu'ils connaissent bien, l'engagement sera presque certainement honoré. L'obligation mutuelle est une force de motivation beaucoup plus puissante que s'entendre dire de faire quelque chose par une quelconque autorité. Chose intéressante, la puissance de l'obligation mutuelle ne se limite pas à de petites équipes. Cela fonctionne très bien dans des équipes de 50, et peut être efficace jusqu'à 150. Le bon moment pour diviser les équipes n'est pas nécessairement quand leurs tailles atteignent 10 ; des équipes ayant une taille jusqu'à 100 ou 150 peuvent être très efficaces si vous pouvez créer un sentiment d'obligation mutuelle entre les membres de l'équipe.
Il y a, bien sûr, un certain nombre de choses qui doivent être en place avant que l'engagement mutuel puisse se produire. Tout d'abord, les membres de l'équipe doivent se connaître les uns les autres.... bien... donc, cela ne fonctionnera pas si vous êtes en permanence en train de dissoudre des équipes. En plus de connaître leurs noms, les coéquipiers doivent pouvoir apprécier les capacités de leurs collègues, avoir la capacité de prendre des engagements fiables, et être en mesure d'avoir confiance dans le fait que leurs coéquipiers vont bien respecter leurs engagements. Ce processus de création d'obligations mutuelles fonctionne réellement mieux s'il n'y a pas de manager, parce que sinon les engagements sont portés par le manager, et non pas par les coéquipiers. Au lieu de ça, le rôle d'un leader est de définir les objectifs généraux, de clarifier les contraintes et de créer l'environnement dans lequel des engagements fiables seront échangés.
Par exemple, le directeur de projet du produit matériel / logiciel (ci-dessus) a présenté une série de prototypes de plus en plus sophistiqués planifiés environ à trois mois d'intervalle. Ayant pris un engagement envers l'équipe, les sous-équipes ont organisé leur travail de manière à avoir quelque chose d'approprié et prêt à chaque échéance du prototype. Lorsque l'occasion d'améliorer considérablement le produit grâce à l'incorporation d'une nouvelle puce s'est présentée, toute l'équipe a été en mesure de rapidement repenser la solution et de s'engager sur le nouvel objectif.
Dans le cas de la construction en mode lean (ci-dessus), une grande équipe, composée de représentants des entrepreneurs, a mis au point tous les détails d'un "calendrier" revu tous les 2 ou 3 mois. Chaque semaine, la même équipe se réunit et repense à la façon dont ce "calendrier" devra être adapté au contexte actuel. Lors de cette même réunion hebdomadaire, les membres de l'équipe s'engagent les uns envers les autres sur ce qu'ils comptent effectivement accomplir dans la semaine suivante, ce qui donne à leurs collègues une semaine pour planifier les équipes de travail, l'arrivée du matériel, et ainsi de suite pour la semaine suivante.
C'est certainement une bonne idée d'avoir de petites sous-équipes dont les membres travaillent en étroite collaboration et concentrés sur les problèmes techniques, coordonnant leurs travaux lors de brèves réunions quotidiennes pour se synchroniser et s'assurer qu'ils sont sur la bonne voie pour respecter leurs engagements. Mais la manière dont ces sous-équipes arrivent à ce niveau d'engagement poussent à réfléchir. Il peut être préférable de remettre en question des milliers d'années d'évolution humaine et de créer un environnement où les gens se connaissent et prennent des engagements mutuels pour atteindre les objectifs vitaux de l'ensemble de la communauté. Après tout, c'est de cette manière que la plupart des choses se sont accomplies... avant qu'il existe un Management.
- NdT : 148 en fait
- Techniquement, Dunbar a calculé la taille relative du néo-cortex, la surface externe du cerveau responsable de la pensée consciente. Pour une parodie humoristique de la théorie de Dunbar, voir "Qu'est-ce-que la Sphère Simienne (Monkeysphere) ?" de David Wong.
- Les informations de ce paragraphe sont tirées de : De combien d'amis une personne a-t-elle besoin ? de Robin Dunbar.
- Lire John Sculley parlant de Steve Jobs.
- Tiré du livre De combien d'amis une personne a-t-elle besoin ? de Robin Dunbar. Fait intéressant, alors que Dunbar trouve une limite approximative de 15 pour le deuxième cercle intime, Allen pense qu'un groupe de 15 est problématique.
- Le nombre de Dunbar a été popularisé par le livre "The Tipping Point" de Malcolm Gladwell. Beaucoup d'informations et de citations dans cette section proviennent du Chapitre 5 de ce livre. Voir http://nextreformation.com/wp-admin/general/tipping.htm pour un extrait plus large.
- NdT : Last Planner System = marque déposée par le Lean Construction Institute
