Les principes du framework "Scrum"
La philosophie de scrum
Scrum est un « framework » et non une méthode, c’est à dire que c’est un ensemble de règles et de principes définis dans le « Scrum Guide » à s’approprier pour réussir à créer des produits adaptés qui créent de la valeur pour ses utilisateurs.
Le principe est assez simple, il se base sur une vision dite « empirique »: avancer au fur et à mesure de l’expérience et en s’améliorant en continu afin d’atteindre un « product goal ». Le Product Goal est essentiel dans scrum, c’est l’objectif final du produit à developper.
Pour cela scrum préconise une approche itérative et incrémentale. C’est à dire qu’il faut répéter des cycles de travail (sprint) afin de créer de la valeur à chaque cycle (incréments) jusqu’à obtenir un résultat satisfaisant.
Apparu dans les années 1990, le framework scrum a été partagé puis largement appliqué dans le monde entier, notamment pour du développement logiciels. Mais la philosophie de scrum peut s’appliquer bien au-delà des produits digitaux et vous allez comprendre pourquoi…
Avec les approches plus classiques comme le « waterfall » ou cycle en V (voir article waterfall-vs-agile-vs-hybride), le but est de définir et de prévoir à l’avance comment doit se dérouler le projet en termes de délai, de cout, mais aussi de périmètre. Cela nécessite donc (en théorie…) d’avoir peu d’incertitudes dès le début du projet.
Dans le cas d’un produit digital par exemple, il est difficile de savoir à l’avance la solution qui va satisfaire les utilisateurs.
Scrum apporte donc une réponse à cette nécessité de s’adapter et de réduire le risque de développer une mauvaise solution.
1. Les 3 piliers de scrum
Ce framework est régi par 3 piliers fondamentaux : la transparence, l’inspection et l’adaptation.
Sans transparence, il n’y a pas d’inspection, sans inspection, il n’y a pas d’adaptation. Et l’adaptation est la clé de la réussite d’un produit adopté par les utilisateurs.
Comment garantir la transparence ?
L’ensemble du travail à faire ainsi que son état d’avancement doit être accessible et visible par l’ensemble de l’équipe et des parties prenantes de façon claire et vérifiable.
L’ambiguïté ou le mensonge (comme par exemple décorer les chiffres pour les rendre plus positifs) sont, par expérience, les pires choses à faire si vous voulez la réussite de votre produit.
Pour garantir cette transparence, le travail déjà réalisé et restant à faire sont repartie en 3 « artefacts » :
Comment permettre l’inspection ?
L’inspection doit être régulière afin d’anticiper les écarts, obtenir des retours des utilisateurs (feedbacks) et permettre une meilleure réaction de l’équipe. Pour réaliser cette inspection de façon efficace, il existe des cérémonies à réaliser dans chacun des sprints :
Encore une fois, le but de ces inspections n’est pas de trouver des fautifs ou des erreurs, mais de s’assurer que l’équipe avance toujours vers le « product goal ».
Comment s’adapter ?
Scrum encourage les équipes à être auto – organisées afin de pouvoir prendre des décisions plus rapidement en fonction des obstacles.
L’objectif est de pouvoir s’ajuster lors des cérémonies d’inspection dès que l’équipe s’écarte du « product goal » grâce aux retours réguliers des utilisateurs afin de toujours être dans une position de création de valeur.
Si votre environnement demande des changements fréquents et que vous souhaitez pourtant tout verrouiller à l’avance, Scrum sera difficile à adopter.
2. L'équipe scrum
Il n’y a pas vraiment de notion de rôle dans scrum, mais plutôt de responsabilités. La « scrum team » se compose d’un Product Owner, d’un Scrum Master et de Développeurs.
Le Product Owner : le « PO » pour les intimes, est responsable de maximiser la valeur du produit. Son rôle est de communiquer clairement le product goal, de créer, d’ordonner et prioriser le product backlog en rédigeant les items de travail (les user stories) et leurs critères d’acceptation.
C’est lui, l’unique représentant des besoins des utilisateurs pour l’équipe. C’est à lui que revient la responsabilité de trancher sur les fonctionnalités à prioriser.
Le PO doit être quelqu’un de structuré avec une excellente capacité de restitution et une communication adaptée aux différents interlocuteurs (utilisateurs, développeurs, managers, commerciaux, designers…).
Le Scrum Master : le scrum master est aussi un élément important de l’équipe, il est le garant de la bonne mise en place de scrum. Son rôle est d’aider l’équipe à avancer sereinement au travers des cérémonies en levant les obstacles opérationnels remontés par l’équipe.
Il a également un rôle de coaching pour permettre à l’équipe et au product owner d’être le plus efficace possible selon les pratiques scrum.
Le scrum master doit être très pédagogue pour inculquer les principes de scrum à l’équipe et il doit aussi être organisé pour aider l’équipe dans sa réalisation.
Les Développeurs : « développeur » est un terme générique qui englobe tous les membres de l’équipe qui ont un rôle à jouer dans la réalisation de l’incrément. Par exemple les testeurs, architectes, backend dev, frontend dev, UX designer, Ingénieur devops, etc…
L’équipe de développement est auto organisée, elle est responsable de la « definition of done » ce qui correspond aux règles à remplir pour livrer un incrément fonctionnel à l’utilisateur.
Les Développeurs doivent pleinement adhérer à la philosophie de scrum pour réaliser les fonctionnalités sélectionnées pour atteindre les sprint goals et communiquer lors des cérémonies en partageant leurs avancements et leurs freins.
3. Les cérémonies
L’ensemble de scrum est rythmé par les cérémonies. Il en existe plusieurs qui se répètent à chaque sprint pour garantir l’inspection régulière du travail effectué.
Avant toute chose il faut comprendre la notion de « sprint » : le sprint est un principe fondamental dans la réalisation de scrum. Il correspond à une période de temps définie pour chaque cycle d’itération qui se répète immédiatement les uns derrière les autres.
Un sprint peut durer en générale entre 1 semaine et 4 semaines en fonction du besoin et de ce que l’équipe a décidé.
Attention, il n’y a pas de pause entre les sprints.
La Sprint planning : la sprint planning est la première cérémonie d’un sprint. Elle permet de planifier l’ensemble du travail à réaliser sur le sprint en définissant l’objectif du sprint et les items à developper.
L’ensemble de l’équipe s’engage à livrer l’ensemble du travail planifié à la fin du sprint.
La Daily scrum : Il s’agit d’une cérémonie quotidienne d’environ 15min qui a lieu à la même heure, pour permettre aux Développeurs d’échanger sur le travail déjà réalisé et restant à faire sur le sprint en cours.
Les Développeurs remontent également au Scrum Master les obstacles qu’ils rencontrent. Le Product Owner ainsi que les utilisateurs ne sont normalement pas présents pour cet évènement.
La Sprint review : le but de la sprint review est de présenter aux utilisateurs et aux parties prenantes, l’incrément réalisé sur le sprint afin d’obtenir des retours sur le fonctionnement et la valeur livrée.
Les avis et retours les plus pertinents sont pris en compte par le product owner et intégrés au backlog.
La Sprint retrospective : La retrospective arrive à la fin du sprint pour l’équipe scrum. La « retro » permet de revenir sur le déroulement du sprint et de collaborer sur ce qui s’est bien passé et sur ce qui peut être amélioré au prochain sprint. Cela concerne les processus, les outils ou les ressources utilisées pour permettre à l’équipe d’être de plus en plus efficace à chaque sprint.
4. Les artefacts
Comme expliqué précédemment, les « artefacts » garantissent la transparence. Ils sont les uniques sources de communication du travail réalisé et du reste à faire. Il existe 3 artefacts :
Le product backlog : le product backlog est primordiale, il est l’unique source de l’ensemble du travail à faire.
C’est une liste structurée d’items ou de fonctionnalités qui sont plus ou moins définies, mais qui sont ordonnées et priorisées. Cette liste n’est évidemment pas figée, elle est mise à jour tout au long des sprints et ne doit répondre qu’à un seul et unique objectif : le product goal.
C’est le product owner qui est l’unique responsable du product backlog et qui assure qu’il est constamment à jour et accessible à toutes les parties prenantes.
Le sprint backlog : le sprint backlog est inhérent au product backlog. Il correspond au travail sélectionné durant la sprint planning pour être développé sur le sprint en cours.
Le sprint backlog est construit par les Développeurs avec le product owner lors de la sprint planning selon un objectif de sprint à atteindre à la fin du sprint.
L’incrément : l’incrément correspond à une version utilisable du produit final mise à disposition des utilisateurs ou de leurs représentants. L’incrément représente l’ensemble de la valeur délivrée lors du sprint.
C’est l’ensemble des incréments délivrés qui composent la valeur du produit final mis à disposition des utilisateurs.
Conclusion
Scrum apporte une philosophie différente des approches classiques avec un mode itératif et incrémental basé sur l’apprentissage, une équipe auto-organisée et qui se concentre sur l’essentiel qui est le product goal.
Scrum est une approche qui a fait ses preuves et qui est très efficace lorsque l’incertitude est élevée. Cependant scrum nécessite une compréhension et une pleine adoption de sa philosophie par l’ensemble des parties prenantes et non pas uniquement de l’équipe scrum, pour en obtenir tous les bénéfices.
Le manque de compréhension de la philosophie scrum et certaines typologies de projets contraints par de lourdes procédures administratives sont les principales causes d’échec des équipes qui adoptent scrum.
Et vous, quelles ont été vos expériences avec scrum ?
Super intéressant !