Qu'est-ce que Scrum et comment se lancer

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 fonctionnels 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 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.

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 transverses, 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 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.

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 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ée. 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.

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 :

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 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.

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.

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 stands-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 se 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.

Concentration

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 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. Leurs approches pour réaliser cet objectif diffèrent 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.

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.