Qu’est-ce que Scrum ?
Scrum est un framework de gestion de projet Agile utilisé par les équipes de développement de logiciels pour collaborer. Il se base sur l’apprentissage par l’expérience, l’auto-organisation de l’équipe pour la résolution des problèmes, et la rétrospective périodique pour s’améliorer continuellement.
La méthodologie vient avec 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 le framework Scrum classique avec l’aide du Guide Scrum et comment ses concepts sont matérialisés sur Jira Software, l’outil Atlassian pour la gestion de projets.
Le framework
Scrum est un framework heuristique : il repose sur l’apprentissage continu et l’adaptation à des facteurs variables. Il se base sur le fait que l’équipe ne maîtrise 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.
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. Cependant, afin de réussir sa mise en œuvre, la communication claire, la transparence et la volonté d’amélioration continue doivent rester les piliers de votre framework.
Artefacts Scrum
Les artefacts sont des outils créés 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 regroupe les tâches « terminées ».
- 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. C’est la « to-do list » des équipes. Le backlog produit est constamment mis à jour, et ses priorités sont revues. Il est géré par le Product Owner qui le maintient en fonction de l’évolution du marché et du retour sur expérience de l’utilisateur.
- 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é en vue de leur implémentation dans le cycle de sprint actuel. Avant chaque sprint, une réunion de planification est organisée. Au cours de celle-ci, l’équipe choisit les éléments sur lesquels elle travaillera à partir du 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. L’« incrément » est présenté 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 de la façon dont les équipes définissent « terminé » et les objectifs de sprint. Par exemple, certaines équipes choisissent d’effectuer une livraison à 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. Par exemple, dans le cas où les livraisons client peuvent être opérées uniquement chaque trimestre. Les sprints sont de deux semaines, mais « terminé » est défini comme achever une portion d’une version plus large qui sera livrée par la suite. Il est utile de noter que plus vous avez besoin de temps pour livrer un logiciel, plus le risque qu’il puisse échoué est élevé.
Cérémonies Scrum
L’ensemble des cérémonies séquentielles que les équipes Scrum effectuent régulièrement constituent des composantes mieux connues du framework.
- “Product Backlog refinement” : 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.
- Planification du sprint : l’ensemble de l’équipe de développement planifie le travail à réaliser durant le sprint. Cette cérémonie est animé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 défini par l’équipe Scrum pour terminer un incrément. Le délai classique d’un sprint est de deux semaines, mais il peut être d’une à quatre semaines. Ceci dit, plus le travail est complexe et plus les inconnues sont nombreuses, plus le sprint doit être court. Mais c’est à l’équipe de développement de voir. 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 que le délai du 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.
- Daily Scrum : mini-réunion quotidienne, rapide, de 15 minutes qui a lieu à la même heure le matin. 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 ou blocages concernant l’objectif du sprint.Le format de stand-up courant est de 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 ?Le Daily Scrum a pour objectif de limiter les bavardages à une réunion quotidienne. L’équipe peut ensuite se concentrer sur son travail pendant le reste de la journée. - Revue de sprint : à la fin du sprint, l’équipe se rassemble afin d’effectuer 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.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.
- 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.
Trois rôles essentiels pour la réussite de Scrum
Une équipe Scrum doit rassembler trois rôles : 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
La priorité du Product Owner 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. Le Product Owner efficace :
- crée et gère le backlog produit ;
- travaille en étroite collaboration avec le business et l’équipe pour s’assurer que tous savent en quoi consistent les tâches du backlog produit ;
- fournit à l’équipe des orientations claires sur les prochaines fonctionnalités à livrer ;
- décide du moment où le produit doit être livré, avec une prédisposition pour des livraisons plus fréquentes.
Le Product Owner fait en sorte 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. 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 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.
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 Work In Progress) à 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 Work In Progress, 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.
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 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 logiciels complexes, quels que soient le secteur et le marché, en fait un framework attrayant à adopter pour votre organisation.
Si vous envisagez de mettre en place la méthode SCRUM, n’hésitez pas à nous contacter. Nos équipes constitués de consultants certifiés SCRUM et Atlassian ont à leurs actifs plusieurs projets mis en place avec succès et seront ravis de partager avec vous leurs retours d’expériences.