Les 3 piliers de Scrum permettent à l’empirisme de vivre. Rappelons ce qu’est l’empirisme d’après le Scrum Guide : “L’empirisme affirme que la connaissance provient de l’expérience et que la prise de décision s’appuie sur l’observation de faits”. Les exemples d’applications seront liés les uns aux autres.
Aujourd’hui, je vous propose de petites descriptions ainsi que des exemples de situations mettant en action les piliers SCRUM, toujours dans un contexte bien défini pour pouvoir se projeter un minimum. N’hésitez pas à me faire des retours pour rendre ces concepts accessibles au plus grand nombre ! #ameliorationcontinue #iteration
Ces exemples sont tirés de mon expérience personnelle et modifiés pour l’article.
Chaque mot avec un “*” est expliqué à la fin de l’article.
Le contexte
Nous sommes une équipe Agile utilisant le cadre de travail Scrum (plusieurs développeurs, un Scrum Master, un Product Owner). Nous développons une application de rencontres, nommée “GeekLuv”, très similaire à Meetic mais visant plutôt un public de fans de pop culture ! L’application dispose d’une belle mise en avant des profils, et surtout elle permet de “matcher” grâce à une liste de goûts en commun et un système de notation ! Possibilité de réunir deux fans ayant une estimation de 10/10 de Keanu Reeves.
Nous sommes en Janvier 2020 (deux mois avant le premier confinement) et l’activité tourne très bien, les livraisons de nouvelles fonctionnalités s’enchaînent et nous pensons pouvoir devenir l’application numéro 1 sur les différents stores d’application pour Smartphone.
L’équipe est bien entendu en maitrise des valeurs et piliers SCRUM.
Transparence
Tous les membres de l’équipe et les parties prenantes ont accès aux informations relatives au projet, y compris les spécifications du produit, les objectifs de l’équipe, les problèmes rencontrés et les résultats vérifiés des diverses hypothèses.
La progression est partagée régulièrement. Cette approche honnête permet d’envisager des solutions adéquates aux problèmes rencontrés et évite de déclencher des peurs inutiles : de toute façon, nous rencontrerons des problèmes imprévus, alors il vaut mieux être soudés et solutionner ensemble. Nous avons, ensemble, les mêmes objectifs.
La transparence permet d’avoir toutes les informations nécessaires pour prendre les meilleures décisions possibles.
Dans Scrum, c’est à travers l’état des trois artefacts que cela se reflète le plus : le product backlog*, le sprint backlog* et l’incrément*.
Comme le précise le Scrum Guide : “La transparence permet l’inspection. Une inspection sans transparence est trompeuse et source de gaspillage”.
Je pourrais résumer la transparence par “les collaborateurs savent ce qu’il se passe“.
Exemples :
- Les développeurs remontent l’indisponibilité d’une librairie de développement (ensemble de fonctions et de classes déjà codées dans un langage spécifique) : Gros problème, la librairie Open Source “EzIdentity” qu’on utilise depuis le début du projet est dépréciée depuis peu. L’équipe qui s’occupe de celle-ci rencontrait des problèmes financiers, la pandémie a fourni le coup de grâce… Plusieurs articles sur internet révèlent des failles de sécurité importantes ! En effet, il est possible de récupérer des données personnelles avec quelques commandes javascript depuis la console de Google Chrome… L’équipe communique cet imprévu. Il faut identifier les failles de sécurité et voir pour les résoudre. À moyen terme, il faudra changer de librairie : actuellement, l’équipe ne dispose pas d’expert en sécurité (donc peut-être pas la compétence), et pourtant ça pourrait devenir la nouvelle priorité… Le product backlog* doit être mis à jour pour prévoir le travail supplémentaire.
- Le Product Owner explique le contexte aux parties prenantes : L’équipe de développement a repéré un point critique de sécurité dans notre application. Nous allons devoir changer la priorité de certains éléments du backlog et créer de nouvelles tâches pour nous concentrer sur la sûreté de notre application : des données sensibles pourraient être piratées…”
Inspection
L’inspection demande l’examen régulier et systématique du travail accompli, des outils et des processus utilisés. Cela permet à l’équipe de détecter les problèmes, les erreurs ou les défauts dès que possible.
Dans Scrum, ce sont les 5 événements* qui simplifient l’inspection.
Comme le précise le Scrum Guide : “L’inspection permet l’adaptation. Une inspection sans adaptation est considérée comme infructueuse. Les événements Scrum sont conçus pour provoquer le changement”.
Je pourrais résumer l’inspection par “Observer et interpréter pour améliorer“.
Bien sûr, sans transparence, l’inspection ne peut être efficace !
Exemples :
- Lors de la Sprint Retrospective, les développeurs réfléchissent sur l’incident du sprint, la faille de sécurité : “Est-ce qu’on pourrait être proactifs sur ce genre de problèmes ?“, “Avons-nous des compétences en sécurité ?“, “Comment vérifier qu’une bibliothèque a vérifié sa sécurité ?“
- Lors de la Sprint Review, le représentant des utilisateurs remonte des problèmes d’accessibilité sur l’application. En effet, les personnes daltoniennes ne peuvent pas consulter le profil des autres personnes. L’application est donc inutilisable pour ce public. Une discussion a lieu entre développeurs et représentant utilisateur pour trouver une solution.
- Pendant le sprint, un développeur prévient les autres développeurs qu’il est bloqué à cause d’un manque de compétence en PHP. Il s’est peut-être un peu surestimé pour cette tâche.
Adaptation
Suite à une inspection régulière de l’équipe, du produit et des processus, l’équipe peut prévoir les ajustements nécessaires et éventuellement réviser les objectifs ou les changer et adapter les priorités pour les prochains sprints, prendre des mesures correctives appropriées, améliorer la qualité du produit et éviter les dérives importantes. L’adaptation est le moteur de l’amélioration continue.
Ajuster ses plans et prendre des mesures pour maximiser la valeur produite. Ces ajustements permettent de s’adapter aux nouvelles informations, aux besoins changeants des parties prenantes et aux défis rencontrés sur le terrain.
Avons-nous amélioré notre situation ? Pouvons-nous produire plus de valeur grâce aux changements ?
Je pourrais résumer l’adaptation par “Nous proposons une meilleure stratégie dès que possible ou nécessaire“. La transparence et l’inspection permettent l’adaptation.
Exemples :
- Le Product Owner met à jour le Product Backlog pour répondre aux problèmes de faille de sécurité.
- Les développeurs prennent en compte la remontée de problème d’accessibilité pour les personnes daltoniennes de l’application et mettent en place les changements appropriés.
Pour conclure sur le contexte
Tout le contexte met en scène les piliers SCRUM, nous pouvons nous poser les questions suivantes :
Est-ce qu’on aurait pu prévoir la faille de sécurité ? Inspection Est-ce que cacher ce détail à l’entreprise et « terminer » le produit dans les temps aurait été bénéfique ? Transparence Est-ce que cette transparence améliorera le futur du produit ? Adaptation Est-ce que l’adaptation permettra au produit de vivre à long terme ? Certainement oui. Est-ce qu’un manque de transparence et d’adaptation a permis d’éviter un problème potentiellement bien plus grand dans le futur ? L’équipe agit avant qu’un scandale puisse éclater.
J’espère que ces exemples vous aideront à y voir plus clair. Le cadre de travail ne peut vivre sans les piliers SCRUM, Il est important de préciser que le manque de transparence annihile, voire peut même aller jusqu’à annuler l’inspection et l’adaptation, et donc l’empirisme.
Sources
Vocabulaire :
Sprint Rétrospective : événement permettant à l’équipe de réfléchir sur le sprint terminé, d’identifier ce qui a bien fonctionné, ce qui peut être amélioré et de mettre en place des actions correctives pour les futurs sprints.
Product Backlog : définition du Scrum Guide : Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit.
Sprint Backlog : définition du Scrum Guide, Le Sprint Backlog est composé de l’Objectif de Sprint (le « pourquoi »), de l’ensemble des éléments du Product Backlog choisis pour le Sprint (le « quoi »), ainsi que d’un plan d’action pour la réalisation de l’Increment (le « comment »).
Incrément : définition du Scrum Guide, Un Increment est une étape concrète vers l’Objectif de Produit. Chaque Increment s’ajoute à tous les Increments précédents et fait l’objet d’une vérification approfondie, ce qui garantit que tous les Increments fonctionnent ensemble. L’incrément est donc le résultat de l’incrément en cours + les incréments précédents ( les fonctionnalités du produit )