Le management agile Quels rôles pour le management dans un contexte informatique agile? Pirmin Lemberger avec la participation de Houda Berrada, Julie Lemaire et Arnaud Gonzales
Introduction En dépit des succès engrangés ces dernières années par les démarches agiles, beaucoup d entreprises hésitent encore à les adopter, surtout en France. Ces réticences sont largement à mettre au compte, pensons-nous, de démarches projets et d organisations des tâches qui pêchent par un excès de cartésianisme et ne prennent en compte, ni la complexité humaine, ni la complexité technique des projets informatiques. Dans une industrie mouvante comme l informatique, où la connaissance, l innovation et la créativité sont maîtresses, il convient de redéfinir le rôle des managers pour que ceux-ci aident leurs équipes à être performantes dans un monde incertain. Le point de vue développé dans ce livre blanc, inspiré des sciences de la complexité, est qu une équipe agile est un système social complexe et adaptatif qu il s agit de faire prospérer. que nous présenterons et qui permettent d attribuer de nouveaux rôles au management dans un contexte agile. Nous nous inspirons des idées développées par Jurgen Appelo dans son livre «Management 3.0». Ce livre blanc peut se lire comme une introduction à son analyse où l adaptabilité remplace la prédictibilité au rang de valeur cardinale. Pirmin Lemberger avec la participation de Houda Berrada, Julie Lemaire et Arnaud Gonzales Les sciences de la complexité offrent pour cette tâche un large éventail de métaphores 2 2
Le management agile Sommaire Le management à l épreuve de l agilité...05 Le besoin de causalité... 08 La peur de perdre ses responsabilités... 09 Redéfinir les rôles du management... 10 Agilité et complexité...11 La systémique... 14 La cybernétique... 15 La théorie des systèmes dynamiques et le chaos... 16 Les automates cellulaires et les systèmes adaptatifs... 17 Favoriser la compétence et l autonomie...19 Les dangers cachés des «bonnes pratiques»... 19 Une définition de la compétence... 21 Les différents types de motivation... 21 Pourquoi l autonomie?... 23 Favoriser l auto-organisation des équipes...25 L auto-organisation n est pas une «bonne pratique»!... 26 Créer la confiance... 27 Quels buts pour qui?... 28 Entretenir la diversité... 30 Favoriser la créativité... 31 Faire émerger une vision globale... 32 03 52
Définir les bonnes contraintes pour créer de la valeur...35 Comment définir des règles... 36 Etablir un contrat social... 37 Définir un objectif partagé... 38 Créer les conditions de l amélioration continue...40 Changer car l environnement change... 41 L art de la navigation en terrain mouvant... 42 Conclusion...46 Sources / Bibliographie...49 04 52
Le management à l épreuve de l agilité
1. Le management à l épreuve de l agilité Pour beaucoup d entreprises soumises conjointement aux fluctuations des usages numériques, aux mutations technologiques et à la nécessité de réduire les coûts de leurs développements informatiques, les démarches dites agiles apportent aujourd hui comme une brise d espoir, celui de voir se réaliser enfin le Graal de l informatique : construire des systèmes informatiques qui répondent aux besoins, tout en respectant les contraintes de budget et de délais. Tous les types d organisations sont a priori concernés, les DSI de grandes entreprises, les SSII et même les éditeurs de logiciels ou les startups. Si l on omet les querelles de chapelle entre méthodologues, toutes ces démarches préconisent, peu ou prou, la même stratégie : La réalisation sur un mode itératif de logiciels par des équipes auto-organisées à taille humaine et ceci sans conception exhaustive préalable. Des équipes techniques travaillant en collaboration étroite avec des utilisateurs chargés de tester les fonctionnalités dès qu elles sont disponibles. L un des premiers objectifs de ce livre blanc sera de comprendre l origine profonde des réticences vis-à-vis des démarches agiles. On oppose d ordinaire ces démarches agiles aux approches plus traditionnelles, comme le cycle en V, qui enchaînent les phases de recueil exhaustif des besoins, de spécifications, de conception, de développement, de tests et enfin de livraison. Le constat fondamental est bien connu : dans un environnement plus incertain que jamais, les spécifications, quel que soit le soin qu on mette à leur élaboration, s avèrent trop souvent obsolètes avant même la première livraison du système aux utilisateurs. Force est de constater toutefois, qu en dépit des nombreux succès engrangés par ces démarches (Mentor), des réticences tenaces subsistent et empêchent leur généralisation. A l évidence, la mise en avant des succès engrangés «ailleurs» n est pas de nature à convaincre tous les responsables informatiques : «ça ne marchera jamais chez nous!» entend-on dire. * Pour approfondir le sujet, nous recommandons vivement la lecture de cet ouvrage qui, par son originalité et la profondeur de ses vues, se démarque largement de la prose insipide qui domine la littérature managériale contemporaine et cela, même si le foisonnement d idées qu il contient n en fait pas forcément une lecture facile. Jurgen Appelo est l auteur de l expression «Management 3.0». Plus important que le crédit que nous pourrions accorder à tel ou tel témoignage de succès et la promotion que nous pourrions en faire, nous paraît l élaboration d une compréhension sur un plan scientifique et psychologique de ce qui fait l efficacité de ces démarches. Pour cela nous nous appuierons largement sur le travail de pionnier de Jurgen Appelo décrit dans son ouvrage «Management 3.0» (Appelo, 2010)* ainsi que sur les expériences de projets menés chez SQLI. Dans cette perspective : l un des premiers objectifs de ce livre blanc sera de comprendre l origine profonde des réticences vis-à-vis des démarches agiles. Avant d en arriver là, remarquons encore que l engouement relatif pour les démarches agiles n est que relativement récent en France. Selon nos estimations il remonte à 3 ou 4 ans tout au plus, la crise économique ayant pour le coup joué le rôle de catalyseur de l innovation méthodologique. 06 52
* XP en 1999, Scrum en 2001, Kanban 2003 et le Lean Software Development en 2003. Les prémisses conceptuelles de ces démarches sont, quant à elles, beaucoup plus anciennes et remontent pour certaines à plus d une vingtaine d années (Nonaka, 1986). Les démarches agiles proprement dites, formulées généralement sous forme des recueils de bonnes pratiques ou de manifestes de valeurs, sont apparues pour la plupart au tournant du siècle*. Au plus proche de la technique, les développeurs et les architectes logiciels ont assurément été les premiers à saisir le potentiel des démarches agiles. Pour les réticences c est donc ailleurs qu il faut regarder! Vers les managers, compris au sens large comme tout responsable, hors direction générale. Voilà le cœur de notre sujet. Avant de l aborder, énumérons rapidement quelques-uns parmi les faux arguments couramment invoqués pour faire obstruction aux démarches agiles : 1. L agilité n est qu un déguisement du bricolage et du dilettantisme qui empêche l émergence d une rigueur élémentaire. 2. L agilité ne permet aucune planification, empêche toute prédictibilité et l élaboration d une documentation complète d un système. 3. L agilité ne s applique pas aux grandes organisations. 4. La culture de l organisation ne s y prête pas. 5. L agilité fait perdre le contrôle des équipes par les managers. La peur du changement et de la perte de contrôle de la part d une partie du management constitue en réalité le cœur de notre propos. Quiconque a participé à un projet agile partagera l avis que chacun de ces arguments relève soit de l idée fausse, tout simplement, soit de la peur séculaire du changement. Le point 1 par exemple, fournit une bonne illustration d une idée fausse à l état pur puisque, chaque «agiliste» le sait, compétence technique et rigueur sont en réalité des préalables indispensables à toutes ces démarches. Loin de négliger l excellence technique, elles l exigent, nous y reviendrons en détail au chapitre 3. La peur du changement et de la perte de contrôle de la part d une partie du management constitue en réalité le cœur de notre propos. Nous pensons en effet que, derrière ces résistances, se cache notamment une appréhension sourde de nombreux managers qui entrevoient mal quel rôle ils pourraient jouer dans l encadrement d équipes agiles dès lors que celles-ci sont réputées autoorganisées. Du coup, vis-à-vis de l instauration de démarches agiles, le management, hélas, fait aujourd hui trop souvent partie du problème plutôt que de sa solution. Comprendre l origine psychologique de cette résistance puis apporter des réponses concrètes et scientifiquement étayées aux rôles que devront assumer les managers dans un contexte agile constituent le fil rouge de ce livre blanc. Les deux prochaines sections abordent les deux facteurs de résistance sur lesquels nous souhaitons mettre l accent : le besoin de causalité et la peur de perdre ses responsabilités. 07 52
Le besoin de causalité Dans notre pays, champion toutes catégories du cartésianisme, l un des passages obligés d une majorité de projets informatiques reste à ce jour l élaboration patiente des fameuses spécifications du système à construire : générales, détaillées, fonctionnelles puis nonfonctionnelles pour ne rien oublier. Pour conjurer les aléas d un projet nous aimons édicter ces mini-constitutions dans l espoir (ou l illusion plutôt) que leur seule force législative en garantira le bon déroulement. Une belle constitution, voilà qui rassure! Le retard au démarrage vis-à-vis des démarches agiles en France que nous évoquions plus haut n est en rien le fruit d un hasard. C est plutôt une manifestation d un trait culturel bien identifiable, celui de notre gargantuesque appétit réglementaire. Nous aimons trouver des causes même lorsque celles-ci n existent pas! Le rituel des «specs» n est qu un exemple parmi d autres d un besoin inné de prédictibilité plus général, qui n est propre ni à l IT ni aux habitudes locales. On peut assez facilement tenter de rationaliser ce besoin en invoquant diverses contraintes économiques que chacun aura présentes à l esprit. Nous pensons cependant que là n est pas le fond de l affaire. En réalité, ce besoin de contrôle est profondément enraciné dans la psyché humaine, bien au-delà des seules contraintes économiques contemporaines d un projet IT. Instinctivement, nous pensons qu il est toujours possible d identifier les bonnes causes qui conduiront aux effets souhaités. En grossissant légèrement le trait, nous espérons que les bonnes «specs» conduiront au bon système! Ce désir immodéré du déterminisme possède des causes diverses dont l analyse exhaustive dépasserait largement le cadre de ces lignes. Trois d entre elles nous semblent pourtant mériter une brève considération pour mieux situer la suite de notre propos. La première est d ordre biologique, la seconde est liée à l histoire de la science récente et la dernière est liée à notre éducation. Sur le versant biologique et inné, il y a fort à parier que nous aimions le déterminisme car l aptitude à en faire bon usage a garanti durant plusieurs centaines de millénaires la survie de nos lointains ancêtres qui habitaient la savane. Leur chance de survie face à des prédateurs plus puissants et plus rapides était largement tributaire de leur aptitude à associer des causes et des effets : si les branches d un fourré bougent, c est qu un lion s y cache! Du coup, la sélection naturelle a favorisé jusqu à l excès notre désir d explication causale. Nous aimons trouver des causes même lorsque celles-ci n existent pas. Nombre de rituels et de superstitions, liés ou non à des projets informatiques, y trouvent une explication rationnelle (Appelo, 2010), (Brooks, 2009). La seconde cause de notre confiance immodérée dans les vertus du déterminisme est plus récente et relève cette fois de l acquis. Depuis deux siècles, avec notamment l avènement de l astronomie moderne, les succès incontestables et parfois spectaculaires du déterminisme ont marqué les esprits. C est bien la connaissance détaillée des lois de la gravitation et l application du déterminisme qui a permis de faire se poser la sonde Curiosity dans un mouchoir de poche sur Mars il y a un an. 08 52
On pourrait citer encore, quoique à degré moindre, le rôle de notre éducation en mathématiques élémentaires qui, pour d évidentes raisons pédagogiques, privilégie l étude des problèmes linéaires pour lesquels les effets sont proportionnels aux causes et forge ainsi son lot de fausses intuitions. Cette quête, souvent inconsciente, d un déterminisme inexistant dans les projets informatiques constitue, pensons-nous, l un des obstacles principaux à surmonter afin d instaurer une culture de l agilité. Elle est en effet à l origine de résistances comme : La difficulté à renoncer à la fausse croyance que l on peut spécifier intégralement un logiciel par avance. La réticence pour un manager à renoncer au mode de management classique de type «commande et contrôle» (cf. point 5 ci-dessus). Ce dernier point fait la transition avec le second facteur de résistance que nous souhaitons aborder. LA peur de perdre ses responsabilités La perte de contrôle par les managers vis-à-vis d équipes techniques auto-organisées, mentionnée au point 5, est rarement évoquée explicitement en ces termes. Elle fait plutôt écho à une anxiété sourde et inavouée, particulièrement lancinante en période de vaches maigres propice aux questionnements existentiels du genre «à quoi je sers dans cette entreprise?» ou, plus prosaïquement, «comment puis-je justifier mon salaire auprès de ma direction?». Les palliatifs usuels, comme se dire systématiquement «over-booké», courir dans les couloirs en arborant des airs importants et enchaîner les réunions, fonctionnent un temps mais ont du mal à dissiper l angoisse sur la durée. L antidote consiste donc à redéfinir les rôles du management. * Les effets pervers sur l innovation des excès de rationalisation et d automatisation, tels qu on les rencontre parfois dans l IT, on parle alors de prolétarisation, ont été analysés par différents auteurs (Stiegler) (P. Lemberger, 2011). Dans un monde où les technologies de l information favorisent l émergence d un mode de production qu on pourrait qualifier de «sur-mesure de masse», les organisations hiérarchiques classiques basées sur le mode «commande et contrôle», avec leurs traditionnels jeux de pouvoir (un terme sur lequel il faudra revenir) s avèrent non seulement caduques, mais surtout contreproductives. Il va sans dire qu on ne crée pas de la valeur dans une industrie en perpétuelle mutation dont le nerf de la guerre est l innovation, la créativité et la connaissance par les mêmes moyens que ceux qui permettent de vendre en masse des produits standardisés* (Barrand, 2007). En effet, les ressorts psychologiques qui favorisent l émergence de la créativité et de l agilité au sein d une organisation sont très différents de ceux nécessaires pour faire des économies d échelle ou mener des efforts d automatisation (Taylorisme). Favoriser l agilité et la créativité exige en réalité de redéfinir la nature même du pouvoir des managers et de transformer son exercice, d où précisément le caractère anxiogène de l opération qu il s agit de surmonter. Mentionnons enfin que l autre extrémité du spectre, celui de l anarchie organisationnelle, n est guère plus propice à la création de valeur, car justement elle inhibe tout processus d autoorganisation. 09 52
Redéfinir les rôles du management Quête d un déterminisme inexistant et appréhension de perdre ses responsabilités ou son statut, voilà selon nous les deux principaux obstacles à surmonter pour instaurer une authentique culture de l agilité dans le management. La démarche à suivre s impose donc d elle-même, elle procède en deux temps. * Jurgen Appelo, dont le sens du marketing n est plus à démontrer, est l auteur de l expression «Management 3.0» qui désigne cette nouvelle conception d un management basé sur les sciences de la complexité. ** Pour une introduction approfondie au sujet nous recommandons l ouvrage M. Griffith (Mitchell, 2009), lauréat du prix Phi Beta Kappa 2010 qui récompense les ouvrages exceptionnels par leur qualité pédagogique. Il nous faut d abord comprendre comment fonctionne une équipe agile que nous assimilerons à un système dynamique auto-organisé. C est le sujet qui sera abordé au chapitre suivant. Notre analyse s inspire de celle présentée dans (Appelo, 2010)* et s appuie sur les sciences de la complexité** (Mitchell, 2009), en particulier sur diverses métaphores biologiques. A la lumière de cette compréhension, nous définirons ensuite les rôles nouveaux qu il nous semble pertinent d attribuer aux managers. Ils tiendront compte de ce qui fait la spécificité de la complexité sociale de projets informatiques menés sur un mode agile. Nous en retenons quatre, logiquement imbriqués : 1. Favoriser la compétence et l autonomie des individus. C est là un préalable à défaut duquel l agilité n est même pas envisageable. 2. Favoriser l auto-organisation des équipes. On se focalise dans ce rôle sur les liens entre individus plutôt que sur les individus eux-mêmes. 3. Définir les bonnes contraintes pour créer de la valeur. L auto-organisation n étant pas un objectif en soi, il s agit d en extraire de la valeur en fixant les bonnes conditions. 4. Enfin, le seul moyen de rester dans la course est de créer les conditions d une amélioration continue, qui est le dernier rôle. Il va sans dire que ces quatre rôles sont en réalité partiellement interdépendants et que la répartition que nous proposons possède, inévitablement, une part d arbitraire. Cependant, nous espérons qu elle aura au moins quelque vertu mnémotechnique. Le chapitre suivant s attache à montrer comment différentes disciplines des sciences de la complexité peuvent jeter une lumière à la fois originale et utile sur la dynamique d une équipe agile. Les chapitres 3 à 6 décriront ensuite les quatre rôles qui incombent à un manager agile. 10 52
Agilité et complexité
2. Agilité et complexité On présente d ordinaire les démarches agiles comme des substituts pragmatiques aux méthodes de conception classiques, jugées trop bureaucratiques ou inutilement formelles. En outre, lorsque l on songe au taux d échec des projets informatiques menés selon ces méthodes classiques, 68% selon certaines sources (Ellis, 2008), (Krigsman, 2008), on se dit qu un qualificatif probablement plus adéquat serait «irréalistes» voir même «irrationnelles», tant le déni de réalité est patent. De toute évidence, un ou plusieurs éléments fondamentaux, dans la nature même de ce qu est un projet informatique, n ont pas été pris en compte. Voilà qui nous ramène au besoin de causalité. Notre besoin inné de prédictibilité est si puissant qu il entretient l illusion coriace que le temps et la charge pour la réalisation d un système informatique sont prédictibles à condition que l effort de planification ait été suffisant. De toute évidence, un ou plusieurs éléments fondamentaux, dans la nature même de ce qu est un projet informatique, n ont pas été pris en compte. Prenant acte de ces observations négatives, les démarches agiles considèrent que le seul objectif réaliste est l optimisation de l effort pour produire un logiciel qui réponde aux besoins des utilisateurs. Ni l architecture logicielle détaillée, découverte en cours de route, ni le planning détaillé ne sont à fournir en début de projet. Toutefois, à l inverse des méthodes traditionnelles, dont la prédictibilité est le plus souvent prise en défaut au fur et à mesure de l avancement du projet, celle des démarches agiles s accroît à chaque itération. Rappelons-en ici quelques principes fondamentaux : Une équipe agile est auto-organisée et l essentiel de sa valeur réside dans les interactions entre individus plutôt que dans la quantité de savoir emmagasinée dans tel ou tel cerveau. Les individus sont présumés compétents, autonomes et responsables. L accent sur la qualité est essentiel. Toutes les tâches fastidieuses et répétitives (comme les tests unitaires ou l intégration) doivent être automatisées pour éviter que s installe un ennui préjudiciable à la motivation. Les utilisateurs du logiciel sont activement impliqués dans sa conception et leur représentant peut à tout moment redéfinir les priorités des différentes fonctionnalités à implémenter. Le mode de développement est itératif. Chaque livraison apporte son lot de nouvelles fonctionnalités testables, permettant d évaluer objectivement l avancement du projet et d obtenir un feedback précoce. Le rythme de travail de l équipe doit être soutenable. Les démarches agiles visent donc la flexibilité plutôt que la prédictibilité puisque celle-ci, il faut bien s y faire, n est qu une illusion. 12 52
Bien que cela ne soit pas directement lié au sujet du management agile, il est à noter que le constat d imprédictibilité et l implication active des utilisateurs que présupposent les démarches agiles viennent tous deux remettre en question des traditions bien établies. D un point de vue logique, l imprédictibilité au sens large n est guère compatible en effet avec la réalisation de projets au forfait dans laquelle le prestataire est seul à porter le fardeau de l incertitude. Pour ce qui est de l implication active des utilisateurs, la dichotomie traditionnelle entre MOA et MOE chère à nos entreprises françaises n y est guère favorable. Ces sujets mériteraient à eux seuls une étude séparée mais il y a fort à parier que l agilité prise au sérieux va de pair avec l instauration de nouvelles formes de partenariats et d organisations (intra et inter entreprises). Bien qu importants, nous considérons ces problèmes comme des épiphénomènes à mettre sur le compte d une vision trop étroitement cartésienne des projets informatiques et des organisations, qui reste le problème fondamental. La complexité dont il est question ici n est en rien liée à la taille de l équipe, qui peut être modeste, mais au caractère non déterministe de son fonctionnement. L origine profonde de cette imprédictibilité, on s en doute, est la dynamique hautement nonlinéaire d une équipe de développement. Nous l envisageons comme un système social complexe et adaptatif, chargé de convertir en logiciel un besoin utilisateur découvert au fil de l eau. Insistons sur le fait que la complexité dont il est question ici n est en rien liée à la taille de l équipe, qui peut être modeste, mais au caractère non déterministe de son fonctionnement. Pour guider, améliorer et faire croître de telles équipes, la première responsabilité du management sera donc de chercher à comprendre comment elles fonctionnent et quels en sont les principaux catalyseurs ou inhibiteurs. La non-linéarité et le caractère auto-organisé exigent en effet un mode de gouvernance différent du mode hiérarchique usuel que l on pourrait qualifier, pour aller vite, de «commande et contrôle» ou de «top down» si l on préfère. L ancien paradigme où l on assimile implicitement une équipe projet à une sorte de machine qu il s agirait de construire sera remisé au profit d analogies tirées pour beaucoup du monde vivant. Il s agit en effet de faire croître plutôt que de construire. Il n existe aucune science unifiée de la complexité mais plutôt un éventail de disciplines qui impliquent aussi bien les sciences dures que les sciences sociales. * L un des plus éminents promoteurs en France de ce regard décloisonné sur les sciences est le sociologue Edgar Morin qui a introduit et développé son concept de «pensée complexe» (Morin, 1982). C est là que les sciences de la complexité viennent à la rescousse. Le pluriel est ici de mise car, pour l heure, il n existe aucune science unifiée de la complexité mais plutôt un éventail de disciplines qui impliquent aussi bien les sciences dures que les sciences sociales. D une certaine manière, on peut considérer que ces disciplines, par les ponts qu elles permettent d établir*, constituent un antidote rationnel au cloisonnement des connaissances techniques, scientifiques et sociales. Citons à titre d exemple certains phénomènes de stabilité dans l atmosphère découverts initialement par les météorologues qui ont, par la suite, fait l objet d une étude abstraite par les mathématiciens qui les ont nommés «attracteurs étranges», un concept qui 13 52
s est finalement avéré utile pour comprendre la récurrence de certains comportement sociaux, nous y reviendrons. Voici quelques-unes des disciplines dont nous nous inspirerons pour comprendre le fonctionnement d une équipe agile. Les concepts et les métaphores présentés alimenteront la description des quatre rôles qu un manager agile devra assumer. Le lecteur pressé pourra cependant passer directement au chapitre 3 et revenir à cette section en cas de besoin. La systémique La systémique se situe au niveau le plus général de l étude des systèmes, qu ils soient complexes ou non. Plutôt qu une science constituée, on devrait parler à son sujet d une approche globale qui vise à surmonter les limites inhérentes à toute démarche cartésienne qui procède par décomposition d un système complexe en sous-systèmes intelligibles plus simples. L objectif initial de la systémique au début du 20ème siècle était de fournir un vocabulaire ainsi qu un jeu complet de concepts qui permettraient d étudier n importe quel système quel que soit le domaine. Même si cette ambition initiale s est avérer irréaliste car trop générale, les concepts forgés à cette occasion restent d une grande utilité, notamment pour notre sujet. La systémique résulte de visions individuelles, parfois conflictuelles, qui se confrontent. La systémique considère qu un système est complexe lorsque son fonctionnement ne se laisse pas appréhender par l analyse des sous-systèmes qui le composent et que son comportement est à la fois non-linéaire et imprévisible. L idée d émergence, à savoir que certains comportements d un système, ne se laissent pas réduire au comportement de ses composantes est centrale. Dans le cadre d une équipe agile par exemple, la vision globale d un système informatique sera conçue dans cet esprit comme une propriété émergente à l équipe. Aucun membre ne la détient à lui seul. Elle résulte de visions individuelles, parfois conflictuelles, qui se confrontent. Cette idée d une vision globale conçue comme une entité émergeante est fondamentale. C est elle qui légitime la pratique des décisions collégiales dans une équipe agile. La systémique nous enjoint donc à concentrer notre attention sur les relations entre individus plus que sur les individus eux-mêmes. Parmi les autres concepts utiles à notre contexte forgés par la systémique, citons les boucles de rétroaction. Lorsque la réponse d un système à une sollicitation externe tend à renforcer cette cause, on parle de boucle positive, étant bien entendu qu il ne s agit pas ici d un jugement de valeur. Ce sont tous les effets de type boule de neige, qu ils soient souhaitables (une équipe qui a du succès attire de nouveaux talents, ce qui renforce ses chances de succès) ou non (une mauvaise qualité de code génère du stress qui diminue encore la qualité). Ce type de boucles amplifie donc les effets de manière non-linéaire et contribue à éloigner un système de l équilibre et à le rendre instable. A l inverse, on parle de boucles négatives lorsque la réponse d un système à une sollicitation externe tend à atténuer cette cause. Elles sont facteurs de stabilité ou d inertie et l on conçoit aisément tout l intérêt de les identifier pour rendre une organisation efficace et 14 52
pérenne. Que de petits effets sur un système complexe puissent avoir de grandes conséquences n est qu une conséquence de l imbrication de ces boucles de rétroaction multiples. la cybernétique * La cybernétique, contrairement à la systémique, a par ailleurs fait l objet d un travail de modélisation mathématique avancé, notamment dans les mains de Norbert Wiener qui en a énoncé les concepts, dont la célèbre boite noire. Etroitement liée à la systémique, la cybernétique étudie plus spécifiquement les systèmes complexes soumis à des buts et régulés par des boucles de rétroaction négatives. Elle étudie donc les mécanismes de causalité circulaires et les flux d informations qui circulent entre un système et son environnement*. Le concept d itération, proche de l acception du terme dans les démarches agiles, y est introduit. Après qu un système a agi sur son environnement, on étudie l impact de cette action et enfin l on compare cet impact à ce qui était prescrit dans les buts assignés. Enfin, la cybernétique étudie aussi comment de nouveaux équilibres peuvent s instaurer dans un système complexe à partir de situations de déséquilibre, un constat particulièrement utile dans le management d équipes agiles comme on le verra au chapitre 6. Un manager devra se connaître lui-même pour bien manager. Plus récemment, la cybernétique a également introduit l idée que l observateur d un système doit s inclure lui-même lorsqu il analyse un système dont il affecte le comportement par sa présence. Ce point de vue marque une rupture épistémologique aussi considérable que l abandon de la démarche analytique déjà évoquée. Un manager par exemple devra se connaître luimême pour bien manager. En ce sens, on le voit, les conclusions de la cybernétique rejoignent à la fois l antique sagesse du précepte «Connais-toi toi-même!» et l idée que le seul pouvoir véritablement utile est celui qu on exerce sur soi-même. L idée de rétroaction est bien sûr fondamentale dans les projets informatiques puisqu une grande part de l imprédictibilité qui les affecte tient à l impact, à priori inconnu, qu un logiciel aura dans le contexte social dans lequel il est introduit. A ce titre, assimiler un système d information à une sorte de machine compliquée qui aurait une existence et des qualités propres, indépendantes des utilisateurs, n est qu un leurre. La théorie des systèmes dynamiques et le chaos La théorie des systèmes dynamiques fait partie de la physique théorique et étudie l évolution de systèmes soumis à des lois déterministes. L un des principaux intérêts de cette théorie est qu elle permet de comprendre les mécanismes de transition entre des situations où la dynamique d un système est régulière et celles où son comportement devient chaotique. Elle permet en particulier de réconcilier le déterminisme avec les idées d imprédictibilité et de chaos, c est le phénomène bien connu de sensitivité aux conditions initiale, appelé aussi l effet papillon. Par ailleurs, pour nombre de concepts déjà évoqués comme le chaos, la stabilité, l imprédictibilité ou le déterminisme, cette théorie fournit des concepts mathématiques dépourvus de toute subjectivité. 15 52
Un attracteur étrange est une structure émergente qui apparaît à la frontière entre l ordre et le chaos. Beaucoup de systèmes complexes réels sont dits dissipatifs, c est-à-dire qu ils sont soumis à une force de freinage qui tend à les ramener vers une situation d équilibre. L expérience montre que des comportements complexes résultent le plus souvent de l influence conjointe d une force de freinage interne et d une force externe qui, elle, tend à créer le mouvement. Le système résout alors ce conflit en adoptant sur le long terme un certain comportement limite. Selon les cas, ce comportement limite pourra être statique, cyclique ou complexe. On parle d attracteur lorsque le système s en approche à long terme, indépendamment des conditions initiales précises. Enfin, celui-ci est dit étrange, lorsqu il correspond à un comportement limite complexe. Un attracteur étrange est donc une structure émergente qui apparaît à la frontière entre l ordre (incarné par la structure de l attracteur) et le chaos (qui empêche toute prévision précise quant à la localisation du système sur cet attracteur). Mentionnons enfin que l ensemble des conditions initiales qui amènent le système à converger vers un attracteur est appelé son bassin d attraction. En bref, la théorie des systèmes dynamiques explique pourquoi, dans certaines circonstances, le comportement à long terme d un système échappe à toute velléité de le contrôler au moyen d un ajustement des conditions initiales. Figure 1 : Deux attracteurs A1, A2 et leur bassin d attraction B1, B2. Le lien S représente un saut de grande ampleur qui permet de passer d un bassin à un autre. La relation avec notre sujet est alors immédiate : combien de fois, dans nos projets informatiques, n avons-nous pas observé des situations qui se répètent, le plus souvent contre notre gré, alors même que nous pensions avoir fait le nécessaire pour nous en prémunir? Combien de DSI finissent par consacrer l essentiel de leur budget informatique à la maintenance de systèmes anciens alors que leur ambition initiale était de diminuer les coûts à grand renfort de technologies flexibles et d architecture SOA (David Shpilberg, 2007)? Le message de la théorie des systèmes dynamiques est que dans de telles situations il peut s avérer judicieux de changer de bassin d attraction ou, plus radicalement, de déplacer l attracteur, un sujet qui sera abordé au chapitre 6. 16 52
Les automates cellulaires et les systèmes adaptatifs * Explicitement : une cellule morte devient vivante lorsque 3 cellules adjacentes sont vivantes, une cellule vivante le reste si 2 ou 3 cellules adjacentes sont vivantes, une cellule meure ou reste morte dans tous les autres cas. Une classe de systèmes dynamiques particulièrement intéressantes à considérer, par la richesse des analogies qu elle suggère, est celle des automates cellulaires. Plutôt que d en donner une définition abstraite, illustrons le concept par un exemple, celui du célèbre «Jeu de la Vie» (Gardner, 1970) inventé par John Conway. L univers de ce système est constitué par un quadrillage à deux dimensions dans lequel chaque cellule peut-être soit vivante, soit morte. A partir d une configuration initiale l évolution du système est régie par trois règles spécifiques qui définissent les états successifs de chaque cellule en fonction de l état des cellules adjacentes*. L un des intérêts du «Jeu de la Vie» (qui en réalité n est pas un jeu!) c est la richesse prodigieuse de comportements qui émergent de ces trois règles**. **Il a prouvé par exemple, qu au moyen de configurations initiales judicieuses et extrêmement complexes, le Jeu de la Vie était capable d effectuer n importe quel calcul. Figure 2 : Une configuration de l automate cellulaire du «Jeu de la Vie». Ce qui en fait une source d inspiration dans le cadre du management agile, c est la question cruciale du choix des règles communes aux équipes agiles et aux automates cellulaires. Choisies au hasard, l immense majorité des règles conduit à des automates dont le comportement, parfaitement ennuyeux, est assimilable aux attracteurs stables ou périodiques évoqués plus haut. De fait, il a fallu tout le génie et la persévérance d un J. Conway pour parvenir à débusquer le jeu des trois règles spécifiques au «Jeu de la Vie» qui, à la frontière de l ordre et du chaos, engendre un comportement complexe et créatif. Dès lors, la question qui tombe sous le sens est la suivante : un manager est-il à une équipe agile ce que J. Conway a été au «Jeu de la Vie»? En d autres termes, le rôle d un manager est-il de définir les bonnes règles pour faire en sorte que son équipe soit créative et productive? D emblée, vendons la mèche, la réponse est non, mais la justification détaillée interviendra au chapitre 5. Pour l instant, remarquons qu à la différence des automates cellulaires, une microsociété telle qu une équipe agile est capable de se doter de ses propres règles. Elle est susceptible d autoorganisation en ce sens qu elle est capable de se maintenir, par elle-même, dans cette zone fragile de créativité, à la lisière du chaos. Elle fonctionne en réalité comme un système complexe adaptatif c est-à-dire comme un système de règles en perpétuelle réévaluation. L évaluation des règles procède par comparaison entre l état actuel du système et l état correspondant au but assigné au système. En l occurrence : réaliser un logiciel qui satisfasse les utilisateurs. Dans cette vision, l une des responsabilités du manager sera de faire en sorte que l équipe agile puisse élaborer ses propres règles. Ce sujet sera abordé aux chapitres 3, 4 et 5. 17 52
L un des principaux messages au management de la part des sciences de la complexité et en particulier de la biologie est le suivant : les systèmes complexes performants dans la nature n ont pas de commandement central. Le rôle du manager n est pas de commander à des individus mais plutôt de manager des équipes pour qu elles prospèrent comme des êtres vivants sains. Une dernière remarque de prudence : il ne saurait être question pour un sujet aux contours aussi flous que le management agile, de découvrir de prétendues lois universelles, encore moins de prouver des théorèmes que l on pourrait asséner comme des vérités absolues à un interlocuteur dubitatif. Les contreparties à l utilisation de métaphores issues d un large éventail de disciplines scientifiques comme nous le faisons sur les traces de Jurgen Appelo, sont la prudence et l esprit critique. Appliquer les concepts et les idées des sciences de la complexité au management d équipes agiles, remplacer les antiques intuitions cartésiennes par de nouvelles, plus rationnelles et mieux adaptées à la complexité technique et sociale des projets informatiques, tels sont les objectifs du management agile. 18 52
Favoriser la compétence et l autonomie
3. favoriser la compétence et l autonomie Les dangers cachés des «bonnes pratiques» L un des principes récurrents dans les métiers de l informatique est celui de la capitalisation. Eviter de réinventer la roue, ne pas refaire ce qui a été fait à maintes reprises ailleurs par d autres, surtout leurs erreurs, voilà qui ne semble guère devoir être remis en question. * API : Application Programming Interfaces. Puisqu il est question ici d agilité, considérons à titre d exemple le génie logiciel. Sont apparus successivement dans cette discipline des principes de conception réutilisables, communément appelé «design patterns» (Erich Gamma, 1994), des API* qui formalisent ces principes dans des langages de programmation spécifiques et, enfin, des implémentations de ces API sous forme de framework réutilisables. La réutilisation dans le génie logiciel concerne donc aussi bien les concepts que leur mise en œuvre effective sous forme de code. D autres référentiels offrent des listes de bonnes pratiques, plus ou moins effrayantes (ou soporifiques) par leur ampleur, pour des sujets aussi variés que l architecture des systèmes d information (TOGAF) le management de système d information (ITIL, CoBiT) ou encore pour l amélioration de la qualité des développements (CMMI). Les démarches agiles ont à leur tour été formalisées sous forme de manifestes ou de crédos plus ou moins flamboyants (Scrum, RUP, Lean Software Development, la méthode Kanban). Si elle est légitime et souvent même indispensable, la démarche de capitalisation, poussée à l extrême, peut aussi engendrer des effets pernicieux dont il faut être conscient. L excès de confiance dont font l objet certains référentiels de bonnes pratiques peut susciter un dangereux sentiment de fausse sécurité. Des processus peaufinés pendant des lustres, avec leur batteries d indicateurs, de rituels et des compte-rendu utilisant le bon modèle de document deviennent alors que des paravents qui retardent la solution des vrais problèmes et mènent à la catastrophe. Les processus constituent un cadre de travail mais ils ne produisent pas d idées. La méconnaissance de la complexité des projets informatiques de la part de responsables n ayant jamais mis les mains dans le cambouis ne fait qu alimenter cet excès de confiance. Ne négligeons pas non plus le rôle néfaste de la mauvaise foi, cette forme de couardise qui fait préférer l abri confortable des procédures aux risques inhérents à toute formulation d un jugement personnel et à toute prise de responsabilité. La compétence et l autonomie sont indispensables. L une des caractéristiques des projets informatiques sur lesquelles on n insiste pas assez, c est que leur complexité ne se laisse pas maîtriser par des procédures, des «templates» ou des algorithmes uniquement. Voilà qui nous amène finalement au sujet de ce chapitre : pour faire face à ce caractère irréductible d une situation complexe particulière, la compétence et l autonomie sont indispensables. Elles sont en réalité des préalables pour gérer la complexité sur un mode agile. La remarque peut paraître banale, mais trop d exemples nous viennent à l esprit pour que nous omettions de rappeler ici ce fait fondamental. 20 52
L exigence de compétence et d autonomie doit primer sur le souci d amélioration des procédures. L application scrupuleuse d un référentiel de bonnes pratiques, quel qu il soit, ne pourra jamais se substituer à la compétence et au sens des responsabilités des individus. Cette remarque prend toute sa signification dans un contexte où l innovation et la créativité jouent un rôle prépondérant. On ne peut en effet ni décider, ni planifier l innovation, on peut tout au plus la cultiver dans un environnement social où sont promues des valeurs comme l excellence technique, la curiosité, l originalité, le sens de l initiative, fût-ce au coût d un zeste de désobéissance et d irrévérence. Une définition de la compétence Mais qu est ce que la compétence au juste? Dans un premier temps on pense évidemment au savoir-faire professionnel et aux connaissances académiques. Un développeur par exemple doit maîtriser un certain nombre de langages de programmation, quelques principes de conception ainsi qu un environnement de développement. Pourtant, le savoir-faire à lui seul ne suffit pas. Que dire en effet d un développeur féru de toutes les API Java/JEE mais incapable de tenir le moindre engagement de délai ou de qualité? A l évidence il ne pourra être qualifié de compétent car il lui manque une qualité tout aussi essentielle que le savoir-faire : la discipline. Nous parvenons ainsi à l équation (Appelo, 2010) : Compétence = (Savoir-faire) * (Discipline) Savoir-faire et discipline sont deux qualités indépendantes, l une pouvant être présente chez un individu sans que l autre ne le soit. Elles devront pour cette raison être développées séparément par les managers. Assurer un haut niveau de savoir-faire suppose naturellement de recruter des profils initialement bien formés mais aussi de leur garantir par la suite la possibilité de se former en continu. Les profils de spécialistes qui se généralisent progressivement sont souvent les plus utiles dans les projets car leur culture générale IT se conjugue avec l expérience de ce que coûte le développement d une réelle expertise. * Paas : Platform as a Service Paradoxalement, la perte de savoir-faire peut aussi résulter de certains progrès technologiques lorsque ceux-ci permettent l automatisation de tâches au préalable manuelles. On peut anticiper par exemple que la généralisation des applications en mode PaaS* conduira à la perte progressive de savoir-faire liés au déploiement d applications sur des machines locales et à la maintenance d une infrastructure matérielle. 21 52
Les différents types de motivation Après le savoir-faire, passons au deuxième facteur de la compétence : la discipline. Largement tributaire de la motivation des individus, un manager devra s attacher à la maintenir à un niveau raisonnable dans ses équipes et donc à en comprendre les diverses facettes. Lorsqu une source de motivation est externe à un individu, on parle généralement de motivation extrinsèque. Entrent dans cette catégorie les formes classiques d incitations et de récompenses comme les bonus financiers, les promotions ou même les compliments adressés pour l accomplissement d un bon travail. Le stimulus externe peut même avoir un effet opposé à celui qui était à l origine de l incitation. Remarquons que ce types de mécanismes d incitation, ou à l inverse de sanction, reposent, là encore, sur un postulat déterministe s agissant du comportement des individus. On présuppose qu il est possible de trouver des causes adéquates pour susciter un certain type de comportement chez certains individus, qu il s agisse d un surcroît de discipline, de qualité du travail ou d investissement personnel. Bien que ce mode de fonctionnement soit effectivement présent à des degrés divers chez tous les humains, de nombreuses études en sciences sociales ont montré de manière particulièrement probante (Pink, 2011) que ce type de mécanisme était non seulement inefficace dans beaucoup de cas, mais était même contre-productif. Et ceci d autant plus que les tâches à réaliser exigeaient un niveau élevé de créativité. Parmi les effets secondaires néfastes engendrés par de telles incitations on peut citer, pêle-mêle, l addiction aux incitations, la destruction de la loyauté, de la créativité et de la solidarité, la perte de sens du travail, la création de compétitions inutiles entre collaborateurs et la diminution de l aptitude à résoudre des problèmes complexes. Dans des cas extrêmes, le stimulus externe peut même avoir un effet opposé à celui qui était à l origine de l incitation. On a donc là un comportement manifestement non-linéaire et imprévisible. Mentionnons à titre d exemples, presque comiques, ces développeurs rémunérés aux nombres de bugs corrigés par jour qui en inventaient de nouveaux pour arrondir leurs fins de mois ou ces employés d un centre d appels rémunérées au nombre d appels pris qui raccrochaient régulièrement au nez des clients, histoire de faire grimper leur compteur. En conclusion, on voit que l inconvénient principal des motivations extrinsèques est leur tendance à engendrer des comportements qui n ont de la vertu que l apparence. On se contente de faire semblant. Un comportement authentiquement vertueux qui s attache à produire un travail de qualité est quant à lui la conséquence d une motivation intrinsèque. L essence de la motivation intrinsèque est une activité qui est sa propre récompense, car porteuse de sens pour celui qui l exerce. Ce type de motivation est beaucoup plus stable que le précédent et ne souffre pas d effets non linéaires indésirables puisque la cause et les effets de la satisfaction, l activité elle-même, sont confondus. Les origines psychologiques de la motivation intrinsèque sont multiples et s enracinent profondément dans la quête de sens que chacun cherche à donner à ses activités : 22 52
désir de se sentir compétent, d être maître de son destin, de nouer des relations avec des individus pour qui on a de l estime, d être partie prenante d un projet auquel on adhère et qui nous dépasse. Bien entendu, il est difficile voire impossible pour un manager, sauf à être un authentique sage, de créer de la motivation intrinsèque chez des collaborateurs qui en sont dépourvus. Ce à quoi ils peuvent contribuer en revanche, c est de garantir des conditions d hygiène de travail qui, lorsqu elles sont absentes, la détruisent : la sécurité du travail, des conditions de travail décentes, et bien sûr un salaire en relation avec les compétences exercées. Une phrase clé, pour un manager pourrait-être celle-ci : «Que puis-je faire pour que vous donniez le meilleur de vous-même?». Pourquoi l autonomie? Le manager peut contribuer à garantir de bonnes conditions d hygiène de travail. L autonomie est un sujet plus subtil que celui de la compétence. On conçoit bien tout d abord qu un degré d autonomie minimal soit nécessaire pour qu émerge l auto-organisation dans un contexte agile où les décisions sont collégiales. Pourtant, l autonomie n est pas seulement une exigence, elle est aussi un moyen de valoriser les individus, les collaborateurs comme les managers. Nul besoin d être un expert en psychologie pour concevoir qu un collaborateur, à qui son manager accorde un niveau d autonomie adapté à son expérience, se sentira valorisé et reconnu dans ses compétences. On distingue trois niveaux d autonomisation pour les collaborateurs (Appelo, 2010) : Autonomie faible Elle consiste à déléguer des tâches qui n ont pas beaucoup d impact sur la marche de l entreprise. Pour une équipe de développement on peut ranger dans cette catégorie la définition de conventions de nommage et de codage et l animation de séminaires internes. Autonomie modérée Cette catégorie correspond au niveau d autonomie souhaitable dans un contexte agile. Elle comprend des tâches comme la participation au recrutement de nouveaux collaborateurs, la possibilité de choisir ses heures de travail, le choix des outils de travail ou encore la prise d initiative pour développer de nouvelles offres. Autonomie importante Enfin dans cette catégorie on trouve les associés. Ceux-ci choisissent eux-mêmes les projets sur lesquels ils souhaitent travailler et leur lieu de travail. Ils déterminent collégialement leurs salaires. 23 52
L autonomisation des collaborateurs est un investissement à long terme qui exige de la patience. Malgré les tentations, un manager doit éviter d appliquer l adage «la meilleur solution pour qu une tâche soit menée à bien c est de la réaliser soi-même». Il devra en revanche assumer la délégation des tâches qu il à confiées à ses collaborateurs, la pire erreur étant de reprendre ce qui a été donné. L autonomisation apporte des bénéfices non seulement aux collaborateurs qui en sont gratifiés mais aussi au manager qui l accorde. Celui-ci voit son statut et sa crédibilité renforcés car la confiance qu il accorde à ses collaborateurs témoigne de l assurance tranquille de celui qui sait s entourer d individus compétents et par conséquent sait se rendre dispensable. Voilà l un des meilleurs antidotes à la peur de perdre ses responsabilités mentionnée dans l introduction. Il existe encore une autre motivation pour autonomiser les collaborateurs, directement liée à l initiation du processus d auto-organisation que nous aborderons au chapitre 4. Chaque manager en a fait l expérience à ses dépends, certaines informations au sein d une organisation ont la fâcheuse tendance à contourner les nœuds de décisions. Souvent par appréhension des conséquences pour qui se fait le messager de questions délicates. Parfois aussi, par simple souci d efficacité car on imagine, à tort ou à raison, que ces nœuds sont déjà saturés d informations et de décisions à prendre. Au chapitre 5 nous verrons qu il existe pour une organisation agile un principe, le principe de subsidiarité, qui consiste à affecter toute prise de décision à l échelon hiérarchique le plus bas possible. Il s agit en réalité d un principe d efficacité et non d un souci de démocratie. Beaucoup de problèmes, surtout s ils sont d ordre technique ou s ils relèvent de l affectation de tâches quotidiennes sont résolus plus efficacement lorsque les prises de décisions sont affectées aux individus qui détiennent l information la plus détaillée et la plus récente. Or celle-ci est souvent détenue par les membres de l équipe agile eux-mêmes. L autonomisation des individus rend ce principe applicable et contribue ainsi à distribuer le traitement de l information dans tout le réseau social plutôt que dans quelques nœuds. On parle alors de micro-management. Déléguer des responsabilités à des individus autonomes présuppose naturellement l instauration d un climat de confiance, nous y reviendrons au chapitre suivant. 24 52