Apprenez à connaître les 3 « rôles » de Scrum : le Product Owner, le Scrum Master et les développeurs pour réussir vos projets.
Avant de passer aux rôles de Scrum, rappelons que Scrum n’est pas une méthodologie mais un cadre délibérément incomplet pour être efficace dans des contextes complexes (avec des variables non prédictives).
Pour que Scrum fonctionne, l’une des conditions fondamentales est la façon dont l’équipe Scrum travaille dans ces contextes.
Voyons comment l’équipe est composée et la signification que chaque membre a dans ce cadre agile.
L’équipe Scrum
« L’unité fondamentale de Scrum est une petite équipe de personnes, une équipe Scrum. L’équipe Scrum est composée d’un Scrum Master, d’un Product Owner et de développeurs. Au sein d’une équipe Scrum, il n’y a pas de sous-équipes ou de hiérarchies. Il s’agit d’une unité cohésive de professionnels qui se concentrent sur un seul objectif à la fois, l’objectif du produit. » – Guide officiel de Scrum
Lorsque nous parlons de rôles dans Scrum, nous ne nous référons pas à la fonction traditionnelle des rôles comprise dans un organigramme, mais à la nature des responsabilités des personnes qui occupent chaque espace au sein de l’équipe Scrum.
C’est pourquoi le Guide officiel de Scrum ne parle pas de rôles et de fonctions dans Scrum. Il se concentre sur les responsabilités au sein de l’équipe Scrum.
Cela dit, le Guide décrit l’équipe Scrum comme un petit nombre de professionnels travaillant sur l’objectif du produit, sans hiérarchie ni sous-équipe.
Le petit nombre de membres (généralement moins de 10) garantit l’agilité et la productivité. Scrum étant conçu pour réagir à peu de frais aux changements, la structure et la taille de l’équipe doivent être adaptées à cette fin.
Elle ne doit pas non plus être trop petite, mais de la taille nécessaire pour que l’incrément produit dans chaque sprint ait une valeur considérable.
Les très grandes équipes sont divisées en Scrum Teams de 10 personnes maximum, travaillant toutes sur le même produit, partageant non seulement un seul Product Owner, mais se concentrant sur un seul objectif de produit et un seul Product Backlog.
Si vous souhaitez approfondir l’utilisation de Scrum à grande échelle, vous pouvez vous pencher sur un cadre dérivé de Scrum appelé LeSS (Large Scale Scrum).
Un autre aspect pertinent concernant les rôles de Scrum est que les équipes adoptant ce cadre agile sont inter fonctionnelles et autogérées dans leur travail.
En d’autres termes, ces équipes contiennent en elles-mêmes toutes les compétences nécessaires pour construire le produit sans avoir besoin de recourir à des compétences externes à l’équipe (transversalité) et décident de la meilleure façon de mener le travail au cours de chaque Sprint sans recevoir d’ordres externes à l’équipe.
Contrairement à l’organisation pyramidale, tous les rôles Scrum sont également responsables de la livraison d’un incrément de produit de valeur dans chaque Sprint.
Ce petit groupe de professionnels est réparti entre les trois rôles suivants : les développeurs, le Product Owner Scrum et le Scrum Master.
Scrum Master
Au sein des rôles de Scrum, le Scrum Master est celui qui s’assure que l’équipe a une compréhension approfondie du fonctionnement du cadre et élimine les obstacles au progrès afin que l’équipe puisse se concentrer sur la livraison d’une valeur incrémentale à la fin de chaque Sprint.
Servent Leadership
L’une des caractéristiques les plus marquantes du Scrum Master est d’être un leader serviteur. Souvent, on ne le qualifie pas de Scrum Master, mais de facilitateur ou même de coach.
Dans ce contexte, être un leader serviteur signifie soutenir l’équipe, le Product Owner de Scrum et l’organisation dans l’utilisation correcte de Scrum. Prenons quelques exemples :
- Veiller à ce qu’une Scrum saine soit pratiquée.
- Que les membres de l’équipe atteignent des niveaux d’autogestion et de transversalité.
- Que l’équipe puisse se concentrer sur la création d’une valeur incrémentale de grande valeur.
- Supprimer les obstacles à la progression de l’Équipe
- Tous les événements Scrum ont lieu et sont productifs.
- Faciliter la collaboration avec les parties prenantes
- Diriger et permettre l’adoption de Scrum par l’organisation.
Connaissance approfondie de Scrum
Quiconque choisit la voie du Scrum Master s’engage sur un chemin dans lequel il doit acquérir une connaissance approfondie de Scrum. Il se concentre sur le processus de travail et l’amélioration continue. Son objectif est que l’équipe Scrum se développe et devienne une équipe :
- Compétente : Non seulement dans la connaissance de Scrum, mais aussi dans la mise en œuvre.
- Autogérée : être capable de décider qui travaille sur quoi, comment ils le font et quand ils le font.
- Transversaux : ne pas dépendre de tiers pour construire un incrément à chaque Sprint.
Pour soutenir la réalisation de ces trois objectifs, il est conseillé de développer et de maîtriser quatre disciplines clés : la formation, le conseil, la facilitation et le coaching.
Les compétences en formation sont utiles pour pouvoir transmettre les connaissances nécessaires à la compréhension de Scrum.
Les compétences en conseil seront utiles pour conseiller l’équipe Scrum et les parties prenantes sur la manière d’utiliser Scrum efficacement et d’éviter les anti-modèles.
La facilitation agile, d’autre part, sera une compétence clé lorsqu’il s’agira d’organiser différents événements Scrum et d’en faire des rencontres significatives pour toutes les personnes impliquées, avec des résultats précieux.
Enfin, le coaching agile est une compétence essentielle pour accompagner l’équipe Scrum afin d’exceller Sprint après Sprint, de briser les croyances auto limitatives, d’élargir leur champ de possibilités en vue de fournir de la valeur et d’améliorer leurs pratiques particulières dans le cadre de Scrum.
Contexte technique
Une question fréquemment posée est de savoir si le Scrum Master doit avoir des connaissances et des compétences en matière de développement de produits.
La réponse courte est qu’il est recommandé qu’il le fasse. Bien que le Scrum Master ne soit pas en charge du développement, un bon Scrum Master pourra difficilement générer une culture de travail agréable et éliminer les difficultés dans les processus de travail s’il ne connaît pas le secteur dans lequel il travaille.
En outre, si le Scrum Master ne connaît pas les aspects techniques du développement de produits, il lui sera difficile de planifier, d’estimer et de communiquer, et le reste de l’équipe pourrait le considérer comme insuffisant dans son rôle.
Product Owner
Parmi les autres rôles de Scrum, et suivant le Guide Scrum officiel, le Product Owner est celui qui s’assure que les Incréments construits par l’équipe ont la plus grande valeur possible dans chaque Sprint. Une caractéristique du Product Owner est d’assumer l’entière responsabilité des décisions concernant le produit.
Le produit peut être un produit numérique, un produit physique, un service, ou même quelque chose de plus abstrait comme une expérience.
Bien qu’il puisse recevoir l’aide d’autres personnes, il ne s’agit pas d’un travail effectué par un comité, il est effectué par le PO seul.
N’oubliez pas non plus que, même s’il peut agir en tant que développeur, les responsabilités du Product Owner sont incompatibles avec celles du Scrum Master. Il s’agit d’une question fréquemment posée et d’un concept qui doit être renforcé.
Etablir les objectifs du produit
L’une des responsabilités du Product Owner est de développer et de communiquer explicitement les objectifs du produit.
Compte tenu de la nature collaborative de Scrum, ces objectifs ne devraient idéalement pas être imposés aux autres, mais être le résultat d’une co-création autour d’une vision du produit.
La vision du produit définit le scénario futur à réaliser avec le produit. Cette vision est typiquement utopique et inspirante et fixe la direction, mais elle n’aide guère à mesurer les progrès. La vision du produit ne fait pas partie du cadre de Scrum.
À partir de la vision, le PO doit établir la stratégie de création du produit. Dans cette stratégie, il/elle exposera les différents objectifs du produit à atteindre. Les objectifs du produit font partie du cadre de Scrum.
Nous pourrions alors en déduire que lorsque nous parlons d’objectifs de produit, nous parlons de différents jalons commerciaux mesurables qui, lorsqu’ils sont enchaînés, déterminent la stratégie du produit en fonction de la vision.
La vision, la stratégie et les objectifs sont le fruit d’un travail de collaboration entre les parties prenantes et les membres de l’équipe Scrum.
Déterminer l’ordre dans lequel le travail est effectué.
Tout ce qui fait partie du Backlog de produit est ordonné. L’ordre est très précis pour les choses prioritaires qui seront transformées en un Incrément à court terme.
Il n’y a guère de raison d’accorder une grande précision à l’ordre des éléments moins prioritaires qui seront travaillés à moyen terme, car tout effort déployé pour classer ces éléments avec précision devra très probablement être réinvesti lorsqu’on découvrira que les priorités doivent être modifiées en fonction du retour d’information ou de l’apprentissage.
À long terme, les éléments du Backlog de produit n’ont absolument aucun sens d’être classés. Au fur et à mesure que vous vous rapprocherez d’eux dans le temps, dans les Refinements, vous les ordonnerez plus précisément.
Assurer la compréhension du Backlog de produit
Le Product Owner fait partie de l’équipe Scrum, il est en contact permanent avec le reste de l’équipe. S’il travaille à distance, il est accessible à tout moment. S’il travaille en face à face, il est assis avec les développeurs. Dans les deux cas, il travaille côte à côte avec le reste de l’équipe Scrum tout au long du Sprint.
Sa responsabilité consiste à s’assurer que tout le monde a la même compréhension du Backlog de produit. Cela ne signifie pas documenter les exigences en détail, mais parler et vérifier pendant le Sprint que l’incrément en cours de création répond aux attentes.
En même temps, il coordonne et facilite les activités que nous appellerons « raffinement », où les parties prenantes, les développeurs et le PO participent activement à la définition du produit à moyen terme et à sa compréhension détaillée à court terme.
Visibiliser le Backlog de produit
Le Product Owner est chargé de rendre le Product Backlog accessible et connu de toutes les personnes concernées, qu’il s’agisse des membres de l’équipe Scrum, des parties prenantes ou de toute autre personne de l’organisation.
Cela ne signifie pas que tout le monde peut le modifier, rappelez-vous que seul le PO a le pouvoir de modifier le Backlog de produit, mais il doit y donner accès, afin d’être informé. Par exemple, quel que soit l’outil utilisé pour stocker le Product Backlog, qui peut être Excel, Google, Trello, Monday, Jira, etc., il n’y a pas de restriction d’accès et dans chaque communication/courriel il est utile d’inclure dans le pied de page un lien pour visualiser le Product Backlog.
Dans l’exercice de son rôle au sein de Scrum, le PO est censé gérer efficacement les variables commerciales impliquées et avoir une connaissance approfondie des problèmes que le produit entend résoudre pour les utilisateurs. En bref, le Product Owner est responsable du succès du produit.
Développeurs Scrum
Enfin, parmi les rôles de Scrum, nous trouvons également ceux qui ont la responsabilité de développeurs au sein de l’équipe Scrum. Les développeurs sont les membres de l’équipe qui créent l’incrément de sprint.
Il est intéressant de noter que les développeurs étaient auparavant connus sous le nom d’équipe de développement, mais cette terminologie a été mise à jour pour devenir les développeurs car, en réalité, l’équipe Scrum ne fait qu’un.
Parmi les trois rôles de Scrum, tout comme le Scrum Master est un expert de Scrum et le Product Owner est un expert de la vision et de la stratégie du produit, il n’y a pas d’ensemble prédéterminé de compétences spécifiques pour les développeurs, car cela dépend du type d’industrie et de produit qu’ils créent.
Outre les compétences techniques qu’ils doivent posséder, qui varient en fonction de l’industrie dans laquelle ils travaillent, certaines responsabilités sont inaliénables.
Créer le plan de sprint
En principe, les Devs sont responsables de la création du plan de chaque Sprint. Pour créer ce plan, ils doivent d’abord estimer le travail à faire, identifier la part de ce travail qu’ils peuvent faire dans le Sprint en question, décomposer ce travail en différentes tâches et donner une certaine cohérence à tout ce travail.
Ce plan sera reflété dans le Backlog du Sprint, il n’est pas gravé dans la pierre et évoluera au cours du Sprint en fonction des enseignements qui en seront tirés.
Ne livrez que ce qui est « terminé ».
Deuxièmement, les développeurs doivent s’engager à respecter les normes de qualité supposées par tous et consignées dans la définition de l’achèvement.
Personne ne peut leur demander de modifier ces critères afin de terminer plus rapidement ou de livrer plus de produit. Ils doivent défendre la qualité de leur travail comme non négociable. L’incrément de chaque sprint doit être aligné sur cette définition de l’achèvement.
Par respect pour votre propre travail, vos coéquipiers et les parties prenantes, vous ne livrerez rien qui ne soit pas terminé.
Adapter le plan fréquemment
Troisièmement, les développeurs de l’équipe Scrum sont chargés d’examiner au jour le jour la progression vers l’objectif du sprint avec les autres développeurs. Il est de leur responsabilité commune de détecter les déviations et de prendre les décisions nécessaires pour adapter le plan des prochaines 24 heures afin de corriger toute éventualité.
Les développeurs ont la responsabilité de décider eux-mêmes de la meilleure façon de travailler, c’est-à-dire de la façon dont ils vont atteindre l’objectif du sprint, et de participer à toutes les réunions qui ont lieu dans le cadre du sprint de travail Scrum.
Je m’appelle Marc. J’ai toujours été passionné par l’informatique depuis mon plus jeune âge… et la création d’Internet ! 😜 J’en ai fait mon métier puisque je travaille dans une agence de webmarketing aujourd’hui. J’adore également partagé autour de moi mes connaissances. Ce qui fait que j’ai énormément de questions de mes clients et de mes proches… Quoi de mieux qu’un blog pour lister ses interrogations et y répondre pour que cela serve au plus grand nombre !