Pauline Gomy

Bienvenue, lecteur. Tu trouveras ici du pro, du perso, des humeurs, des nouvelles, voire autre chose…

Scrum, bachotage, et projets étudiants

Il est rare, tout de même, qu’on se lance dans une certification pour rien. Ou alors on a mal compris le titre du stage. C’est peut-être ce qui m’est arrivé, quand, jeudi matin, j’ai découvert que je devais passer la certification de professional scrum master le lendemain (il faut dire que j’avais demandé le stage il y a deux ans). Ouf, j’ai réussi avec 94 % de bonnes réponses à l’avoir. Preuve que je suis encore capable de bachoter comme le font certains étudiants, pas les miens. Mais finalement, à quoi ça sert ?

Précisons que je n’ai qu’une vision partielle puisque quelques uns de mes étudiants se sont organisés en Scrum, mais sans mon aide en tant que coach. Empiriquement, ils ont beaucoup bénéficié des apports de Scrum. Mais je n’ai encore jamais formé les étudiants à l’utiliser, et de toute façon, tous ne le souhaiteraient pas ni n’en seraient capables. Je ne l’ai jamais non plus exercé en entreprise…

C’est quoi Scrum

Faisons un petit récapitulatif pendant que c’est encore frais. Scrum est une des nombreuses méthodes agiles (bien qu’au sens strict ce soit plutôt un cadre qu’une méthode). Elle tire son nom de la mêlée, ce qui n’est pas sans rappeler certains grands moments des projets étudiants. Scrum permet de produire des produits créatifs et complexes dans un environnement changeant et complexe. Dit comme ça, on voit bien le lien avec les projets étudiants… Pour expliquer le cadre que permet Scrum, j’ai préparé un schéma que j’ajouterais à cet article dès qu’il sera lisible.

Scrum et projet étudiant

Mais allons d’ores et déjà aux conclusions, après tout c’est un blog et pas une revue scientifique hein.

Les objectifs sont toujours business driven. Aussi, ils permettent de recadrer l’utilité du projet : qui est l’utilisateur final ? Quel est le but de notoriété ? Ce projet permet-il d’assurer la survie de l’entreprise ? Est-il conforme aux besoins marchés ou aux contraintes externes ? Ce n’est, ni plus ni moins, qu’une manière de recadrer les objectifs hors du fantasme : obtenir le diplôme, être une preuve de compétence pour les recruteurs, idéalement devenir un projet shippé, voire générer des revenus, a minima des prix.

La scrum team est auto-gérée : c’est un point très important pour nous autres pédagogues. Cela veut dire, à l’extrême, qu’en suivant ces principes l’équipe peut décider de se séparer d’un de ses membres. Je crois d’ailleurs qu’on devrait cesser de forcer nos équipes étudiantes à se supporter jusqu’à la fin.

Un sprint possède des règles de jeu immuables : planification, daily scrum, avancement du projet, sprint review puis retrospective. C’est idéal pour un projet étudiant : ils prennent des options, se voient régulièrement de façon active, présentent le résultat de leur sprint (qui doit être fonctionnel et utilisable), puis débattent entre eux des possibilités d’amélioration. Réflexivité, auto-organisation, responsabilisation, justification du travail établi : tous nos besoins sont inclus dedans, et c’est dans la réalité ce qu’on fait (plus ou moins suivant les responsables de formation, car la retrospective est souvent omise).

La development team n’est pas dérangée pendant son sprint. les stakeholders ou le PO restent en retrait (témoins grâce à la transparence). C’est une bonne idée pour nous : si les sprints sont suffisamment courts (deux semaines environ), les étudiants peuvent avancer sans être remis en cause, tout en ayant quand même accès à des précisions si besoin, bien sûr. Les coachings fréquents sont souvent source de perturbation.

Les rôles sont clairement répartis sans qu’il y ait de sensation hiérarchique. C’est là qu’on atteint les conditions de réussite de l’utilisation de scrum pour un projet étudiant.

La dev team doit avoir les compétences pour produire (en général, c’est le cas puisqu’on les apporte avant ou pendant ou qu’on soutient leur acquisition), et qu’on évite absolument de mettre en danger les étudiants en leur faisant redimensionner le projet ou en choisissant un commanditaire adhoc grâce à notre expérience.

Les stakeholders par ailleurs, sont clairement identifiés : c’est l’école, qui apporte en industrie (via l’infrastructure) le nécessaire pour réaliser le projet. C’est souvent le problème avec certains étudiants qui n’arrivent pas à communiquer à des profs comme s’ils étaient des pros. Il faut que les profs assument clairement leur rôle : c’est aussi la notoriété de l’école qui est en jeu, l’avenir des étudiants donc leur placement et les taux de réussite du diplôme. Nous sommes bien des stakeholders…

Le scrum master doit pouvoir faciliter et implémenter scrum : il doit avoir une formation adhoc et faire appel au « coach agile » (qui peut être un professeur externe si possible non stakeholder). Il n’est pas pensable d’imaginer que le scrum master soit un professeur, la hiérarchie serait trop forte et l’investissement trop faible. A mon avis le responsable de formation ne devrait pas être coach agile pour un scrum master de ses étudiants, mieux vaudrait un autre professeur moins investi comme stakeholder. C’est à checker.

Plus délicat, le product owner doit être : soit un « commanditaire » auquel cas un des étudiants relayera son besoin/objectif en tant que PO proxy. C’était le cas, notamment, avec l’équipe « Le corps une autobiographie » pour Darjeeling cette année. S’il n’y a pas de commanditaire, l’idéal est le producer projet, c’est-à-dire l’étudiant le mieux à même d’endosser une responsabilité business marketing, donc d’emmener l’équipe vers un projet shippable. A défaut, le PO devrait être l’auteur principal du projet, bref le gardien de l’univers, qui a la main sur les fonctionnalités, qui sera en général plutôt le game designer ou l’UX designer, ou directeur de création. Bref, la personne par défaut la plus à même de concevoir des epics et users stories cohérentes.

Quels bénéfices en attendre ?

Les règles de jeu sont ludiques : événements timeboxés, possibilités de fonctionner en posts-its, Kanban ou encore planning poker, possibilité d’utiliser des logiciels efficaces comme basecamp ou Trello. En général plébiscités par les étudiants.

Il est néanmoins possible d’imposer des méthodes d’ingénierie en parallèle (cf xtreme programing, ou plus simplement process orientés utilisateurs avec tests), car Scrum s’en accommode très bien.

Enfin et surtout, même si la vision des étudiants n’est pas claire en début de projet, les itérations produiront un nécessaire apprentissage, la fameuse réflexivité qu’on recherche. Scrum nous (me) privera sans doute d’une certaine forme de maternage…

Le planning review est idéal pour remplacer jurys intermédiaires : responsabilisant, permettant de voir à la fois des résultats et une construction simple mais efficace (rappel des objectifs, présentation des résultats, discussion de la poursuite, et surtout organisation par la dev team elle-même).

Reste la question de l’évaluation finale.  Mais ça… C’est une autre histoire 🙂

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Information

Cette entrée a été publiée le 29 mai 2015 par dans Réflexions, et est taguée , , , .
%d blogueurs aiment cette page :