pixabay/geralt
Il n’est plus à démontrer que l’intelligence d’un groupe est bien plus puissante qu’un ensemble d’individus. En revanche, il existe des organisations où l’intelligence collective est polluée par du “bruit” : structure très hiérarchique, peu de liberté, pas d’écoute, etc. Il est très important de réduire au maximum ce bruit dans le but de créer un environnement le plus favorable possible à l’émergence de l’intelligence collective.
Des exemples concrets d’intelligence collective
1-La rétrospective
La rétrospective est un événement de Scrum qui est indiscutable et généralement toujours apprécié. Pouvoir écarter les problèmes rapidement, pouvoir désamorcer certaines situations dans un cadre bienveillant et promouvant l’amélioration continue permet à l’ensemble de l’équipe de se responsabiliser.
Le groupe décide alors de lui-même ce qu’il devient. Ici, le but commun est de devenir une équipe meilleure via l’intelligence des membres (anticipation, projection, empathie, retenue, etc.) et via leurs connaissances (expériences passées, connaissances théoriques, etc.). Les prises de décisions sont faites suivant des méthodes diverses : vote (dot voting, main levée, etc.), consensus, consentement, etc. Il est très important, dans n’importe quelle organisation, de savoir s’arrêter et prendre du recul, afin de déceler des axes d’améliorations, et de les appliquer.
Une des grosses difficultés de la rétrospective est de récolter les réels avis de l’ensemble des membres (par exemple : un membre d’équipe peut être timide, le groupe peut suivre l’avis d’un membre qui agit comme un leader, etc.). Il s’agira alors du travail du Scrum Master (ou d’un facilitateur) d’essayer de trouver des formats adéquats pour son équipe afin que l’ensemble des membres soient pleinement impliqués et libres de s’exprimer.
Avantages : résolution des problèmes d’une équipe, visibilité de l’état d’une équipe, pratique très centrée sur l’humain, doit permettre à tous les membres de s’exprimer équitablement.
Limites : peut devenir un lieu de règlement de comptes personnel s’il n’y a pas un cadre clair, une bonne rétrospective nécessite de bien être animée.
2-Le Pair Programming
Le Pair Programming est une pratique énoncée dans Extreme Programming. Elle consiste à utiliser un seul ordinateur pour deux développeurs pour créer une portion de code. Le premier développeur est le conducteur, il tape le code, pendant que le second développeur, l’observateur, passe en revue les lignes de code écrites. Le conducteur se concentre sur l’aspect “tactique” du code (l'implémentation, les détails d’implémentation, etc.) alors que l’observateur se concentre sur l’aspect “stratégique” du code (améliorations possibles, patterns globaux, intégration, etc.). On échange régulièrement les rôles entre les développeurs en utilisant, par exemple, la technique pomodoro.
Au premier abord, on peut penser que le pair programming est une pratique coûteuse. En réalité, on perd entre 15% et 100% de temps de travail effectif pour un développeur. En revanche, les coûts de maintenance liés à la qualité du code sont réduits. De plus, les évènements extérieurs qui pourraient perturber un développeur (appels téléphoniques, mails, etc.) peuvent être gérés beaucoup plus facilement. En effet, un développeur peut rester totalement concentré pendant que l’autre gère cette interruption. Enfin, l’apprentissage et le partage de connaissance de cette pratique permet aux développeurs de monter en compétence et peut contribuer à des heures travaillées beaucoup plus efficaces.
Avantages : partage de connaissances, meilleur design du code.
Limites : pratique souvent remise en cause pour son efficacité, certains binômes incompatibles.
3- Le Brainstorming
Le Brainstorming est un atelier permettant de générer et développer des idées via un processus généralement créatif. Un atelier d’idéation se déroule généralement en deux phases :
-une phase de divergence, durant laquelle on va générer un maximum d’idées, de façon collective ou individuelle.
-une phase de convergence, durant laquelle l’ensemble du groupe va tenter de converger vers une idée ou un ensemble d’idées.
On peut répéter ces phases plusieurs fois, c’est par exemple le cas pour un atelier tel que le 1-2-4-All, tiré des Liberating Structures :
- On génère des premières idées seul pendant 1 minute.
- On partage à deux les idées et on trouve un nouvel ensemble d’idées pendant 2 minutes.
- On partage à quatre les idées et on trouve un nouvel ensemble d’idées pendant 4 minutes.
- On partage à l’ensemble les idées et on trouve un dernier ensemble d’idées pendant 5 minutes.
Durant les phases de partage, on crée des boucles de divergence (partage des idées) puis de convergence (tri, regroupement des idées). On travaille alors de manière totalement itérative et incrémentale.
Avantages : génération facile et rapide d’idées, utilisation de l’ensemble d’un groupe, amusant/intéressant.
Limites : faire aboutir la phase de convergence, nécessite une ouverture de la part des membres.
4- La documentation collaborative
La documentation collaborative est une pratique visant à écrire de la documentation en groupe. Un des exemples les plus connus et les plus intéressants de documentation collaborative est certainement Wikipédia. Wikipédia permet à n’importe quel contributeur de créer, modifier et illustrer une page de définition. Wikipédia permet aux collaborateurs réguliers de suivre les évolutions d’une page afin de vérifier la crédibilité, l’exhaustivité, l’objectivité, la lisibilité et la pertinence de l’information ajoutée. Ainsi, les actes de spams et vandalismes peuvent être évités facilement.
Dans un cadre professionnel, le fait d’avoir une documentation collaborative et vivante permet de créer un contenu de qualité, validée par plusieurs personnes et améliorée au fur et à mesure. Les erreurs ou imprécisions commises par les uns sont corrigées par les autres. Les bonnes idées et pratiques utilisées par les uns sont partagées avec les autres. La connaissance des membres est alors partagée au sein de l’organisation. La plupart des outils de documentation collaborative (Google Docs, Confluence, etc.) possède un historique afin de pouvoir restaurer facilement une version antérieure d’une page. Ainsi, les contributeurs n’ont plus peur de modifier et de faire vivre la documentation. De plus, par le biais de commentaires par exemple, les membres peuvent faire valoir leur avis afin d’affiner au maximum la documentation, de poser des questions sur celle-ci, ou même de remercier les contributeurs. Dans certains cas, le wiki peut rapidement devenir un simple répertoire où les membres stockent leur travail et où aucune interaction n’est développée. Il perd alors tout son intérêt.
Avantages : partage de connaissances, évolution de la documentation facilitée.
Limites : organisation de la documentation souvent complexe, nécessite parfois une remise en question de l’existant, nécessite une grande confiance envers les autres et de la rigueur.
5 - Les communautés de pratique
Les communautés de pratique sont des groupes de personnes travaillant sur les mêmes sujets et qui sont conduites à constamment trouver des solutions face à des problèmes rencontrés dans leurs pratiques professionnelles. Les communautés de pratique prônent une vision sociale de l’apprentissage à travers le partage de connaissances entre les différents membres.
Selon Etienne Wenger, le théoricien de cette pratique, elles sont caractérisées par trois dimensions :
- L’ouverture aux autres et à leurs solutions : le croisement des expériences de chacun étant au coeur de l’apprentissage collectif.
- Un but commun : l’interaction entre les membres permettant de résoudre les problèmes rencontrés pour atteindre ce but.
- Un langage partagé : un lexique commun de mots, de processus, de pratiques, d’outils afin de faciliter les échanges.
Les communautés de pratique prennent du temps à être mises en oeuvre et suivent le chemin suivant : le point de départ est d’être en silos, puis on partage des histoires, puis on résout des problèmes communs, pour enfin utiliser la connaissance collective pour créer d’encore meilleures pratiques. La communauté se doit d’être vivante afin de perdurer et elle ne doit pas reposer sur un seul élément de celle-ci. Il existe généralement des communautés de pratique sur des sujets tels que le développement, l’Agilité, la data science, le DevOps ou encore la facilitation mais on peut imaginer ce genre de communauté autour de n’importe quel métier ou activité d’un métier qui regroupe des problèmes ne permettant pas une solution automatique et qui fonctionne à coup sûr.
Avantages : résolution de problèmes à plusieurs, partage de connaissances.
Limites : difficulté de mise en place, repose souvent sur un leader.
Au final, par où commencer ?
Evidemment, il peut s’avérer compliqué de choisir un seul outil ou une seule méthode pour définir ce qui sera le plus efficace au sein d’une organisation. Cela peut être influencé de part les différentes expériences de chacun, qui permettront de guider un choix sur la solution à adopter, toujours et idéalement en accord avec le reste des membres du groupe. Une fois de plus, cela peut se décider par le vote, le consensus, le consentement, ou tout autre façon juste de laisser chacun s’exprimer, toujours dans le but pour mieux avancer collectivement.
Tout comme l’agilité, l’intelligence collective émerge au sein des organisations, on ne peut pas forcer son apparition. De plus, ce n’est pas seulement par le biais de la mise en place de ces différentes pratiques qu’elle émergera. L’intelligence collective nécessite un cadre, des conditions et une croyance en celle-ci. L’organisation doit donc soutenir cette émergence, en faisant évoluer les mentalités positivement. Ce chemin est long et nécessite un réel travail d’apprentissage, d’amélioration continue et de partage.
Par Vincent ROSSIGNOL et Jordan TAHRAOUI, respectivement Scrum Master et Product Owner chez SOAT
Des exemples concrets d’intelligence collective
1-La rétrospective
La rétrospective est un événement de Scrum qui est indiscutable et généralement toujours apprécié. Pouvoir écarter les problèmes rapidement, pouvoir désamorcer certaines situations dans un cadre bienveillant et promouvant l’amélioration continue permet à l’ensemble de l’équipe de se responsabiliser.
Le groupe décide alors de lui-même ce qu’il devient. Ici, le but commun est de devenir une équipe meilleure via l’intelligence des membres (anticipation, projection, empathie, retenue, etc.) et via leurs connaissances (expériences passées, connaissances théoriques, etc.). Les prises de décisions sont faites suivant des méthodes diverses : vote (dot voting, main levée, etc.), consensus, consentement, etc. Il est très important, dans n’importe quelle organisation, de savoir s’arrêter et prendre du recul, afin de déceler des axes d’améliorations, et de les appliquer.
Une des grosses difficultés de la rétrospective est de récolter les réels avis de l’ensemble des membres (par exemple : un membre d’équipe peut être timide, le groupe peut suivre l’avis d’un membre qui agit comme un leader, etc.). Il s’agira alors du travail du Scrum Master (ou d’un facilitateur) d’essayer de trouver des formats adéquats pour son équipe afin que l’ensemble des membres soient pleinement impliqués et libres de s’exprimer.
Avantages : résolution des problèmes d’une équipe, visibilité de l’état d’une équipe, pratique très centrée sur l’humain, doit permettre à tous les membres de s’exprimer équitablement.
Limites : peut devenir un lieu de règlement de comptes personnel s’il n’y a pas un cadre clair, une bonne rétrospective nécessite de bien être animée.
2-Le Pair Programming
Le Pair Programming est une pratique énoncée dans Extreme Programming. Elle consiste à utiliser un seul ordinateur pour deux développeurs pour créer une portion de code. Le premier développeur est le conducteur, il tape le code, pendant que le second développeur, l’observateur, passe en revue les lignes de code écrites. Le conducteur se concentre sur l’aspect “tactique” du code (l'implémentation, les détails d’implémentation, etc.) alors que l’observateur se concentre sur l’aspect “stratégique” du code (améliorations possibles, patterns globaux, intégration, etc.). On échange régulièrement les rôles entre les développeurs en utilisant, par exemple, la technique pomodoro.
Au premier abord, on peut penser que le pair programming est une pratique coûteuse. En réalité, on perd entre 15% et 100% de temps de travail effectif pour un développeur. En revanche, les coûts de maintenance liés à la qualité du code sont réduits. De plus, les évènements extérieurs qui pourraient perturber un développeur (appels téléphoniques, mails, etc.) peuvent être gérés beaucoup plus facilement. En effet, un développeur peut rester totalement concentré pendant que l’autre gère cette interruption. Enfin, l’apprentissage et le partage de connaissance de cette pratique permet aux développeurs de monter en compétence et peut contribuer à des heures travaillées beaucoup plus efficaces.
Avantages : partage de connaissances, meilleur design du code.
Limites : pratique souvent remise en cause pour son efficacité, certains binômes incompatibles.
3- Le Brainstorming
Le Brainstorming est un atelier permettant de générer et développer des idées via un processus généralement créatif. Un atelier d’idéation se déroule généralement en deux phases :
-une phase de divergence, durant laquelle on va générer un maximum d’idées, de façon collective ou individuelle.
-une phase de convergence, durant laquelle l’ensemble du groupe va tenter de converger vers une idée ou un ensemble d’idées.
On peut répéter ces phases plusieurs fois, c’est par exemple le cas pour un atelier tel que le 1-2-4-All, tiré des Liberating Structures :
- On génère des premières idées seul pendant 1 minute.
- On partage à deux les idées et on trouve un nouvel ensemble d’idées pendant 2 minutes.
- On partage à quatre les idées et on trouve un nouvel ensemble d’idées pendant 4 minutes.
- On partage à l’ensemble les idées et on trouve un dernier ensemble d’idées pendant 5 minutes.
Durant les phases de partage, on crée des boucles de divergence (partage des idées) puis de convergence (tri, regroupement des idées). On travaille alors de manière totalement itérative et incrémentale.
Avantages : génération facile et rapide d’idées, utilisation de l’ensemble d’un groupe, amusant/intéressant.
Limites : faire aboutir la phase de convergence, nécessite une ouverture de la part des membres.
4- La documentation collaborative
La documentation collaborative est une pratique visant à écrire de la documentation en groupe. Un des exemples les plus connus et les plus intéressants de documentation collaborative est certainement Wikipédia. Wikipédia permet à n’importe quel contributeur de créer, modifier et illustrer une page de définition. Wikipédia permet aux collaborateurs réguliers de suivre les évolutions d’une page afin de vérifier la crédibilité, l’exhaustivité, l’objectivité, la lisibilité et la pertinence de l’information ajoutée. Ainsi, les actes de spams et vandalismes peuvent être évités facilement.
Dans un cadre professionnel, le fait d’avoir une documentation collaborative et vivante permet de créer un contenu de qualité, validée par plusieurs personnes et améliorée au fur et à mesure. Les erreurs ou imprécisions commises par les uns sont corrigées par les autres. Les bonnes idées et pratiques utilisées par les uns sont partagées avec les autres. La connaissance des membres est alors partagée au sein de l’organisation. La plupart des outils de documentation collaborative (Google Docs, Confluence, etc.) possède un historique afin de pouvoir restaurer facilement une version antérieure d’une page. Ainsi, les contributeurs n’ont plus peur de modifier et de faire vivre la documentation. De plus, par le biais de commentaires par exemple, les membres peuvent faire valoir leur avis afin d’affiner au maximum la documentation, de poser des questions sur celle-ci, ou même de remercier les contributeurs. Dans certains cas, le wiki peut rapidement devenir un simple répertoire où les membres stockent leur travail et où aucune interaction n’est développée. Il perd alors tout son intérêt.
Avantages : partage de connaissances, évolution de la documentation facilitée.
Limites : organisation de la documentation souvent complexe, nécessite parfois une remise en question de l’existant, nécessite une grande confiance envers les autres et de la rigueur.
5 - Les communautés de pratique
Les communautés de pratique sont des groupes de personnes travaillant sur les mêmes sujets et qui sont conduites à constamment trouver des solutions face à des problèmes rencontrés dans leurs pratiques professionnelles. Les communautés de pratique prônent une vision sociale de l’apprentissage à travers le partage de connaissances entre les différents membres.
Selon Etienne Wenger, le théoricien de cette pratique, elles sont caractérisées par trois dimensions :
- L’ouverture aux autres et à leurs solutions : le croisement des expériences de chacun étant au coeur de l’apprentissage collectif.
- Un but commun : l’interaction entre les membres permettant de résoudre les problèmes rencontrés pour atteindre ce but.
- Un langage partagé : un lexique commun de mots, de processus, de pratiques, d’outils afin de faciliter les échanges.
Les communautés de pratique prennent du temps à être mises en oeuvre et suivent le chemin suivant : le point de départ est d’être en silos, puis on partage des histoires, puis on résout des problèmes communs, pour enfin utiliser la connaissance collective pour créer d’encore meilleures pratiques. La communauté se doit d’être vivante afin de perdurer et elle ne doit pas reposer sur un seul élément de celle-ci. Il existe généralement des communautés de pratique sur des sujets tels que le développement, l’Agilité, la data science, le DevOps ou encore la facilitation mais on peut imaginer ce genre de communauté autour de n’importe quel métier ou activité d’un métier qui regroupe des problèmes ne permettant pas une solution automatique et qui fonctionne à coup sûr.
Avantages : résolution de problèmes à plusieurs, partage de connaissances.
Limites : difficulté de mise en place, repose souvent sur un leader.
Au final, par où commencer ?
Evidemment, il peut s’avérer compliqué de choisir un seul outil ou une seule méthode pour définir ce qui sera le plus efficace au sein d’une organisation. Cela peut être influencé de part les différentes expériences de chacun, qui permettront de guider un choix sur la solution à adopter, toujours et idéalement en accord avec le reste des membres du groupe. Une fois de plus, cela peut se décider par le vote, le consensus, le consentement, ou tout autre façon juste de laisser chacun s’exprimer, toujours dans le but pour mieux avancer collectivement.
Tout comme l’agilité, l’intelligence collective émerge au sein des organisations, on ne peut pas forcer son apparition. De plus, ce n’est pas seulement par le biais de la mise en place de ces différentes pratiques qu’elle émergera. L’intelligence collective nécessite un cadre, des conditions et une croyance en celle-ci. L’organisation doit donc soutenir cette émergence, en faisant évoluer les mentalités positivement. Ce chemin est long et nécessite un réel travail d’apprentissage, d’amélioration continue et de partage.
Par Vincent ROSSIGNOL et Jordan TAHRAOUI, respectivement Scrum Master et Product Owner chez SOAT