QUELS RÔLES POUR LE MANAGEMENT DANS UN ......1 XP en 1999, Scrum en 2001, Kanban en 2003 et le Lean...

1

QUELS RÔLES POUR LE MANAGEMENT DANS UN CONTEXTE INFORMATIQUE AGILE ?

1. LE MANAGEMENT À L’ÉPREUVE DE L’AGILITÉ ................................................................................5-10LE BESOIN DE CAUSALITÉ LA PEUR DE PERDRE SES RESPONSABILITÉS REDÉFINIR LES RÔLES DU MANAGEMENT

2. AGILITÉ ET COMPLEXITÉ ...............................................................................................................11-17LA 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 ..........................................................................18-24LES 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 .....................................................................25-34L’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 ........................................35-39COMMENT DÉFINIR DES RÈGLES ETABLIR UN CONTRAT SOCIAL DÉFINIR UN OBJECTIF PARTAGÉ

6. CRÉER LES CONDITIONS DE L’AMÉLIORATION CONTINUE .........................................................40-44CHANGER CAR L’ENVIRONNEMENT CHANGE L’ART DE LA NAVIGATION EN TERRAIN MOUVANT

7. CONCLUSION .........................................................................................................................................45

8.RÉFÉRENCES.........................................................................................................................................46

TABLE DES MATIÈRES

3 48

SQLI DIGITAL PERFORMANCE

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.

Pirmin Lembergeravec la participation de

Houda Berrada, Julie Lemaire et Arnaud Gonzales

13/09/2013

4 48


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.

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 foisonne-ment 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 ».

LE MANAGEMENT À L’ÉPREUVE DE L’AGILITÉ

L’un des premiers objectifs de ce livre blanc sera de

comprendre l’origine profonde des réticences vis-à-vis des

démarches agiles.

5 48


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, 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ècle1.

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

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.

6 48


7 48


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.

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

LE BESOIN DE CAUSALITÉ

Nombre de rituels et de superstitions,

liés ou non à des projets informatiques, y trouvent

une explication rationnelle (Appelo, 2010), (Brooks, 2009).

8 48


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

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.

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


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.

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és3 (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.

10 48


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.

REDÉFINIR LES RÔLES DU MANAGEMENT

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 48


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

AGILITÉ ET COMPLEXITÉ

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.

12 48


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’établir6, 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.

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.

13 48


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

LA SYSTÉMIQUE

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.

14 48


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

LA CYBERNÉTIQUE

Le concept d’itération, proche de l’acception du terme

dans les démarches agiles, y est introduit.

7 La cybernétique, contrairement à la systémique, a par ailleurs fait l’objet d’un travail de modélisation mathématique avancé, notam-ment dans les mains de Norbert Wiener qui en a énoncé les concepts, dont la célèbre boîte noire.

15 48


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

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

LA THÉORIE DES SYSTÈMES DYNAMIQUES ET LE CHAOS

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 :

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.

16 48


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 adjacentes8. 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ègles9.

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

LES AUTOMATES CELLULAIRES ET LES SYSTÈMES ADAPTATIFS

Figure 2 : Une configuration de l’automate cellulaire du « Jeu de la Vie ».

Figure 2 :

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 48


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.

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.

18 48


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

FAVORISER LA COMPÉTENCE ET L’AUTONOMIELES DANGERS CACHÉS DES « BONNES PRATIQUES »

10 API = Application Programming Interfaces

19 48


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.

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.

20 48


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

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.

11 PaaS = Platform as a Service

21 48


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

LES DIFFÉRENTS TYPES DE MOTIVATION

Le stimulus externe peut même avoir un effet opposé à celui

qui était à l’origine de l’incitation.

22 48


Une phrase clé, pour un manager pourrait-être

celle-ci: « Que puis-je faire pour que vous donniez le

meilleur de vous-même ? ».

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 : 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 ? ».

23 48


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 faibleElle 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éeCette 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 importanteEnfin 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. 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

POURQUOI L’AUTONOMIE ?

24 48


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épens, 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.

25 48


SUPPOSONS QU’À LA LUMIÈRE DU CHAPITRE PRÉCÉDENT UN MANAGER N’AIT AFFAIRE QU’À DES INDIVIDUS COMPÉTENTS, AUTONOMES ET MOTIVÉS, POUR CONSTITUER SES ÉQUIPES.

L’hypothèse peut sembler hardie, mais nous la faisons pour la clarté dans notre argumentation. Reste encore à constituer cette collection d’individualités compétentes en équipes auto-organisées. Pour que la mayonnaise prenne, encore faut-il que plusieurs conditions soient réunies. Les individus les plus compétents par exemple n’ont pas nécessairement envie de travailler ensemble. Il s’agit donc de créer du lien entre les individus car la performance d’un système social complexe comme une équipe agile tient souvent d’avantage à la qualité des liens du réseau qu’à l’expertise associée à chacun de ses nœuds. Ceci est d’autant plus important dans les domaines comme l’IT où une grande part du savoir est de nature implicite et ne s’acquiert pas par l’étude d’ouvrages mais par assimilation lors de collaborations informelles au sein d’équipes projets.

Deux conditions sont incontournables pour qu’émerge ce lien : la confiance entre les membres de l’équipe ainsi qu’un objectif partagé par tous. Ce sont les sujets des deux prochaines sections ainsi qu’en partie du chapitre 5. Mais, avant cela, revenons un instant sur l’auto-organisation elle même. On aurait tort de penser qu’il s’agit d’un phénomène exotique ou artificiel. En réalité l’auto-organisation est le phénomène le plus naturel du monde. Ce n’est pas une « bonne pratique », c’est plutôt la pratique par défaut d’une majorité de systèmes adaptatifs. Les systèmes vivants en témoignent de manière particulièrement probante, aucun designer

FAVORISER L’AUTO-ORGANISATION DES ÉQUIPESL’AUTO-ORGANISATION N’EST PAS UNE « BONNE PRATIQUE » !

Ce qui est artificiel, c’est d’imaginer que le schéma

classique d’un commandement émanant d’une autorité

centrale, suivi du contrôle de son exécution, puisse

fonctionner pour élaborer des systèmes complexes fiables.

26 48


n’ayant jamais conçu (à notre connaissance) une cellule vivante, une fourmi ou un éléphant. Les systèmes complexes et stables comme les organismes vivants n’ont pas été conçus par une autorité centrale mais ont crû pour s’adapter à leur environnement lui-même changeant. Ce qui est artificiel, voire irrationnel, c’est le fait de prétendre concevoir et planifier par avance des systèmes complexes en interaction avec un système social, comme s’il s’agissait de machines. Ce qui est artificiel, c’est d’imaginer que le schéma classique d’un commandement émanant d’une autorité centrale, suivi du contrôle de son exécution, puisse fonctionner pour élaborer des systèmes complexes fiables.

Pour qu’émerge le phénomène d’auto-organisation deux conditions doivent être remplies. D’une part, le système adaptatif doit posséder une frontière bien définie. C’est le cas par exemple d’une cellule vivante. Il en ira donc de même pour une équipe agile. Pour que s’initie le processus d’auto-organisation, il faudra que chaque équipe soit identifiée comme telle, et par conséquent que chacun sache sans ambigüité à laquelle il appartient. D’autre part, il faut qu’un objectif ait été assigné à cette équipe pour qu’elle crée de la valeur, un sujet qui sera traité en détail au chapitre 5.

Le reste de ce chapitre est organisé comme suit. Nous examinerons dans un premier temps comment réaliser les deux conditions indispensables à l’auto-organisation : la création de liens de confiance et l’assignation d’un objectif à une équipe. Le maintien d’une saine dose de diversité dans les profils d’une équipe est une mesure d’hygiène importante à plus d’un titre, ce sera le sujet d’une autre section. Les deux dernières sections enfin seront consacrées à l’émergence de la créativité et à la construction d’une vision globale d’un système informatique complexe. La création de valeur est aussi une propriété émergente, c’est même la plus importante de toute, le chapitre 5 lui sera entièrement consacré.

27 48


LA CONFIANCE QUE L’ON ACCORDE À UN COLLABORATEUR OU UNE ÉQUIPE EST CET ÉTAT D’ESPRIT QUI PERMET DE TRAVAILLER SANS ARRIÈRE-PENSÉE

Indépendamment même de toute considération éthique, elle est un facteur d’efficacité opérationnelle. Elle simplifie la vie en minimisant la quantité d’informations à échanger pour effectuer une certaine tâche de même que le nombre de contrôles à effectuer. Bien souvent elle pourra se substituer avec profit à l’échafaudage laborieux de contrats qui prétendent anticiper toutes les figures imaginables de mauvaise foi. Evidemment, la confiance ne se décrète pas. Elle se gagne, lentement. Elle est accordée à celui ou celle dont les actes coïncident le plus souvent avec les intentions affichées. Girouettes, manipulateurs et opportunistes sont, à l’inverse, de véritables trous noirs pour la confiance : ils la détruisent durablement.

CRÉER LA CONFIANCE

1

2

3

Figure 3 :

Figure 3 : Les relations de confiance entre un manager dans l’ordre où elles devraient être

instaurées.

28 48


Le premier devoir, particulièrement pour un manager, est d’avoir confiance en soi. C’est une condition indispensable pour gagner celles des autres, tant il est vrai que la plupart des humains ont une aptitude remarquable à déceler les signaux de fausseté, mêmes infinitésimaux. La confiance en soi exige de ne pas se mentir à soi-même et de rester fidèle à ses convictions, même en présence de pressions politiques ou d’avis divergents. Enfin, et dans le même ordre d’idées, n’oublions pas que l’un des moyens les plus efficaces, mais aussi les plus difficiles pour susciter la confiance, est de savoir reconnaître sereinement ses propres faiblesses.

S’agissant de la confiance qu’un manager décide d’accorder à un collaborateur ou à une équipe, celle-ci doit être assumée par lui. En clair, si cette confiance était trahie par l’un de ses collaborateurs, il sera responsable de la confiance qu’il a décidé d’accorder. La relation entre un manager et son équipe est évidement asymétrique. Pour cette raison c’est à lui d’initier le cercle vertueux de la confiance en attribuant, sans attendre de retour immédiat, la sienne à son équipe. Non pas pour se défausser de ses propres responsabilités, mais pour investir ses collaborateurs d’un surcroît de pouvoir et par conséquent de responsabilités. Une manière courante hélas de détruire ce type de confiance, parfois par inadvertance, consiste pour un manager à réaliser lui-même une tâche qu’il avait confiée à un collaborateur ou à prendre une décision à sa place.

Un manager peut contribuer activement à l’instauration d’un climat de confiance entre membres d’une équipe en jouant sur le caractère transitif de la relation de confiance. Imaginons que Pierre et Paul, fassent partie de l’équipe de Jacques et n’aient pas encore établi de lien de confiance. Celle-ci pourra naître dès lors que Pierre et Paul entretiennent tous deux une relation de confiance avec Jacques, leur manager, qui jouera alors le rôle de nœud de confiance dans le réseau. Enfin un manager doit aussi s’assurer que chacun puisse s’exprimer librement ; en multipliant les occasions de prises de parole informelles par exemple. Il peut aussi aider les individus à tenir leurs propres engagements ou les inciter à annoncer ouvertement qu’ils ne parviendront pas à les tenir.

29 48


NOUS ABORDONS ICI LA SECONDE CONDITION POUR QUE S’ENCLENCHE L’AUTO-ORGANISATION : L’ASSIGNATION D’UN BUT À UNE ÉQUIPE.

Par là, nous anticipons en partie le sujet du chapitre 5 consacré à la définition de contraintes propres à créer de la valeur. La notion de but ou d’objectif est cependant plus subtile et plus riche, on le verra, que la simple assignation par une instance externe d’un objectif à une équipe agile. Ce sujet est délicat pour deux raisons. D’une part, les sciences dures ont coutume de considérer que les questions liées à la finalité ou au sens doivent être maintenues hors du champ scientifique. Ceci peut donc créer chez certains une inhibition à aborder les questions touchant au « pourquoi » d’une activité. Nous pensons au contraire, en accord avec les chercheurs en sciences sociales, que ce sujet est tout à fait sérieux et qu’on ne peut manquer de l’aborder lorsqu’il s’agit de clarifier le rôle du management. Une seconde source de difficulté tient au fait que les termes même d’objectif, de but ou de sens, qu’on les applique à une entreprise, à une équipe ou à un individu, possèdent une sémantique qui prête à confusion. Notre première tâche sera donc d’y mettre bon ordre.

Nous inspirant de (Geus, 1997) et (Appelo, 2010), nous définirons trois concepts distincts de buts. Tous s’appliquent à un organisme vivant auquel nous assimilerons par la suite une équipe agile ou plus généralement une organisation.

Le but intrinsèqueChaque organisme vivant possède une tendance innée à la survie. C’est cette tendance naturelle et spontanée que l’on définit comme étant son but intrinsèque. Pour une équipe de développement ce but intrinsèque peut être assimilé à « créer du logiciel », faute de quoi en effet elle n’a plus de raison d’être et sera dissoute. Un point important sur lequel il convient d’insister est que le but intrinsèque d’un système vivant ou d’un système social doit être compris comme une propriété émergente. C’est une résultante des interactions entre les sous-systèmes qui le composent. Le but intrinsèque d’un brin d’ADN par exemple est de se répliquer alors que le but intrinsèque d’un organisme vivant est de survivre. De même, le but d’une équipe de développement -créer du logiciel - peut lui aussi être très différent des buts autonomes des membres qui la composent (voir plus loin).

Le but extrinsèqueCette notion de but extrinsèque n’a de sens que lorsqu’un organisme vivant possède un propriétaire, un directeur ou un chef. C’est alors le but assigné par son propriétaire à cet organisme. Le but extrinsèque d’un chien de chasse est de ramener du gibier à son maître.

QUELS BUTS POUR QUI ?

Pour une équipe de développement ce but

intrinsèque peut être assimilé à « créer du logiciel »

30 48


La définition d’un but autonome s’inscrit dans

la quête de sens profondément enracinée

dans tout être humain.

Le but extrinsèque d’une équipe de développement lui est assigné en début de projet par un manager, par des utilisateurs ou par un Product Owner. C’est l’une des contraintes à imposer pour que l’auto-organisation crée de la valeur, nous y reprendrons au chapitre 5.

Le but autonomeCette dernière acception du terme « but » présuppose l’existence d’une conscience, d’une volonté propre ou, si l’on préfère, d’un libre arbitre pour le système complexe en considération. Une fourmi ne peut avoir de but autonome car elle n’a pas de libre arbitre. Un être humain ou un organisme social peuvent en revanche décider de se donner un tel but. Le but autonome de tel développeur pourra être d’écrire du code élégant, celui de tel autre sera de finir son travail aussi rapidement que possible pour pouvoir se consacrer à sa famille etc. La définition d’un but autonome s’inscrit dans la quête de sens profondément enracinée dans tout être humain. Nous avons besoin de nous percevoir comme partie prenante d’un processus auquel nous pouvons attribuer un sens. La réalisation d’un but autonome est en réalité le seul vrai moteur, c’est lui qui rend possible l’émergence d’un but intrinsèque.

Des trois notions de buts que nous venons d’évoquer, seul le but extrinsèque possède un sens pour un système mécanique ou une machine, pour la bonne et simple raison qu’on peut les posséder. Le but intrinsèque est une spécificité des êtres vivants. Le but autonome est le propre d’êtres doués de conscience. Croire qu’on pourrait assimiler ces derniers à des machines est l’une des erreurs les plus grossières auxquelles peut conduire l’excès de cartésianisme.A la lumière de ces clarifications sémantiques on comprend mieux le caractère fallacieux d’affirmations, récurrentes dans certains milieux, du genre : « le but premier d’une entreprise est d’enrichir les actionnaires ». C’est évidemment une confusion grossière des termes. L’enrichissement des actionnaires n’est que le but des actionnaires eux-mêmes et non pas celui des individus qui composent l’entreprise. Les actionnaires ne possèdent que les actifs de l’entreprise mais ils ne possèdent ni les individus, ni les relations qu’ils entretiennent. En réalité l’enrichissement des actionnaires ne pourra jamais tenir lieu de stratégie mais sera une conséquence de la coordination des buts autonomes des individus en un but intrinsèque cohérent à une entreprise. Celle-ci devra donc formuler une vision et porter des valeurs auxquelles ses membres pourront choisir d’adhérer. Sans ligne directrice, l’addition chaotique des intérêts individuels, se fera au détriment de l’intérêt général de l’entreprise, nous y reviendrons au chapitre suivant.

31 48


Avant d’aborder les deux propriétés émergentes essentielles d’une équipe agile, la créativité et la constitution d’une vision globale d’un système informatique, abordons rapidement le sujet de la diversité. On peut la concevoir comme une forme d’hygiène sociale.

Alors que l’hétérogénéité technologique est souvent perçue comme une source de complications inutiles (P. Lemberger, 2011), il en va très différemment pour les systèmes vivants. La biologie abonde d’exemples qui attestent que la diversité des comportements est le garant de la survie d’une espèce dans un milieu changeant et hostile. La consanguinité, à l’inverse, est la plus grave menace. De même, la diversité des profils d’une équipe a été identifiée par différents auteurs (voir références dans (Appelo, 2010)) comme un facteur de stabilité, de résilience face aux difficultés dans des situations inédites. Pour autant qu’elles restent dans des limites raisonnables, les différences de personnalités, de points de vue, de formations, de cultures sont une source de richesse dans l’appréhension de contextes aussi complexes que ceux des projets informatiques. Afin d’éviter que les tensions et les débats, que la diversité ne manquera pas de créer, ne dégénèrent en pugilat puis en explosion stérile, il faudra veiller à ce qu’une majorité des individus qui composent l’équipe possèdent des aptitudes relationnelles minimales en plus de leurs compétences spécifiques. Une faible proportion de profils de type « autistes géniaux » pourra néanmoins s’avérer bénéfique surtout dans des contextes ou la créativité prime avant toute autre considération.« Qui se ressemble s’assemble » affirme le dicton. En effet, la plupart d’entre nous avons une tendance à nouer des relations lorsqu’elles confortent nos convictions, notre légitimité ou nos aspirations. Ainsi se constituent des microsociétés qui partagent le même jargon, les mêmes préoccupations et les mêmes plaisanteries. De petits cocons douillets qui tranquillisent leurs membres mais atrophient leur vision de la complexité du réel.Ne nous leurrons pas, créer de la diversité demande un peu de courage.

ENTRETENIR LA DIVERSITÉ

Ne nous leurrons pas, créer de la diversité

demande un peu de courage.

32 48


La créativité joue un rôle crucial dans l’élaboration des solutions informatiques. C’est elle qui, hors de tout cadre procédural préétabli, permettra de tenir compte des spécificités d’un contexte technique et humain pour proposer des solutions innovantes et adaptées. Il en va pour la créativité comme pour la motivation, un manager ne pourra les créer ex-nihilo à lui seul. Il peut et il doit cependant faire le nécessaire pour cultiver l’esprit de créativité et pour cela il doit en comprendre les principaux ressorts.

Les psychologues distinguent trois types de créativité :

La créativité pré-conventionnelleC’est la forme de créativité qu’on trouve par exemple chez de jeunes enfants qui, pour résoudre un problème qu’on leur soumet, ont recours avant tout aux images, à l’émotion et à la spontanéité. Ce mode de créativité fait abstraction de toutes les contraintes, qu’elles soient techniques, scientifiques ou qu’elles relèvent des conventions sociales.

La créativité conventionnelleDans ce mode, la pensée est rationnelle mais elle reste dominée par la conscience des contraintes qui s’exercent sur la solution à imaginer. C’est le mode de pensée conformiste, sans originalité d’individus rationnels mais sans imagination.

La créativité post-conventionnelleSurmontant le caractère inhibiteur de la conscience des contraintes, la créativité post-conventionnelle parvient à imaginer des solutions neuves par associations libres d’éléments disparates avec l’ingénuité d’un débutant, tout en gardant à l’esprit les contraintes du réel. C’est le type de comportement que doit viser une équipe agile. La créativité ne se planifie pas, elle se cultive et s’entretient. Pour entretenir une atmosphère propice à la créativité, un manager peut prendre quelques mesures de bon sens. La créativité s’épanouira plus naturellement dans un environnement où règnent franchise et liberté de parole que dans les atmosphères lourdes où règne l’omerta et où planent les menaces de traquenards. Un manager peut encourager l’ouverture en créant un environnent où la prise de risque et les erreurs sont reconnues comme inhérentes aux métiers de l’IT. Parmi les mesures qu’un manager pourra prendre pour favoriser la créativité post-conventionnelle citons encore l’instauration de rites de partage d’idées comme des brainstorms ou des séminaires informels ou la mise en valeur d’individus qui ont fait preuve de créativité.Rappelons aussi que la routine est l’ennemie de toute créativité, raison pour laquelle une majorité de démarches agiles préconise d’automatiser autant que possible les tâches rébarbatives comme le déploiement, l’intégration ou les tests unitaires.

Enfin, toute créativité implique par définition de s’aventurer dans l’inconnu avec une part inévitable d’inconfort et d’appréhension. Faire en sorte que chacun trouve ici ses bonnes limites devrait là encore faire part des attributions d’un bon manager agile.

FAVORISER LA CRÉATIVITÉ

33 48


Dans la vision classique, cartésienne, d’un système d’information, l’activité de modélisation, qu’elle intervienne en phase de conception ou en amont d’une démarche d’urbanisation, cherche à construire une vision globale et détaillée d’un système ou d’un projet.

A cet effet, différents modèles sont utilisés, typiquement un modèle par niveau de l’architecture : l’architecture matérielle, logicielle, fonctionnelle ou encore les processus métiers. De fait, rares sont les exemples où une telle modélisation complète existe et est maintenue à jour. L’expérience montre que l’effort à consacrer pour synchroniser tous ces modèles avec une réalité changeante est le plus souvent irréaliste pour être maintenu sur la durée.Plus pragmatiques, les démarches agiles considèrent qu’une modélisation globale et détaillée n’est ni nécessaire, ni même possible. La vision globale n’est en définitive que l’agrégat de représentations individuelles même si elles sont parfois conflictuelles. En d’autres termes, c’est une propriété émergente qui appartient à une équipe plutôt qu’à un individu.Une autre manière de voir vient corroborer ce point de vue. Envisageons un projet informatique comme un réseau d’individus et de systèmes informatiques en interaction et imaginons un instant qu’un individu en détienne à lui seul une vision exhaustive. Pour le coup, cela impliquerait que la totalité de la complexité du système serait contenue dans un seul de ses nœuds. A l’évidence cette dernière affirmation est fausse puisque la complexité réside comme nous l’avons vu dans les liens et dans les boucles de rétroactions (entre individus et systèmes). L’impossibilité pour un individu à détenir une vision globale d’un système dont il est partie prenante est ce qu’on appelle le Darkness Principle (Appelo, 2010).

FAIRE ÉMERGER UNE VISION GLOBALE

La complexité réside comme nous l’avons vu dans les liens et dans les boucles

de rétroactions (entre individus et systèmes).

34 48


Figure 4 : La vision globale d'un système complexe émerge des visions individuelles.

Cette dernière observation justifie en particulier que de nombreuses pratiques agiles préconisent des réunions quotidiennes durant lesquelles les décisions sont prises de manière collégiale.La responsabilité du manager est donc de faire en sorte que les équipes prennent leurs propres décisions, non pas pour des raisons de tactique RH, mais simplement car les décisions collégiales sont plus lucides puisqu’elles reposent sur une vision plus complète du système. L’information disponible dans le réseau est plus grande et plus précise que celle contenue dans chacun de ses nœuds. Paradoxalement mais heureusement, l’abandon par un manager du contrôle explicite d’une équipe agile apte à prendre ses propres décisions, renforcera son statut et le contrôle qu’il a d’un projet.

Dans le même ordre d’idées, on voit là encore tout l’intérêt qu’il y a pour un manager à diversifier les profils dans son équipe puisque la vision qui en émergera sera plus riche que celle d’une équipe monolithique.

2004 2005 2006 2007 2008 2009 2010 2011

100%

77%

60%

49%35

%25%20

%15%

SYSTÈME D’INFORMATION

Figure 4 :

35 48


L’existence de sociétés criminelles, parfois mieux organisées que certains états, démontre si besoin était que l’auto-organisation n’est pas un bien en soi. Pour qu’un système adaptatif produise de la valeur, encore faut-il que des contraintes et des règles dirigent son évolution dans une direction choisie. La possibilité de diriger un système social, une entreprise, un pays ou une équipe de développement dans une direction choisie est la conséquence de l’existence chez l’homme d’une conscience. C’est elle qui l’a conduit à inventer des lois, des règles d’éthique, des gouvernements et… le management.

Tout l’art du manager agile consistera à concilier son rôle de facilitateur d’auto-organisation, tel qu’il a été décrit au chapitre 4, avec un rôle de créateur de valeur et de régulateur. Les métaphores du « Jeu de la Vie » et celle des systèmes adaptatifs décrits au chapitre 2 suggèrent une répartition assez claire des rôles pour ce qui concerne l’élaboration des règles de fonctionnement d’une équipe auto-organisée. L’équipe agile définira elle-même ses propres règles de fonctionnement pour tout ce qui relève de sa responsabilité de « convertisseur de savoir en innovation ». Ses membres, supposés compétents et autonomes, connaissent en effet mieux que quiconque les mesures à prendre pour résoudre les problèmes technologiques et les questions d’affectation des tâches. Un manager agile appliquera ici le principe de subsidiarité qui s’énonce ainsi : chaque règle au sein d’une organisation agile sera élaborée par l’autorité compétente la moins centralisée, la plus petite (en taille) ou celle située au plus bas dans l’échelle hiérarchique.Enfin, lorsqu’un manager choisira d’imposer une règle à ses équipes, il motivera ce choix, en considérant qu’il s’adresse à des individus doués de raison.Le manager créateur de valeur devra jouer un rôle de régulateur chargé de définir les contraintes et les incitations propres à créer de la valeur. Selon l’analogie des systèmes adaptatifs du chapitre 2, il ajustera, non pas les règles qui régissent la dynamique du système complexe, mais plutôt les paramètres de l’environnement dans lequel celui-ci évolue et élabore ses propres règles. On distinguera deux grandes catégories de paramètres environnementaux à gérer par un manager agile : l’établissement d’un contrat social et la définition d’un objectif partagé.

DÉFINIR LES BONNES CONTRAINTES POUR CRÉER DE LA VALEURCOMMENT DÉFINIR DES RÈGLES ?

Chaque règle au sein d’une organisation agile

sera élaborée par l’autorité compétente la moins

centralisée, la plus petite (en taille) ou celle située

au plus bas dans l’échelle hiérarchique.

36 48


Avant d’aborder ces deux questions, revenons brièvement sur l’élaboration de règles en général, qu’elles émanent d’une équipe ou d’un manager en charge de son environnement. L’influence culturelle du célèbre principe de précaution se manifeste parfois par une tendance à l’accumulation de règles censées anticiper et éviter tous les dysfonctionnements techniques ou humains imaginables. Expérience faite, l’impact de cette inflation règlementaire est une réalité doublement néfaste. D’une part l’effort pour mémoriser un écheveau législatif lui fait perdre toute crédibilité auprès de ceux même qui sont censés l’appliquer car, rapidement, la vérification de sa mise en application se révèlera illusoire. Ensuite, il en va pour l’excès de législation comme pour celui des bonnes pratiques que nous avons déjà évoqué, le risque est de créer un faux sentiment de sécurité qui à son tour déclenche une spirale de déresponsabilisation et de perte de jugement. Dans le domaine de la sécurité routière par exemple, il a été démontré que l’ajout de signalisation et de feux rouges peut conduire à une augmentation des accidents (Spangers, 2007). On préfèrera donc des ensembles resserrés de règles simples du genre : « les réunions commencent à l’heure », « chaque question posée par un utilisateur exige une réponse dans la journée » ou « le code doit être mis en gestion de configuration une fois par jour ».Dans cet esprit, l’élaboration de règles devrait toujours tenir compte du contexte d’un projet. Accepter de se soumettre à des règles élaborées par des personnes n’ayant aucune connaissance du contexte projet auquel elles devront s’appliquer est une mauvaise idée.

Les règles élaborées dans d’autres contextes seront considérées plutôt comme des principes de bon sens que comme des dogmes intangibles.

Accepter de se soumettre à des règles élaborées par

des personnes n’ayant aucune connaissance du contexte

projet auquel elles devront s’appliquer est

une mauvaise idée.

37 48


En philosophie politique, l’idée de contrat social désigne un principe d’organisation d’une société humaine dans laquelle des individus acceptent, pour garantir leur sécurité, de restreindre leur propre liberté en échange d’un gouvernement chargé de faire appliquer des lois.

Même si aujourd’hui beaucoup d’entreprises s’apparentent davantage à des mini-aristocraties qu’à d’authentiques méritocraties, l’idée de contrat social demeure valable même dans ces contextes, car elle permet de caractériser une relation saine entre un manager agile et ses équipes. En échange du respect des règles et des contraintes qu’il sera amené à édicter pour créer de la valeur, un manager agile devra en contrepartie formuler explicitement ce à quoi il s’engage auprès de ses équipes. C’est là une condition indispensable pour créer un sentiment de solidarité professionnelle dans lequel pourra s’ancrer la formulation d’un projet commun.

Les attributs du manager agile sont en définitive assez proches de ceux du gouvernement d’un état de droit et de sa police. Il est chargé d’assurer la sécurité et la liberté de parole de ses collaborateurs face aux multiples sources de pression, qu’il s’agisse par exemple d’autres collaborateurs ou de clients de mauvaise foi. Par ailleurs, l’élan auto-organisateur propre à chaque équipe peut aussi créer des effets de compétition préjudiciables à l’intérêt général pour tout ce qui concerne l’accès aux ressources partagées d’une entreprise comme les salles de réunion, les ressources de calcul ou les machines à café. Garantir un accès équitable aux ressources communes et éviter leur surexploitation font donc aussi partie des responsabilités d’un manager agile. Un point important pour un manager qui souhaite faire respecter certaines règles ou certaines limites est de les édicter explicitement.

Les considérer comme implicitement connues ou, ce qui est plus grave, laisser les individus les découvrir par eux-mêmes, est une solution de facilité qui comporte des risques psychologiques importants en cas d’infraction par inadvertance. La définition d’une barrière d’autorité qui énumère des limites claires à l’autonomie ou aux initiatives de chacun, tout comme la définition d’une notion d’appartenance à une équipe déjà évoquée, sont essentielles car elles contribuent à l’auto-organisation du système social.

ÉTABLIR UN CONTRAT SOCIAL

Un point important pour un manager qui souhaite faire

respecter certaines règles ou certaines limites est de les

édicter explicitement.

38 48


Parmi les trois catégories de buts discutées au chapitre 4, le but extrinsèque correspond à l’affectation d’un objectif à une équipe agile par une instance extérieure. Bien qu’un manager ne soit pas à proprement parler le possesseur de son équipe, il en est néanmoins responsable et, à ce titre, il est habilité à lui assigner des objectifs qui visent la création de valeur (plutôt que la création de divertissements technologiques par exemple). Par son caractère fédérateur, cet objectif contribuera à souder l’équipe le temps d’un projet.

Voici deux objectifs de ce type :• Objectif de l’équipe A : « Au terme de ce projet, notre maîtrise de HTML 5/CSS 3 pour répondre aux besoins d’ergonomie et de respect des standards de nos clients ne sera plus à démontrer ».• Objectif de l’équipe B : « Ce projet doit démontrer la crédibilité de notre équipe pluridisciplinaire formées d’architectes IT, d’experts métiers et de statisticiens pour aborder les problématiques Big Data dans un contexte banque-assurance ».

Dans l’idéal, un objectif partagé devrait correspondre à une forme d’intérêt supérieur, à un motif fédérateur propre à transcender les objectifs individuels. Par conséquent un tel objectif ne devra en aucun cas être corrélé avec la promesse d’une récompense de type bonus, surtout à court terme. L’idée est plutôt qu’un objectif partagé, une fois atteint, réponde aux aspirations profondes des individus : désir de sens, de reconnaissance, de participation à un challenge, d’utilité pour la communauté, de réalisation de soi, d’exploration des possibles, de travail bien fait ou de contribution au progrès, pour ne citer que quelques exemples. Que l’atteinte d’un tel objectif soit nécessairement mesurable n’est pas une condition indispensable en revanche, contrairement à ce qu’un certain folklore managérial désuet voudrait nous faire croire.

Parmi les innombrables adjectifs que l’on peut associer à un bon objectif retenons-en quatre : compréhensible, réaliste, spécifique et stimulant.

La prescription d’un certain niveau de qualité est souvent omise des objectifs à atteindre durant un projet. L’expérience montre pourtant que, laissé à la libre appréciation de chacun, le niveau de qualité est au mieux imprévisible. Des études révèlent d’ailleurs qu’environ 80% des individus s’imaginent fournir un travail de qualité supérieure à la moyenne ! Comme les limites à l’autonomie que nous évoquions précédemment, les objectifs de qualité doivent donc eux aussi être formulés explicitement par un manager agile.

DÉFINIR UN OBJECTIF PARTAGÉ

39 48


Naturellement, la définition d’un objectif partagé se pose également au niveau global de l’entreprise. Des chercheurs en sociologie du leadership ont d’ailleurs montré que parmi les besoins les plus significatifs propres à entretenir la motivation des équipes figure notamment l’expression d’une vision par les dirigeants ((Thomas, 2009) cité par (Appelo, 2010)). Faute d’objectifs clairement formulés, les stratégies individuelles se feront en général au détriment de l’intérêt de l’entreprise. Progressivement, celle-ci dégénèrera en une aristocratie plus soucieuse de préserver ses privilèges par le jeu des traquenards politiques que de créer de la valeur pour l’entreprise. Jurgen Appelo distingue pour ce type d’objectifs d’entreprise deux notions : d’une part la déclaration de vision et d’autre part la déclaration de mission.

• Formuler une vision de l’entreprise c’est esquisser un projet ambitieux et fédérateur pour l’avenir. Elle est destinée tout à la fois à inspirer des actions et à guider les décisions stratégiques.• Formuler une mission pour l’entreprise c’est dire quelle est sa raison d’être aujourd’hui et indiquer quels moyens seront mis en œuvre pour réaliser la vision.

La vision comme la mission de l’entreprise devraient lui être spécifique et la démarquer de ses concurrents. Pour une société de service, un slogan du genre « Tous nos consultants ont l’esprit de service et ne sont obsédés que par la satisfaction de leurs clients » n’est clairement pas une vision. Une vision pourrait ressembler à : « Notre société sera d’ici 5 ans la première SSII 100% agile qui intègrera pleinement les principes du management agile aussi bien dans les relations avec ses clients que dans le management de ses collaborateurs ». Dans l’immédiat, une déclaration de mission pourrait ressembler à : « Notre ambition est de garantir la qualité de nos prestations par une spécialisation à un nombre limité de domaines de compétences sur des sujets d’actualité (cloud computing, Big Data, design HTML 5) et par une veille technologique active sur ces sujets. »

40 48


LE PROPRE D’UN SYSTÈME INFORMATIQUE EST QU’IL N’EXISTE PAS INDÉPENDAMMENT DE L’ENVIRONNEMENT POUR LEQUEL IL A ÉTÉ CRÉÉ.

Non seulement les usages, les besoins, les compétiteurs, les technologies et le marché changent continuellement, mais le système lui-même modifie son environnement, le plus souvent de manière imprévue. En cas de succès d’un service par exemple, des usages inattendus peuvent émerger et nécessiter alors des adaptations conséquentes. Tel un organisme vivant contraint de s’adapter pour survivre dans un environnement en perpétuelle évolution, un système informatique devra, lui aussi, évoluer faute de dépérir. Maintenir la satisfaction des utilisateurs à un niveau à peu près constant, sans même parler de l’accroître, nécessite des évolutions permanentes. Un management agile ne peut donc se contenter de créer de la valeur « une fois pour toutes ». Encore faut-il assurer que cette valeur perdure au moyen d’une stratégie lucide d’amélioration continue dans des contextes incertains. Une tâche primordiale d’un manager agile est donc de faire accepter ce changement permanent à ses équipes, non pas comme une exception temporaire ou comme une situation transitoire par laquelle il faudrait passer, mais plutôt comme une caractéristique intrinsèque des projets informatiques et des organisations agiles. Comme disait Héraclite : « Rien n'est permanent, sauf le changement. » La difficulté, nous l’avons déjà évoqué, réside dans le fait que notre culture occidentale et cartésienne incite beaucoup d’entre nous à voir spontanément dans l’incertitude plus de risques que d’opportunités. Nous cherchons spontanément une stabilité illusoire dans des contextes aussi imprévisibles que celui des projets informatiques, là où l’expérimentation et l’acceptation de l’erreur comme partie prenante d’un processus normal de découverte serait l’attitude la plus rationnelle.

Un sujet directement lié à l’adaptation continue des systèmes informatiques est la compréhension des causes qui conduisent progressivement à leur complexification. Pourquoi un système informatique se complexifie-t-il ? Est-ce inévitable ? Peut-on définir et mesurer

CRÉER LES CONDITIONS DE L’AMÉLIORATION CONTINUECHANGER CAR L’ENVIRONNEMENT CHANGE

41 48


objectivement cette complexité ? Le sujet est vaste et dépasse largement le cadre de cet article. Très schématiquement toutefois, on peut distinguer deux types de complexité ou plutôt de complexification au sein d’un SI. Le premier est une complexité que l’on pourrait qualifier d’utile. C’est celle qui résulte d’une complexification de l’environnement lui-même modélisé, d’une manière ou d’une autre, dans le système : le nombre de cas d’utilisation d’un logiciel augmente, le cadre règlementaire dont il faut tenir compte complexifie les règles de gestion à coder, etc.… Le second type de complexité est la complexité inutile qui résulte d’une maîtrise insuffisante des technologies, de redondances et de la tendance naturelle à l’augmentation de l’entropie pour un système sur lequel on n’intervient pas. La quête de simplicité raisonnable doit donc être active et permanente. Nous pensons qu’un manager agile ne peut faire l’économie d’une compréhension sérieuse de ces enjeux et renvoyons le lecteur à cet ouvrage (P. Lemberger, 2011) pour une analyse détaillée des causes de complexité inutiles dans un système d’information et des moyens d’y remédier.Revenons un instant à l’adaptation d’un système informatique à son environnement. Qui dit besoin d’adaptation dit, nécessairement, défaut d’adéquation. Mais comment au juste définir l’adéquation d’un système d’information ? Hélas, il n’y a pas de réponse évidente à cette question car il n’existe pas d’échelle universelle pour l’adéquation qui en permettrait une mesure objective. La définir comme la satisfaction des utilisateurs est une possibilité qui vient rapidement à l’esprit. Pourtant, cette définition laisse beaucoup à désirer car comment évaluer l’adéquation si seule une fraction des utilisateurs est satisfaite ? Définir l’adéquation d’un système informatique comme un fonctionnement conforme aux attentes n’est guère satisfaisant non plus car il est fort possible qu’un système informatique rende pleinement satisfaction alors qu’il ne correspond à aucune attente préalable. Jurgen Appelo propose quant à lui la définition suivante : l’adéquation d’un système informatique correspond à son aptitude à consommer, dans un certain contexte, du temps et/ou de l’argent de certains individus pour créer de la valeur pour d’autres individus.Faute de mieux, c’est celle que nous adopterons.Enfin, un manager agile sera lui-même amené à prendre des décisions dans un contexte incertain. S’il n’existe certes aucune méthode infaillible pour agir efficacement dans de tels contextes, les sciences de la complexité fournissent néanmoins quelques analogies suggestives pour guider l’action dans un environnement mouvant. Ce sera l’objet de notre dernier paragraphe.

L’adéquation d’un système informatique correspond à son

aptitude à consommer, dans un certain contexte, du temps

et/ou de l’argent de certains individus pour créer de la

valeur pour d’autres individus.

42 48


La littérature managériale fourmille littéralement de méthodes d’amélioration continue, de plans d’amélioration de la qualité et de méthodes de gestion du changement. Pensons par exemple à la célèbre roue de Deming qui illustre la méthode de gestion de la qualité « Plan-Do-Check-Act » (PDCA) ou à la méthode Six Sigma, très en vogue actuellement, qui vise à réduire la variabilité des processus de production.

Toutes ces méthodes font l’hypothèse, plus ou moins implicite, qu’un système, un processus ou une organisation peuvent être améliorés progressivement, chaque itération amenant son lot d’améliorations. C’est précisément ce postulat de linéarité, implicite aux méthodes de gestion du changement classiques, que les sciences de complexité nous invitent à remettre en question.

Pour illustrer notre propos, imaginons qu’en dépit des mises en garde de la section précédente, nous ayons retenu pour le système complexe (par exemple un système informatique ou même une organisation) une certaine notion d’adéquation (fitness). Imaginons ensuite que l’on puisse représenter chaque « état » d’un tel système par un jeu de paramètres, vraisemblablement très nombreux. Le graphe qui représente alors, symboliquement, l’adéquation d’un système en fonction des paramètres qui le caractérisent est ce qu’on appelle le paysage d’adéquation (fitness landscape). Le problème d’un manager agile en quête d’amélioration continue consiste donc à naviguer progressivement vers le maximum global de ce paysage. Deux caractéristiques de ces paysages d’adéquation de systèmes complexes méritent d’être pris en considération.

1. La recherche a mis en évidence que le degré d’interdépendance entre les composants d’un système complexe avait un impact significatif sur la forme de ce paysage. Ainsi, il a été constaté que le maxima global est d’autant plus marqué et aisément identifiable que ce degré de couplage est faible. Lorsque celui-ci est très fort, on parle de catastrophe de la complexité car aucun maximum n’est clairement identifiable et tout changement possède des effets imprévisibles.2. Contrairement aux paysages accidentés des Alpes qui, eux, n’évoluent que sur des durées géologiques, le paysage d’adéquation d’un logiciel évolue sur des échelles de temps beaucoup plus brèves, quelques semaines ou quelques mois tout au plus. Qu’apparaisse une nouvelle opportunité, un nouveau besoin ou une nouvelle technologie et c’est tout le paysage qui est chamboulé. Et même correctement identifiés, les pics peuvent alors disparaître !

L’ART DE LA NAVIGATION EN TERRAIN MOUVANT

Figure 5 : La roue de Deming. Les cales sous la roue représentent le principe de non-régression.

Figure 5 :

43 48


Considérons un projet informatique comme un tel système complexe et tirons quelques conclusions à partir des deux remarques précédentes.Les composants dont il est question dans la première remarque pourront être identifiés dans ce contexte à des individus, des outils, des méthodes de développement, des processus, des langages de programmation etc. On voit donc tout l’intérêt qu’il y a à éviter un couplage trop fort entre ces éléments qui devraient rester aussi interchangeables que possible, faute de quoi la « catastrophe de complexité » guette et risque de rendre le projet chaotique.

On constate ensuite l’erreur du postulat de linéarité. Rien en effet ne garantit qu’un sommet du paysage soit atteignable par itérations successives de petites améliorations. En règle générale, le chemin vers le sommet comportera des régressions et demandera des sauts qualitatifs pour rejoindre un camp de base, situé dans la bonne chaîne de montagne, à partir duquel l’ascension finale pourra être menée. Ces sauts qualitatifs correspondent à des innovations radicales ou à des changements d’habitudes. Dans une DSI un tel changement pourrait correspondre, par exemple, au passage d’un modèle de développement planifié à un mode agile. Pour une ESN, un tel saut pourrait correspondre à une modification du type de contrats avec ses clients : par exemple le passage d’un mode projet au forfait à un mode plus collaboratif.

Enfin, concernant la seconde remarque, la possibilité de voir disparaître des pics est naturellement inquiétante mais il existe aussi une reformulation positive de cette observation. Si le paysage est susceptible de changer inopinément alors, plutôt que d’entreprendre une longue et incertaine ascension d’un pic lointain et mouvant, essayons plutôt de déplacer la montagne à gravir ! Déplacer une montagne dans le paysage d’adéquation revient en l’occurrence à changer les conditions de l’environnement projet. Changer les conditions d’un projet permet de supprimer des montagnes qui auparavant faisaient obstacle : recruter des développeurs ou des managers qui viendront soutenir l’instauration d’une démarche agile plutôt que s’y opposer. L’élément essentiel pour changer l’environnement demeure cependant le désir même de changer et de s’améliorer. Le rôle du manager est donc de rendre ce changement souhaitable. Voilà qui nous ramène au sujet de la motivation traité au chapitre 3 : le changement devient souhaitable dès lors qu’il répond aux motivations intrinsèques des individus : quête de sens, de compétence, de reconnaissance, etc.

Figure 6 :

Figure 6 : Le premier paysage d’adéquation correspond à une situation de catastrophe de

complexité. Le second correspond à une situa-tion où les différents éléments d'un projet sont raisonnablement indépendants. Pour parvenir

au sommet il faut cependant changer de chaîne de montagnes.

44 48


Une autre métaphore tirée de l’analyse des systèmes dynamiques vient corroborer l’analyse précédente, celle des attracteurs déjà mentionnée au chapitre 2. Rappelons qu’à long terme un système dynamique non-linéaire se stabilise typiquement autour d’une région bien déterminée de l’espace des paramètres, l’attracteur. Plus que cela, tous les systèmes dont le point représentatif se trouve initialement dans un certain bassin d’attraction verront leur évolution terminer sur l’attracteur associé. Dans les cas favorables, pour un projet informatique, l’attracteur correspond à cercle vertueux et créateur de valeur, capable de résister aux différents contextes projets (différents points dans un même bassin). En revanche, cette métaphore explique aussi pourquoi, hélas, il est souvent si difficile d’échapper à certaines issues néfastes dans les projets informatiques (non satisfactions des utilisateurs, non respect des contraintes budgétaires, des délais etc…) et ceci en dépit de toutes les bonnes intentions et des efforts déployés. Ces efforts, on l’a compris, sont assimilables à des variations de conditions initiales dans le bassin d’attraction d’un « mauvais » point fixe.

Deux solutions se présentent alors. La première consiste à faire un saut d’un bassin d’attraction vers un autre, saut qu’on pourra assimiler à la mise en œuvre par une équipe projet d’une innovation radicale comme par exemple un changement du processus de développement ou l’utilisation d’une technologie disruptive etc. La seconde consiste plutôt à déplacer ou à faire disparaître les mauvais attracteurs et leur bassin d’attraction. On pourra l’interpréter comme une modification de l’environnement du projet : modification des types de contrats avec les clients, modifications des facteurs d’incitations, changement de business model, prise en compte des motivations intrinsèques des collaborateurs.

45 48


LE MANAGEMENT AGILE TEL QU’IL EST DÉFINI PAR JURGEN APPELO DANS SON OUVRAGE MANAGEMENT 3.0 N’A RIEN D’UNE NOUVELLE RECETTE MAGIQUE ASSORTIE DE MIROBOLANTES PROMESSES DE ROI.Plus sérieusement, cette analyse apporte un regard neuf sur le management, ancré dans les résultats et les concepts des sciences de la complexité. Elle vise à transformer la culture même du management dans le monde informatique. Son objectif est de mettre en cohérence les pratiques managériales avec certains aspects fondamentaux des projets informatiques, liés principalement à leur imprédictibilité, qui restent trop souvent méconnus ou même carrément niés.

On peut voir le management agile comme une synthèse de deux catégories d’idées appliquées au management. D’une part, celles des démarches de développement comme Scrum, XP ou Kanban, qui définissent des rôles, des rituels et des livrables destinés à mettre en œuvre les principes de l’agilité dans les projets informatiques. D’autre part, les résultats et idées des sciences de la complexité tels que l’étude des systèmes dynamiques non-linéaires, la théorie du chaos ou encore les automates cellulaires qui, collectivement, fournissent un riche éventail de concepts et de métaphores qui permettent de mieux appréhender la dynamique d’un système aussi complexe qu’un projet informatique.

Ce qui fait l’originalité de cette démarche est qu’elle s’inspire d’autres disciplines qui cherchent elles aussi, parfois depuis des décennies, à comprendre et maîtriser des systèmes complexes, au premier rang desquels on citera l’étude du monde vivant, concepteur par excellence de systèmes à la fois complexes et robustes.Cette compréhension approfondie nous a permis de définir les quatre responsabilités principales à assumer par un manager agile : (1) « Favoriser l’autonomie et la compétence », (2) « Favoriser l’auto-organisation des équipes », (3) « Définir des contraintes pour créer de la valeur » et enfin, (4) « Créer les conditions d’une amélioration continue ».Les remises en questions qu’implique ce nouveau paradigme du management sont nombreuses et profondes. Rappelons quelques exemples :

• Les démarches d’amélioration linéaires, par petits pas, font fi de la nécessité de recourir à des innovations radicales dans les technologies ou dans l’environnement d’un projet informatique.• Les organisations hiérarchiques qui fonctionnent en mode « commande et contrôle » sont peu appropriées à l’élaboration de systèmes complexes et fiables.• Les méthodes d’incitation classiques telles que les primes ou les bonus ne sont pas des facteurs de motivation efficaces pour des tâches qui nécessitent créativité, initiative et responsabilité.

Soyons clair, il ne saurait évidemment être question de faire table rase du passé. Les traditions, les habitudes et les inerties sont nombreuses et il serait irrationnel de les ignorer. Notre souhait cependant est, qu’à la lumière des réflexions développées dans ces quelques pages, le lecteur puisse alimenter sa propre réflexion et contribuer à son niveau à faire reculer un le folklore managérial au profit d’un peu plus de raison. Tant il est vrai qu’à long terme on ne gagnera jamais à en différer indéfiniment l’application.

CONCLUSION

46 48


RÉFÉRENCES• Appelo, J. (2010). Management 3.0 - Leading Agile Developpers, Developping Agile Leaders.Boston: The Addison Wesley Signature Series.

• Barrand, J. (2007). Le manager agile. Paris: Dunod.

• Brooks, M. (2009, février 4). Born believers: How your brain creates God. New Scientist.

• David Shpilberg, S. B. (2007, October 01). Avoiding the Alignment Trap in IT. MITSloan.

• Ellis, K. (2008). Business Analysis Benchmark. Rapport du cabinet IAG consulting.

• Erich Gamma, R. H. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Professional.

• Gardner, M. (1970, october). The fantastic combinations of John Conway’s new solitaire game «life». Scientific American, pp. 120-123.

• Geus, D. (1997). The living Company. Boston: Harvard Business School Press.

• Krigsman, M. (2008, 12, 11). Study: 68 percent of IT projects fail. ZDNET.

• Mentor, O. Agile and XP Object Mentor Success Stories. http://www.objectmentor.com/omSolutions/agile_customers.html.

• Mitchell, M. (2009). Complexity a Guided Tour. New York: Oxford University Press.

• Nonaka, H. T. (1986, jan-fév). The New New Product Development Game. Harvard Business review.

• P. Lemberger, M. M. (2011). Managing Complexity of Information Systems - The Value of Simplicity. Wiley.

• Pink, D. (2011). La vérité sur ce qui nous motive. Paris: LEDUC.S Editions.

• Spangers, C. (2007). Le trafic sans règles est plus sûr. blog.meervrijheid.nl, http://www.meervrijheid.nl/index.php?pagina=1520.

• Stiegler, B. Prolétarisation. Ars Industrialis.

• Thomas, K. W. (2009). Intrinsic Motivation at Work: What Really Drives Employee Engagement. Berrett-koehler Publishers.

SQLI Digital PerformanceImmeuble le Pressensé268 avenue du Président Wilson93 210 La Plaine Saint-DenisTél : 01 55 93 26 00www.sqli.com

QUELS RÔLES POUR LE MANAGEMENT DANS UN ......1 XP en 1999, Scrum en 2001, Kanban en 2003 et le Lean...

Documents

Transcript of QUELS RÔLES POUR LE MANAGEMENT DANS UN ......1 XP en 1999, Scrum en 2001, Kanban en 2003 et le Lean...