Fermez

Scrum

Découvrez comment appliquer la méthodologie Scrum avec l'aide de nos experts

Qu'est-ce que Scrum ?

Scrum est un framework qui aide les équipes à collaborer. À l'instar d'une équipe de rugby (d'où le nom de cette méthodologie) s'entraînant en vue d'un match important, Scrum encourage les équipes à apprendre par l'expérience, à s'auto-organiser pendant qu'elles tentent de résoudre un problème, mais aussi à réfléchir à leurs victoires et à leurs défaites pour s'améliorer en continu.

Même si la méthodologie Scrum dont je parle est le plus souvent utilisée par les équipes de développement, ses principes et ses enseignements sont valables pour tout type de travail en équipe. C'est l'une des raisons pour lesquelles Scrum est si populaire. Souvent considéré comme un framework de gestion de projet Agile, Scrum décrit un ensemble de réunions, d'outils et de rôles qui interagissent de concert pour aider les équipes à structurer leur travail et à le gérer.

Dans cet article, nous verrons comment se compose un framework Scrum classique avec l'aide du Guide Scrum et de David West, PDG de Scrum.org. Nous inclurons également des exemples montrant comment nos clients s'écartent de ces notions fondamentales pour répondre à leurs besoins spécifiques. Pour cela, Megan Cook, responsable produit Groupe pour Jira Software et ancienne coach Agile, nous donnera ses trucs et astuces dans notre série de vidéos Le coach Agile :

Scrum articles

[CONTINUED]

Le framework

On croit souvent que Scrum et Agile sont identiques, car Scrum se focalise sur l'amélioration continue, un principe fondamental d'Agile. Cependant, Scrum est un framework de gestion du travail, alors qu'Agile est un état d'esprit. Vous ne pouvez pas vraiment « devenir Agile » : l'ensemble de l'équipe doit changer de point de vue sur la façon d'apporter une valeur ajoutée aux clients. Vous pouvez toutefois utiliser un framework tel que Scrum pour engager la réflexion et intégrer les principes Agile à vos méthodes de communication et de travail quotidiennes.

Le framework Scrum est heuristique : il repose sur l'apprentissage continu et l'adaptation à des facteurs variables. Il reconnaît que l'équipe ne sait pas tout au démarrage d'un projet et évoluera avec l'expérience. La méthodologie Scrum est structurée pour aider les équipes à s'adapter naturellement à l'évolution des conditions et des exigences des utilisateurs. La redéfinition des priorités et les cycles de livraison courts sont intégrés au processus pour permettre à votre équipe d'apprendre et de s'améliorer en permanence.

Le framework Scrum | Le coach Agile Atlassian

Même si Scrum est structuré, il n'est pas tout à fait rigide. Son exécution peut être adaptée aux besoins de n'importe quelle organisation. De nombreuses théories sont avancées sur la façon dont les équipes Scrum doivent travailler pour réussir. Toutefois, après plus de dix années à aider les équipes Agile à faire leur travail, Atlassian a appris que la communication claire, la transparence et la volonté d'amélioration continue doivent rester les piliers de votre framework. Pour le reste, c'est à vous de voir.

Artefacts Scrum

Commençons par identifier les trois artefacts de Scrum. Les artefacts sont des objets que nous créons, comme un outil pour résoudre un problème. Dans Scrum, ils sont au nombre de trois : le backlog produit, le backlog de sprint et l'incrément qui définit les tâches « terminées ». Ce sont les trois constantes d'une équipe Scrum autour desquelles nous continuons de réfléchir et d'investir durant les heures supplémentaires.

  • Le backlog produit est la liste principale des tâches à réaliser. Il est géré par le Product Owner ou le responsable produit. C'est une liste dynamique de fonctionnalités, d'exigences, d'améliorations et de correctifs qui fait office de point de départ pour le backlog de sprint. Pour résumer, c'est la « to-do list » des équipes. Le backlog produit est constamment repensé, et ses priorités sont redéfinies. Il est géré par le Product Owner, car, à mesure que nous en apprenons plus ou que le marché change, certains éléments peuvent ne plus s'avérer pertinents ou certains problèmes peuvent être résolus d'autres manières.
  • Le backlog de sprint est la liste d'éléments, d'user stories ou de correctifs de bug que l'équipe de développement a sélectionnés en vue de leur implémentation dans le cycle de sprint actuel. Avant chaque sprint, une réunion de planification (que nous verrons plus tard dans cet article) est organisée. Au cours de celle-ci, l'équipe choisit les éléments sur lesquels elle travaillera dans le backlog produit. Un backlog de sprint peut être flexible et évoluer durant un sprint. Toutefois, l'objectif fondamental d'un sprint (ce que l'équipe souhaite atteindre à partir du sprint actuel) ne peut pas être remis en question.
  • L'incrément (ou l'objectif de sprint) est le produit final exploitable qui a été obtenu pendant le sprint. Chez Atlassian, nous présentons généralement l'« incrément » durant la démo de fin de sprint au cours de laquelle l'équipe montre ce qui a été effectué durant le sprint. Vous n'entendrez peut-être pas parler du terme « incrément », puisqu'il est souvent remplacé par la définition de « terminé » : une étape importante, l'objectif du sprint, voire une version complète de l'epic livré. Cela dépend simplement de la façon dont vos équipes définissent « terminé » et dont vous définissez vos objectifs de sprint. Par exemple, certaines équipes choisissent de livrer quelque chose à leur client à la fin de chaque sprint. Pour elles, « terminé » signifie donc « livré ».Toutefois, cela peut ne pas être réalisable pour d'autres équipes. Imaginez que vous travaillez sur un produit basé sur serveur pour lequel les livraisons client peuvent uniquement avoir lieu chaque trimestre. Vous choisirez peut-être tout de même de travailler par sprints de deux semaines, mais vous définirez « terminé » comme achever une portion d'une version plus large qui sera livrée par la suite. Bien sûr, plus vous avez besoin de temps pour livrer un logiciel, plus le risque que celui-ci coure à l'échec est élevé.

Comme vous pouvez l'imaginer, votre équipe peut choisir de définir de nombreuses variations, même au sein des artefacts. C'est pourquoi il est important de rester ouvert à de nouvelles méthodes de gestion des artefacts. Votre définition de « terminé » génère peut-être un stress néfaste pour votre équipe. Vous devrez alors en sélectionner une autre.

Astuce 

Vous devriez adopter un framework aussi flexible que votre produit. Prenez le temps dont vous avez besoin pour voir comment les choses se déroulent, apporter les ajustements nécessaires, et n'usez pas de force pour le simple plaisir d'assurer la cohérence.

Cérémonies ou événements Scrum

L'ensemble d'événements séquentiels, de cérémonies ou de réunions que les équipes Scrum effectuent régulièrement constituent des composantes mieux connues du framework. Ce sont les cérémonies qui divergent le plus d'une équipe à l'autre. Par exemple, certaines équipes considèrent toutes ces cérémonies comme fastidieuses et répétitives, alors que d'autres les utilisent comme un point de contrôle nécessaire. Nous vous recommandons de commencer par organiser toutes les cérémonies pendant deux sprints et de voir comment vous vous sentez. Vous pouvez ensuite effectuer une rétrospective rapide pour déterminer les éventuels ajustements nécessaires.

 

Voici une liste de toutes les cérémonies clés auxquelles une équipe Scrum peut participer :

  1. Organisation du backlog : parfois qualifié de préparation du backlog, cet événement est sous la responsabilité du Product Owner. Ce dernier a deux tâches principales : faire de la vision du produit une réalité et rester constamment en ligne avec le marché et le client. Par conséquent, il tient à jour cette liste en s'appuyant sur le feedback des utilisateurs et de l'équipe de développement pour aider à définir des priorités et à maintenir un backlog propre et disponible à tout moment. Pour en savoir plus sur la gestion d'un backlog sain, c'est par ici.

  2. Planification du sprint : l'ensemble de l'équipe de développement planifie le travail à réaliser (le périmètre) durant le sprint actuel pendant cette réunion. Celle-ci est menée par le Scrum Master. À cette occasion, l'équipe détermine l'objectif du sprint. Les user stories sont ensuite ajoutées au sprint à partir du backlog produit. Ces stories correspondent toujours à l'objectif, et l'équipe Scrum s'accorde à dire qu'elles sont possibles à implémenter durant le sprint.

    À la fin de chaque réunion de planification, chaque membre de l'équipe Scrum doit savoir avec certitude ce qu'il est possible de livrer durant le sprint et comment réaliser l'incrément.

  3. Sprint : un sprint désigne le délai réel dont l'équipe Scrum a besoin pour terminer un incrément. La longueur classique d'un sprint est de deux semaines, mais certaines équipes estiment qu'un périmètre d'une semaine ou qu'un délai d'un mois pour livrer un incrément de valeur est plus simple. Selon Dave West, de Scrum.org, plus le travail est complexe et plus les inconnues sont nombreuses, plus le sprint doit être court. Mais c'est véritablement à votre équipe de voir, et vous ne devriez pas avoir peur du changement si quelque chose ne fonctionne pas ! Durant cette période, le périmètre peut être renégocié entre le Product Owner et l'équipe de développement si nécessaire. C'est ce qui confère à la méthodologie Scrum sa nature empirique.

    Tous les événements, de la planification à la rétrospective, ont lieu durant le sprint. Dès lors qu'un certain intervalle de sprint est établi, il doit rester constant tout au long de la période de développement. L'équipe peut ainsi apprendre des expériences passées et appliquer ces enseignements aux sprints futurs.

  4. Mêlée ou stand-up quotidien(ne) : mini-réunion quotidienne qui a lieu à la même heure (généralement, le matin) et au même endroit pour simplifier les choses. Beaucoup d'équipes essaient de s'en tenir à 15 minutes, mais ce n'est qu'une indication. Cette réunion est également appelée « stand-up quotidien » pour souligner le fait qu'elle doit être rapide. L'objectif de la mêlée quotidienne ou « daily scrum » est de mettre tous les membres de l'équipe en phase avec l'objectif du sprint et de définir un plan pour les prochaines 24 heures.

    C'est l'occasion de faire part d'éventuelles préoccupations concernant l'objectif du sprint ou de bloqueurs.

    Un format de stand-up est courant. Il consiste à demander à chaque membre de l'équipe de répondre à trois questions sur la réalisation de l'objectif du sprint :

    •      Qu'est-ce que j'ai fait hier ?
    •      Qu'est-ce que je prévois de faire aujourd'hui ?
    •      Y a-t-il des obstacles ?

    Nous avons toutefois constaté que la réunion se transformait rapidement en une lecture à voix haute des plannings de la veille et de ceux du lendemain. Le stand-up s'appuie sur une théorie : il limite les bavardages à une réunion quotidienne. L'équipe peut ensuite se concentrer sur son travail pendant le reste de la journée. S'il se transforme en une lecture à voix haute des plannings, n'hésitez pas à changer de format et à être créatif.

  5. Revue de sprint : à la fin du sprint, l'équipe se rassemble pour une session informelle afin d'assister à une démo de l'incrément ou de l'inspecter. L'équipe de développement présente aux parties prenantes et à ses collègues les éléments du backlog terminés pour avoir leur avis. Le Product Owner peut décider de livrer ou non l'incrément. Cela dit, l'incrément est livré dans la plupart des cas.

    Cette revue est également l'occasion pour le Product Owner d'apporter des modifications au backlog produit sur la base du sprint actuel, lesquelles peuvent ensuite être intégrées à la session de planification du prochain sprint. Pour un sprint d'un mois, envisagez de « time-boxer » votre revue de sprint à un maximum de quatre heures.

  6. Rétrospective de sprint : la rétrospective est l'occasion pour l'équipe de se rassembler afin de documenter ce qui a fonctionné ou non dans un sprint, un projet, des relations, des outils, chez des personnes, voire dans certaines cérémonies et d'en discuter. L'idée est de créer un espace dans lequel l'équipe peut se concentrer sur ce qui a bien fonctionné et sur les choses à améliorer, et non sur les échecs.

Trois rôles essentiels pour la réussite de Scrum

Une équipe Scrum doit rassembler trois rôles spécifiques : le Product Owner, le Scrum Master et l'équipe de développement. Et, comme les équipes Scrum sont pluridisciplinaires, l'équipe de développement comprend des testeurs, des concepteurs, des spécialistes de l'expérience utilisateur et des ingénieurs opérationnels, en plus des développeurs.  

Le Product Owner Scrum

Les Product Owners sont les champions de leur produit. Leur priorité est de comprendre les exigences du business, des clients et du marché, puis de prioriser le travail de l'équipe d'ingénierie en conséquence. Les Product Owners efficaces :

  • créent et gèrent le backlog produit ;
  • travaillent en étroite collaboration avec le business et l'équipe pour s'assurer que tous savent en quoi consistent les tâches du backlog produit ;
  • fournissent à l'équipe des orientations claires sur les prochaines fonctionnalités à livrer ;
  • décident du moment où le produit doit être livré, avec une prédisposition pour des livraisons plus fréquentes.

Le Product Owner n'est pas toujours le responsable produit. Sa priorité est de s'assurer que l'équipe de développement offre un maximum de valeur ajoutée au business. Il est également important que le Product Owner soit une seule personne. Aucune équipe de développement ne se réjouira de recevoir des directives différentes de plusieurs Product Owners.

Le Scrum Master

Les Scrum Masters sont les champions de Scrum au sein de leur équipe. Ils coachent l'équipe, les Product Owners et le business sur le processus Scrum et cherchent les façons d'affiner leur pratique en la matière.

Un Scrum Master efficace comprend parfaitement le travail que l'équipe doit réaliser et peut aider celle-ci à optimiser la transparence et le flux de livraison. En tant que chef d'orchestre, il prévoit les ressources nécessaires (humaines et logistiques) pour planifier le sprint, le stand-up, la revue et la rétrospective de sprint.

L'équipe de développement Scrum

Les équipes Scrum abattent le travail. Elles sont les championnes des pratiques de développement durables. Les plus efficaces sont celles qui travaillent de façon soudée et proche géographiquement. Elles comptent généralement entre cinq et sept membres. Une façon de déterminer la taille de l'équipe consiste à suivre la règle des « deux pizzas » du PDG d'Amazon, Jeff Bezos : deux pizzas doivent suffire pour nourrir l'équipe.

Les membres de l'équipe présentent des compétences variées. Ils se forment les uns les autres afin qu'aucun ne devienne un goulot d'étranglement dans la livraison du travail. Les équipes Scrum efficaces s'organisent de façon autonome et adoptent une attitude du « nous » dans leur approche des projets. Les membres de l'équipe s'entraident tous afin de garantir la réussite du sprint.

L'équipe Scrum détermine le plan pour chaque sprint. Elle prévoit la quantité de travail qu'elle pense pouvoir assumer tout au long de l'itération en se servant de sa vélocité comme d'un guide. En gardant une longueur d'itération fixe, l'équipe de développement bénéficie d'un feedback important sur son processus d'estimation et de livraison. Avec le temps, ses prévisions deviennent donc de plus en plus précises.

Scrum, Kanban et Agile

Scrum est un framework Agile si populaire que ces deux méthodologies sont souvent confondues l'une avec l'autre. Il existe toutefois d'autres frameworks, comme Kanban, qui est une alternative populaire. Certaines entreprises choisissent même de suivre un modèle hybride de Scrum et Kanban, appelé « Scrumban » ou Kanplan (Kanban avec un backlog).

Scrum et Kanban utilisent tous deux des méthodes visuelles, comme le tableau Scrum ou Kanban, pour suivre l'avancement du travail. Tous deux donnent la priorité à l'efficacité et à la subdivision de tâches complexes en plus petits blocs gérables. Leur approche pour réaliser cet objectif diffère toutefois.

Scrum se concentre sur des itérations à durée limitée. Une fois la durée d'un sprint finalisée, les stories ou les entrées du backlog produit qui peuvent être implémentées durant ce cycle de sprint sont déterminées. Dans Kanban, le nombre de tâches ou la quantité de travail en cours (limite WIP) à implémenter au cours du cycle actuel est fixé(e) au préalable. Le temps nécessaire pour implémenter ces fonctionnalités est ensuite calculé en remontant dans le temps.

Kanban n'est pas aussi structuré que Scrum. Hormis la limite WIP, cette méthodologie est relativement ouverte à l'interprétation. Scrum intègre toutefois plusieurs concepts catégoriques dans le cadre de son implémentation, comme la revue de sprint, la rétrospective, la mêlée quotidienne ou « daily scrum », etc. La méthodologie insiste également sur la transversalité, c'est-à-dire la capacité d'une équipe Scrum à ne pas dépendre de membres externes pour atteindre ses objectifs. Il n'est pas toujours simple de forme une équipe transverse. En ce sens, Kanban est plus facile à adapter, alors que Scrum peut être considéré comme un virage fondamental dans le processus de réflexion et dans le fonctionnement d'une équipe de développement.

Mais, pourquoi Scrum ?

Le framework Scrum en lui-même est simple. Les règles, artefacts, événements et rôles sont faciles à comprendre. Son approche semi-normative aide véritablement à lever les ambiguïtés du processus de développement, tout en offrant aux entreprises la liberté suffisante pour ajouter leur propre touche.

L'organisation de tâches complexes en user stories gérables en fait la méthodologie idéale pour les projets complexes. Par ailleurs, la démarcation claire des rôles et les événements planifiés garantissent la transparence et la responsabilité collective tout au long du cycle de développement. Les livraisons rapides maintiennent la motivation de l'équipe et la satisfaction des utilisateurs à un niveau élevé, car il est possible de voir l'avancement dans un bref laps de temps.

Toutefois, la maîtrise de Scrum peut prendre un certain temps, en particulier si l'équipe de développement est habituée à un modèle en cascade classique. Les concepts d'itérations plus restreintes, de mêlées quotidiennes, de revues de sprint et l'identification d'un Scrum Master pourraient s'avérer un virage culturel difficile à prendre pour une nouvelle équipe.


Toutefois, les avantages à long terme prévalent nettement sur la courbe d'apprentissage initiale. Le succès de Scrum dans le développement de produits matériels et logiciels complexes, quels que soient le secteur et le marché, en fait un framework attrayant à adopter pour votre organisation.

 

Claire Drumond
Claire Drumond

Claire Drumond est stratège marketing, conférencière et rédactrice pour Atlassian. Elle est l'auteur de nombreux articles sur les blogs Trello et Atlassian. Par ailleurs, elle contribue régulièrement à diverses publications sur Medium, notamment HackerNoon, Art+Marketing et PoetsUnlimited. Elle intervient sur Agile, l'élimination des silos et la promotion de l'empathie lors de conférences techniques à travers le monde.
Twitter : @claire_drumond // Medium : @cdrumond

Up Next
sprints