Qu'est-ce que Scrum et comment se lancer
Scrum : qu'est-ce que c'est, comment ça marche et comment se lancer
Parcourir les rubriques
Lancez-vous gratuitement avec le modèle Scrum pour Jira
Simplifiez votre projet et planifiez, suivez et gérez facilement le travail au fil des sprints. Le modèle Jira Scrum inclut des tableaux, des backlogs, des feuilles de route, des rapports, et bien plus encore !
Qu'est-ce que Scrum ?
Scrum est un framework de gestion de projet Agile qui aide les équipes à structurer et à gérer leur travail selon un ensemble de valeurs, de principes et de pratiques. À 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 et ancienne coach Agile, nous donnera ses trucs et astuces dans notre série de vidéos Le coach Agile :
Articles sur Scrum
Du silo à la cohésion avec les tableaux Scrum Jira
Le tableau Scrum Jira affiche visuellement l'avancement au cours du cycle de développement.
Télécharger gratuitementAgile et Scrum
Les gens pensent 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 une philosophie. La philosophie Agile est centrée sur l'amélioration progressive continue par le biais de petites livraisons fréquentes. 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 Guide Scrum et le Manifeste Agile permettent de comprendre la différence entre Scrum et Agile et d'obtenir une définition de Scrum. Le Manifeste Agile met en avant quatre valeurs :
- Les individus et leurs interactions plutôt que les processus et les outils
- Des logiciels opérationnels plutôt qu'une documentation exhaustive
- La collaboration avec les clients plutôt que la négociation contractuelle
- L'adaptation au changement plutôt que le suivi d'un plan
La définition de Scrum repose sur l'empirisme et la pensée Lean. L'empirisme dit que les connaissances découlent de l'expérience et que les décisions sont prises en fonction des observations. La pensée Lean réduit les pertes et se concentre sur l'essentiel. Le framework Scrum est heuristique : il repose sur l'apprentissage continu et l'adaptation à des facteurs variables. Il reconnaît qu'au démarrage d'un projet, l'équipe ne sait pas tout, et qu'elle é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.
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.
Le framework Scrum
Le framework Scrum décrit un ensemble de valeurs, de principes et de pratiques que les équipes Scrum suivent pour fournir un produit ou un service. Il indique les membres d'une équipe Scrum et leurs responsabilités, les « artefacts » qui définissent le produit et le travail nécessaire à sa création, ainsi que les cérémonies Scrum qui guident l'équipe Scrum dans son travail.
Membres d'une équipe Scrum
Une équipe Scrum est une petite équipe flexible qui se consacre à la livraison d'incréments de produits commités. Généralement petite (une dizaine de personnes), elle est tout de même suffisamment grande pour accomplir un volume de travail conséquent en un sprint. 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 responsable produit soit une seule personne. Aucune équipe de développement ne se réjouira de recevoir des directives différentes de plusieurs responsables produit.
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.
Artefacts Scrum
Les artefacts Scrum sont des informations importantes utilisées par l'équipe Scrum pour aider à définir le produit et le travail à effectuer pour le créer. 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 auxquelles une équipe Scrum doit réfléchir pendant les sprints et au fil du temps.
- 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 corrections 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.
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
Le framework Scrum inclut des pratiques, des cérémonies et des réunions Scrum que les équipes Scrum organisent régulièrement. Ce sont les cérémonies Agile 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 :
-
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.
-
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. -
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. -
Mêlée quotidienne (Daily Scrum) ou stand-up : 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 du « 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. -
Revue de sprint : à la fin du sprint, l'équipe se rassemble pour une session informelle afin d'assister à une démo ou à l'inspection de l'incrément. L'équipe de développement présente aux parties prenantes et à ses collègues les tâches du backlog terminées 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 prochaine session de planification du sprint. Pour un sprint d'un mois, envisagez de « time-boxer » votre revue de sprint à un maximum de quatre heures. -
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.
Lancez-vous gratuitement avec le modèle Scrum pour Jira
Simplifiez votre projet et planifiez, suivez et gérez facilement le travail au fil des sprints. Le modèle Jira Scrum inclut des tableaux, des backlogs, des feuilles de route, des rapports, et bien plus encore !
Valeurs Scrum
En 2016, cinq valeurs Scrum ont été ajoutées au Guide Scrum. Ces valeurs orientent le travail, les actions et le comportement de l'équipe Scrum. Elles sont considérées comme essentielles à son succès.
Engagement
Étant donné que les équipes Scrum sont petites et flexibles, chaque membre de l'équipe joue un rôle important dans sa réussite. Par conséquent, chacun doit accepter de ne s'engager à accomplir que les tâches qu'il est en mesure de terminer et de ne pas se surcharger. Des communications fréquentes doivent avoir lieu concernant l'avancement des tâches, souvent par le biais de stand-ups.
Courage
Une équipe Scrum fait preuve de courage lorsqu'elle ose remettre en question le statu quo ou tout ce qui entrave sa réussite. Les membres de l'équipe doivent avoir le courage et sentir libres d'essayer de nouvelles choses. De même, une équipe Scrum doit avoir le courage et se sentir libre d'être transparente en ce qui concerne les obstacles, l'avancement des projets, les retards, et bien plus encore.
Concentrez-vous
Au cœur du workflow des équipes Scrum se trouve le sprint : une période précise et ciblée pendant laquelle l'équipe accomplit une quantité définie de travail. Il fournit une structure, ainsi que la concentration nécessaire à la réalisation de la quantité de travail prévue.
Ouverture
Le stand-up quotidien favorise une ouverture qui permet aux équipes de parler librement du travail en cours et des bloqueurs. Chez Atlassian, nous demandons souvent à nos équipes Scrum de répondre aux questions suivantes :
- Sur quoi ai-je travaillé hier ?
- Que dois-je faire aujourd'hui ?
- Quels tickets me bloquent?
Cela permet de mettre en évidence l'avancement et d'identifier les bloqueurs. L'équipe en sort également renforcée quand tout le monde partage son avancement.
Respect
La force d'une équipe Agile réside dans sa collaboration et dans le fait de reconnaître que chaque membre de l'équipe contribue au travail dans un sprint. Ses membres célèbrent les réussites de chacun et se respectent mutuellement autant qu'ils respectent le Product Owner, les parties prenantes et le Scrum Master.
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 Kanban ou Scrum, 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 (Daily Scrum), et bien d'autres. 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 former 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.
Se lancer avec 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 parfaite compréhension 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 (Daily Scrum), 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.
Pour découvrir Scrum grâce à Jira, consultez ce tutoriel.
Ressources associées
Lancez-vous gratuitement avec le modèle Scrum pour Jira
Simplifiez votre projet et planifiez, suivez et gérez facilement le travail au fil des sprints. Le modèle Jira Scrum inclut des tableaux, des backlogs, des feuilles de route, des rapports, et bien plus encore !
Kanban
Présentation de la méthodologie kanban pour le développement logiciel Agile et ses avantages pour votre équipe Agile.
Lire cet article