Comment éviter le gaspillage dans vos projets ?
Le gaspillage, c’est quoi ?
“Faire un mauvais emploi de quelque chose, de telle sorte qu’il se perd en partie. Dépenser inutilement, follement, dilapider. Faire un emploi désordonné, sans profit de quelque chose” — Définitions du Larousse.
Prenons l’exemple d’une équipe.
Nous sommes le 6 mai, 14h00. Un développeur de l’équipe vient de prendre une Userstory qui lui a été envoyée par le Product Owner. En l’analysant, il note rapidement une dépendance avec une API appartenant à une autre équipe et constate qu’il reste encore des zones d’ombre dans les règles. Doit-il commencer à développer ? Le contributeur API a-t-il déjà été informé ? Que doit-il faire, surtout que la fin de l’itération est très proche ?
Ces moments d’incertitudes, de découvertes très tardives de sujets techniques et de questions encore ouvertes qui bloquent le delivery, c’est ce qui provoque une spirale de nombreux gaspillages de temps, de coûts et de motivation des équipes dans nos projets. Il est donc essentiel de réduire le plus possible ces gaspillages.
Le saviez-vous ?
Le Lean Manufacturing a listé 8 types de gaspillages :
Cela ne vous rappelle rien ?
Dans la réalité, nous aurons forcément une notion de gaspillage dans nos projets, mais l’important est de les réduire au maximum à chaque étape de votre delivery.
Dans la suite de cet article, nous vous proposerons quelques conseils pour les réduire dans certaines situations.
La surproduction & les stocks excessifs
“Gardez la Backlog Produit propre. Les sujets anciens vieillissent comme le lait, pas comme le vin.” — Agile Product Manifesto.
Dans l’exemple ci-dessous, l’indicateur “Cumulative Flow Diagram” indique que le stock s’accumule dans la backlog de l’équipe car l’écart s’agrandit par rapport aux autres phases du delivery (rédaction, développement et test).
Cela veut dire que :
- L’équipe ajoute de plus en plus de stories dans la backlog, avec le risque de ne pas pouvoir les traiter tout de suite … voire jamais.
- Le Product Owner est en train de faire un travail d’analyse, de recueil de besoin avec son Métier qui ne verra peut-être jamais le jour, ou, au mieux qui sera priorisé plus tard, avec le risque d’être modifié car le besoin aura changé depuis.
Pour éviter ce gaspillage, il est important de :
- Prioriser avec le Métier les sujets à plus forte valeur ajoutée,
- De rester focus uniquement sur les sujets qui ont le plus de valeur pour le cadrer et le développer,
- De vérifier la capacité de l’équipe à prendre en compte ces besoins,
- De suivre régulièrement les indicateurs de l’équipe (dont la Prédictibilité), en ajoutant à votre Kanban une limite sur en-cours pour veiller à réduire le gaspillage d’un stock excessif ou d’une surproduction qui ne pourrait pas être traitée par l’équipe (le fameux débit de l’équipe). Bref, éviter que l’équipe travaille d’arrache-pied pour rien !
Les défauts
Il ne faut pas oublier que les défauts ne sont pas uniquement techniques. Ils peuvent exister à tous niveaux :
- Une mauvaise traduction ou compréhension du besoin,
- Un mauvais transfert des informations,
- Un objectif mal communiqué,
- Une erreur de développement,
- Un test non ou mal effectué,
- Etc.
Pour éviter ce gaspillage, rapprochez au plus tôt vos équipes du Métier, voire des utilisateurs au travers d’ateliers collaboratifs pour :
- Comprendre le sens du besoin et des objectifs,
- Convier les personnes qui posent les bonnes questions et celles qui savent y répondre,
- Avoir le même vocabulaire,
- Etre promoteur dans la création du produit,
- Remonter les alertes au plus tôt sur des sujets techniques ou fonctionnels,
- L’amélioration continue.
Quelques ateliers pour vous aider :
- Story Mapping,
- Event Modeling,
- 3 Amigos,
- La Démo,
- Rétrospective de l’équipe.
Etape sans valeur ajoutée
“Mais, qu’est-ce que je fais dans cette réunion ?” — Développeur désabusé.
Pour éviter ce gaspillage, lors de vos ateliers, assurez-vous bien d’avoir invité les bonnes personnes, comme le préconise le Domain Driven Design.
Rassembler les personnes qui connaissent les questions à poser et celles qui connaissent les réponses.
Il s’agit aussi de préciser l’ordre du jour de l’atelier pour que les participants vérifient qu’ils seront les personnes adéquates. D’autre part, nos expériences montrent que, lors des ateliers collaboratifs tels que le Story Mapping ou les premières étapes de l’Event Modeling, les développeurs et testeurs ne se sentent pas forcément utiles car cela ne parle que “fonctionnel”. Expliquez-leur que leur présence est nécessaire pour :
- Prendre connaissance des sujets fonctionnels qui vont arriver et s’en imprégner bien avant de démarrer les développements,
- Poser des questions directement au Métier,
- Proposer des solutions,
- Apporter leur expertise technique et remonter leurs risques.
Nous avons parlé de réunions, mais il existe bien d’autres types d’étapes sans valeur ajoutée, ou que vous considérez comme telle. N’hésitez pas à vérifier leur utilité en discutant avec vos collègues, ou lors de vos rétrospectives. Souvent, derrière un process, il y avait surement un problème à résoudre.
Temps d’attente
C’est un des gaspillage des plus épuisants : être bloqué du fait de l’attendre d’une réponse, de la disponibilité d’une personne ou d’allers-retours incessant par mails.
Pour éviter ce gaspillage, plusieurs solutions sont possibles :
- Priorisez ensemble les sujets à plus forte valeur ajoutée. Les personnes se sentent plus impliquées lorsqu’elles ont priorisé conjointement,
- Les agendas : Soyez transparent. N’hésitez pas à présenter comment vous aller mener votre phase de cadrage d’un nouveau sujet, en indiquant la durée, le planning des ateliers, les personnes impliquées, ce que vous attendrez d’elles et le résultat à obtenir. Il en est de même pour la phase de delivery (via le Release Planning ou le PI Planning).
- Suivez vos temps d’attente en consultant vos indicateurs Lead Time et Cycle Time de vos sujets. Cela permettra d’être factuel, lorsque vous demanderez aux intervenants du projet de participer, par exemple, à la réduction de la durée de maturation qui est trop longue du fait d’un manque de maturation du produit, de l’indisponibilité d’une partie de l’équipe ou du Métier,
- Lancez des ateliers collaboratifs plus que des mails (Story Mapping, Event Modeling, 3 Amigos). Cela vous permettra d’écourter le temps d’attente grâce à une interaction directe entre les personnes.
Mouvements inutiles & déplacements inutiles
Notre Métier vient de nous ajouter une nouvelle fonctionnalité, alors que nous sommes en plein développement ! Cela vraiment perturber notre delivery !
Nous le savons bien, l’Agilité, c’est accepter le changement … mais sous certaines conditions.
“Responding to change over following a plan.” — Extrait de l’Agile Manifesto, 2001.
Pour éviter ce gaspillage, concentrez-vous sur votre objectif. Il est indispensable d’avoir défini un objectif fonctionnel de version/cadence avec l’équipe et votre Métier avant de se lancer dans les développements. Cet objectif peut se faire dès l’atelier de Story Mapping en utilisant les “Objectives and Key Results” et de s’y référer régulièrement pour éviter toute dérive.
- Des sujets techniques en cours de développement ne répondent pas forcément aux objectifs ? Mais vont-ils aider à atteindre les objectifs ? N’hésitez pas à demander à l’équipe de repréciser ces derniers lors d’un daily.
- Une nouvelle demande du Métier ? Challengez-le en lui demandant si ce sujet participe bien à l’atteinte des objectifs. Si oui, vous lui demanderez de déprioriser des évolutions avec moins de valeur. Si non, vous aurez l’argument pour lui proposer de l’ajouter dans une version suivante.
Attention, nous parlons bien d’objectifs fonctionnels. Par exemple, l’objectif d’une cadence n’est pas de respecter le planning mais bien ce qu’elle apportera fonctionnellement à l’utilisateur final.
Sous-utilisation des compétences
Quel Product Owner n’a pas distribué des Userstories à des développeurs qui maitrisaient techniquement le sujet ? C’est presque un reflexe qui devient assez néfaste pour l’équipe et son delivery car l’on crée de plus en plus de dépendances de l’équipe vis à vis de l’expert.
- L’expert devient toujours plus expert,
- Le développeur qui vient d’arriver dans l’équipe ne monte pas en compétence,
- L’expert part en congés = un delivery bloqué pendant ses vacances !
Pour éviter ce gaspillage, efforcez-vous à respecter la notion de flux tiré. A savoir : dès qu’un développeur est disponible, il tire la Userstory la plus prioritaire dans la Backlog, même si vous savez qu’il prendra plus de temps à développer que l’expert. Mais, n’hésitez pas à proposer du pair-programming avec ce dernier qui aidera le développeur dans sa montée en compétence.
En résumé
Evidemment, cet article ne liste pas toutes les difficultés que vous pourriez rencontrer lors de vos projets. Cependant, il est important d’être conscient de ce gaspillage, que nous sommes en partie responsable sans le vouloir et surtout que nous sommes capable d’en réduire une bonne partie par de bonnes pratiques et la meilleure est la Rétrospective, qui est essentielle pour l’amélioration continue de votre équipe !
N’hésitez pas non plus à utiliser la technique du serpent des gaspillages avec votre équipe en les représentant sous forme de cartes, puis d’afficher le résultat et de mettre à jour ce serpent régulièrement ! (Un template sous Draft.io)
