Partage des connaissances, source de réactivité

En agilité et en particularité dans Scrum, il est important d’avoir des équipes polyvalentes. Des équipes étant capable de travailler à tous les niveaux et de résoudre n’importe quel problème. On se heurte souvent à un problème de connaissances. Seulement un sous-ensemble d’individus connaissent ce module (par exemple s’il est historique), cet outil, ce client … Ces spécialisations sont des points de blocages potentiels pour l’équipe. En cas de départ ou d’absence de ces « Centre de connaissances » il est difficile d’avancer, de progresser rapidement et d’être réactif.

Des outils de partage des connaissances existent (comme les wikis, evernote, onenote…) mais leur coût de mise-à-jour sont souvent élevés pour pas qu’ils ne deviennent obsolètes. C’est pourquoi je préfère la transmission de connaissance directe en effectuant du travail collaboratif.
Au départ de tout travail, il y a un besoin client, au sein de l’équipe ce besoin est au début centralisé dans un seul de ses membres, le Product Owner. Il transmet sa connaissance pendant les cérémonies de Planning. Il présente les besoins et le profil du client à l’équipe qui choisit une solution pour répondre au besoin.
La conception de la solution est l’occasion de partager de la connaissance sur le produit et sur l’architecture des composants. En Scrum l’équipe travaille de façon transversale sur les composants pour délivrer la fonctionnalité, il est donc souvent nécessaire d’effectuer des modifications à plusieurs niveaux dans les couches du produit. Profitez de cette période de conception rapide pour transmettre de la connaissance sur les différents modules ou leurs interactions. Pour cela vous pouvez utiliser des outils comme le Mind Mapping. Rassemblez vous autour d’un tableau pour dessiner l’architecture et les modules impactés, cela permet en plus de transmettre la connaissance d’avoir une vision commune sur le travail à réaliser. Ici nous appelons ces ateliers «Agile Modeling».
Ensuite, dans des méthodes plus pratiques (comme xp) on incite les membres à faire du binômage, ce qui permet une communication directe entre les deux membres. Ils améliorent ainsi leur méthode de programmation et leurs connaissances du langage. Le code qui en résulte est souvent plus simple et contient moins d’erreurs. Vous pouvez aussi regarder du côté de la code review qui permet de réduire significativement le nombre de défauts tout en partageant sur le code réalisé.
On peut aussi travailler en binôme sur la réalisation d’un test, qu’il soit manuel ou automatique. Dans tous les cas le binômage permet la transmission de connaissance sur les outils les composants et les habitudes de l’équipe.

Ces solutions sont techniques et permettent la transmission de connaissances liées à la technique à l’équipe. Il existe une dernière forme de connaissance aussi appelé «sens client». Connaître son client permet d’éviter des erreurs grossières, on attribue souvent à tort au product owner tout ce qui attrait au client. La transmission des habitudes du client à l’équipe permet d’être plus autonome et de faire des choix plus pertinents. Dans certaines équipes le product owner est peu présent et ces équipes ont souvent du mal à répondre au besoin de façon pertinente.
En bref le partage des connaissances est primordial, qu’il soit technique ou fonctionnel. La polyvalence permet d’éviter des blocages dû au départs et aux absences. Enfin en cas de pression l’équipe peut plus facilement s’auto-organiser pour répondre au besoin.
Et vous ? Qu’utiliser vois comme outils et méthodes pour partager la connaissance entre les membres de l’équipe ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *