Un travail d’équipe Scrum coordonné
Scrum, le cadre de gestion Agile le plus répandu, est né d’un article de la Harvard Business Review de 1986 publié par Hirotaka Takeuchi et Ikujiro Nonaka. Dans leur article, H. Takeuchi et I. Nonaka présentaient le terme « Scrum » en décrivant les stratégies collaboratives auxquelles les équipes de rugby avaient recours pour marquer des points et suggéraient que les équipes de développement de produits pourraient utiliser des méthodes similaires pour améliorer leurs taux de réussite.
L’étude présentée dans l’article indiquait que les petites équipes auto-organisées enregistraient de bien meilleurs résultats sur des produits complexes lorsqu’on leur donnait des objectifs à atteindre mais qu’on les autorisait à déterminer comment les atteindre par elles-mêmes.
Dans les années 1990, Ken Schwaber et Jeff Sutherland ont développé le cadre Scrum et formalisé les rôles des membres de l’équipe Scrum. En 1995, ils ont publié un article intitulé « Scrum Software Development Process » (Processus de développement des logiciels Scrum). Après avoir progressivement amélioré Scrum et publié d’autres articles, K. Schwaber et J. Sutherland ont terminé la première publication du Guide Scrum en 2010.
Le Guide Scrum décrit Scrum et les rôles d’équipe comme un « cadre qui permet aux gens de résoudre des problèmes adaptatifs complexes tout en fournissant de manière productive et créative des produits de la plus haute valeur possible. ... Le cadre Scrum comprend les équipes Scrum et leurs rôles, événements, artefacts et règles associés ».
Le Guide Scrum décrit les rôles des membres de l’équipe comme suit : « l’équipe Scrum se compose d’un product owner, de l’équipe de développement et d’un Scrum master. Les équipes Scrum sont auto-organisées et transversales. Les équipes auto-organisées choisissent la meilleure manière d’accomplir leur travail plutôt que d’être dirigées par des personnes extérieures à l’équipe. Les équipes transversales disposent de toutes les compétences nécessaires pour accomplir leurs activités sans avoir à faire appel à d’autres personnes qui ne font pas partie de l’équipe. Le modèle d’équipe Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité. Les équipes Scrum livrent les produits de manière itérative et progressive, ce qui optimise les opportunités de recevoir des commentaires ».
K. Schwaber et J. Sutherland ont publié une édition actualisée du Guide Scrum en juillet 2016. L’ajout le plus intéressant à l’édition 2016 est la section Les valeurs Scrum, qui évoque les interactions des membres des équipes Scrum les uns avec les autres et avec d’autres membres du personnel de l’entreprise.
Guide de la gestion de projets
Votre guichet unique pour la gestion de projets
Prêt à tirer le meilleur parti de vos efforts de gestion de projet ? Consultez notre guide complet de la gestion de projet pour obtenir des conseils, des bonnes pratiques et des ressources gratuites afin de gérer votre travail plus efficacement.
Recommandations sur la taille de l’équipe Scrum
Les experts proposent souvent des conseils sur la taille de l’équipe idéale pour obtenir l’équipe Scrum la plus cohérente et optimiser le niveau de collaboration au sein du groupe. K. Schwaber, qui propose une formation Scrum par le biais de son organisation Scrum.org, formule des recommandations sur la taille de l’équipe dans son ouvrage de 2007, The Enterprise and Scrum. Schwaber explique que les équipes Scrum doivent être « de taille limitée afin d’optimiser la vitesse, le contenu, l’exactitude et l’ampleur des communications. La taille de l’équipe est de neuf personnes maximum ».
Plus loin, l’ouvrage de K. Schwaber offre le conseil suivant : « Faites en sorte que la taille de l’équipe soit aussi proche que possible de sept. On peut penser que sept esprits soient capables d’atteindre et de maintenir un modèle mental partagé d’un système et de sa représentation dans la conception et le code sans aides artificielles telles que la documentation. Les malentendus et le temps d’enregistrement sont minimisés ».
Mindi Schnase, chef de projet chez Renown Health, possède une certification CSM (Certified ScrumMaster) délivrée par la Scrum Alliance et une certification PMP (Project Management Professional) délivrée par le PMI (Project Management Institute). Chez International Game Technology (IGT), son précédent employeur, M. Schnase avait travaillé comme ingénieure principale en assurance qualité avant d’accepter un poste de Scrum master. M. Schnase a travaillé avec des équipes Scrum de différentes tailles.
M. Schnase affirme qu’une équipe de sept à neuf personnes reste adéquate et gérable, mais elle explique également que la taille de l’équipe doit dépendre des caractéristiques du projet. « Cela dépend vraiment de la portée du projet. J’ai été Scrum master pour plusieurs équipes ; l’une était composée de trois membres, tandis que d’autres en comptaient sept à dix ».
J. Sutherland, qui anime toujours des formations Scrum par l’intermédiaire de Scrum Inc., propose de nombreuses informations sur la dynamique d’équipe sur le site Web de son organisation, y compris l’analyse suivante concernant les tailles des équipes et la productivité :
«
Lawrence Putnam, une véritable légende du développement de logiciels, a passé sa vie à étudier combien de temps les choses prenaient et pourquoi. Son travail a démontré à maintes reprises que les projets comptant vingt personnes ou plus travaillaient plus laborieusement que les équipes composées de cinq membres ou moins. Beaucoup, beaucoup plus... Il a donc examiné 491 projets de taille moyenne dans des centaines d’entreprises différentes. Tous ces projets portaient sur la création de nouveaux produits ou fonctionnalités, et non sur la refonte d’anciennes versions. En divisant les projets par tailles d’équipes, il a immédiatement constaté que les équipes de plus de huit personnes mettaient beaucoup plus de temps à réaliser leurs activités. Pour effectuer la même quantité de travail, les groupes composés de trois à sept personnes fournissent environ 25 % des efforts des groupes de neuf à vingt ».
En termes de taille de l’équipe, les experts semblent s’accorder sur un nombre magique : sept membres constitueraient l’équipe idéale. Cependant, n’ayez pas peur d’ajuster le nombre de membres en fonction de projets spécifiques.
Les flux de travail et événements Scrum rendent les équipes Scrum plus efficaces
Des équipes de tous types et tailles participent à un flux de travail particulier lorsqu’elles prennent la décision d’appliquer Scrum dans le cadre de la gestion de projets Agile. Les événements Scrum ont un but précieux : ils encouragent les communications régulières, en particulier entre les membres de l’équipe, et minimisent le recours aux réunions complémentaires non définies dans Scrum.
Sans intégrer les événements Scrum à leur emploi du temps, les équipes ne seraient pas aussi efficaces ni concentrées. La liste suivante représente le flux de travail typique que les membres des équipes Scrum utilisent pour le développement de produits.
Vision du produit – Le product owner s’appuie sur des commentaires issus de diverses sources, y compris les utilisateurs finaux, les clients, les membres de l’équipe et d’autres parties prenantes pour résumer la vision du produit dans un énoncé de vision. L’énoncé de vision du produit comprend des informations sur l’analyse de rentabilité au regard des objectifs du produit et la façon dont le produit s’inscrit dans les stratégies de l’entreprise.
Backlog produit et affinement - Les éléments du backlog produit représentent tout ce qui peut être livré pour un projet de manière indépendante. La plupart de ces éléments se concentrent sur la fourniture de valeur aux clients, les fonctionnalités des produits et les récits d’utilisateurs. (Les récits d’utilisateurs présentent des scénarios spécifiques et détaillés pour expliquer ce que les utilisateurs pourraient accomplir s’ils se dotaient d’une nouvelle fonctionnalité). Les backlogs produits peuvent également inclure les exigences commerciales, les spécifications, les cas d’utilisation et d’autres éléments.
Le product owner hiérarchise les éléments du backlog produit en fonction de la valeur commerciale que chaque élément représente. En général, 80 % de la valeur d’un produit réside dans 20 % de ses fonctionnalités. L’attribution d’une valeur commerciale permettant de hiérarchiser les éléments du backlog produit garantit que les fonctionnalités ayant le plus de valeur sont créées en premier. Les éléments apparaissant en haut du backlog produit sont bien définis et inclus dans un sprint à venir ; les autres éléments doivent être affinés lors d’une réunion d’affinement du backlog produit.
Certains product owners et équipes de développement organisent une réunion d’affinement du backlog produit vers le milieu ou la fin du sprint actuel afin d’affiner davantage les éléments du backlog produit pour les sprints futurs. D’autres équipes Scrum traitent l’affinement comme un processus continu.
Exécution de sprints efficaces : Les deux étapes suivantes servent à aider les équipes à exécuter des sprints efficaces. Un sprint (parfois appelé itération de longueur fixe) représente la période pendant laquelle les équipes effectuent une seule itération de travail avant de se réunir et de se préparer pour la prochaine. C’est un élément majeur de la gestion de projets Agile.
- Planification de sprint – Le product owner, le Scrum master et l’équipe de développement se réunissent au cours d’une session de planification de sprint pour choisir les éléments du backlog produit pour le sprint à venir et s’engager à atteindre un objectif. Les membres de l’équipe de développement sélectionnent les éléments apparaissant en haut du backlog produit jusqu’à ce qu’ils aient assez de travail pour remplir le calendrier du sprint. Les éléments sélectionnés sont déplacés vers un backlog de sprint.
- Backlog de sprint et tableau Scrum - Tous les éléments du backlog de sprint doivent être terminés à la fin du sprint. Pour conférer un sentiment de responsabilité partagée, les éléments sont placés dans l’une des colonnes, généralement étiquetées À faire, Travail en cours (TEC) et Terminé, sur un tableau Scrum physique ou numérique (tableau des tâches). Le tableau Scrum doit être consultable par l’ensemble de l’équipe, et les éléments associés (souvent indiqués comme des tâches ou récits d’utilisateurs sur des notes adhésives) doivent refléter le statut du sprint en temps réel. Le respect de cette ligne directrice permet à l’équipe d’apporter des ajustements en cas de retard de l’un des éléments.
Sprint - Les sprints durent une à quatre semaines. Chaque sprint représente un cycle de développement bref et aboutit soit à un incrément de produit (officiellement dénommé « incrément de produit potentiellement livrable »), soit au produit fini. Les équipes ne sont pas toujours en mesure d’accomplir un incrément de produit susceptible d’être expédié, surtout au début ; cependant, l’équipe doit s’efforcer de le faire au fur et à mesure qu’elle s’améliore au fil du temps.
Scrum quotidien - Au cours de chaque sprint, les membres de l’équipe de développement participent à des réunions générales quotidiennes dénommées « Daily Scrum ». Les réunions durent au minimum 15 minutes car les participants ne font que répondre à trois questions de base : 1) Qu’est-ce qui a été accompli depuis la dernière réunion ?, 2) Qu’est-ce qui sera accompli avant la prochaine réunion ?, et 3) Quels obstacles se dressent sur le chemin ?
L’objectif de ces réunions est de donner à l’équipe de développement l’occasion de coordonner ses efforts, de synchroniser le travail et de signaler les obstacles (problèmes technologiques, obstacles du service, etc.). Ce n’est pas le type de réunion au cours de laquelle les employés rendent compte de leurs progrès à leur responsable. Le Scrum master peut participer à ces réunions pour savoir quels obstacles il doit résoudre, mais le product owner n’y participe généralement pas.
Réunion Scrum of Scrums - Une déclaration de Mike Cohn , instructeur Scrum sur le site Web de la Scrum Alliance, décrit la réunion Scrum of Scrums comme « une technique très utile pour mettre Scrum à l’échelle dans de grandes équipes de projet. Ces réunions permettent aux groupes d’équipes de discuter de leur travail, en se concentrant en particulier sur les domaines de chevauchement et d’intégration. Imaginez un projet parfaitement équilibré comprenant sept équipes, chacune avec sept membres d’équipe. Chacune des sept équipes organiserait (simultanément ou tour à tour) sa propre réunion Scrum quotidienne (Daily Scrum). Chaque équipe désignerait ensuite une personne pour assister à une réunion Scrum of Scrums ».
Lors des réunions Scrum of Scrums animées par M. Schnase, les participants comprenaient des Scrum masters, des product owners, des responsables techniques ainsi que des responsables de l’assurance qualité, des sponsors de programmes et des chefs de service directement liés aux projets des équipes Scrum. « Tous les quinze jours, nous organisions un Scrum of Scrums pour discuter des réalisations, des jalons, de la progression, des interdépendances et des obstacles », explique M. Schnase.
Évaluation du sprint - À la fin de chaque sprint, l’équipe effectue une évaluation du sprint (également dénommée « évaluation d’itération » ou « démonstration de sprint ») pour démontrer les fonctionnalités du produit créées pendant le Sprint aux parties prenantes, c’est-à-dire aux personnes directement affectées par le résultat du produit. Les évaluations de sprint, ou démonstrations de sprint, constituent également une opportunité précieuse de démontrer le produit aux personnes qui utilisent le logiciel et peuvent fournir des commentaires immédiats.
Rétrospective du sprint - Après l’évaluation du sprint, l’équipe Scrum participe à une réunion rétrospective pour évoquer les qualités et défauts du sprint et planifier des améliorations. La rétrospective a également pour objectif de développer davantage le processus et les pratiques appliqués par l’équipe Scrum et de les rendre plus efficaces pour le prochain Sprint.
L’équipe trouve également des moyens d’améliorer la qualité du produit et, si nécessaire, de modifier certains éléments en fonction de la définition de « terminé ». « The Basics of Scrum » sur Scrum Inc. définit la notion de « terminé » comme suit : « Un élément du backlog est prêt s’il est indépendant et exploitable, s’il a reçu un nombre de points et s’il est associé à une définition claire des critères indiquant qu’il est terminé. C’est ce qu’on appelle « la définition de « terminé » ». Elle garantit que tout le monde sait exactement ce que l’on attend d’un élément lors de sa livraison ».
Modèle Scrum de développement d’équipe
M. Schnase explique qu’il est important, pour établir une équipe Scrum efficace, que tout le monde travaille avec passion et adopte une attitude positive vis-à-vis du processus afin d’assurer une bonne collaboration entre les membres de l’équipe. Différents supports Scrum évoquent le modèle de développement de groupe de Bruce Tuckman comme une méthode efficace à appliquer lors de la mise en place d’une équipe Scrum ou de l’ajout de nouvelles personnes à l’équipe. L’article de Bruce Tuckman, intitulé « Developmental sequence in small groups » et publié en 1965 dans Psychological Bulletin, indique que les nouvelles équipes doivent passer par différentes étapes avant d’atteindre un niveau de performance élevé et d’obtenir des résultats optimaux. Bruce Tuckman a intitulé ces étapes Forming (Former), Storming (S’affairer), Norming (Normaliser) et Performing (Performance).
Le nom de chaque étape du modèle de développement de groupe de Bruce Tuckman reflète avec précision la dynamique d’équipe au cours de cette période particulière.
Forming (Former) – Selon Bruce Tuckman, cette étape est axée sur l’orientation, les tests et la dépendance. Les membres de l’équipe ne se connaissent pas encore et considèrent toujours leur travail comme une série de tâches individuelles plutôt que comme un effort de collaboration de l’ensemble de l’équipe. Souvent, les séances de team building et les déjeuners de groupe aident l’équipe à se sentir plus à l’aise.
Storming (S’affairer) – Au cours de l’étape Storming, les membres de l’équipe campent généralement sur leurs opinions et résistent à l’influence de l’équipe à différents égards, ce qui provoque souvent des conflits intragroupe. Au cours de l’étape Storming, les membres de l’équipe sont encouragés à accepter les différences au sein de l’équipe, mais la diversité peut entraîner une profusion d’idées et une productivité accrue. Pour passer à l’étape suivante, les membres de l’équipe doivent être rassurés quant aux exigences liées à leur travail et à leurs tâches. Au fur et à mesure que la confiance et la stabilité s’installent, il deviendra plus facile de résoudre les conflits.
Norming (Normaliser) – Lorsque l’équipe atteint le stade de la normalisation, les membres ont déjà des domaines d’accord bien établis et sont parvenus à un consensus. Des lignes directrices claires ont été établies concernant les rôles individuels, ce qui a donné lieu à une nouvelle situation caractérisée par la transparence et la cohésion entre les membres. L’objectif de cette étape est de favoriser la collaboration pour élaborer des normes de groupe et débattre d’idées et d’interprétations pertinentes.
Performing (Performance) – À l’étape Performance, le groupe acquiert une vision unifiée, une énergie collective et une raison d’être. L’équipe a appris à bien fonctionner collectivement et à résoudre les problèmes de manière positive et diplomatique. Selon Bruce Tuckman, les rôles sont devenus flexibles et fonctionnels, et la structure d’équipe peut prendre en charge un niveau de performance plus élevé.
M. Schnase recommande de prendre en compte le modèle de B. Tuckman lorsque de nouveaux venus sont intégrés à une équipe Scrum car la présence d’un nouveau membre change la dynamique de l’équipe. Selon elle, l’équipe passe par les étapes Forming, Storming, Norming et Performing à chaque fois qu’elle change. « Le rythme de travail ralentit lorsque vous ajoutez un nouveau membre, vous devez donc en tenir compte ».
M. Schnase a également proposé une autre raison pour laquelle les rétrospectives Sprint sont efficaces. « Les rétrospectives sont importantes car l’équipe doit réfléchir aux points positifs et aux éléments qu’elle pourrait améliorer. Elles aident l’équipe à passer au stade Performing ».
Formation initiale d’équipes Scrum
Comme pour la plupart des modèles de développement, il faut du temps pour obtenir des résultats ; il en va de même pour les équipes Scrum. Une nouvelle équipe ne génère pas immédiatement des résultats supérieurs. Le temps nécessaire pour qu’une équipe atteigne l’étape Performing dépend de ses membres et d’autres facteurs, y compris sa cohésion. Par conséquent, le team building est impératif.
« Le team building initial est bénéfique pour établir des relations de confiance et pour permettre à tous les membres de l’équipe de constater les points forts des autres membres », explique M. Schnase. « Il faut du temps pour développer une équipe ».
Le secret du team building consiste à trouver une activité qui sera intéressante et amusante pour tout le monde, et à proscrire les exercices maladroits de team building auxquels personne n’aime assister. Préparez une liste d’activités d’équipe potentielles et demandez aux membres lesquelles ils apprécient tout en sollicitant des suggestions supplémentaires. Vous pouvez envisager une excursion pour permettre aux membres de faire connaissance à l’extérieur du bureau, comme une sortie dans un musée ou un match sportif dans votre région, une initiative de bénévolat de groupe ou un simple déjeuner d’équipe pour renforcer les liens entre les membres de l’équipe. En outre, la participation collective à un atelier de formation Scrum, en particulier un atelier qui comprend des sessions en sous-groupes, vous aidera à analyser les points forts individuels qui profiteront à l’ensemble de l’équipe.
Équipes Scrum en télétravail ou équipes Scrum co-localisées
Il est difficile d’organiser un événement de team building lorsque les membres de l’équipe sont situés dans différentes villes, et encore plus dans différents pays. M. Schnase a travaillé avec des membres d’équipes Scrum dans le monde entier. Contrairement aux experts qui recommandent d’établir uniquement des équipes colocalisées car il est souvent plus facile de développer la cohésion et la confiance lorsque les employés travaillent ensemble au même endroit, M. Schnase déclare que ce type de configuration n’est pas toujours réalisable.
Dans le cadre de ses fonctions au sein d’IGT, par exemple, M. Schase travaillait avec des membres d’équipes Scrum en Australie et en Chine ainsi que dans différentes villes des États-Unis. Selon elle, il est possible de trouver des solutions même si les différences de fuseau horaire peuvent compliquer les choses, en particulier pour les réunions de groupe.
Dans ces situations, le processus de team building peut avoir lieu en ligne par visioconférence. Certaines entreprises ont compris l’intérêt de réunir les membres de l’équipe dès le départ et sont prêtes à payer pour faire en sorte que l’équipe se réunisse dans un lieu central à des fins de formation ou à de team building. Si c’est le cas de votre employeur, nous vous conseillons de demander aux membres de l’équipe Scrum s’ils ont envie de se réunir lors d’une conférence de formation Scrum, par exemple. Si tout le monde acquiesce, proposez cette option à votre employeur.
Rôles, responsabilités et qualités à rechercher pour les membres de l’équipe Scrum
Les premiers développeurs Scrum ont imaginé des rôles d’équipe Scrum au sein d’une structure auto-organisée similaire à celle que les équipes de rugby utilisent pour passer un ballon et fouler le terrain en tant qu’unité cohérente. La structure d’équipe Scrum est désormais un modèle éprouvé que les équipes de développement de produits doivent appliquer pour obtenir des résultats continus, coordonnés et fiables.
Une équipe Scrum équilibrée comprend :
- un product owner qui promeut la vision du produit et hiérarchise les différents éléments du backlog produit afin d’optimiser les fonctionnalités et la valeur du produit pour le client ;
- un Scrum master qui coache efficacement l’équipe de développement, organise les événements et élimine les distractions qui entravent la progression de l’équipe ;
- et les membres de l’équipe de développement qui se concentrent sur l’achèvement des livrables par incréments (fonctionnalité de produit terminée à la fin de chaque sprint) et la production d’un produit final de qualité supérieure.
J. Sutherland et K. Schwaber soulignent qu’il existe de bonnes raisons de définir des rôles Scrum spécifiques et que la combinaison de ces rôles entraîne souvent une diminution de la productivité. Les employeurs doivent également reconnaître que les équipes sont beaucoup plus productives et stables lorsque leurs membres ne se concentrent que sur un produit par sprint et ne sont pas tenus de travailler sur plusieurs produits ou avec d’autres équipes.
Dans les sections suivantes, nous examinons les responsabilités et qualités à rechercher pour chaque poste afin de faciliter l’évaluation des candidats par les responsables du recrutement.
Rôle de responsable de produit
Le Guide Scrum décrit le rôle de product owner comme étant responsable d’« optimiser la valeur du produit et du travail de l’équipe de développement ». En d’autres termes, le product owner est responsable de la livraison d’un produit de qualité qui optimise le retour sur investissement (RSI) de l’organisation. Ses autres responsabilités incluent la compréhension et l’explication des attentes du client pour un produit ainsi que la gestion du backlog produit, une liste hiérarchisée des fonctionnalités du produit.
M. Schnase explique que le product owner doit avoir un type de personnalité qui lui permette de « confier à l’équipe des exigences et des objectifs globaux pour le produit, tout en la laissant libre de déterminer comment atteindre ces objectifs ».
Généralement, les product owners ont de l’expérience dans la gestion de produits ou de projets, le marketing ou la conception d’expériences utilisateur (UX). Leur expérience recouvre souvent l’analyse des attentes des clients, des produits des concurrents, des demandes du marché et des tendances futures pour le type de produit en cours de développement. Leurs diplômes varient en fonction du type de produit, d’entreprise et d’industrie. Plus important encore, le product owner doit avoir une vision forte et une certaine connexion avec le produit.
Voici une liste de responsabilités qui doivent figurer dans la fiche de poste du product owner pour assurer sa réussite dans ce poste.
- Développe la vision du produit et met l’accent sur les attentes du client – Le product owner doit être capable d’évaluer les informations provenant de diverses sources, de développer une vision du produit et de promouvoir cette vision. Le product owner doit être en mesure de présenter des messages clés concernant le produit qui trouveront un écho auprès des membres de l’équipe Scrum, des parties prenantes et d’autres personnes au sein de l’organisation. Il est particulièrement important que le product owner représente le point de vue du client lorsqu’il explique le produit et la manière dont ses fonctionnalités nouvelles ou améliorées dépasseront les attentes.
- Tient compte des aspects commerciaux du développement de produits – Les product owners doivent avoir le sens des affaires, comprendre les besoins de l’entreprise, notamment en matière de développement de produits et reconnaître l’importance du calendrier, des conditions de marché positives et des décisions basées sur les préoccupations budgétaires et le retour sur investissement. Les product owners doivent également faire preuve d’un sens stratégique lors du développement de plans de lancement de produits et de la promotion du produit à plusieurs niveaux, que ce soit sur le marché, à la haute direction ou à l’équipe Scrum.
- Motive l’équipe en énonçant des objectifs clairs et inspirants – Un product owner doit discuter des exigences et objectifs globaux de chaque projet avec l’équipe de développement, répondre à toutes les questions et laisser l’équipe déterminer comment répondre à ces attentes. Le product owner est chargé de hiérarchiser les éléments du backlog produit, mais ce sont les membres de l’équipe de développement qui décident de la quantité de travail à accomplir pendant chaque sprint et du nombre de sprints nécessaires. Par conséquent, le product owner doit avoir la capacité de motiver les membres de l’équipe sans essayer de les contrôler.
- Optimise la valeur des produits et la progression de l’équipe de développement – Cette responsabilité globale souligne à quel point il est essentiel pour le product owner d’identifier les fonctionnalités du produit qui sont actuellement les plus importantes et figurent en haut de la liste des priorités pour le prochain sprint. Pour bien s’en acquitter tout au long du processus de développement de produits, le product owner doit affiner et réorganiser en permanence les éléments du backlog produit. Les éléments du backlog produit ou, plus spécifiquement, les fonctionnalités du produit et les récits d’utilisateurs, doivent être hiérarchisés en fonction de la valeur que chacun apporte au produit. Certains experts vont plus loin en affirmant que la valeur représente un compromis entre valeur commerciale la plus élevée et éléments de coût les plus faibles ; cependant, il est parfois nécessaire de satisfaire des clients clés et d’analyser d’autres facteurs stratégiques pour l’entreprise.
- Hiérarchiser et gérer les éléments du backlog produit – Seuls responsables du backlog produit, les product owners expérimentés reconnaissent les interdépendances à prendre en compte et à évaluer correctement. Les product owners les plus efficaces comprennent la nécessité d’être sélectifs sur les demandes de changement ou de nouvelles fonctionnalités. Ils savent qu’ils ne peuvent pas tout accepter s’ils veulent s’assurer que les autres aspects du développement de produits restent en phase avec les exigences en matière de valeur commerciale et d’attentes réalistes. Savoir quand dire « non » est un élément important du travail.
- Affine régulièrement le backlog produit – Pour s’assurer que l’ensemble de l’équipe comprend chaque fonctionnalité répertoriée dans le backlog produit, le product owner clarifie les descriptions, explique leur niveau d’importance et demande à l’équipe s’il lui reste des questions. En outre, ces informations contribuent à garantir l’engagement de l’équipe envers un produit de haute qualité qui correspond aux attentes du client. Même si certains product owners demandent aux membres de l’équipe de développement d’ajouter des spécifications techniques et d’autres détails similaires au backlog produit, le temps consacré à ces tâches doit être maintenu au minimum.
- Présente des récits d’utilisateurs qui se concentrent sur les fonctionnalités du produit – L’équipe de développement est responsable du backlog de sprint déterminé lors de la réunion de planification du sprint, mais le product owner est responsable des récits d’utilisateurs, qui sont des descriptions de fonctionnalités énoncées du point de vue de l’utilisateur. Certains product owners créent la plupart des récits d’utilisateurs eux-mêmes, tandis que d’autres font participer toute l’équipe au processus.
- Reste impliqué dans le travail d’équipe et disponible en permanence – L’engagement à livrer le meilleur produit possible doit s’appuyer sur un engagement actif avec l’équipe. Les product owners mettent l’accent sur leur disponibilité auprès de l’équipe et utilisent leurs compétences en communication pour développer des relations solides.
- Élargit ses connaissances grâce au réseautage – Les product owners doivent comprendre pourquoi il est nécessaire de réseauter avec d’autres acteurs de leur industrie en participant régulièrement à des conférences et des ateliers. C’est un excellent moyen d’acquérir des connaissances en écoutant ce que les autres ont à dire sur les techniques de modélisation commerciale, les enseignements tirés, les expériences de réussite des produits, etc.
Le rôle de Scrum master
Il incombe au Scrum master de s’assurer que l’équipe Scrum comprend et suit les pratiques et règles Scrum. Outre cette responsabilité, le Scrum master s’assure que les autres membres de l’organisation respectent suffisamment la théorie Scrum pour limiter les distractions auxquelles l’équipe Scrum doit faire face et accepter les commentaires concernant les interactions susceptibles d’entraver les progrès de l’équipe.
En tant que coach d’une équipe et organisateur de projets complexes, le Scrum master apporte de la valeur en éliminant autant d’obstacles que possible pour permettre à l’équipe de développement de rester concentrée sur ses objectifs. M. Schnase a déclaré que les Scrum masters devaient aider leur équipe en supprimant, au besoin, les obstacles et les blocages. « Si quelqu’un ne peut accéder à un dossier sur le réseau dont il a besoin ou si l’environnement de test est en panne, les Scrum masters peuvent l’aider à faire remonter et à résoudre ces problèmes », explique M. Schnase. « En plus de se montrer persuasifs et enthousiastes, les Scrum masters doivent être en mesure de communiquer avec n’importe quelle partie prenante »
Les Scrum masters sont issus de divers milieux et disciplines universitaires, y compris la conception, l’ingénierie, l’informatique, le marketing, la gestion de produits ou de projets, l’assurance qualité et les tests. Ils affichent des qualités telles que l’humilité, la persévérance et la fidélité et justifient d’une large base de connaissances et de solides compétences en leadership qui leur permettent d’être d’excellents organisateurs et négociateurs capables de résoudre les conflits. Les Scrum masters doivent également maintenir leur engagement envers Scrum, quelle que soit la pression qu’ils subissent de la part d’autres sources.
Pour assurer en permanence un bon niveau de performance, les Scrum masters doivent prendre de multiples responsabilités et posséder différentes qualités personnelles, comme le démontre la liste détaillée ci-dessous.
- Assume les fonctions de dirigeant-serviteur - Un véritable dirigeant-serviteur a conscience que l’équipe doit disposer des ressources nécessaires pour fournir des résultats au client d’une manière qui réponde aux objectifs commerciaux de l’entreprise. À cet égard, le Scrum master dessert plusieurs groupes simultanément : les membres de l’équipe, le client et l’entreprise. Selon le Guide Scrum, le rôle du Scrum master recouvre des responsabilités spécifiques en matière de services au product owner, à l’équipe de développement et à l’organisation. Le Scrum master, qui donne l’exemple, est le type de personne que les autres membres de l’équipe veulent imiter. Un Scrum master inspirant encourage les autres à croire en leurs capacités et à développer leur potentiel, même lorsque les choses ne se passent pas comme prévu.
- Assume ses responsabilités sans revendiquer le pouvoir - Dans son article de blog intitulé « Leader of the Band », M. Cohn donne la définition suivante de la responsabilité sans pouvoir : « Sans se croire responsable de la réussite du projet (c’est l’équipe qui en est responsable), le Scrum master assume la responsabilité de l’adoption de Scrum par l’équipe et de sa pratique. Un Scrum master assume cette responsabilité sans revendiquer aucun des pouvoirs qui pourraient s’avérer utiles pour y parvenir ».
Dans un autre article intitulé « Advice for Interviewing Scrum masters », M. Cohn a clarifié cette attente en affirmant : « Un chef d’orchestre a expliqué une fois qu’il n’avait pas de pouvoir réel sur la manière dont les musiciens jouaient. Il ressentait pourtant une responsabilité très importante de les aider à devenir les meilleurs musiciens possibles ».
- Résout les obstacles, et si possible, les évite - Le Scrum master protège le travail de l’équipe de développement en résolvant ou en supprimant les obstacles à chaque fois que cela est possible. Souvent, les membres de l’équipe évoquent un obstacle au Scrum master pendant le Scrum quotidien et expliquent pourquoi cet obstacle peut entraver leur capacité à accomplir leur travail pendant un sprint.
Il ressort des offres d’emploi publiées récemment que les responsables du recrutement préfèrent les Scrum masters qui possèdent des connaissances techniques approfondies et/ou comprennent bien un secteur particulier. Les Scrum masters dotés de ce type de connaissances présentent l’avantage de pouvoir aider leurs équipes à résoudre plus rapidement les obstacles qui donnent lieu à des problèmes techniques.
Certains obstacles dissimulés sous la surface présentent des menaces pour l’efficacité globale de l’équipe, c’est pourquoi un Scrum master observateur, engagé et capable d’éliminer de telles menaces peut s’avérer très précieux. Plus un Scrum master est expérimenté, plus il sera en mesure d’identifier les problèmes potentiels et de les résoudre avant qu’ils ne deviennent des casse-têtes.
- Coache l’équipe sur la manière de s’améliorer - Les Scrum masters coachent leurs équipes en fournissant des exemples basés sur leurs connaissances et leurs expériences et en les guidant pour tirer le meilleur parti de leur potentiel. Ce faisant, ils aident les membres de l’équipe à mieux se comprendre et à mettre en œuvre des pratiques reposant sur l’auto-organisation et les fonctionnalités transversales. Lorsque les Scrum masters encouragent l’auto-organisation, les équipes s’approprient mieux leur travail, prennent des décisions et réalisent des estimations plus facilement et ont davantage l’impression d’atteindre un objectif commun.
M. Cohn fait le parallèle entre le coaching Scrum master et le type d’assistance que fournissent les préparateurs physiques. « Le soutien que vous apportent les Scrum masters est similaire à celui que vous proposent les préparateurs physiques : ils vous aident à respecter un programme d’exercices et à effectuer tous les exercices correctement. Un bon préparateur vous motive tout en s’assurant que vous ne trichiez pas en évitant les exercices les plus difficiles. Le pouvoir du préparateur est toutefois limité. Il ne peut pas vous faire faire un exercice que vous ne souhaitez pas faire. Il vous rappelle plutôt vos objectifs et la manière dont vous avez choisi de les atteindre ».
- Reconnaît et résout les conflits dès que possible – Tous les membres d’une équipe Scrum ont la liberté de s’attaquer aux attitudes peu productives et aux comportements dysfonctionnels, mais les conflits proviennent parfois d’incompréhensions ou de la nécessité de faire des compromis. Dans ces situations, les Scrum masters doivent identifier les conflits entre les membres de l’équipe suffisamment tôt pour les désamorcer avant qu’ils ne produisent trop de dégâts. En outre, les Scrum masters savent que les conflits sont inévitables et pas toujours néfastes. La capacité à surmonter les conflits rendra finalement l’équipe plus forte.
Dans son article de blog intitulé « Advice for Interviewing Scrum masters », M. Cohn explique le rôle que joue l’état d’esprit collaboratif des Scrum masters dans la résolution des conflits. « Un bon Scrum master veille à assurer une culture de la collaboration au sein de l’équipe. Le Scrum master doit mettre les membres de l’équipe à l’aise pour soulever des problèmes et engager une discussion ouverte. En cas de conflit, les Scrum masters collaboratifs encouragent les équipes à réfléchir en termes de solutions qui profitent à tous les participants plutôt qu’en termes de gagnants et de perdants ».
- Organise les événements Scrum – Les meilleurs Scrum masters ont l’air de comprendre instinctivement comment organiser les événements et orienter les gens. En réalité, la plupart des Scrum masters reçoivent ce type de formation en suivant des cours de leadership et/ou en accumulant des années d’expérience. Les personnes qui assistent à leurs événements Scrum apprécient leur préparation et leur capacité à définir des attentes claires.
- Écoute et observe – La aussi, l’équilibre est essentiel. S’ils ont des compétences de communication exceptionnelles, les Scrum masters efficaces savent aussi quand écouter et d’observer. Par « écoute », nous entendons une écoute concentrée et active. Par « observation », nous faisons référence à l’observation de ce qui n’est pas communiqué à haute voix, mais qui se fait sentir en observant de près le langage corporel, les expressions faciales et d’autres indices.
- Agit en tant qu’éducateur et promoteur Scrum – Les Scrum masters s’assurent non seulement que les membres de l’équipe Scrum comprennent et suivent Scrum, mais également que les autres employés liés à leurs équipes comprennent Scrum. Lors de l’adoption du système Scrum par les organisations, les Scrum masters sont les figures de proue qui planifient la mise en œuvre, qui suggèrent des changements permettant d’accroître la productivité de l’équipe Scrum et qui proposent une assistance au cours de la période d’ajustement. Dans les grandes entreprises, cet effort implique parfois de travailler avec d’autres Scrum masters pour augmenter l’efficacité de Scrum.
Lorsqu’ils enseignent Scrum à d’autres personnes, les Scrum masters doivent parfois surmonter le scepticisme de certains en faisant la promotion de Scrum et des résultats obtenus par d’autres entreprises mettant en œuvre le cadre et les principes directeurs Scrum.
- Utilise les compétences politiques d’entreprise pour influencer les autres dans l’ensemble de l’organisation – Les Scrum masters expérimentés savent qu’ils peuvent modifier le comportement des gens en leur donnant une raison de changer la manière dont ils font les choses ou les influencer en ajustant la culture et les conditions dans lesquelles ils évoluent, mais qu’ils ne peuvent pas vraiment changer les gens eux-mêmes. Ces Scrum masters savent également faire preuve de persuasion et motiver les personnes travaillant à différents niveaux au sein d’une organisation car ils comprennent qui prend les grandes décisions, comment exploiter les alliances existantes et comment contourner les personnes les plus susceptibles présenter des obstacles.
Rôle des membres des équipes de développement
Les personnes chargées de créer le produit sont collectivement dénommées « équipe de développement ». Ce groupe comprend généralement des professionnels jouissant d’une expérience et d’une formation en développement de logiciels, conception d’interfaces utilisateur, bases de données, ingénierie des opérations, ingénierie d’assurance qualité, tests, analyse de systèmes et rédaction technique (spécialistes de la documentation). Selon le Guide Scrum, « Scrum ne reconnaît aucun titre pour les membres de l’équipe de développement en dehors de celui de développeur, quel que soit le travail effectué par la personne ; cette règle ne souffre aucune exception ».
La fonction principale de l’équipe de développement consiste à effectuer le travail nécessaire à une succession réussie de sprints et d’incréments de produit, suivie de la livraison d’un produit final de qualité. Pour les embauches au sein de votre équipe de développement Scrum, M. Schnase suggère de rechercher des candidats professionnels prêts à fournir une assistance en matière de tests et à exécuter d’autres fonctions telles que l’automatisation. « Chaque membre de l’équipe doit être disposé à se former et à aider les autres ».
En outre, « The Basics of Scrum », publié par Scrum Inc., évoque l’importance de disposer d’une équipe de développement interfonctionnelle. « En outre, au moins deux personnes de l’équipe doivent être capables d’accomplir n’importe quel élément du backlog produit. Cela permet d’éliminer les interdépendances liées aux compétences d’un membre de l’équipe particulier au cas où il tombe malade, part en vacances ou change de poste ».
La liste suivante évoque les responsabilités partagées par les membres de l’équipe de développement ainsi que les qualités que présentent les meilleurs éléments de l’équipe.
- Offre les fonctionnalités et le niveau de qualité promis – Les employés les mieux adaptés au travail d’équipe Scrum sont les collaborateurs et communicateurs qui s’améliorent constamment au fil de leur mission au sein d’une équipe, sont en mesure de mettre en œuvre les fonctionnalités prévues et fournissent un travail de qualité. Grâce à leurs actions, ils démontrent un fort engagement à atteindre les objectifs et une capacité à prospérer dans un environnement Scrum.
- Cherche véritablement à proposer un produit final que les clients apprécieront – Les membres les plus précieux d’une équipe sont ceux qui connaissent bien leurs clients et se décevraient eux-mêmes s’ils ne fournissaient pas les efforts nécessaires pour dépasser les attentes des clients. Ces employés sont fiers de leur travail et ravis de recevoir des commentaires positifs de la part des clients.
- Aide l’équipe à rester concentrée sur l’achèvement – Les équipes de développement sont responsables de toutes les tâches du backlog de sprint. Les équipes très performantes copient ces tâches dans un tableau Scrum et procèdent fréquemment à des mises à jour pour s’assurer que tout le monde dispose d’une représentation visuelle en temps réel de l’avancement de n’importe quelle tâche. Les colonnes du tableau Scrum doivent indiquer clairement quelles tâches sont terminées et l’état d’avancement des éléments restants. Les membres de l’équipe qui suivent ces lignes directrices éliminent les confusions et s’assurent que l’équipe reste concentrée sur l’avenir.
- Utilise Scrum et d’autres réunions quotidiennes comme outils de communication – Les membres de l’équipe les plus consciencieux savent que leur temps est précieux et limité, et ils respectent de la même manière le temps de leurs collègues. Ils participent au Scrum quotidien et aux autres réunions désignées et se préparent à communiquer dans les délais impartis. Les autres communications avec leurs collègues restent concises et précises.
- Prend des engagements réalistes – Les développeurs qui gèrent leur temps efficacement reconnaissent que chacun doit bénéficier de pauses au cours de sa journée. Nous avons tous besoin de temps pour nous détendre et nous ressourcer, surtout si nous souhaitons favoriser la créativité. Il est donc nécessaire d’intégrer des pauses dans nos calendriers pour planifier adéquatement les imprévus et les urgences. Les développeurs expérimentés le savent et estiment les échéances des différents engagements en conséquence.
- Propose des idées pour les futurs sprints – Tout le monde apprécie les membres de l’équipe qui prennent l’initiative de proposer des options fonctionnelles pour les éléments non traités qu’ils détectent dans le backlog produit. Même si le product owner est responsable du backlog produit, tous les membres de l’équipe peuvent proposer des idées sur la manière d’affiner son contenu. L’amélioration des éléments du backlog produit améliore inévitablement les incréments du produit et le produit final.
- Accueille les opportunités de formation transversale et d’apprentissage continu – Les membres de l’équipe axés sur la croissance sont enthousiastes concernant les opportunités d’apprentissage avancé car ils comprennent l’importance de l’innovation et s’adaptent en permanence à l’évolution rapide de l’environnement technique. Ils sont ouverts au changement et disposés à se former transversalement et à s’engager dans des situations de collaboration. Ils sont également disposés à partager leurs expériences avec d’autres employés et à faire figure de mentors pour les nouveaux membres de l’équipe.
- Combine l’expérience technique et les connaissances commerciales – Les membres de l’équipe de développement qui sont quasiment aussi versés dans les concepts commerciaux que dans la technologie sont précieux sur plusieurs fronts. S’ils peuvent expliquer la technologie au personnel de l’entreprise, ils peuvent également informer les employés des conséquences de la sortie d’un produit qui se concentre trop sur le marketing et pas assez sur les facteurs techniques sous-jacents.
Par exemple, si l’ajout de fonctionnalités trop nombreuses pèse lourdement sur les performances globales du produit, ces développeurs informent dès que possible le product owner de leurs préoccupations. Ces développeurs représentent des atouts précieux car ils sont capables de formuler leurs préoccupations dans des termes commerciaux que le product owner comprendra, d’indiquer qu’ils sont prêts à travailler sur des solutions et de montrer qu’ils comprennent l’impact des aspects techniques comme les performances sur la valeur marchande d’un produit.
- Applique une politique de non-ingérence pour l’équipe – D’autres employés d’une entreprise peuvent être tentés de faire valoir leurs propres exigences sur une équipe de développement. C’est probablement la raison pour laquelle le Guide Scrum inclut la mention suivante : « Personne n’est autorisé à demander à l’équipe de développement de travailler sur un autre cahier des charges, et l’équipe de développement n’est pas autorisée à agir sur les consignes de quelqu’un d’autre ».
Conseils généraux d’embauche pour tous les rôles de l’équipe Scrum
Après avoir évoqué les détails, examinons une liste de qualités générales que les experts Scrum disent rechercher chez les autres membres de l’équipe.
- Admet ses erreurs et en tire des enseignements – Même si tout le monde fait des erreurs, il est important que chacun apprenne de ces erreurs et s’améliore en conséquence. Avant d’embaucher ou d’inviter quelqu’un à rejoindre votre équipe Scrum, cherchez à identifier les candidats qui n’admettront pas leurs erreurs. En effet, cela pourrait révéler des traits plus problématiques, par exemple en matière de responsabilité. Les équipes travaillent collectivement sur d’innombrables détails ; il est donc essentiel que vous choisissiez un candidat capable de passer en douceur à un rôle d’équipe sans avoir tendance à chercher des coupables.
- Accueille les commentaires – Les membres de l’équipe pleinement conscients de leur rôle savent donner et recevoir des commentaires de manière claire, directe et respectueuse. Ils savent également que les commentaires doivent être utiles et motivants. Dans la mesure du possible, ces membres de l’équipe cherchent des moyens de formuler leurs commentaires en privé. Par ailleurs, la confiance est un élément important de l’équation. Les collègues qui se font confiance travaillent mieux collectivement. Une bonne évaluation de la manière dont les candidats abordent les commentaires et la confiance permet de mieux comprendre leur caractère.
- Apporte de l’humour, de l’énergie et du plaisir au travail – Le travail en équipe et le sentiment d’être lié aux autres exigent un investissement personnel de la part de chacun. Souvent, les employés qui expriment leur personnalité par l’humour, l’énergie et les hobbies créent plus rapidement des liens avec les autres. Il n’est pas toujours facile d’évaluer ces qualités lors des entretiens d’embauche, mais les questions générales sur les centres d’intérêt et passe-temps préférés, voyages et activités du week-end peuvent révéler quelques indices sur la manière dont le candidat s’intégrerait dans une équipe Scrum particulière.
La boîte à outils Scrum
La responsabilité collective est un élément important de Scrum. Pour s’améliorer en tant qu’équipe, il est utile de suivre les performances et les progrès en utilisant un éventail d’outils.
- Tableau Scrum – Il existe différents types de tableaux de tâches, mais le modèle le plus couramment utilisé dans Scrum est le tableau Scrum déjà mentionné dans cet article. Comme nous l’avons évoqué, le tableau Scrum comprend des colonnes généralement intitulées À faire, Travail en cours (TEC) et Terminé. Chaque tâche du backlog de sprint est inscrite sur une note adhésive et placée dans l’une de ces colonnes pour aider l’équipe Scrum à déterminer la quantité de travail restant à accomplir avant la fin du sprint.
Les tableaux Scrum peuvent également être utilisés pour suivre les résultats de l’équipe à l’aide d’une métrique dénommée « vitesse ». Pour mesurer la vitesse, l’équipe attribue une valeur de point relative à chaque tâche du backlog de sprint. Une fois le sprint terminé, l’équipe peut ajouter des points dans la colonne Terminé et calculer la vitesse totale de l’équipe pour le Sprint en question. L’utilisation de cette méthode aide les équipes à créer une base de référence pour les performances de l’équipe et à prévoir le travail qu’elles pourront traiter dans le cadre des sprints à venir.
Les équipes peuvent également utiliser les tableaux Scrum et la vitesse pour prévoir la date d’achèvement d’un projet ou analyser l’impact des ajustements du flux de travail sur l’amélioration des taux de performance de l’équipe. Pour de plus amples informations, consultez la formation Scrum Board de Scrum Inc.
- Diagramme de burn-down – Au cours de la réalisation d’un sprint, les équipes pourraient s’appuyer sur un diagramme de burn-down de sprint quotidien pour visualiser la quantité restante de travail dans le backlog de sprint. Le travail restant est représenté sur l’axe vertical, et le délai (selon le nombre de jours d’un sprint) est représenté sur l’axe horizontal. Ce type de représentation visuelle peut aider les équipes à mesurer leur progression et à rester sur la bonne voie pour respecter la date d’achèvement prévue. Les diagrammes de burn-down peuvent également s’avérer utiles pour suivre les tendances et les tâches à réaliser au cours du calendrier de lancement d’un produit. Pour plus d’informations sur la création d’un diagramme de burn-down, consultez la formation Tableau de burn-down de sprint de Scrum Inc.
- Matrice RACI – Chaque équipe sait qu’à certains moments, la responsabilisation individuelle est nécessaire. Dans ces situations, il est utile de disposer d’un outil comme la matrice RACI (responsable, redevable, consulté, informé) pour répartir les tâches et les livrables en un diagramme organisé des rôles et responsabilités. Pour de plus amples renseignements concernant cet outil, consultez « Un guide complet de la gestion de projet pour tout ce qui concerne la matrice RACI ».
Utilisez Smartsheet pour gérer facilement les projets Scrum
De la simple gestion de tâches et de projets à la gestion complexe de ressources et de portefeuilles, Smartsheet vous aide à améliorer la collaboration et à accélérer le travail. Vous avez ainsi les moyens d'accomplir plus de travail. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports de synthèse sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.