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. |
Définition 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.
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
Si cet article expliquera concrètement les règles de scrum, il fournira différents liens où tout ne respectera 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 :
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.
De plus, le scrum insiste sur la nécessité d’être transparent sur l’état d’avancement que ce soit sur le contenu des itérations ou sur le produit dans sa globalité. En effet, la transparence est essentielle pour s’assurer que tous les acteurs du projet avancent ensemble dans la même direction.
Pour ma part, je n’hésite pas à mettre un management visuel complet afin d’aider à une transparence complète. Cette pratique n’est pas en soi imposée par le framework mais s’avère être la plus efficace pour être transparent.
Voici quelques articles pour vous aider à améliorer la transparence de l’équipe :
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
- à la review où l’équipe fait un point en fin d’itération du travail accompli
- avec la daily (petite réunion d’équipe du matin pour aligner tout le monde sur l’avancement du sprint)
Attention à bien comprendre que cette inspection a pour but principal que l’équipe soit en capacité de prendre de bonnes décisions ; elle n’a surtout pas pour but de faire du reporting à d’éventuels manager. C’est une inspection pour les équipes elles-mêmes et seulement elles.
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.
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.
Dans des cas exceptionnels, le scrum master et/ou le product owner peuvent également être considéré faire parti de l’équipe de développement si ils ont des tâches à réaliser liées à la réalisation du produit.
Bien comprendre les responsabilités
Ces 3 rôles ont des responsabilités complémentaires parfois très mal comprises. Voici un dessin qui clarifie le positionnement de ces 3 rôles clés :
Et souvent, les rôles de product owner et de scrum master sont très mal compris.
Le product owner est responsable du backlog mais n’est pas responsable des rendus ; ainsi, il n’a pas à tester le résultat du travail de l’équipe de développement. En effet, c’est l’équipe de développement qui est 100% autonome sur la réalisation qui doit s’assurer que les rendus correspondent parfaitement au besoin décrit.
De même, le scrum master n’est absolument pas un chef de projet et encore moins un manager hiérarchique de l’équipe ; en effet, il est le gardien des processus scrum, de sa mise en place et aide le product owner et l’équipe de développement à prendre leur totale autonomie sur leurs responsabilités respectives. Le scrum master n’est pas non plus l’animateur des cérémonies ; en effet, il peut animer une cérémonie à la demande des autres rôles de façon temporaire.
N’hésitez pas à lire les articles cités ci-dessus pour meilleure compréhension encore de ces différents rôles clés de scrum.
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
Attention, ces rôles ne sont pas officiels dans scrum mais sont des ajouts que nous retrouvons très régulièrement dans les entreprises. Ceux-ci ne doivent pas aller à l’encontre des fondamentaux du framework.
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 :
- une sprint planning :
- ouverture du sprint
- l’équipe démarre un sprint en planifiant le travail à réaliser.
- elle définie un objectif de sprint
- elle définie le plan pour atteindre cet objectif
- 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 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
Certaines équipes transforment le concept de « product backlog refinement » (anciennement appelé grooming) en cérémonie supplémentaire. Cette pratique est une adaptation cohérente mais pas définie par scrum. Le product backlog refinement est une pratique importante de scrum où le product owner et l’équipe de développement affine l’écriture des demandes ensemble.
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 :
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 évoluer ; 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.
Le product backlog est de la responsabilité à 100% du product owner. Cependant, il peut se faire aider par l’équipe de réalisation si il en a le besoin.
Le scrum rappelle l’importance que le product owner et l’équipe de réalisation ensemble travaille ensemble son affinage ; cela permet en effet d’avoir des demandes écrites mieux comprise par l’ensemble des acteurs du projet… Et donc que les réalisations soient beaucoup plus fluides. Nous appelons ce principe scrum : le product backlog refinement.
Voici un article complet sur le sujet et qui vous propose de nombreux articles autour de ce product backlog :
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.
Il est très important de comprendre que le sprint backlog est lié à la réalisation du produit ; ainsi, seule l’équipe de réalisation en est responsable. Si le product owner veut le modifier, il devra le faire avec l’accord de l’équipe de réalisation.
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. Pour faire simple, c’est le produit dans un statut stable avec l’ensemble des ajouts que nous avons à la fin de chaque sprint.
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
Conclusion scrum
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 ?
N’hésitez pas à nous proposer des évolutions de ce long article en commentaire. Il s’améliorera grâce à vos différents feedbacks.
Lien utile : exercice corrigé scrum en anglais
Bonjour.
Je n’arrive pas à trouver les épisodes de lecture du scrum guide en français sur votre chaîne youtube. Le dernier chapitre que vous lisez est l’annulation de Sprint dans la vidéo :
https://youtu.be/_pTS7XBJ2RY
La suite de cette épisode 5 je ne retrouve pas qui parle du chapitre « Planification du Sprint » jusqu’à la fin du guide.
J’ai parcouru tous vos vidéo. Vous faite un excellent travail.
S’il y a les épisodes 5 6… non partagés ou qui ne sont pas dans la playlist « scrum guide français : scrum guide francais http://www.youtube.com/playlist?list=PL9Q_Ei1JWJ4f5VcugVY84ipKEOfsPvphG » elle contient seulement 4 épisodes et la lecture du guide n’est pas terminé merci de le partager le reste des vidéo de lecture dans cette playliste.
Merci d’avance.
Bonjour Akram,
Le 5ème épisode arrive le 4 mai. Tous épisodes apparaitront au fur et à mesure sur la chaine youtube. Si tu es abonné et que tu reçois les notifications, tu les auras 🙂
La vidéo à été strike ? Possible de l’avoir en download / private / … ?
En effet, j’ai remis à jour l’article 🙂