A la découverte de Scrum

A la découverte de Scrum

Chez Atlas Management, cela fait maintenant plusieurs années que nous utilisons le cadre de travail Scrum. La performance, la réactivité et la communication sont des valeurs fortes de cette méthode qui nous permettent d’être productif et de mettre l’équipe au centre de nos missions.

Cette méthode fait tellement partie de notre quotidien, que nous réalisons aujourd’hui ne pas avoir écrit d’articles sur le sujet. Ce sera maintenant chose faite ! Pour ce premier article, nous vous proposons de (re)découvrir cette méthode, son origine, les rôles et les événements qui ponctuent son quotidien.

Mais avant toute chose, précision que Scrum n’est pas une méthode :

« C’est un cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible. »[1]

Commençons par l’agilité

L’agilité ne se limite pas au cadre Scrum : Extreme Programming (XP), Lean, Kanban, Adaptive software development (ASD), … Ils sont tous des cadres de travail dits agiles.

L’agilité est apparue il y a bien longtemps. Il aura fallu environ un siècle pour passer des premiers essais au cadre de travail et à la culture que nous connaissons aujourd’hui. Dès 1930, de premiers travaux traitant de développement itératif et incrémental apparaissent avec la roue de Deming. Ce principe, découpé en 4 étapes, s’oppose à la division du travail en tâches simples mais se concentre sur les interactions et l’approche systémique.

La première méthode agile voit réellement le jour en 1991 avec RAD, Rapid Application Development. Avant dédié au monde industriel, c’est la première fois que l’agilité apparait dans le monde informatique.

En 2001, plusieurs grands acteurs de l’agilité se regroupent pour définir les concepts et la culture agile. De là nait l’Agile Manifesto. On y retrouve les quatre valeurs de l’agilité :

Les individus et les interactions, plus que les processus et les outils

Des logiciels opérationnels, plus qu’une documentation exhaustive

La collaboration avec les clients, plus que la négociation contractuelle

L’adaptation au changement, plus que le suivi d’un plan

Scrum et son Histoire

Naissance de Scrum

C’est en 1986 que le terme « Scrum » fait son apparition via la publication d’un article dans le « The New New Product Development Game ». Bien que posant les premières notions de la méthodologie, l’explication faite ne traite en rien de la méthode que nous pouvons connaitre aujourd’hui. En se basant sur l’observation d’un match de rugby, les professeurs Hirotaka Takeuchi et Ikujiro Nonaka explique la différence entre méthode séquentielle et méthode itérative.

Le rugby se prête parfaitement pour mettre en avant la signification du mot « Scrum », qui signifie « mêlée » en anglais. Cette mêlée représente le travail d’équipe et la force du collectif par de courtes itérations.

C’est ensuite Ken Schwaber qui, en 1995, pose les bases de la méthodologie que nous connaissons aujourd’hui. En collaboration avec Jeff Sutherland, ils écriront par la suite le Scrum Guide, en 2011.

Des valeurs fortes

Scrum repose sur l’empirisme, c’est-à-dire qu’il se base sur l’expérience acquise par les individus afin d’améliorer l’organisation. Il repose sur 3 piliers que sont :

  • La transparence, qui apporte communication au sein de l’équipe et compréhension globale ;
  • L’adaptation pour toujours viser l’amélioration continue ;
  • L’inspection, afin de détecter la différence entre les besoins et les réalisations.

Ces 3 pilliers reposent les 5 valeurs citées pour la première fois dans l’ouvrage de Ken Schwaber et Marc Beedle datant de 2001.

La vie en Scrum

L’équipe Scrum

Le 3 principaux rôles SCRUM
Illustration : les 3 rôles SCRUM

L’équipe Scrum comporte trois rôles : le Scrum Master, le Product Owner et l’équipe de développement. Toute cette équipe doit travailler ensemble, de manière collaborative et auto-organisée. Il n’existe pas de hiérarchie, à l’inverse d’une méthode de gestion de projet classique.

Afin de travailler de la manière la plus collaborative possible, les équipes utilisent les meilleurs outils, tels que Slack ou Trello.

L’équipe doit aussi être pluridisciplinaire. Elle doit comprendre toutes les compétences nécessaires au bon déroulé du projet, sans dépendance envers des personnes extérieures. Ceci permettre de gagner en performance et en flexibilité et donc en productivité.

Scrum Master

Le Scrum Master représente la connaissance de la méthode, il en est le garant. Son objectif est de mettre en place la méthodologie adéquate afin d’en maximiser sa valeur. Il organise et facilite le bon déroulé des événements et élimine les obstacles qui pourraient se présenter. Vrai pilier de la méthodologie, il accompagne le reste de l’équipe dans leurs tâches.

Le Scrum Master n’est en rien un chef de projet ; il ne manage pas, il lead.

Product Owner

Le Product Owner est le représentant de la connaissance métier. Son objectif est de centraliser les besoins. Il connait donc le produit à réaliser et en porte la vision. Il cherche à maximiser la valeur et à respecter les besoins.

Il est responsable de la liste des tâches qui seront réalisées au cours du projet. Il en est le garant et est le seul à pouvoir le modifier, le maintenir et le prioriser. Etant le seul avec cette capacité, il est donc, par conséquent, le seul validateur des incréments produits.

En plus de sa participation à des événements Scrum, il gère et suit le budget projet.

Bien qu’étant une personne unique, il peut être assisté par un Proxy-PO qui sera alors en support pour l’assister dans ces tâches quotidiennes.

Equipe de développement

Le troisième rôle de Scrum est l’équipe de développement. Composée de 3 à 9 personnes et entièrement de développeurs, il n’existe aucune hiérarchie dans cette équipe. Nous parlons encore une fois d’autonomie et d’auto-organisation.

Pluridisciplinaire, l’équipe possède une variété de compétence, lui permettant de réaliser la mission sans aide extérieure. Responsable du développement du produit, elle est aussi en charge de sa qualité.

Un découpage en sprints

Illustration : le cycle de vie SCRUM

Un sprint se représente comme un vrai cycle de vie. Il va rythmer le projet tout en visant la production et la valeur. Conservant toujours le même rythme, il dure généralement entre 2 à 4 semaines.

Ce schéma représente un sprint en Scrum avec ses 3 artefacts et 4 événements :

  • Le product backlog

Il représente la vision globale du projet avec l’ensemble des attentes. Il est donc la responsabilité du Product Owner.

Il se décompose sous forme de user stories, de courtes histoires utilisateurs. Un product backlog doit être partagé à toute l’équipe en constamment, maintenu à jour et évolutif dans le temps.

Définit en début de projet, il est modifié et affiné via le grooming qui permet d’affiner les user stories et de les prioriser.

  • Le sprint planning

Il marque le début de sprint. Son temps varie en fonction de celui-ci, on compte 4h pour un sprint de 2 semaines. Toute l’équipe est présente et identifie les user stories du product backlog qui seront à réaliser durant le prochain sprint.

C’est le moment de l’estimation. Les user stories sont estimées en termes de complexité grâce à des techniques d’estimation (la plus répandue étant l’utilisation du planning poker).

  • Le sprint backlog

Issu du sprint planning, il comprend les user stories qui seront réalisées au cours du prochain sprint.

  • Le daily scrum

Scrum repose sur la communication d’équipe. De manière quotidienne, l’équipe se retrouve afin d’effectuer un point d’avancement et anticiper les problèmes. Limité à 15 min, chaque membre de l’équipe prend la parole afin de répondre à trois questions :

+ Qu’est-ce que j’ai réalisé hier ?

+ Qu’est-ce que je vais faire aujourd’hui ?

+ Quels sont les problèmes qui m’empêchent d’avancer ?

Attention à ne pas tomber dans les 7 pièges du daily !

  • L’incrément

Incrément représente la réalisation de l’équipe de développement accumulée au cours des sprints. Il comprend donc les réalisations des sprints précédents ainsi que celui venant de se terminer. Seules les user stories terminées et validées en font partie.

  • La revue de sprint

C’est à ce moment que l’incrément est validé. L’équipe de développement présente chaque user story et le Product Owner a pour rôle de les valider, ou non. Cette validation se base sur ce qu’on appelle la « Definition of Done », la définition du terminé. Celle-ci a été établie en début de projet par la globalité de l’équipe.

La revue de sprint dure environ 2h pour un sprint de deux semaines.

  • La rétrospective

La rétrospective clôt le sprint et se réalise à la suite de la revue de sprint. Ici, on se focalise sur l’équipe. L’objectif est de faire un point sur les problématiques humaines, organisationnelles et techniques. Durant cet atelier, l’équipe échange sur son ressenti et ses attentes en vue d’améliorer constamment la méthode de travail.

On compte généralement 1h pour un sprint de deux semaines.

Comment en apprendre plus ?

Il y a une grande quantité d’articles sur Internet à propos de l’agilité et de Scrum, au point qu’il y a une confusion générale sur le sujet.

Devenir agile demande un réel investissement et la pratique reste le seul moyen d’en comprendre les tenants et aboutissants.

Si vous souhaitez vous tourner vers les certifications, il existe dorénavant de nombreux moyens, que ce soit par le suivi d’une formation et le passage de la certification en présentiel ou directement en ligne.

Pour vous simplifier la vie, nous avons sélectionné pour vous les meilleures ressources sur ce sujet : articles/blog/livres/organismes de formation.

Nous proposons également un système de prêt de livre gratuit sur la région du Grand Nouméa. Notre bibliothèque contient un bon nombre de livre sur l’agilité et la méthode Scrum.

Si vous souhaitez recevoir plus de contenu sur Scrum et l’agilité, cliquez sur le lien ci-dessous et précisez dans le formulaire de contact que vous êtes intéressés par notre sélection “Agilité” :


[1] Définition du Guide Scrum

Ajoutez un commentaire

Share This