SQLI DIGITAL PERFORMANCE TABLE DES MATIÈRES

Transcription

1 1

2

3 TABLE DES MATIÈRES 1. LE MANAGEMENT À L ÉPREUVE DE L AGILITÉ LE BESOIN DE CAUSALITÉ LA PEUR DE PERDRE SES RESPONSABILITÉS REDÉFINIR LES RÔLES DU MANAGEMENT 2. AGILITÉ ET COMPLEXITÉ LA SYSTÉMIQUE LA CYBERNÉTIQUE LA THÉORIE DES SYSTÈMES DYNAMIQUES ET LE CHAOS LES AUTOMATES CELLULAIRES ET LES SYSTÈMES ADAPTATIFS 3. FAVORISER LA COMPÉTENCE ET L AUTONOMIE LES DANGERS CACHÉS DES «BONNES PRATIQUES» UNE DÉFINITION DE LA COMPÉTENCE LES DIFFÉRENTS TYPES DE MOTIVATION POURQUOI L AUTONOMIE? 4. FAVORISER L AUTO-ORGANISATION DES ÉQUIPES L AUTO-ORGANISATION N EST PAS UNE «BONNE PRATIQUE»! CRÉER LA CONFIANCE QUELS BUTS, POUR QUI? ENTRETENIR LA DIVERSITÉ FAVORISER LA CRÉATIVITÉ FAIRE ÉMERGER UNE VISION GLOBALE 5. DÉFINIR LES BONNES CONTRAINTES POUR CRÉER DE LA VALEUR COMMENT DÉFINIR DES RÈGLES ETABLIR UN CONTRAT SOCIAL DÉFINIR UN OBJECTIF PARTAGÉ 6. CRÉER LES CONDITIONS DE L AMÉLIORATION CONTINUE CHANGER CAR L ENVIRONNEMENT CHANGE L ART DE LA NAVIGATION EN TERRAIN MOUVANT 7. CONCLUSION RÉFÉRENCES

4 Pirmin Lemberger avec la participation de Houda Berrada, Julie Lemaire et Arnaud Gonzales 13/09/2013 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. Les sciences de la complexité offrent pour cette tâche un large éventail de métaphores 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. 4 48

5 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 dîtes 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 ESN 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. 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) 1 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. 1 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». 5 48

6 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. 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, 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 1. 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. 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. 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 auto-organisé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. 1 XP en 1999, Scrum en 2001, Kanban en 2003 et le Lean Software Development en

7 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 non-fonctionnelles 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. Nombre de rituels et de superstitions, liés ou non à des projets informatiques, y trouvent une explication rationnelle (Appelo, 2010), (Brooks, 2009). 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 7 48

8 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 le 6 août 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. 8 48

9 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. 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. 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. 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 contre-productives. 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 3 (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 auto-organisation. 3 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). 9 48

10 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. 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) 4 et s appuie sur les sciences de la complexité 5 (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 quelques vertues mnémotechniques. 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. 4 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 compléxité. 5 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

11 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. 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. 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. 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

12 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. 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. 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. L origine profonde de cette imprédictibilité, on s en doute, est la dynamique hautement non-liné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. 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 6, 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 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

13 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. 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. 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érée 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 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 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

14 Le concept d itération, proche de l acception du terme dans les démarches agiles, y est introduit. LA CYBERNÉTIQUE 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 7. 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. 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 lui-mê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. 7 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 boîte noire

15 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 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. 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 initiales, 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é. 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. 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. Figure 1 : 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. 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

16 LES AUTOMATES CELLULAIRES ET LES SYSTÈMES ADAPTATIFS 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 8. 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 9. Figure 2 : 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 8 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 meurt ou reste morte dans tous les autres cas. 9 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

17 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. 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 auto-organisation 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. 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 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. 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 10 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-rendus 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. 10 API = Application Programming Interfaces 18 48

19 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. 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é. 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. 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

20 UNE DÉFINITION DE LA COMPÉTENCE 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. 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. 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 11 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. 11 PaaS = Platform as a Service 20 48