Scrum

L’agilité est la capacité d’une organisation à fournir tôt et souvent des services ayant un véritable impact sur ses utilisateurs, tout en s’adaptant à temps aux changements dans son environnement.

Scrum est l’une des méthodes agiles existantes. Il en existe plusieurs mais c’est la plus utilisée actuellement. Il n’existe pas de Scrum académique, seul le cadre est défini : tous les projets sont différents et constituent un contexte unique pour mettre en place les pratiques. Il y a 3 piliers : la transparence, l’inspection et l’adaptation. La transparence permet l’inspection qui permet l’adaptation.

Scrum n’est peut être pas fait pour votre organisation. Si une entreprise est trop dans le contrôle ou toujours dans l’urgence et les interruptions, alors il ne faut pas appliquer Scrum. Du moins pas avant d’avoir changé ces points. En effet, pendant un sprint (nous reviendrons sur ce que c’est), il n’y a pas d’interruption, pas de changement. Le changement s’effectue en fin de sprint.

L’élément central du Scrum est l’équipe. Tout tourne autour de cela. L’équipe s’autogère, les membres de l’équipe décident qui fait quoi, quand et comment. Même si c’est rare, une équipe peut donc travailler sur plusieurs projets en même temps. Le Scrum s’applique à l’équipe, pas au produit ou au projet.

Quelques définitions et principes

User Story : c’est un objectif final (pas une fonctionnalité qui est un ensemble de stories) exprimé du point de vue de l’utilisateur du logiciel. Elles sont généralement de type story mais peuvent aussi être de type bug, dette technique et exploration technique (spike). Les stories ne sont pas uniquement fonctionnelles, il y a aussi des stories non fonctionnelles (sécurité, maintenabilité, performance). Quand la story n’est pas affinée (trop grosse) mais qu’elle n’est pas non plus de la taille d’une fonctionnalité, on parle d’Epic.
Sprint : C’est une période de temps pendant laquelle l’équipe travail sur les users stories. La spécification, l’architecture, le codage, les tests se font à l’intérieur des sprints (de manière non séquentielle). En général, un sprint dure 2 semaines.
Saison : C’est une période de temps constitué de plusieurs sprints. En général 3 mois, ce qui équivaut à 6 sprints.
Backlog : Le backlog est une liste de tâches priorisée (des users stories), utilisée par l’équipe pour développer le produit. Le backlog est souvent séparé en deux parties : des stories pour l’équipe, des features pour les parties prenantes (clients, utilisateurs, investisseurs). Il fortement conseillé d’avoir un seul backlog et d’éviter qu’il soit trop gros (moins de 100 items). Il faut aussi éviter que le backlog soit rempli de tickets de bug (ce n’est pas un bug tracker !). On s’en doutait aussi mais Excel n’est pas le bon outil pour gérer un backlog. Enfin, un backlog est ouvert, vivant et par définition ne serait jamais vide tant que le produit existe.
Sprint Planning : C’est une réunion où toute l’équipe collabore et discute du travail prioritaire souhaité pour le sprint et définit l’objectif du sprint. En général cela dure 4h et à lieu une fois par sprint.
Daily Scrum : C’est une réunion qui a lieu tous les jours, d’une durée de 15min, de préférence debout afin de discuter de l’avancement des stories.
Sprint Review : C’est une réunion où l’équipe se concentre sur le produit en cours de développement, en particulier sur la mise à jour créée pendant le sprint. L’équipe invite les parties prenantes à discuter de ce qui a été réalisé pendant le sprint et adaptent le backlog en fonction de ces retours. Souvent il y a une démo. Cela dure 2h en moyenne et a lieu une fois par sprint.
Sprint Restrospective : C’est une réunion où l’équipe analyse ce qui s’est passé et ce qu’elle aimerait améliorer pour l’avenir. On parle en terme de fonctionnement. Cela dure 1h la plupart du temps et a lieu également en fin de sprint. L’idée est de sélectionner une amélioration à faire pour le prochain sprint.

Comment se passe un sprint ?

On part souvent d’idée qui deviennent des fonctionnalités devennant à leur tour des Epics, qui deviendront des users stories. C’est le rôle du Product Owner (PO) d’affiner et de prioriser tout cela. Il va pour cela utiliser un bac à sable / sandbox (bac à idées), un bac d’affinage / grooming backlog (pour affiner et obtenir des users stories), un bac de départ / sprint backlog (quand la story est prête pour le sprint) et un bac à glace (icebox) (quand on veut stocker les éléments afin qu’ils ne soient pas être supprimés, souvent c’est une idée validée mais reportée à plus tard).

Sur un Sprint de 2 semaines, cela s’enchaîne de cette façon : Sprint Planning x1 –> Daily Scrum x8 –> Sprint Review x1 –> Sprint Restrospective x1. L’implémentation des users stories se fait en continue.

Le Sprint Planning permet à l’équipe de choisir un objectif de sprint et de définir le sprint backlog.
Le Daily Scrum permet à l’équipe de discuter sur la façon d’aboutir à l’objectif de sprint en fin de sprint.
Le Sprint Review permet à l’équipe de parler de l’incrément produit qui vient d’être développé dans le sprint et d’envisager quoi faire dans le prochain.
Le Sprint Restrospective permet à l’équipe d’échanger sur la façon dont ils peuvent améliorer leur efficacité lors du prochain sprint.

La mise en service (release en prod) est souvent décorélée du sprint. En fin de sprint, il est d’usage de déployer en staging la nouvelle version afin d’obtenir les feedback. Le déploiement en prod se fait généralement quand une feature est terminée. Le déploiement et l’intégration continue (CI/CD) est l’aboutissement recherché.

Que se passe-t-il avant le 1er sprint ?

Il n’y a pas de règle mais voici ma vision : faire Lean startup en sprint court afin d’obtenir un MVC le plus rapidement possible. Une fois le MVC terminé et validé, lancer un prélude de 2 semaines afin de constituer l’équipe, le backlog de features pour la saison et de stories pour le 1er sprint, et l’environnement de travail. A l’issue de ce prélude, lancer le 1er sprint.

Cela ressemble à quoi ?

Il n’y a pas qu’une façon de faire. Scrum n’impose rien. Tout comme le dev, tout se fait généralement en anglais.

Backlog de fonctionnalités (pour les parties prenantes)

Prêtes (Ready)	En cours (In Progress)	Finies (Done)
As a User, I want to have a dashboard so that I can see relevant KPIs about my readers and my posts. As a User, I want to have a payment system so that I can publish paid articles that readers will have to pay to read it	As a User, I want to have a content management system so that I can manage posts to provide quality content to my readers. As a User, I want to have a backoffice so that I can manage everything related to administration.	As a User, I want to have a auth system so that I can connect to the backoffice.

En lien avec ce backlog de fonctionnalités, l’équipe Scrum utilise un backlog pour le produit.

Backlog produit / stories (pour les l’équipe Scrum)

Bac à sable (Sandbox)	Affinage (Refinement)	Prêtes (Ready)	En cours (In Progress)	Finies (Done)	Bac à glace (Icebox)
As a User, I want to have a payment system so that I can publish paid articles that readers will have to pay to read it.	As a User, I want to have a backoffice so that I can manage users and rights.	As a User, I need to be able to download Google analytics reports so that I can see relevant KPIs about my readers and my posts. As a User, I need to be able to see Google analytics KPIs in my backoffice so that I can see relevant KPIs about my readers and my posts. As a User, I want to have a backoffice so that I can manage medias.	As a Content Owner, I want to be able to create content so that I can provide information to readers. As a Content Owner, I want to be able to upload images so that I can use them in my post.	As an Editor, I want to review content before it is published so that I can assure it is correct. As a User, I want to have a auth system so that I can connect to the backoffice. As a User, I want to have a recovery password tool so that I can connect to the backoffice.	As a User, I want to connect to my backoffice with SSO so that I can connect more easily.

Parfois, il est intéressant d’être plus spécifique et de décrire le détail des travaux à effectuer pour une story. On appelle ces morceaux de story des tâches.

Backlog de tâches (Tasks)

Stories Prêtes (Ready)	Stories pour le Sprint	Tâches – A faire (Todo)	Tâches – Prêtes (Ready)	Tâches – Finies (Done)	Stories finies (Done)
As a User, I need to be able to download Google analytics reports so that I can see relevant KPIs about my readers and my posts. As a User, I need to be able to see Google analytics KPIs in my backoffice so that I can see relevant KPIs about my readers and my posts. As a User, I want to have a backoffice so that I can manage medias.	As a Content Owner, I want to be able to create content so that I can provide information to readers. ————- As a Content Owner, I want to be able to upload images so that I can use them in my post.	Design the UI of the frontend Automate tests ——— Update security Design the UI	Code the backoffice ——— Code the backoffice	Code the front ——— Configure a cloud object storage	As an Editor, I want to review content before it is published so that I can assure it is correct. As a User, I want to have a auth system so that I can connect to the backoffice. As a User, I want to have a recovery password tool so that I can connect to the backoffice.

Vous l’aurez remarqué, on utilise par convention cette tournure de phrase : As a <persona> I want to <goal> so that I can <benefit>.

En Scrum, on voit parfois une colonne “A Tester”, cela n’est pas conseillé pour différentes raisons.

Une story doit être de 3 jours au grand maximum. Une tâche doit durer au maximum 1 jour. Des changements mineurs (feedback de revue) sont regroupés en une seule story. On peut aussi créer des story de réserve vide pour y ajouter des imprévus (un bug urgent) car les bugs n’existent pas par définition sur une story qui n’est pas à l’état terminé. Si le bug est non critique il est à mettre dans le backlog, s’il est critique, on peut utiliser la story de réserve. Dans tous les cas, il faut modifier les conditions d’acceptation pour ne pas que ça se reproduise.

Qu’est-ce que story prête ? (Definition of Ready – DoR)
Pour qu’une story soit prête, elle doit être décomposée, débattue, dérisquée, avec une définition de fini, démontrable et désirable. Une fois prête l’équipe Scrum peut lancer son implémentation.

Qu’est-ce que story finie ? (Definition of Done – DoD + Acceptance Criteria)
Pour qu’une story soit finie, il faut pouvoir vérifier si elle fonctionne et si elle est utilisable. Cela se fait au fait au fur et à mesure et pas à la fin du sprint. Il faut donc donner une définition de ce qui fait que l’on considère un story comme terminée : les conditions d’acceptation, la qualité externe (utilisable), la qualité interne (maintenable). Si la story n’est pas terminée, on crée une story de type dette technique dans le prochain sprint. Une feature est terminée quand toutes les stories sont terminées et que le déploiement a été effectué.

Une DoD concerne le produit, de ce fait de nombreuses stories vont partager la même DoD, on peut alors faire des listes génériques : des storyotype. Par exemple : coder en suivant le standard de l’entreprise, avec une revue de code effectuée, avec des tests unitaires passées avec succès, avec des tests d’acceptation passés avec succès, avec une documentation utilisateur rédigée, avec une traduction effectuée, etc.

Les conditions d’acceptation (acceptance criteria) ne concerne qu’un item du backlog, il permet de vérifier que cet item est utilisable. Voici un exemple.

User story : As a User, I want to have a recovery password tool so that I can connect to the backoffice.

Acceptance criteria :
Scenario : The user forget his password and get a recovery link.
Given that I don’t remember my password
When I click the Forget my password button
Then I received an email with a recovery link

Quel outil ?

Tout sauf Excel :). Scrum n’impose pas d’outil, au contraire, à l’origine Scrum encourage le présentiel et un environnement de travail favorable à son application. Un tableau blanc et des post-it de couleurs suffisent. Sinon Trello et Jira sont des logiciels fréquemment utilisés dans le cadre de Scrum.

Les KPI en SCRUM

L’estimation du temps n’est pas utile avec la méthodologie Scrum. Cela a l’avantage d’éviter le micro management et le suivi individuel. Oui, il n’y a pas de mesure individuelle (temps passé, etc) ! Que du collectif. De ce fait il n’y a pas non plus besoin de comité de pilotage ou de suivi. Bref, pas de bullshit, pas de micro-planification.

Des indicateurs collectifs existent cependant afin d’avoir une idée globale de la direction que prend le projet :
– burnup de sprint (à préféré au burndown chart)
– nombre de stories finies / nombre de tâches finies
– Nombre de conditions d’acceptation passées
– L’humeur de l’équipe (par exemple en utilisant teammood)
– La vélocité en termes de nombre de stories (attention ce n’est pas une mesure de productivité : des grosses stories peuvent apporter 0 valeur, il n’y a pas forcément de corrélation)

Encore une fois, il n’y a jamais de mesure individuelle, ni de mesure de temps, ni d’estimation en temps. Pourquoi ? Car tout simplement ces mesures ne sont pas fiables et prennent du temps à faire. Imaginons que l’on mette en place ces mesures et que l’on observe des écarts entre le prévu et le réel : on ne peut pas dire si cela est dû à un problème d’estimation, un problème de compétence, un problème de définition du travail… il faut mieux se concentrer sur produire quelque-chose que de faire des estimations qui ne servent a rien.

L’équipe Scrum

Une équipe scrum c’est généralement 3 à 10 personne avec un Product Owner (PO), un Scrum Master (SM) et une équipe autonome et pluri-disciplinaire. Le PO se charge de savoir comment augmenter la valeur, pour cela il doit savoir ce que veulent les utilisateurs et transmettre ces informations à l’équipe. Le SM fait en sorte que le développement se fasse sans encombre, notamment en appliquant Scrum. Dans une équipe Scrum il n’y a pas de chef, le PO ou le SM sont au même niveau que tout le monde.

Autre précision, avec Scrum, il n’y a pas de phase de maintenance. Il n’y a donc pas d’équipe dédiée à cela. Logique. De la même façon il n’y a pas d’architecte en dehors de l’équipe. L’équipe doit être autonome et pluri-disciplinaire pour ne pas être bloquée par des éléments externes.

Enfin, l’alignement culturel de l’organisation n’est pas obligatoire au départ mais a terme cela le deviendra. Sans quoi des obstacles d’organisation empêcheront l’équipe de mener à bien son travail.

Si plusieurs équipes sur un produit

Parfois il y a plusieurs équipes pour un produit. Ce n’est pas conseillé mais dans le cas où le produit est tellement important alors il est possible de mettre en place ce système. Voici quelques conseils pour ne pas retomber dans des travers “non agiles” :

• Cela reste du Scrum, plus précisément du scrum de scrums
• Ne pas ajouter de nouveaux rôles
• Continuer d’avoir des équipes autonomes pour développer une feature de bout en bout (feature team)
• Ne pas faire d’équipe “composant”
• 1 Product Owner (PO) est possible jusqu’a 3 équipes Scrum. Sinon il faut avoir un PO par feature ainsi qu’un PO de PO = PM (Product Manager)
• Avoir le même rythme de sprint pour toutes les équipes
• Avoir un backlog de features commun
• Avoir un backlog stories / tasks commun ou séparé, c’est au choix du PM.
• Avoir une définition de prêt et de fini identiques pour tous
• Pour les daily scrum, chaque équipe fait sa mêlée habituelle puis il y a une mêlée de mêlée avec un seul membre par équipe

Dans la plupart des situations, on va chercher à éviter le scaling agile : un projet peut être décomposé en sous projet indépendant, ce qui revient à faire du scrum classique sur chacun d’eux.

La mauvaise application de Scrum

Les risques de mal faire du scrum sont nombreux. Voic comment appréhender les principaux :

• Le misonéisme (résistance à l’innovation). Scrum introduit une innovation social. Il faut donc expliquer pourquoi l’entreprise a choisit de faire de l’agile.
• L’ignorance : Il faut connaître Scrum. Pas juste le principe. Sinon cela est mal appliqué et ne fonctionne pas. Il faut donc se former.
• La peur : Scrum fonctionne si tout le monde est en confiance. Le contrôle, la hiérarchie ne contribuent pas à cela. Il faut donc que la culture de l’entreprise soit alignée avec l’agilité
• Le ratatinement : Scrum doit être responsable de toute la chaine de valeur, de l’idée du projet à son déploiement. Pas juste pour la partie dev. Il faut donc mettre cela en place dès le départ et mettre en place des pratiques de devops comme le déploiement continu
• L’orgueil : Il est possible d’adapter scrum mais cela doit être fait avec humilité, une fois que l’équipe ou l’entreprise maitrise parfaitement Scrum. Pas avant.