Rôles Scrum : qui fait quoi

Lorsqu’une organisation décide d’adopter Scrum, l’une des premières choses à comprendre est la différence entre les rôles Scrum et les rôles d’exécution de projet traditionnels. Il existe deux ensembles de rôles impliqués dans Scrum :

Rôle interne

  • Propriétaire du produit – détient la vision du produit
  • Scrum Master — aide l’équipe à utiliser au mieux Scrum pour construire le produit
  • Équipe de développement — construit le produit
Rôles internes Scrum

Rôle externe

  • Propriétaire d’entreprise
  • Partie prenante (c’est-à-dire les utilisateurs finaux et les experts du domaine)
  • etc.
Rôles Scrim : rôles internes et externes

Qu’est-ce qu’une équipe Scrum ?

Une équipe Scrum (communément appelée « l’équipe ») est petite (3 à 9 sans compter le Scrum Master et le Product Owner), co-localisée (au moins virtuellement), auto-organisée, autonome, axée sur la valeur, complète- groupe de temps de personnes appelées, simplement, membres de l’équipe. Certains de ces termes doivent être définis :

Auto-organisé :  Une équipe auto-organisée est une équipe qui choisit la meilleure façon d’accomplir son travail, plutôt que d’être dirigée (microgérée) par d’autres en dehors de l’équipe. Étant donné que les membres de l’équipe travaillent ensemble, cela facilite l’apprentissage et motive l’équipe à s’approprier son processus.

Cross Functional:  Une équipe interfonctionnelle est une équipe qui contient toutes les connaissances et compétences nécessaires pour atteindre ses objectifs et ses buts, ce qui lui permet de terminer son travail sans aide extérieure.

Axé sur la valeur :  les membres de l’équipe apprécient de travailler ensemble ; ils s’améliorent constamment eux-mêmes, leur équipe, leur environnement et leurs outils ; et ils s’efforcent d’avoir des valeurs personnelles telles que l’ouverture, la concentration, l’engagement, le respect et le courage.

Équipe interfonctionnelle

Rôles Scrum

Notre voyage commence par une description générale de l’équipe Scrum elle-même, passe à une discussion des trois rôles au sein de l’équipe (le Product Owner, le Scrum Master et l’équipe de développement), et se termine par une description des rôles en dehors de l’équipe (le propriétaire d’entreprise, parties prenantes et experts en la matière).

Rôles internes

Le propriétaire du produit

Chaque membre de l’équipe Scrum joue le rôle de membre de l’équipe, mais un seul membre de l’équipe est tenu responsable devant l’entreprise du succès de l’équipe Scrum et de la valeur des résultats de l’équipe Scrum. C’est le Product Owner ou PO, pour faire court. Et cette responsabilité est une chose importante – elle définit le PO comme le chef officiel de l’équipe en ce qui concerne le monde extérieur.

Le Product Owner est la seule personne responsable de la gestion du Product Backlog. La gestion du backlog produit comprend :

  • Exprimer clairement les éléments du Product Backlog.
  • Ordonner les éléments du Product Backlog pour atteindre au mieux les objectifs et les missions.
  • Optimiser la valeur du travail effectué par l’équipe de développement.
  • S’assurer que le Product Backlog est visible, transparent et clair pour tous, et montre ce sur quoi l’équipe Scrum travaillera ensuite.
  • S’assurer que l’équipe de développement comprend les éléments du backlog de produit au niveau nécessaire.

Le PO est les yeux et les oreilles de l’équipe Scrum vers le monde extérieur (vers les parties prenantes). Il ou elle est le seul point de contact formel de l’équipe Scrum, le canal d’information. Ajoutez à cela que le PO a le dos de l’équipe Scrum. Cela signifie qu’en étant tenu responsable des résultats de l’équipe Scrum, le bon de commande est consacré à s’assurer que l’équipe Scrum reçoit les bons commentaires pour créer le bon produit au bon rythme. Le PO passe beaucoup de temps à définir la portée du produit, à clarifier les attentes obscures, à négocier les dates de livraison et à faire en sorte que tout soit adapté à l’équipe Scrum.

Nous devons également noter que même si le mot « Propriétaire » figure dans le titre, le PO peut ne pas être l’expert du produit. Certes, le PO a beaucoup de connaissances et de compétences, mais le rôle est défini par la responsabilité, et non par des compétences spécifiques au produit. Un bon PO se rend compte qu’il peut y avoir une richesse d’intelligence à la fois à l’intérieur et à l’extérieur de l’équipe Scrum et sait comment en tirer parti à la fois pour le bien de l’équipe Scrum et pour le bien du produit.

Rôles et responsabilités d’un propriétaire de produit Scrum

Maître de mêlée

Le Scrum Master Alors que le PO est les yeux et les oreilles vers le monde extérieur, à bien des égards, les yeux et les oreilles du Scrum Master sont décidément tournés vers l’intérieur, ce qui inclut les rôles suivants :

  • Le Scrum Master est un leader informel qui s’inquiète de ce qui se passe en interne au sein de l’équipe Scrum et s’assure que Scrum est utilisé correctement.
  • Le Scrum Master est un leader sans responsabilités managériales. Au contraire, il ou elle se concentre sur la santé de l’équipe Scrum et sur l’amélioration continue de l’équipe Scrum, en particulier en ce qui concerne l’utilisation de Scrum par l’équipe Scrum.
Les principaux rôles d’un Scrum Master

Rôles joués par un Scrum Master

Service au Product Owner

Le Scrum Master sert le Product Owner de plusieurs manières, notamment :

  • Veiller à ce que les objectifs, la portée et le domaine du produit soient compris par tous les membres de l’équipe Scrum aussi bien que possible.
  • Trouver des techniques pour une gestion efficace du Product Backlog.
  • Aider l’équipe Scrum à comprendre le besoin d’éléments clairs et concis du Product Backlog.
  • Comprendre la planification des produits dans un environnement empirique.
  • S’assurer que le Product Owner sait comment organiser le Product Backlog pour maximiser la valeur.
  • Comprendre et pratiquer l’agilité.
  • Faciliter les événements Scrum à la demande ou au besoin.

Service Scrum Master à l’équipe de développement

Le Scrum Master sert l’équipe de développement de plusieurs manières, notamment :

  • Coaching de l’équipe de développement dans l’auto-organisation et la transversalité.
  • Aider l’équipe de développement à créer des produits à haute valeur ajoutée.
  • Supprimer les obstacles au progrès de l’équipe de développement.
  • Faciliter les événements Scrum à la demande ou au besoin.
  • Coacher l’équipe de développement dans des environnements organisationnels dans lesquels Scrum n’est pas encore pleinement adopté et compris.

Scrum Master Service à l’Organisation

Le Scrum Master sert l’organisation de plusieurs manières, notamment :

  • Diriger et encadrer l’organisation dans son adoption de Scrum ;
  • Planifier les implémentations de Scrum au sein de l’organisation ;
  • Aider les employés et les parties prenantes à comprendre et à appliquer Scrum et le développement empirique de produits ;
  • Provoquer des changements qui augmentent la productivité de l’équipe Scrum ; et,
  • Travailler avec d’autres Scrum Masters pour augmenter l’efficacité de l’application de Scrum dans l’organisation.

Équipe de développement

L’équipe de développement Le terme « équipe de développement » est utilisé pour représenter la partie de l’équipe Scrum qui développe ou crée actuellement le produit – et cela peut inclure ou non le PO et le SM. Il est tout à fait approprié, et souvent utile, que le PO et le SM fassent partie de l’équipe de développement, mais ils doivent toujours réaliser que leurs rôles de leadership passent avant tout.

Le rôle et les responsabilités d’une équipe de développement Scrum

Rôles externes

Les parties prenantes sont le but pour lequel un produit ou un service est créé en premier lieu. Les parties prenantes sont les personnes qui ont certains besoins, désirs et désirs ; ainsi, en termes commerciaux, ils ont certaines exigences qui doivent être remplies.

Scrum définit les parties prenantes comme ne faisant pas partie de l’équipe Scrum. Il est de la responsabilité de l’équipe Scrum de répondre aux exigences des parties prenantes et de les satisfaire.

Notez que:

Habituellement, les parties prenantes ne comprennent pas clairement ce dont elles ont besoin et même si elles le font, elles changent souvent d’avis. Habituellement, déterminer les besoins réels d’une partie prenante est réalisé grâce à de nombreuses réunions avec les parties prenantes et également après de nombreux essais et erreurs.

Autres  articles essentiels  liés aux rôles Scrum :

Leave a Reply

Votre adresse e-mail ne sera pas publiée.