J’ai participé ce lundi soir à un atelier organisé au sein du French Scrum User Group ayant comme thème “Produire des contrats types pour les différents rôles Scrum” et animé par Luc Bizeul. Ce fut un moment enrichissant et convivial, et je profite de ce billet pour remercier les participants pour la qualité de leurs contributions. Les contrats élaborés à cette occasion sont en cours de rédaction / mise au propre avant diffusion à la communauté, mais je vais lever un coin du voile dans la suite du billet.
Des contrats ? Pourquoi faire ?
Cet atelier avait pour but de rédiger et proposer une première version d’une série de 3 contrats tri-partite, décrivant les devoirs de chacun des acteurs classiques Scrum (Scrum Master, Product Owner, Développeur) envers les autres acteurs en se concentrant sur les interactions. Ces contrats s’inscrivent dans une approche de type coaching et s’entendent comme des contrats moraux passés entre les acteurs, qui matérialisent les engagements pris.
3 rôles, 3 contrats, 3 groupes de travail
Nous nous sommes organisés en 3 groupes (un par rôle) et nous nous sommes prêtés à un jeu de rôles, chaque groupe endossant un des rôles Scrum. L’objectif proposé est simple : lister pour chaque rôle ses devoirs envers chacun des 2 autres types d’acteurs. Ce fut l’occasion de nombreuses discussions, abordant une large palette de sujets (parfois débordant du cadre de l’atelier …) au travers des retours d’expérience et d’échanges constructifs, comme par exemple :
- “Definition of done” : faut-il l’inclure dans les contrats élaborés au sein l’atelier ?
- aspects juridiques de la contractualisation agile : de la difficulté de faire cohabiter le droit des contrats informatiques et les principes agiles
- notion d’engagement : “on ne s’engage que sur ce qui dépend de soi”
- choix des mots : de la nécessité d’utiliser des termes sans équivoque, compris par tous (cas pratique vécu en atelier, mis en lumière par les participants venant de l’autre côté de l’Atlantique)
- définition de l’équipe : équipe composée uniquement des développeurs / développeurs et Scrum Master / développeurs, Scrum Master et Product Owner ?
- importance du rôle du Product Owner au sein du projet, trop souvent sous estimée
- partage des enjeux et des risques d’un projet entre l’ensemble des acteurs
- rôle du management, et ses devoirs envers les différents acteurs (délégation, attribution du temps nécessaire aux tâches du process, etc.)
- etc.
Et en avant première …
… les notes de travail qui serviront à rédiger le contrat “Scrum Master” !
Le Scrum Master doit :
- être : - de bonne foi
- transparent
- respecter ses devoirs vis à vis du Product Owner : - veiller à la mise à jour régulière du Burn Down Chart
- alerter le PO en cas de problème
- s’assurer que les indicateurs de suivi du projet fournis soient compris de tous
- respecter ses devoirs vis à vis de l’équipe (développeurs) : - protéger l’équipe des perturbations extérieures
- pousser l’équipe à identifier et résoudre les problèmes (autonomie)
- challenger l’équipe à tenir ses engagements et améliorer son efficacité (aspect coaching)
- faciliter les échanges au sein de l’équipe (veiller à ce que chacun s’exprime)
- respecter ses devoirs vis à vis de l’équipe et du Product Owner - organiser les cérémonies Scrum
- être responsable du back log des problèmes
- être responsable du respect des process (animation et timeboxing réunion, durée des itérations)
- faciliter les échanges entre le Product Owner et l’équipe
- faire monter le Product Owner et l’équipe en compétence sur Scrum
