Étude de cas
Note, cette étude de cas est aussi disponible en format vidéo : https://youtu.be/kmdvC477_Ok
Le client est un site e-commerce reconnu qui existe depuis le début des années 2000 et qui compte plus d’un millier de collaborateurs, 20 millions de clients et plus d’un milliard d’euros de chiffre d'affaires en 2023.
Ce client a fait appel à Scrum Life pour les aider à réaligner un groupe de 17 personnes représentant différentes équipes sur les objectifs de l’entreprise . Le groupe est composé de développeurs, de designers et de Product Owners.
L’objectif était de les faire repenser l’organisation du travail et remettre en question quelques croyances limitantes, afin de permettre aux équipes d’améliorer le temps nécessaire pour livrer de la valeur aux utilisateurs.
Nous avons choisi un format mixte : formation théorique d’une journée et mise en pratique sur la seconde journée.
Quelques jours avant le début de l’atelier nous avons travaillé avec la Head of Product afin de bien cerner ses attentes, qui se concentrait sur la définition, pour les équipes, de la valeur attendue par l’entreprise.
Nous lui avons proposé de créer le Product Vision Board du produit principal de l’entreprise : le site marchand.
Nous avions de la chance, la Head of Product, bien que récemment arrivée dans l’entreprise, avait une très bonne vision et a su la retranscrire au travers du Product Vision Board.
Le premier jour de l’atelier était donc sous la forme d’une formation sur les bases de la gestion de projet. Le but étant dans cette journée de confronter l’idée des participants sur ce qu’est l’agilité avec les bonnes pratiques.
C’est un exercice que nous faisons très souvent et qui met en lumière pour les participants, mais aussi pour la direction, les incompréhensions de l’agilité, de Kanban, de Scrum, ce qui permet généralement déjà d’identifier des raisons à certains points de blocage ou de friction existants.
Mais c’est aussi, grâce à un contenu pédagogique simple mais percutant, une journée riche en questions. Les participants voyaient souvent déjà comment “aller plus loin” dans leur quotidien.
Le premier jour est le moment où nous confrontons la vision au groupe :
Après avoir présenté rapidement le principe du Product Vision Board, chaque participant doit le remplir individuellement. Enfin, nous dévoilons alors celui produit par la direction (la Head of Product) et discutons des différences. Cela permet aux participants de se rendre compte d’un décalage, parfois énorme, entre leur compréhension et la vision de la direction sur ce qu’est la valeur, mais pas que. Par exemple cette fois-ci, les participants ont découvert la “cible” de l’entreprise, c'est-à-dire le profil de client qui est important pour l’entreprise et comment l’entreprise mesure les objectifs business.
Cette fois-ci, l’objectif business principal était clair : augmenter le panier moyen d’un profil client en particulier.
Ce qui fut particulièrement intéressant ici c’est qu’une grande partie du groupe s’est alors rendu compte que leurs actions des derniers mois n’étaient pas du tout tournées vers cet objectif. Que beaucoup de décisions prises étaient soit désastreuses pour cet objectif, soit à côté de la plaque (par exemple, une décision qui augmente le panier moyen mais pour une cible que l’entreprise ne souhaite pas voir grandir).
La seconde journée commença avec une surprise pour les participants.
Ils ont dû vivre une planification telle qu’elle a été présentée dans le modèle Scrum la veille. Une version courte, bien sûr, bornée à 20 minutes. Nous avons divisé le groupe en 3 équipes plus ou moins aléatoires. Ce qui veut dire qu’elles n’étaient ni équilibrées ni parfaites dans leur composition.
Pas équilibrées, ce qui veut dire que comme dans beaucoup d’équipes dans beaucoup d’entreprises, certaines équipes n’avaient pas toutes les compétences idéales. Une des équipes n’avait même pas de développeur !
Ils ont alors tous pu se rendre compte qu’il était bien plus simple d’avoir un focus quand l’objectif était clair et transmis, et cet objectif, nous leur avons donné grâce au Product Vision Board :
La planification devait permettre de faire émerger une solution technique dont le but était d’améliorer l’objectif business, ne serait-ce qu’un tout petit peu : “Augmenter le panier moyen de la cible prioritaire de 1 centime.”
“Un centime,” ce n’est pas tant que ça, ça ne paraît pas insurmontable, et ça leur a permis de se lancer sans a priori négatif.
Un autre point qui est ressorti du debrief de cette journée, c'est qu'il n'est finalement pas nécessaire d'avoir une liste complète de choses à faire plus ou moins prêtes pour apporter de la valeur, ce qu’on appelle souvent un backlog produit. Les équipes se sont toutes focalisées sur une chose, une seule, qui améliorerait un peu l’objectif business et sont sorties de ce court planning avec, pour chaque équipe, une idée et un plan d’action.
La fonctionnalité ou le plan n’avaient jamais fait partie de leur backlog produit.
Nouvelle surprise pour eux : la suite de la journée ne serait pas de la théorie, mais bien une mise en action. Les équipes ont eu comme mission de produire, réellement, leur idée dans la journée, avec un niveau de finition qui veut dire prêt à déployer.
Note importante : Il est intéressant de noter ici que la surprise n’était pas un stratagème de notre part. Les équipes n’avaient pas compris qu’elles devaient mettre en place leur idée juste après. Nous avons remarqué avec elles, après coup, que c’était un heureux malentendu qui leur a évité de s’auto-censurer sur la solution. Certains n’auraient pas choisi la même solution de peur de ne pas pouvoir la réaliser dans les temps.
Donc, vers 10h30, après leur séance de planification, les équipes ont commencé à s’organiser en se déplaçant, en discutant, en collaborant ensemble.
La matinée passe, nous prenons un peu plus d’une heure pour déjeuner, puis vient l’après-midi. Pendant tout ce temps, nous les avons aidées et challengées pour leur rappeler de faire preuve d’empirisme et les guider. Et bien sûr, nous les avons aidés à garder en tête l’objectif réel.
Nous avons dû leur rappeler régulièrement que le but de l’exercice n’était pas de réaliser leur idée qui a émergée pendant la planification, mais que c’était de “Augmenter le panier moyen de la cible prioritaire de 1 centime.”
On se rend compte bien ici qu’en quelques heures à peine, réaliser la fonctionnalité pensée, celle prévue en planning, avait pris la priorité sur atteindre l’objectif. Les participants ont pu expérimenter des astuces pour revenir à l’essentiel, se poser la question, plusieurs fois par jour, si ce qu’on fait est bien la meilleure chose à faire pour l’objectif qu’on s’est donné. Avoir du recul.
Six heures après leur planification, soit vers 16h30, c’était l’heure de la “revue”. Toutes les équipes ont arrêté la production et chacune à leur tour, ont montré le résultat de leur cinq heures de travail (oui souvenez-vous, on a pris une bonne grosse heure pour déjeuner).
Nous rappelons les règles de la journée, de ne présenter que ce qui a été réalisé vraiment et qui est prêt à être mis en production : on dit souvent “potentiellement déployable”.
Chaque équipe devant aussi justifier, d’une manière ou d’une autre, en quoi elle pensent que cette fonctionnalité permettra d’augmenter le panier moyen d’au moins un centime pour la cible voulue.
Les membres des équipes présentèrent leur cas, équipe par équipe. Pas juste le ou la Product Owner, mais bien l’équipe entière. Ils ont parlé de leur idée originale, des renoncements et de leur réalisation finale puis bien sûr, de la suite possible.
Les présentations sont courtes et se focalisent sur le produit, pas la technique. Les seuls éléments techniques qui sont donnés le sont par fierté pour montrer l’ingéniosité de leur solution.
Nous avons mentionné plus tôt qu’une des équipes n’avait même pas de développeur. Et bien cette équipe a su jouer avec ses forces – c’est une autre grande leçon de cet exercice. Leur solution ne nécessitait pas de développement, ils ont su trouver un autre moyen d’atteindre leur objectif, dans ce cas-là, en profitant du système d’affichage des publicités déjà existant.
Un des atouts du produit est qu’il fournit déjà un grand nombre de données, ce qui fait que les équipes ont pu extrapoler l’impact de leurs réalisations : Plus d’1 million d’euros pour une équipe, et 400 000 à 500 000 euros pour les deux autres, en partant d’une fourchette basse des prévisions sur un an.
Soit environ deux millions d’euros de gain sur un an pour 6 heures de travail en 1 seule journée.
Nous, on trouve que c’est pas mal !
La notion de “terminé”. Nous avons choisi de limiter l’exercice à “prêt à être déployé”, mais sans le déployer car cela semblait impossible dans l’organisation actuelle de l’entreprise. Nous avons donc profité de ces journées pour identifier les raisons qui ne permettaient pas de mettre en production le soir même, voici les réponses des équipes :
Avez-vous remarqué ? Rien, techniquement, ne semblait empêcher la mise en production le jour même. Les seules raisons sont que “quelqu’un veut donner son avis”.
La suite à cela serait certainement de creuser pourquoi ces validations sont nécessaires et surtout, qu’est-ce qu’il nous manque dans notre process et nos outils pour livrer le vendredi sans crainte ?
Nous pouvons extraire certains événements et conditions qui ont permis le succès de cette journée.
Discutons-en de vive voix !
Pour nous contacter, vous pouvez utiliser le formulaire ci-dessous, ou nous écrire à contact@scrumlife.tv :
