Business Digital

Constituer une équipe Scrum : les trois responsabilités

12 دقائق للقراءة

Vous venez de réunir cinq personnes pour développer StockPro, une application web de gestion de stock et de ventes pour une quincaillerie de quartier. Tout le monde est motivé, mais en deux semaines rien n’avance vraiment : le développeur backend attend les maquettes, la personne qui connaît le métier corrige les priorités tous les jours, et personne ne sait qui tranche quand deux idées s’opposent. Ce n’est pas un problème de compétence. C’est un problème de responsabilités mal réparties. Scrum répond précisément à cela avec une équipe de trois responsabilités complémentaires. À la fin de ce tutoriel, vous saurez constituer une équipe Scrum saine et placer chaque personne devant la bonne redevabilité.

Ce que vous allez apprendre

  • Reconnaître ce qu’est — et ce que n’est pas — une équipe Scrum selon le Guide Scrum 2020.
  • Distinguer sans ambiguïté les trois responsabilités : Product Owner, Scrum Master et Developers.
  • Attribuer à chaque membre de l’équipe StockPro un périmètre clair de décision.
  • Éviter les confusions classiques (chef de projet déguisé, comité de décision, équipe à deux vitesses).

Ce que vous allez mettre en place

Vous repartirez avec une équipe StockPro de cinq personnes structurée correctement : une personne porte la valeur du produit, trois personnes construisent l’incrément, une personne fait vivre le cadre. Vous aurez aussi une fiche de responsabilités prête à afficher, qui sert de contrat d’équipe.

Prérequis

  • Avoir un produit réel à construire (ici StockPro) — Scrum sert à livrer un produit, pas à remplir un agenda.
  • Cinq à dix personnes disponibles régulièrement. Si vous savez déjà ce qu’est une user story, vous êtes à l’aise ; sinon, ce n’est pas bloquant pour ce chapitre.
  • Niveau : débutant. Durée estimée : environ 30 minutes de lecture et de mise en place.

Repère. Tout ce chapitre s’appuie sur le Guide Scrum 2020, rédigé par Ken Schwaber et Jeff Sutherland, qui est la définition de référence du cadre. C’est notre source unique pour les responsabilités.

Étape 1 — Comprendre ce qu’est une équipe Scrum

Avant de distribuer les rôles, il faut comprendre l’unité de base. Dans le Guide Scrum 2020, l’équipe Scrum (Scrum Team) est une seule équipe de personnes focalisée sur un même objectif produit à la fois. Elle réunit « un Scrum Master, un Product Owner et des Developers ». Le point important : il n’y a pas de sous-équipes ni de hiérarchie interne. Pas d’équipe « design » d’un côté et « dev » de l’autre qui se passent le travail par-dessus un mur.

Trois propriétés définissent une équipe Scrum saine. Elle est petite : typiquement dix personnes ou moins. Au-delà, la communication coûte plus cher que ce qu’elle rapporte, et il vaut mieux découper le produit et constituer plusieurs équipes. Elle est pluridisciplinaire (cross-functional) : ses membres possèdent ensemble toutes les compétences nécessaires pour créer de la valeur à chaque Sprint, sans dépendre d’un service extérieur pour avancer. Elle est auto-gérée (self-managing) : c’est l’équipe elle-même qui décide en interne qui fait quoi, quand et comment — personne d’extérieur ne lui dicte sa façon de travailler.

Pour StockPro, cela signifie une chose concrète : votre équipe de cinq doit pouvoir, à elle seule, concevoir l’écran de saisie d’une vente, l’implémenter, le tester et le rendre utilisable. Si chaque livraison dépend d’un prestataire externe qui valide le design, l’équipe n’est pas réellement pluridisciplinaire, et Scrum patinera.

Point d’étape. Vous devez pouvoir répondre oui à : « cette équipe a-t-elle, en interne, toutes les compétences pour livrer une fonctionnalité de bout en bout ? » Si la réponse est non, identifiez la compétence manquante avant d’aller plus loin.

Étape 2 — Le Product Owner : maximiser la valeur

Le Product Owner est responsable de maximiser la valeur du produit issu du travail de l’équipe. C’est le gardien du pourquoi et du quoi. Concrètement, le Guide Scrum lui confie la gestion du Product Backlog : formuler explicitement l’objectif produit (le Product Goal), créer et exprimer clairement les éléments du backlog, les ordonner, et s’assurer que ce backlog est transparent, visible et compris de tous.

Deux règles évitent les erreurs les plus fréquentes. D’abord, le Product Owner est une seule personne, pas un comité. Il peut consulter largement — la propriétaire de la quincaillerie, les vendeurs, le comptable — mais au moment de trancher l’ordre des priorités, c’est lui qui décide. Ensuite, il peut déléguer certaines tâches (rédiger des éléments, par exemple) aux Developers, mais il en reste redevable. On ne se cache pas derrière « l’équipe a décidé ».

Pour que la décision du Product Owner ait du poids, le Guide Scrum est clair : l’organisation doit respecter ses arbitrages. Si tout le monde court-circuite ses priorités, le rôle est vidé de son sens. Sur StockPro, la personne idéale est celle qui connaît le métier de la quincaillerie et parle au nom des utilisateurs réels : elle saura dire qu’enregistrer une vente passe avant l’export comptable annuel.

La rédaction et la priorisation de ce backlog font l’objet d’un tutoriel dédié : Rédiger et prioriser le Product Backlog.

Étape 3 — Les Developers : construire l’incrément

Les Developers sont les personnes de l’équipe qui s’engagent à créer, à chaque Sprint, un incrément utilisable du produit. Le terme « Developers » est large : il englobe toute personne qui contribue à construire le produit — développeurs, certes, mais aussi celles et ceux qui font le design, les tests, l’analyse. Sur StockPro, vos trois Developers couvrent le front, le back et les tests.

Le Guide Scrum 2020 leur confie quatre redevabilités précises. Ils créent le plan du Sprint, c’est-à-dire le Sprint Backlog. Ils insufflent la qualité en respectant une Definition of Done. Ils adaptent leur plan chaque jour en direction de l’objectif de Sprint. Et ils se tiennent mutuellement responsables en tant que professionnels. Ce dernier point est souvent négligé : dans une équipe auto-gérée, ce n’est pas un chef qui distribue les tâches, ce sont les Developers qui s’organisent et se tiennent les uns les autres à un standard.

Le piège classique consiste à attendre qu’un « lead » assigne le travail chaque matin. En Scrum, c’est l’équipe qui tire les tâches du Sprint Backlog selon les priorités et ses compétences. L’auto-organisation n’est pas du désordre : c’est une discipline collective.

Point d’étape. Demandez à vos Developers : « qui décide de l’ordre dans lequel on prend les tâches du Sprint ? » La bonne réponse est « nous, ensemble », pas « le chef ».

Étape 4 — Le Scrum Master : rendre le cadre efficace

Le Scrum Master est responsable de l’efficacité de l’équipe Scrum et de la bonne mise en place de Scrum tel que défini dans le Guide. Le Guide 2020 le décrit comme un véritable leader qui sert (true leader who serves). Ce n’est ni un chef de projet, ni un secrétaire de réunion : il sert trois cercles.

Il sert l’équipe en la coachant vers l’auto-gestion et la pluridisciplinarité, en l’aidant à se concentrer sur des incréments de grande valeur, en faisant lever les obstacles (impediments) qui la freinent, et en veillant à ce que les événements Scrum aient lieu, soient positifs, productifs et tiennent dans leur durée impartie. Il sert le Product Owner en l’aidant à définir l’objectif produit et à gérer le backlog, en facilitant la collaboration avec les parties prenantes. Il sert l’organisation en accompagnant l’adoption de Scrum et en faisant tomber les barrières entre les parties prenantes et l’équipe.

Sur StockPro, le Scrum Master remarquera par exemple que l’équipe perd deux jours à attendre un accès à la base de données : son travail est de faire sauter ce blocage, pas d’écrire le code à la place des Developers. Une même personne peut, dans une petite structure, être à la fois Developer et Scrum Master — mais elle doit alors avoir conscience du chapeau qu’elle porte à chaque instant.

Étape 5 — Poser le contrat de responsabilités de StockPro

Il est temps de rendre tout cela concret. Réunissez votre équipe et remplissez ensemble une fiche simple. L’objectif est qu’en cas de doute, chacun sache vers qui se tourner. Voici un exemple de fiche pour StockPro :

Produit      : StockPro (gestion de stock + ventes, quincaillerie)
Product Owner: Awa  -- porte la valeur, ordonne le Product Backlog
Scrum Master : Karim -- garant du cadre, lève les obstacles
Developers   : Fatou (front), Ibrahim (back), Moussa (tests)
Objectif produit (Product Goal) :
  "Permettre d'enregistrer une vente et de suivre le stock
   en temps reel, sans papier."

Affichez cette fiche, physiquement ou dans l’espace partagé de l’équipe. Ce n’est pas de la bureaucratie : c’est le rappel visible que les décisions de valeur reviennent à Awa, que les blocages remontent à Karim, et que la façon de construire appartient au trio de Developers. Toute l’équipe, ensemble, reste responsable de produire un incrément de valeur à chaque Sprint.

Point d’étape final. Chaque membre doit pouvoir énoncer en une phrase sa redevabilité principale. Si deux personnes revendiquent la même décision (par exemple l’ordre des priorités), vous avez un conflit de rôle à clarifier avant le premier Sprint.

Pièges fréquents

Symptôme Cause probable Correctif
Les priorités changent tous les jours, l’équipe ne finit rien Plusieurs personnes jouent au Product Owner Nommer un seul Product Owner dont l’arbitrage est respecté
L’équipe attend qu’on lui assigne les tâches chaque matin Auto-gestion non installée, réflexe de chef de projet Laisser les Developers tirer les tâches eux-mêmes du Sprint Backlog
Le Scrum Master écrit du code à la place de l’équipe Confusion entre servir et faire Recentrer le Scrum Master sur les obstacles et le cadre
Une « équipe design » livre à une « équipe dev » Sous-équipes interdites par le cadre Fusionner en une seule équipe pluridisciplinaire
Quinze personnes dans l’équipe, réunions interminables Équipe trop grande Découper le produit, viser dix personnes ou moins

Récapitulatif

Vous venez de poser les fondations humaines de StockPro. Une équipe Scrum est une unité unique, petite, pluridisciplinaire et auto-gérée, sans sous-équipes. Trois responsabilités la structurent : le Product Owner maximise la valeur en gérant le Product Backlog ; les Developers construisent l’incrément et s’organisent eux-mêmes en respectant la qualité ; le Scrum Master rend le cadre efficace en servant l’équipe, le Product Owner et l’organisation. L’ensemble de l’équipe demeure responsable d’un incrément de valeur à chaque Sprint. Avec cette répartition claire, les blocages du début — priorités mouvantes, attente, décisions floues — disparaissent.

Aide-mémoire

Responsabilité En une phrase
Product Owner Maximise la valeur, possède et ordonne le Product Backlog (une personne)
Developers Créent l’incrément, planifient le Sprint, garantissent la qualité, s’auto-organisent
Scrum Master Rend Scrum efficace ; sert l’équipe, le PO et l’organisation ; lève les obstacles
Équipe Scrum ≤ 10 personnes, pluridisciplinaire, auto-gérée, sans sous-équipes

À vous de jouer

Dans la quincaillerie, le comptable demande à Ibrahim (back) de coder en urgence un export comptable, alors que le Sprint en cours vise l’enregistrement des ventes. Que doit-il se passer ?

Voir une solution

Ibrahim ne prend pas la demande directement. Une demande de valeur passe par le Product Owner (Awa), qui décide si et quand l’export comptable entre dans le Product Backlog et avec quelle priorité. Pendant le Sprint en cours, l’objectif de Sprint protège l’équipe des nouvelles demandes : c’est précisément le rôle du cadre. Si l’export est vraiment critique, c’est une conversation entre Awa et l’équipe, pas un ordre direct au développeur.

Tutoriels frères

Ressources

FAQ

Le Scrum Master est-il le chef de l’équipe ?
Non. Il n’a pas d’autorité hiérarchique sur les Developers. C’est un leader au service de l’équipe : il rend le cadre efficace et lève les obstacles, mais ne distribue pas les tâches ni n’évalue les personnes.

Peut-on avoir deux Product Owners ?
Non, le Product Owner est une seule personne. Il peut s’appuyer sur d’autres pour rédiger ou analyser, mais la responsabilité de l’ordre du backlog n’est pas partagée, sinon les priorités deviennent incohérentes.

Une même personne peut-elle cumuler deux responsabilités ?
C’est possible dans une petite équipe (par exemple Developer et Scrum Master), mais déconseillé pour le couple Product Owner / Scrum Master, dont les points de vue doivent rester distincts. La personne doit toujours savoir quel chapeau elle porte.

Combien de personnes au maximum ?
Le Guide Scrum 2020 recommande dix personnes ou moins. Au-delà, on découpe le produit en plusieurs équipes plutôt que de grossir une seule équipe.

مشاركة