Un manager agile est un manager qui évolue dans un écosystème agile. Il n’est pas toujours simple de trouver sa place lorsqu’on a été manager dans un environnement traditionnel; ni de trouver la bonne posture managériale, plus délégative. La communauté de pratique est un bon moyen pour un manager agile, de (re)trouver sa place et sa légitimité. Ce n’est évidemment pas la seule. Elle fait partie de la panoplie de pratiques pour manager agile. C’est également une piste importante pour la scalabilité de l’agilité dans l’organisation, mais c’est un autre sujet.
Les communautés de pratique
Les communautés de pratique existent depuis quelques dizaines d’années, au moins 1990 a priori. Elles permettent le partage de connaissances, d’un savoir-faire et de progresser ensemble sur un domaine, au sein d’une organisation. Nous allons nous concentrer sur les communautés de pratique internes aux entreprises. Etienne Wenger soutient que ces communautés de pratique sont « la connaissance la plus dynamique et la plus versatile de l’entreprise, une ressource qui constitue le socle de sa capacité à savoir et à apprendre » Car elle touche, entre autre, à la connaissance tacite du métier difficile à capter. D’ailleurs, certains situent cette pratique dans le cadre du Knowledge management. Dans l’écosystème agile, ces communautés sont arrivées à deux niveaux principalement :
- Les communautés de pratiques agiles, souvent constituées autour des rôles Scrum : Product Owner, Scrum Master, coach agile, manager agile.
- Les communautés de pratiques techniques ou métiers. Les équipes agiles sont orientées produit ou fonctionnalités métier. Elles sont pluridisciplinaires, avec des testeurs, des développeurs de toutes technos, des analystes métier. Contrairement à l’organisation traditionnelle organisée par profil (technique, métier, marketing, …). Les communautés transverses ont pour but de garder une connaissance transverse aux produits ou fonctionnalités, et d’assurer une homogénéité de pratiques (développement, briques techniques, ergonomie, …).
J’ai pu observer que ces communautés sont importantes pour le statut social des experts qui, avec l’arrivée de l’agilité, ne vivent pas toujours bien de se retrouver au même niveau que tous les équipiers (i.e. sans rôle hiérarchique) d’un projet Scrum. Ils retrouvent, avec les communautés de pratiques techniques, un espace où leur expertise est valorisée et valorisable. Spotify a fait beaucoup d’avancées sur ce sujet et propose un modèle d’organisation avec des communautés de pratique, ses chapters et ses guildes.
Modèle spotify
Ces communautés créent globalement du lien entre les équipes.
Organisation des communautés de pratique
Ces communautés sont généralement auto-organisées. Elles sont « l’émergence d’un management coopératif ». Et cela bouscule les managers. Avec le modèle d’organisation proposé par l’agilité, et particulièrement par Scrum, c’est le deuxième effet KissCool : les managers ont déjà vu l’arrivée d’équipes auto organisées et d’un Scrum Master, ce qui les a sorti une première fois de l’arène opérationnelle. Rebelote avec les communautés transverses au niveau de l’organisation !
Le manager agile & les communautés de pratique agiles
Plutôt qu’une nouvelle menace pour son poste, c’est une opportunité à saisir pour le manager. Jean-Claude en parle très bien. Il propose que le manager Agile soit l’initiateur voire l’animateur de ces communautés. Plutôt que de se voir exclu du jeu, il en devient l’acteur bienveillant, le pilote. C’est pourquoi ce sont des pratiques pour le manager agile. A minima, il doit en être le sponsor, pour qu’elles trouvent la légitimité du temps qu’on leur accorde. Leur existence et leur animation sont donc de véritables enjeux, c’est pourquoi il vous faut des pratiques pour vos communautés de pratique !
5 pratiques pour vos communautés de pratique
J’ai eu l’opportunité d’accompagner, ces dernières années, plusieurs communautés de pratique agiles pour différents clients. Voici quelques retours d’expérience, qui ont bien marché, sur la manière de les animer dans un esprit collectif et collaboratif.
#1 Créer la vision d’une communauté
Avec une communauté de managers lors d’une transition agile, j’ai utilisé l’atelier du speed boat enrichi. Voilà comment cela se déroule : On commence par dessiner une île paradisiaque, le terme du voyage (i.e. la transition agile). L’objectif de l’atelier est que tout le monde s’aligne sur leur futur rôle de manager Agile. Chacun y met d’abord sa propre vision, en écrivant ses propres sticky notes, puis une vision collective se forge sur le rôle en regroupant, reformulant, mettant de côté chaque point. Ensuite, on utilise le speed boat pour visualiser les freins et les moteurs permettant d’atteindre plus rapidement cette île. Cela permet d’identifier les chantiers sur lesquels la communauté de pratiques doit travailler. On initialise le backlog de la communauté. On peut enrichir l’atelier en visualisant les écueils ou les risques par des rochers effleurant l’eau, ou des orages zébrés d’éclairs. Il y a d’autres manières de faire, on peut citer le Pocket-Sized Agile Principles ou le product box.
#3 Prioriser les sujets
Une fois les sujets identifiés, j’aime bien utiliser un autre atelier des innovations games: Prune the product Tree. Les participants mettent les sujets sur un arbre et les répartissent par thème. Ces thèmes sont émergents, ils deviennent les branches de l’arbre, les sujets en sont les feuilles. Ensuite, on déplace les sujets par priorité : les priorités hautes proches du tronc de l’arbre, et basses vers l’extérieur. On schématise les futures tailles de l’arbre pour les saisons à venir. Cela permet visuellement de répartir les sujets dans les différentes saisons, par priorité. On peut maintenant se concentrer sur la prochaine saison pour identifier les feuilles des branches. On découpe les sujets en des tâches plus actionnables, (bon ok des actions SMART). Ici, la métaphore de l’arbre marche à deux niveaux : pour les saisons et le fait qu’une communauté de pratique évolue de manière organique, c’est un bon rappel.
#5 Prendre des décisions collectives
Oui, mais pas forcément unanimes. Le Dot Vot est là pour vous aider à faire émerger rapidement la bonne décision collective, les 2 ou 3 actions à réaliser… C’est un classique de n’importe quelle rétrospective Scrum. Cet atelier est bien utile dans ces communautés de pratique où il n’y a pas de chef. Il y a par contre un leader, mais qui n’impose pas les décisions.
#2 Définir le rythme des rencontres
Bien qu’informelles, je vois un intérêt à donner un rythme aux réunions de ces communautés de pratiques, plutôt court, toutes les 2 semaines par exemple. Mais plus important, un rythme pour les objectifs à moyens termes. Et pour cela, j’ai repris l’idée de Laurent Sarrazin, la notion de saisons, comme les séries télévisées, calées sur le rythme des vacances scolaires, avec une planification à la rentrée et un bilan, voire une démo avant les vacances. Tout cela est raconté dans Rupture douce saison 1.
#4 Rétrospectives sur les pratiques
On a vu jusque-là des ateliers plutôt destinés au démarrage de la communauté ou au démarrage de chaque nouvelle saison. Ca permet de remplir le backlog des sujets de la communauté et de le prioriser. En fin de saison, j’aime bien faire une rétrospective des pratiques, comme à la fin d’un Sprint :Rétrospective du backlog grooming (pardon Claude, l’affinage de son backlog) avec les Product Owners, rétrospective des rétrospectives avec les Scrum Masters (ça rend fou tout ça…).C’est une communauté de pratique, on est là pour s’améliorer sur nos pratiques justement… J’utilise tout particulièrement l’atelier learning matrix pour rappeler que c’est un moment de partage et d’apprentissage. Dans cet atelier, on demande aux participants d’écrire ce qui a bien marché pour eux (on partage les bonnes pratiques), ce qui n’a pas bien marché (c’est cool on va pouvoir en débattre ensemble !), ce qu’ils ont appris (on ancre l’apprentissage) et les questions qu’on se pose encore (re cool on va pouvoir aussi en discuter).
Avec un client, on a passé comme cela une journée complète avec les Product Owners et une journée complète avec les Scrum Masters pour repasser chaque pratique, en changeant l’atelier de rétrospective à chaque nouvelle pratique.
