[SDG #2] Le Manifeste Agile, un modèle de sagesse pour l’Église et autres institutions

Dans ce deuxième épisode de Sagesse de geeks, c’est à nouveau du monde de l’informatique que nous vient une perle de sagesse. Le Manifeste Agile va nous apprendre quelques grands principes et valeurs pour rester dynamiques et vivants dans un monde en mouvement.

Évoluant depuis des années dans l’univers agile des logiciels libres et open-source, je suis parfois surpris par la lourdeur et l’inneficacité de certains fonctionnements institutionnels ou associatifs trop lourds et statiques. Un clash de modes de gouvernance a d’ailleurs été un des trois facteurs dans ma casse de l’année passée:

Ce n’est pas un problème d’église. De nombreuses institutions ou associations se heurtent à la difficulté d’un monde qui change si vite que toute prévision est quasiment impossible — alors que ces institutions se sont construites sur des rythmes plus lents, dans des contextes plus stables. Beaucoup peinent à s’adapter. Et c’est cause de stress et de souffrances.

Dire ça, ce n’est pas poser un jugement sur la réalité actuelle de nos associations et institutions pachydermiques. Ni sur les gens et décisions passées qui ont conduit à la situation actuelle. « Du passé faisons table en marbre. » La réalité est ce qu’elle est, c’est notre point de départ.

Comment aller de l’avant à partir de là? Comment faire face à un monde qui évolue constamment? Le changement peut-il être une aubaine plutôt qu’une menace?

Comment passer d’une grosse machine, lourde et peu réactive, à un organisme, souple et adaptable?

C’est là que le Manifeste Agile devient notre senseï.

Le Manifeste Agile

Dans les années 1990, de nombreuses méthodes légères de développement de logiciel ont émergé, en réaction aux approches lourdes plus traditionnelles: des approches sur-réglementées, planifiées méticuleusement à l’avance, micro-managées. 

En 2001, 17 experts de ces méthodes légères (parmi lesquels l’inventeur du Wiki, les fondateurs de Scrum, XP programming ou Crystal clear, parmi d’autres) se rassemblent pour synthétiser les valeurs et principes clés de leurs approches. Le Manifeste pour le développement Agile de logiciels en est le résultat.

Le manifeste agile, c’est très succinct. C’est 4 valeurs (75 mots en français). Et 12 principes sous-jacents (229 mots).

20 ans plus tard, son influence est indéniable. « Agile » est un buzz-word, des coaches agiles apparaissent à tous les coins du globe pour aider toutes sortes d’organisations et entreprises à devenir plus compétitives, et cela ne concerne de loin pas que le monde du développement logiciel.

Plus qu’une méthode ou des outils, il s’agit d’une manière d’être, d’un savoir faire, d’un mindset. « Don’t do agile, be agile » ¹Ne fais pas de l’agile, sois agile. Et si l’approche n’est pas sans critiques²Une des principales étant: la lettre tue l’esprit. Vouloir « faire de l’agile » peut amener tout un tas de processus, méthodologies, outils et autres boulets qui alourdissent le travail, et rendent le milieu encore moins agile., nous pouvons malgré tout tirer beaucoup de sagesse pour nos institutions et associations en quête de vigueur.

Les 4 valeurs

Le cœur du manifeste est composé de 4 valeurs, et il se lit en 1 minute:

Mais voilà, il s’agit d’un manifeste pour le développement de logiciels.

Ci-dessous, voici comment ces valeurs nourrissent mes réflexes dans les contextes dans lesquels j’évolue, hors du développement informatique. J’ai principalement en tête:

• Le contexte institutionnel de mon église
• Le contexte associatif de holygames et de la ludothèque de Chailly principalement
• Ma famille

Aucun de ces domaines de ma vie n’est complètement Agile à proprement parlé au sens du manifeste (déjà parce que le manifeste ne parle pas de familles ni d’institutions agiles), mais j’essaie d’y injecter des impulsions.

Et en réalité, il n’y a rien de nouveau, rien de révolutionnaire. Ces principes sont derrière la démarche scientifique. Et sont dans la vie, simplement, de tout organisme résiliant qui doit vivre dans un environnement mouvant, parfois hostile.

Voici donc la sagesse que je retire du manifeste:

1. Ce que nous sommes est plus important que ce que nous faisons

La structure est au service des gens, et pas l’inverse.

Par « des gens » ou « ce que nous sommes », on entend des individus et leurs relations, les dynamiques communautaires qui se déploient. Comme l’a enseigné un charpentier palestinien du 1e siècle: le leader n’est pas celui qui domine et qui est servi (ça c’est les tyrans), mais c’est celui qui sert et qui libère les autres pour servir.

Le but d’une organisation est de faire s’épanouir les gens qu’elle côtoie. Tous les gens qu’elle côtoie — que ce soit les bénévoles ou les professionnels qui y travaillent, les bénéficiaires, les partenaires qui investissent, etc.

Le postulat est: plus les gens seront biens, épanouis, plus ils voudront et seront capables de donner le meilleur d’eux-mêmes. Et donc plus ce sera au bénéfice de l’organisation… Et donc des gens dans leur ensemble. Et ainsi de suite.

Au contraire, une organisation préoccupée par son maintient, sa survie, verra les gens comme des ressources à exploiter. Et les gens partiront. « L’organisation qui veut sauver sa vie la perdra. »

Un corollaire de cela est la valorisation du travail en équipes semi-autonomes, auto-organisées. Avec le postulat que l’individu évolue bien dans un groupe à taille humaine, qui développe sa complémentarité, la connaissance des forces et faiblesses des unes et autres dans un climat de confiance. Et qui est libre de s’organiser comme elle le souhaite, du moment qu’elle fait ce qu’on lui demande. Le manager est là pour donner aux équipes qui en ont besoin des outils pour mieux s’organiser. Pas pour dire comment faire.

Poussé à l’extrême, des organisations entière s’organisent autour de ce réflexe: management horizontal, gouvernance partagée mode holacracy ou sociocracy 3.0

Pour donner du meilleur de nous-mêmes, nous avons besoin d’un cadre sécuritaire: droit d’être soi-même, de poser des questions, faire des suggestions, prendre des risques, de faire des erreurs.

Il semblerait qu’un jour un ingénieur Google a fait une boulette qui a couté un million de dollars de perte. Au lieu de le blâmer et de le virer (on réagit à la perte par plus de perte), son chef a rassemblé l’équipe en disant: « qu’est-ce qu’on a appris? » Après une session de travail en équipe, le chef a demandé: « est-ce qu’on a gagné plus d’un million de dollars en apprentissages? » L’équipe a répondu « oui », et ils se sont tous remis au boulot.

Dans ce sens, les outils, processus et règlements doivent servir les gens et les relations qui se créent. Dans mon expérience d’église pas exemple, pour certaines personnes le règlement est quasi parole d’évangile, et si ça coince quelque part, c’est le règlement qui doit primer. Peu importe si cela blesse des gens, bloque des activités et détruit des relations et communautés. La sécurité, pour ces personnes, est dans le suivi du règlement.

Avec une telle mentalité, on nourrit une culture où il est très difficile de prendre des risques, et de tirer des apprentissages des échecs (puisqu’on punit les échecs en coupant les têtes). Il n’y a pas de droit à l’erreur. (Alors que, spirituellement, en église par exemple, on a deux-trois ressources autour du pardon, théoriquement.)

Les règlements, processus et outils ne sont pas inutiles. Ils ont de la valeur. Ils peuvent servir de guides pour démarrer, d’aide pour s’organiser, d’arbitre en cas de conflit, etc. Mais ils doivent pouvoir être adaptés souplement aux situations sur lesquelles on les applique — qui sont toutes uniques et spécifiques.

Et donc si le règlement est au service des gens et des relations, alors il doit pouvoir évoluer rapidement (cf. valeur 4).

2. Ce qui est est plus important que ce qu’on en dit

Être agile, c’est se confronter sans cesse à la réalité, s’y frotter le plus possible. Et adapter ce qu’on dit à ce qui est, et pas l’inverse.

Humains capables de penser, nous essayons constamment d’apprivoiser la réalité par notre langage. Et c’est formidable et puissant. Mais nous courrons toujours le risque de perdre le contact avec la réalité, et d’habiter dans les abstractions qui nous rassurent.

Bien sûr, la réalité est cachée et ce qu’on en dit influence la manière dont on la perçoit. Mais elle résiste à nos théories quand on s’y frotte.

Un peu plus concrètement: les rapports d’activités sont moins importants que les activités. 

Ça peut paraître idiot, dit comme ça. Mais on peut si rapidement perdre un temps fou à rédiger des rapports, qui seront lu dans des bureaux, discutés dans des assemblées qui siègent dans des nuages pour prendre des décisions sur la suite de l’organisation — et l’on perd complètement le contact avec la réalité.

Ce qui n’existe pas dans le rapport d’activité n’existe pas dans la tête des gens, n’a pas de valeurs. Et on passe alors plus de temps à écrire des rapports qu’à nourrir des activités.

Or ce sont les activités qui apportent de la valeur à l’organisation.

De même avec les projets: pour rassurer des managers non-agiles, on fait des feuilles de projets, des budgets, des plans… qui peuvent rapidement être des plans sur la comète, parce que les choses évoluent sur le terrain (cf. valeur 4). Et on gaspille énormément d’énergies à des choses qui ont pour seule utilité d’essayer de se rassurer, plutôt que de créer de la valeur pour l’organisation.

De même avec les répartitions: par exemple en église actuellement nous avons une répartition théorique des ressources ministérielles (telle région aurait droit à tant de ministres), mais la réalité est qu’il manque de ministres (toutes les régions sont sous-dotées, certaines plus que d’autres). J’ai des collègues qui travaillent à partir de la répartition théorique: « nous avons droit à tant de force, donc on fait des activités comme si on était tant » (ce qui nous permet de ne rien remettre en question) — ce qui conduit à des burnouts en série. 

Au contraire, une approche agile dira: « voyons quelles sont les forces effectives que nous avons, puis ce que nous pouvons faire de manière durable avec cela. » Mais cela implique de pouvoir et savoir dire « non » à des activités, ce qui n’est pas gagné…

De fait, une communauté vivante, grandissante, joyeuse, avec des activités riches et variées est la meilleure mesure de la santé d’une organisation. Si les rapports aident à rendre ça visible, tant mieux. Mais il ne faut pas inverser les choses.

La documentation est utile, mais elle doit être TJAB — Tout Juste Assez Bonne (JBGE, Just Barely Good Enough) pour être utile aujourd’hui à prendre les décisions qui permettront de faire le prochain pas concret. Et elle peut-être modifiée demain pour répondre aux besoins d’après-demain. Ça suffit.

Un réflexe agile est donc de simplifier — minimiser constamment le travail inutile, qui n’apporte pas de valeur.

En Église par exemple, j’ai souvent l’impression de « parler de l’église » beaucoup plus que de « vivre l’église ». On passe un temps fou en séances, comités, organisations, gestion, etc. Et si peu à partager et vivre des choses avec les gens. 

De même, une famille ou un couple peut s’empêtrer dans des thérapies, des discussions constantes sur le fonctionnement — au lieu de fonctionner et vivre des choses.

Bref, parler de l’activité est utile, nécessaire, indispensable. Mais moins que vivre l’activité.

3. Faire avec est plus important que faire pour

Faire pour est plus simple, car cela évite la rencontre avec l’autre qui a des besoins différents. Mais c’est donc aussi plus pauvre, parce qu’on passe à côté de l’enrichissement qui peut en découler: en transformation de l’un ou de l’autre, en apprentissage, en redéfinition des besoins de chacun et donc des objectifs, etc.

• Range la chambre d’un enfant pour lui et elle sera propre une fois.
• Range la chambre d’un enfant avec lui et elle sera aussi propre une fois, au début. Et ce sera plus long. Mais tu auras appris à mieux connaître l’enfant et son fonctionnement. Et lui aura appris un peu à ranger.

Il est plus facile de développer dans nos tours d’ivoire des activités ou des produits qu’on pense être bonnes pour les bénéficiaires. Et parfois elles le sont. Mais parfois elles sont à côté de la plaque, les bénéficiaires partent, on devient amer, …

Être agile, c’est développer les activités avec les gens concernés. Les impliquer tout au long du processus plutôt qu’à la fin seulement.

Par exemple développer la routine du soir avec l’enfant. Ou les horaires d’ouverture de la ludothèque avec les clients. Ou le module de catéchisme avec les jeunes et leurs parents.

Cela implique aussi de développer une culture de feedbacks: créer un environnement sécure où les feedbacks peuvent être donnés et entendus (valeur 1), les prendre à la lettre comme des faits plutôt qu’expliquer aux gens pourquoi ils auraient dû aimer notre activité géniale (valeur 2), et nourrir un contexte dans lequel ils peuvent servir à apporter des améliorations (valeur 4).

Dans les processus décisionnels, c’est prendre les décisions avec les gens qui seront impactés concrètement par les décisions. Plutôt que par des gens qui sont dans une hiérarchie, ou des experts supposés, ou qui ont besoin de rassurer telle ou telle partie prenante.

4. L’adaptation au changement est plus importante que le suivi d’un plan

On aime les plans, et les plans sont utiles. Si un plan fonctionne, il n’y a pas de raison de le modifier.

Le souci est dès que le plan ne colle plus avec la route. C’est l’avertissement du GPS: « en cas de conflit, suivez les indications de la route. »

La réalité doit alors primer sur le plan (principe 2).

Dans l’institution réformée en particulier, on adooore les plans à toutes les sauces. Que ce soit dans la liturgie (un culte réformé tradi est un plan détaillé à la virgule qui ne laisse place à aucun imprévu) ou dans les séances (avec des ordres du jour fixés à la avance, et la mesure de la présidence se situe dans la capacité à suivre cet ordre du jour).

Il y a un enjeu d’apprivoisement psychologique du changement.

Dans une institution non-agile, le changement est fondamentalement pénible, donc on repousse, et lorsque ce n’est plus possible de faire autrement (en général quand on est dans le mur) on fait une grosse restructuration, épuisante, stressante. Et on a bien la confirmation que le changement, c’est menaçant.

L’enjeu c’est d’implémenter des changements constants, réguliers. D’en faire une habitude pour évoluer sans cesse, petit à petit, par petits pas.

Si le changement est une menace, l’ignorer ne le fait pas partir mais rajoute une source de difficulté: on est stressé ET on est en décalage avec la réalité.

Dans une démarche agile, non seulement le changement est une donne (dans l’environnement, dans les besoins, etc), il fait partie de la réalité et donc on l’accueille. Mais plus encore, le changement est une aubaine, une opportunité. Même si parfois c’est douloureux.

Derrière cet enjeu psychologique, il y a un enjeu spirituel de maîtrise: est-ce que je veux contrôler la réalité, ou suis-je prêt à lâcher prise pour me laisser porter? Est-ce que j’ose la confiance? Si le plan me guide concrètement pour faire le prochain pas, il est utile. S’il est là pour me rassurer par rapport à l’incertitude de ce qui pourrait arriver, c’est peut-être une idole.

Concrètement, et pour respecter le principe de simplicité et de non-gaspillage inutile, cela signifie d’injecter plus d’énergie dans l’adaptabilité que dans la planification.

Au lieu de définir les étapes du projet, en détail, on se fixe sur la destination, et on part une boussole à la main. Et régulièrement on ajuste la trajectoire.

Cela signifie donc d’être très clair sur la direction générale, la mission. Et que cette mission soit opérationnelle pour prendre des décisions.

Rien de tel qu’un environnement avec une mission claire mais qui n’est jamais mentionnée, jamais utilisée pour prendre des décisions ou évaluer des activités (ma chère église, je te regarde).

Cela signifie qu’en séance de travail, on ne se demande pas: que va-t-on faire les 17 prochaines années en détail avant de se mettre à l’ouvrage. Mais quel est le prochain pas?

Le plan, la direction indiquée doit être suffisamment précise pour permettre de décider des prochains pas, mais pas plus.

Et ce prochain pas ne doit pas être parfait: quand on se réunit tous les 5 ans pour décider ce qu’on va faire les 5 années suivantes, les décisions ont intérêt à être excellentes, et donc on investit de l’énergie à faire un gros projet qui finira probablement dans un tiroir parce que soit trop flou et inopérant, soit trop précis et donc en décalage avec la réalité (qu’on ne peut pas prévoir), soit simplement trop gros pour être lu et communiqué.

Au contraire, dans une démarche agile, le prochain pas doit être suffisamment bon pour maintenant, pas plus. Et demain on peut corriger le tir si nécessaire.

Autrement dit, être agile implique de privilégier des cycles courts plutôt que des cycles longs voire très longs. Des cycles courts permettent des évaluations fréquentes (et donc des apprentissages réguliers), et des réajustements en temps réel.

Si on prend une décision tous les 5 ans, alors: si c’est la mauvaise on est coincé pour 5 ans, et cela met une grosse pression quand il faut choisir

De même, si on attend que tout soit parfait avant de révéler un projet aux utilisateurs, on perd leurs feedbacks (cf. valeur 3). Ainsi par exemple le principe RERO (release early, release often³Publiez tôt, publiez souvent) afin de créer des boucles de rétroactions rapides.

En résumé

Être agile, c’est privilégier:

• Ce que nous sommes plutôt que ce que nous faisons
• Ce qui est plutôt que ce qu’on en dit
• Faire avec plutôt que faire pour
• L’adaptation plutôt que le suivi d’un plan.

Être agile, c’est de ne pas vivre sur l’acquis des réformes passées,
ni dans l’attente des réformes futures,
mais de se réformer, aujourd’hui, un tout petit peu. 

Ecclesia reformata semper reformanda

Sagesse de Geeks — SDG — Soli Deo Gloria