Favoriser la réussite collective grâce aux méthodes Agile

Cet article présente un outil simple à mettre en place pour favoriser la réussite collective dans un environnement d’apprentissage. Pour que vous puissiez comprendre sa fonction, permettez-moi de décrire la situation-problème.

Le cadre pédagogique proposé à BeCode — la branche belge des écoles Simplon , formant gratuitement des développeurs web Junior en six mois — repose sur ces piliers:

  • pédagogie par projets, qui permet d’apprendre par la pratique et en autonomie;
  • learning by teaching: on ne comprend vraiment quelque chose que lorsqu’on est capable de l’expliquer. Les apprenants se trouvent très vite en situation d’expliquer telle ou telle notion, voire d’animer des ateliers d’initiation à la programmation.
  • la réussite est un enjeu collectif: on apprend en interaction avec les autres, le mode opératoire étant: je cherche par moi-même. Si je suis bloqué, j’en parle au groupe. Si malgré cela je suis toujours bloqué, j’en parle au coach qui ne donne pas de réponse mais me remet sur les rails.
Becode, en une phrase.

Mais le groupe se disloque…

Fort bien tout cela. Chaque semaine un projet. Et projet par projet, les apprenants apprennent et montent en compétence à une vitesse impressionnante. Mais après quelques semaines de formation, des tensions s’accumulent, le groupe se désolidarise… un peu à la manière du peloton durant le Tour de France.

Comment en est-on arrivé là?

Une dynamique négative s’est installée insidieusement entre un groupe de tête qui termine systématiquement non seulement les objectifs principaux mais également les objectifs secondaires des briefings, et ceux/celles qui n’arrivent que rarement à réaliser les objectifs principaux dans les temps impartis. La révolte gronde.

Il faut savoir que les apprenants de BeCode viennent d’horizons très divers. Certain(e)s arrivent déjà muni d’une certaine expérience de la programmation. D’autres par contre, la découvrent avec BeCode, ce qui est tout à fait normal.

La raison est systémique: afin que chacun(e) trouve suffisamment de challenge en fonction de sa situation de départ, nous décrivions dans nos briefings des objectifs principaux (que tout le monde doit atteindre) et des objectifs “bonus” (à réaliser si il y a encore du temps). Un peu à la manière des quêtes principales et secondaires des jeux vidéos.

Nous voulions bien faire, mais n’avions pas du tout anticipé les tensions que ce système générerait par accumulation: ce sont toujours les mêmes qui arrivent aux bonus, tandis que les autres peinent à atteindre les objectifs principaux dans les temps, accumulant un ressenti d’échec.

Cette situation problématique est donc un effet pervers d’une intention louable: proposer des objectifs différenciés en fonction des niveaux.

Une résolution Agile.

Après avoir constaté et discuté de la situation entre formateurs, nous avons alors organisé le lundi matin une réunion de crise avec les apprenants, en leur exposant le problème à résoudre: l’objectif de réussite collective est en train d’échouer et il faut impérativement à présent regrouper le peloton.

La mission proposée : repasser sur chacun des six projets déjà accomplis, un par un et dans l’ordre, en vérifiant l’état d’avancement du projet pour chaque apprenant.

Avec une règle : personne ne passe au projet suivant tant que toute l’équipe n’a pas terminé les objectifs principaux. Si tu a terminé tu vas aider. Si tu traines, tu fais ton possible pour hausser le rythme.

Mesure 1: le kanban “Peloton”

Afin d’avoir une vision d’ensemble, nous avons dessiné sur le tableau blanc un kanban adapté à la problématique, permettant à chacun(e) de positionner un post-it marqué de son nom dans la colonne où il/elle se trouve dans la réalisation du projet actif:

  • pas commencé
  • en cours
  • besoin d’aide
  • Objectifs principaux terminés
  • Bonus

Une dernière colonne, à droite, liste le pipeline de la séquence d’exercices / projets à réaliser dans le temps imparti, et permet de situer où le groupe se situe dans son ensemble, par rapport au travail à abattre.

Le kanban “Peloton”

Mesure 2: binômes aléatoires

Dorénavant, chaque jour, l’ apprenant se voit ainsi assigner un binôme, aux cotés duquel il passera la journée. Ce binôme constitue la première personne à qui adresser ses questions.

Mesure 3: fini les bonus

Dorénavant, si l’apprenant a terminé, il doit chercher à aider les autres, ce qui va l’amener par exemple à faire du “learning by teaching” ou à muscler sa capacité à débogguer ou à localiser les erreurs de syntaxe dans un bout de code.

Au fond, c’est cela le vrai bonus: avoir l’occasion d’expliquer avec ses mots et débogguer plus rapidement en étant confronté aux problèmes des autres.

Les effets observés

  • Dans l’ensemble, le groupe s’est parlé et se connait mieux. Les “lents” et les “rapides” comprennent mieux leurs différences, leurs attentes mutuelles et se retrouvent d’accord sur la nécessité de collaborer pour avancer dans leur formation, ce qui est un objectif qu’ils partagent tou(te)s.
  • Le Kanban est un outil fort apprécié par les apprenants car il leur permet de s’auto-gérer et rend transparent ce qui auparavant était l’objet de spéculations. Ils peuvent se situer à tout moment et voir facilement qui galère, qui peut aider.
  • Par sa présence constante et visible dans l’espace de travail physique (et non digital) le kanban rappelle à tout instant que la formation se fait collectivement ce qui, au final, renforce l’esprit d’équipe.
  • Le système de binômes aléatoires crée des occasions de mieux se connaitre individuellement, au delà des préjugés.

Au final, de cette situation-problème, nous avons tous tiré énormément d’apprentissages. Comme quoi, effectivement, chaque problème, chaque obstacle, chaque difficulté est une occasion d’apprendre et de grandir. Ensemble.

Le kanban “peloton” et Mister G. comme scrum master de la semaine.