Scrum : introduction à Scrum (en français)

introduction scrum

Le scrum est devenu la méthodologie de projet la plus populaire au sein des DSI françaises ; mais qu’est-ce que cette méthode agile concrètement ? Nous allons profiter de cet article pour voir ce qu’est ce framework sur lequel nous avons déjà fait de nombreux articles.

Si vous cherchiez un article pour expliquer scrum en français, c’est l’article que vous devez lire !

Subtilité : nous parlons souvent de méthode scrum mais ceci est un abus de langage. Scrum est un « cadre » et non une méthode. Essayer d’utiliser le terme de framework à la place de méthode scrum.

Petite définition du scrum

Quelle définition pourrait-on mettre derrière scrum ? Ce framework agile propose un cadre léger qui peut s’avérer complexe à mettre en place. Voici les 3 points clés qui pourraient le caractériser :

  • les sprints (itérations) et leurs évènements
  • les 3 rôles clés
  • les artefacts
    • product backlog
    • sprint backlog
    • increment
    • definition of done

D’ailleurs, vous pouvez regarder notre vidéo de 2 minutes sur la définition du scrum (la minute agile) :

Les origines du scrum

The New New Product Development Game

Le nom de « Scrum » pour une méthodologie de gestion de projet est apparue en 1986 dans la publication The New New Product Development Game écrite par deux japonais Hirotaka Takeuchi et Ikujiro Nonaka.

Cependant, on n’y retrouve pas les fondements du framework agile que nous connaissons ; d’ailleurs ces deux japonais ne sont pas considérés comme les pères de l’actuel framework.

Le terme de Scrum qui signifie Mêlée en français a été emprunté du Rugby qui était très populaire auprès de ces deux japonais. Ceux-ci ont décidé de faire référence au Rugby qui est un sport reconnu pour être un sport très collectif.

La mêlée amène l’idée de consolider l’équipe après une faute commise ; ici nous pouvons rapidement comprendre que la faute représente une mauvaise gestion de projet qui mettait les projets en danger.

mélée scrum
la mélée en rugby

Article pour approfondir ce sujet : les origines du Scrum

La première version du scrum

En 1995, Ken Schwaber présente pour la première fois les fondements de ce qu’est le Scrum que nous connaissons aujourd’hui. Il va co-écrire avec Mike Beedle l’Agile Software Development with Scrum en 2001 ; puis, ils publieront ce livre en 2004.

Jeff Sutherland et Ken Schwaber proposent le Scrum Guide en 2001 disponible gratuitement sur Internet ; ce dernier connait quelques évolutions de temps en temps. La dernière version date de novembre 2017 et propose quelques ajustements.

Le Scrum entreprise

Dans cet article et les différents liens que vous y trouverez, vous pourrez voir que tout ne respecte pas à 100% le Scrum Guide. J’ai préféré parler du Scrum qui est appliqué dans les entreprises d’aujourd’hui. Cependant, ces éventuelles adaptations ne vous dépayseront pas pour autant.

Vous trouverez d’ailleurs en entreprise une application du framework adapté avec des pratiques devenues très populaires comme les user-stories ou le poker planning. Il faut savoir que ces deux pratiques viennent d’un autre framework agile nommé l’Extreme Programming qui n’existe quasiment plus dans les entreprises francophones.

Il est assez rare de nos jours de voir un scrum s’appliquer sans ces deux pratiques populaires.

Qu’est-ce que le Scrum ?

Ce framework agile fonctionne sur une approche incrémentale et itérative.

Les cycles de développements sont volontairement courts et itératifs ; nous sommes en grande majorité sur des itérations de deux semaines (certains en font sur 4 semaines) que nous appelons des sprints.

En Scrum, il est très important d’avoir des cycles de projet agile structurés avec des itérations courtes, rythmées et  égales.

Ces itérations courtes sont essentielles pour se laisser la capacité d’adapter rapidement les processus voir le scope du projet ; nous profitons de ces itérations très courtes pour obtenir un maximum de feedback des clients (à la fin de chaque itération) ce qui permet éventuellement d’incrémenter le produit de nouvelles évolutions.

Ces itérations sont représentées simplement par différentes cérémonies que nous verrons plus en détail à la suite de l’article : la sprint planning qui démarre l’itération, la daily stand-up tous les matins, la sprint review et rétrospectives qui ferment le sprint.

Voici un schéma qui présente ce framework :

framework scrum
framework agile scrum – méthode scrum en français

Les 3 piliers du Scrum

La transparence

Le Scrum impose de partager tous les aspects liés au processus à l’ensemble des décideurs et la vision globale des développements à l’ensemble des observateurs.

Pour ma part, je n’hésite pas à mettre un management visuel complet afin d’aider à une transparence complète.

Faire un board complet
Le management visuel en Agile
Des astuces dans le management visuel

L’inspection

Il est essentiel de bien suivre l’avancement des développements et des objectifs de l’équipe. Cette inspection se fait grâce au management visuel de façon transparente, se fait à la review où l’équipe fait un point en fin d’itération du travail accompli et se fait avec la daily (petite réunion d’équipe du matin pour aligner tout le monde sur l’avancement du sprint).

Certaines équipes scrum utilisent des indicateurs de suivis pour bien suivre l’état d’avancement d’un sprint ou/et du développement du produit :

Burndown Chart – savoir le construire
Burnup Chart : suivi de projets
Diagramme de flux cumulés

Adaptation

Le Scrum préconise d’adapter les processus et l’environnement de travail afin de proposer un contexte optimal à l’équipe. La cérémonie de la rétrospective en fin de sprint permet de définir des axes d’amélioration en équipe afin d’être dans une réelle démarche d’amélioration continue.

L’équipe scrum pourra tester de nouvelles pratiques qu’elle décidera d’adopter ou non selon les résultats ; elle n’hésitera pas également à supprimer les pratiques devenues obsolètes.

amélioration méthode adaptation
amélioration méthode adaptation

Les 3 rôles clés de Scrum

Le scrum propose 3 rôles clés différents :

Bien que je vous recommande fortement de lire ces 3 articles, sachez que toute personne qui n’est ni Product Owner, ni Scrum Master, fait parti de l’équipe de développement. L’équipe de développement n’est pas constitué que de développeurs.

Voici quelques rôles supplémentaires possibles que nous pouvons avoir dans ces équipes qui s’adaptent à des contextes pas toujours optimals :

Qu’est-ce un Proxy Product Owner ?
Qu’est-ce ce rôle d’Agile Catalyst ?
Le testeur agile en scrum

Les cérémonies principales

Le scrum propose différentes cérémonies (réunion) pour rythmer l’ensemble des sprints (itérations) comme nous l’avions vu brièvement ci-dessous.

Un sprint est constitué de :

  • un sprint planning :
    • l’équipe démarre un sprint en planifiant le travail à réaliser.
  • une sprint review :
    • fermeture du sprint
    • l’équipe fait une revue du parcours réalisé pendant le sprint
    • l’équipe invite les utilisateurs/clients à faire des feedbacks sur le produit avec les dernières évolutions « done »
  • une sprint rétrospective :
    • après la sprint review
    • l’équipe fait un point ensemble pour chercher des axes d’amélioration
  • un daily scrum
    • l’équipe de développement se réunit pour s’harmoniser ensemble : qu’est-ce qui a été fait hier, ce qui a été fait aujourd’hui, y a t il une alerte
    • chaque matin (sauf jour d’ouverture du sprint)

Pour en savoir plus sur l’ensemble des cérémonies d’un sprint en scrum, voici un article que je vous recommande très complet sur le sujet :

Cérémonies du sprint

Les artefacts agile scrum

Ce framework propose 4 artefacts (dont 1 lié à la transparence) que les équipes doivent connaitre.

Product backlog

Le product backlog représente le regroupement de l’ensemble des choses à réaliser sur le produit pour le faire évaluer ; il est de la responsabilité du product owner. Contrairement aux méthodes cycle en V/waterfall, le backlog évolue constamment pour prendre en compte les nombreux feedbacks obtenus.

Voici un article complet sur le sujet et qui vous propose de nombreux articles autour de ce product backlog :

Product Backlog – définition

Sprint backlog

Le sprint backlog représente l’ensemble des items qui sont pris en charge par l’équipe de développement lors du sprint en cours ; il contiendra également le plan pour livrer ces items dans un environnement stable. Nous considérons que chaque sprint possède son propre sprint backlog.

Sprint backlog

Increment

L’incrément représente l’ensemble des items qui sont « done » dans le sprint en cours ajouté à l’incrément du sprint précédent.

Incrément en scrum

Definition of Done

L’équipe de développement va définir ensemble l’ensemble des critères qui permettront d’affirmer qu’un item (user story par exemple) peut être considéré comme « done ». Nous appelons couramment cette pratique par l’acronyme Dod

Definition of Done (DOD)

Conclusion

N’hésitez pas à aller découvrir tous nos articles complets sur scrum que je publie régulièrement sur ce blog. Cependant, n’oubliez pas que ce n’est pas une méthode en soit mais un cadre léger auquel il faut ajouter les pratiques adaptées pour améliorer l’environnement de l’équipe.

Alors, prêt pour mettre en place ce framework agile ?

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 531 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.