Scrum : le guide complet !

Scrum est un framework de développement de produit qui repose sur le découpage du travail à accomplir et la mise en place d’un cycle de travail régulier. Aujourd’hui utilisée par 75% des entreprises ayant adopté des pratiques agiles selon cette étude, Scrum est particulièrement indiqué pour le développement de produits complexes. Une méthode en plein développement qui facilite la création de produits dans des contextes compliqués: est-ce de la magie? Non, mais bien utilisée, c’est un outil très efficace.

Etymologie et histoire de Scrum

La première utilisation du terme Scrum dans un contexte de gestion de projet date du milieu des années 80. Le mot Scrum désigne la mêlée au rugby, et a dès lors été employé pour désigner une méthode dans laquelle l’équipe se réunit régulièrement pour définir son travail et les modalités de sa collaboration. La méthode a commencé à être formalisée dans les années 90, notamment sous l’impulsion de Ken Schwaber et Jeff Sutherland, qui continuent encore aujourd’hui à mettre à jour le Scrum Guide, dont la première version officielle ne date que de 2010. Scrum est donc un framework évolutif, dont les préceptes sont régulièrement mis à jour.

Les piliers de Scrum

Scrum repose sur trois piliers : la transparence, l'inspection et l'adaptation.

La transparence

Les éléments importants du processus doivent être visibles par tous. Ce pilier implique également la création d’une norme commune (un vocabulaire commun, par exemple) afin de s’assurer que tout le monde parle le même langage.

L’inspection

Les utilisateurs de Scrum doivent fréquemment inspecter les artefacts Scrum et l’état d’avancement par rapport à un objectif de sprint (Sprint Goal) afin de détecter les écarts indésirables. La fréquence de ces inspections doit être suffisamment courte pour réagir rapidement aux problèmes, mais pas trop rapprochée, afin de ne pas gêner le travail en cours. Il est préférable d’impliquer toute l’équipe dans ces inspections, afin de responsabiliser tout le monde sur l’avancement du produit.

L’adaptation

Si l’inspection souligne un ou plusieurs aspects du processus dérivant hors des limites acceptables, et qui risquent de détériorer la qualité du produit, le processus ou le matériel utilisé par le processus doit être ajusté. Un ajustement doit être fait dès que possible afin de minimiser le risque d’autres dérives.

Ces piliers se traduisent dans un ensemble de pratiques codifiées, qui s’articulent autour de 3 rôles, 3 artefacts et 5 cérémonies.

Les 3 rôles de Scrum

Les rôles codifiés par Scrum sont les suivants :

Le Product Owner (PO)

Il est responsable de la valeur métier apportée par le produit. Il exprime les attentes des utilisateurs pour orienter le travail à effectuer, priorise les tâches, aligne les parties prenantes autour de la vision produit et élabore les plannings et budgets. Il est également chargé de valider le travail effectué, ou au contraire de demander les ajustements nécessaires pour répondre aux besoins fonctionnels identifiés.

Tout savoir sur la journée type du Product Owner

Le Scrum Master (SM)

Il s’assure de l’application et du respect des valeurs et des pratiques Scrum, vérifie que les règles sont comprises et mises en oeuvre, et s’assure que l’équipe est fonctionnelle et productive. C’est lui qui est chargé de lever les obstacles qui s’opposent au bon travail de l’équipe. Il anime également la plupart des cérémonies. En un mot : c’est un facilitateur.

L’équipe de développement

Elle est pluridisciplinaire, colocalisée et à temps plein (dans l’idéal). Elle met en oeuvre toutes les actions nécessaires pour remplir son engagement au cours du sprint. Elle est en général composée de 3 à 9 personnes : en-dessous de 3 personnes, le degré de complexité de l’organisation est trop faible pour que Scrum apporte de la valeur. Au-dessus de 9 personnes, il est très difficile d’impliquer tout le monde à niveau égal et de maintenir une communication efficace.

Les artefacts

Les artefacts représentent l’ensemble des objets qui structurent la vision du produit à développer. Il s’agit des éléments ci-dessous :

Le product backlog

Liste priorisée d’éléments de travail plus ou moins finement découpés, qui représentent l’ensemble des fonctionnalités à réaliser à plus ou moins long terme. Scrum ne précise pas quelle forme doivent prendre ces éléments de travail, mais il s’agit principalement dans les faits d’Epics ou de User Stories.

Tout savoir sur le backlog, comment le construire et le gérer ?

Le sprint backlog

Il s’agit de la liste priorisée des éléments de travail que l’équipe s’est engagée à réaliser au cours du sprint. C’est une partie du product backlog, estimée et découpée en tâches, qui doivent être traitées par l’équipe de développement puis validées par le Product Owner.

L’incrément de produit

L’ensemble des fonctionnalités développées au cours d’un sprint, c’est le résultat du travail effectué sur le sprint backlog. Il doit être utilisable en tant que tel, que le PO décide de sa mise en production ou non. Il peut être mis à disposition d’utilisateurs sélectionnés pour obtenir du feedback, ou mis en production pour les utilisateurs finaux

Les 5 cérémonies

Scrum est une méthode très rythmée : le temps est découpée en sprints, itérations de 1 à 4 semaines durant lesquelles sont réalisés les incréments de produit, eux-mêmes cadencés par un ensemble de cérémonies qui se répètent avec une fréquence propre. Ces cérémonies sont les suivantes :

Le sprint planning

La planification du sprint est la première réunion du sprint, celle qui permet à l’équipe de s’engager sur l’objectif du sprint et s’accorder sur les stories associées. Elle se découpe en deux temps : explication et définition de l’objectif (le PO présente les US à l’équipe de développeurs et lève les incompréhensions, l’équipe estime les Stories prêtes) et création du sprint backlog (l’équipe sélectionne les US qu’elle s’engage à traiter durant le sprint et les découpe en tâches).

Le Daily Scrum Meeting (souvent appelé “Daily” ou “Stand up”)

Le Daily Scrum Meeting est une cérémonie quotidienne axée autour de l’équipe de développement qui a pour but de faire le point sur le travail effectué et les obstacles de l’équipe. Chacun y répond à trois questions :

1. Qu’est-ce que j’ai fait depuis le dernier daily Scrum meeting?
2. Qu’est-ce que je vais faire avant le prochain ?
3. Ai-je rencontré des difficultés/blocages ?

La revue de sprint

Ouverte à l’ensemble des parties prenantes intéressées, la revue de fin de sprint est la présentation du travail effectué pendant l’itération et permet la collecte de feedbacks et l’orientation du travail restant.

La rétrospective

Dédiée à l’équipe Scrum (équipe de développement, PO et SM), la rétrospective vise à améliorer les façons de travailler de l’équipe en capitalisant sur l’expérience des sprints passés. C’est une cérémonie cruciale pour la démarche d’amélioration continue de l’équipe.

L’affinage du backlog

Cette cérémonie ne dispose pas d’une récurrence particulière dans le sprint, elle s’effectue au besoin. Il s’agit d’un temps d’échange entre le Product Owner et l’équipe de développement afin de s’assurer de disposer de suffisamment d’US prêtes pour le sprint planning. Les stories prêtes doivent respecter les “6 D” :

1. Décomposée
2. Débattue
3. “Dérisquée”
4. Définition de finie existe pour elle
5. Démontrable
6. Désirable

Quelques indicateurs utiles

La régularité de Scrum lui permet de se prêter à la définition d’un certain nombre d’indicateurs de suivi utiles. Ces indicateurs ne sont pas des éléments imposés par le framework, mais des ajouts qui permettent de faciliter l’application de Scrum, et d’en multiplier la valeur ajoutée.

Parmi ces indicateurs, on retrouve :

• la vélocité
• le travail effectué par l’équipe pendant un sprint (qui se base sur l’analyse du passé)
• la capacité, le travail que l’équipe pourra effectuer au cours du sprint à venir (sur la base de sa vélocité antérieure et de sa situation actuelle, par exemple absence d’un membre).

Le management visuel permet de structurer le suivi du sprint et du produit, une équipe dispose généralement d’un tableau Kanban pour suivre l’avancée des tâches embarquées dans son sprint, et de graphiques du type burn-down / burn-up pour suivre l’avancée de sa réalisation.

Source : http://www.clariostechnology.com/productivity/blog/burnupvsburndownchart

La théorie, d’accord, mais en pratique ?

Scrum est une méthode exigeante : elle implique un rythme constant pour l’équipe et le respect d’un certain nombre de règles et de pratiques. Il est donc important de s’assurer que le rythme adopté est soutenable sur le long terme et de permettre à l’équipe de réfléchir sur le sens de ses pratiques ainsi que sur les adaptations qu’elle pourrait souhaiter (en particulier dans le cadre de la rétrospective)

Toutefois, il ne faut pas sombrer dans le laxisme. Le concept de ScrumButs ([« On utilise Scrum, mais … »][Raison qui justifie la déviation][Contournement]) illustre l’idée que des pratiques expérimentées ne doivent pas être abandonnées pour des ajustements arbitraires : la mise en place de Scrum suppose de trouver un équilibre entre souplesse et laxisme.

Evidemment, plus le projet est simple (équipe de développement de 3-4 personnes, stakeholders impliqués et disponibles, vision produit facilement partagée…), plus la mise en place de Scrum sera rapide et sans douleur. Malheureusement, cela veut aussi dire que dans des contextes plus compliqués, Scrum est souvent considéré comme un framework “trop simple” pour le projet, ce qui amène à faire les ajustements arbitraires mentionnés ci-dessus… Pourtant, la raison d’être de Scrum était de résoudre des problèmes complexes !

Schéma récapitulatif

Tout l’art de Scrum est donc de réussir à adapter les valeurs et les principes du framework pour construire une méthodologie pertinente, sans pour autant réaliser un nombre de compromis excessif et finalement de nuire à la construction du produit.

Scrum est souvent qualifié de facile à comprendre, mais difficile à maîtriser : cet article a pour but de vous donner les bases vous permettant de comprendre le framework, à vous maintenant de le pratiquer pour le maîtriser !