Cet idée d’article Et si on ajoutait du Lean dans la rétro de sprint me vient suite à un post LinkedIn de Cecil Dijoux, des commentaires de Nicolas Ploquin et Frédéric Buono-Blondel sur le contenu des rétrospectives Scrum.
Mes constats
Je ne compte plus le nombre de fois (et je ne suis pas le seul) où j’ai assisté à des rétrospectives Scrum durant lesquelles seuls comptaient le bien-être de l’équipe, les interactions entre leurs membres ou encore le bla-bla sans aucun indicateur factuel.
J’ai même assisté (en tant qu’observateur) à une rétrospective où les membres essayaient de résoudre un problème dont le principal acteur était un manageur… qui plus est absent. On notera au passage que ces mêmes membres n’avaient pas pris 2 minutes pour regarder ce qu’ils avaient livrés à leur client (peu de chose !). Ou comment choisir les mauvaises batailles…
Ce que dit le Scrum Guide
Avant d’apporter des éléments de réponse à Et si on ajoutait du Lean dans la rétro de sprint, retour aux sources avec le Scrum Guide.
Quand on pratique une démarche, il est bon de lire (et relire) le référentiel posé par ses auteurs. Que ce soit CMMi, ISO, Scrum, Cobit, Lean et autres !
Avant de rappeler ce que les auteurs du Scrum Guide ont écrit, j’aimerais juste préciser que Scrum, XP et autres pratiques agiles, DevOps ou Lean nécessitent rigueur et respect du modèle ; sinon autant faire autre chose ! Cette absence de sérieux (et non, on ne fait pas ce qu’on veut !) est l’une des causes de la grande majorité des échecs des pratiques agiles et du Lean !
Des pistes pour s’améliorer
L’objectif de la Sprint Retrospective consiste à réfléchir à des pistes pour améliorer la qualité et l’efficacité. »
Source : Le Guide Scrum, Ken Schwaber & Jeff Sutherland, novembre 2020
Ah tiens ! Des pistes pour améliorer la qualité et l’efficacité… L’ordre des mots ayant toute son importante, on notera que la qualité vient avant efficacité. Et c’est juste logique ! Mauvaise qualité = rework = gaspillage = perte d’efficacité !
Autant le rappeler une énième fois ici : il n’y a pas de vitesse sans la qualité !
Recherche des causes racines
Continuons avec le Scrum Guide, qui précise :
La Scrum Team inspecte le déroulement du dernier Sprint en ce qui concerne les individus, les interactions, les processus, les outils et leur Definition of Done. Les éléments inspectés varient souvent selon le domaine d’activité. Les hypothèses qui les ont fait dévier sont identifiées et leurs origines explorées. »
Source : Le Guide Scrum, Ken Schwaber & Jeff Sutherland, novembre 2020
Souvent, très souvent, les équipes s’arrêtent aux individus et aux interactions. Sûrement parce que c’est plus simple, dans le sens où cela évite de se remettre vraiment en cause en regardant droit dans les yeux ses propres problèmes. Pas forcément individuellement, mais en tant qu’équipe. Vous savez, les 3 singes : je ne vois pas, je n’entends pas, je ne parle pas…
Ne me faites pas dire que le bien-être des personnes n’est pas important. Bien au contraire, c’est juste une des finalités de l’Agile et du Lean que de redonner du sens et du bien-être dans le travail. Mais pour y arriver, il faut accepter de résoudre les vrais problèmes.
Quant à leurs origines explorées... c’est-à-dire la cause racine découverte avec la technique des 5 pourquoi (ou une autre), autant dire qu’elle n’existe que dans les meilleures équipes Scrum.
Correction ou résolution ?
Enfin, les auteurs du Scrum Guide ajoutent :
La Scrum Team discute de ce qui s’est bien passé durant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été (ou n’ont pas été) résolus. »
Source : Le Guide Scrum, Ken Schwaber & Jeff Sutherland, novembre 2020
Déjà, mettons les points sur les i : résolu = occurence du problème supprimée définitivement. Résolu est différent de corrigé ! Corrigé = rendre le service le plus rapidement possible au client (= protection du client). Pour ceux qui pratiquent ITIL, on est dans la gestion des incidents.
Ce que vise l’Agile, c’est la résolution des problèmes durant le sprint. Avoir des boucles rapides d’amélioration et éviter d’attendre les REX (Retour d’EXpérience, qui au mieux arrivent plusieurs mois après la fin du projet). Avec le Lean, on vise à le faire au plus tôt après son apparition ; ce qu’on appelle arrêt au premier défaut.
L’idée de la rétrospective de Scrum est de sanctuariser une étape d’amélioration dans les sprints. En Lean, nous expliquons toujours que l’amélioration continue est un temps de travail, ce n’est pas le soir ou le week-end. La rétrospective a ce mérite qu’il ne faut pas négliger. Et pourtant, nous entendons encore et encore que les rétrospectives ne servent à rien car les équipes ne produisent pas… Idée fausse, quand tu nous tiens…
Et si on ajoutait Du Lean dans la rétro de sprint
Il y a des débats de clochers autour de « Agile ou Lean ? ». Pour ma part, je suis intimement persuadé que l’Agile et le Lean peuvent fonctionner ensemble. Mais ce n’est pas le sujet de cet article.
La satisfaction du client
Le client est au coeur des démarches Agile et Lean. Il est donc primordiale de s’assurer de sa satisfaction. Quels sont les résultats de la sprint review ? Que disent les utilisateurs lors des interviews réalisées en dehors des sprints ou lors d’observations / questionnements (exemple avec les User Journey Map : Reconnecter développeurs et utilisateurs avec l’UJM) ?
Tous ces éléments devraient alimenter un panneau visuel des 5 attentes des clients :
- Donnez-moi ce que je veux ;
- Quand je le veux ;
- Où je le veux ;
- Soyez fiables (= qualité) ;
- Ne me faites pas perdre mon temps.
Une profusion d’améliorations possibles si l’équipe sait écouter ses clients et se remettre en cause, parfois profondément. Ces éléments doivent être passés en revue lors de la rétrospective pour en déduire des améliorations. Travail à faire en lien avec le Product Owner, responsable de son produit.
US livrées versus US prévues
S’intéresser à ses clients, c’est savoir également regarder ce que l’équipe a délivré à la fin du sprint. C’est-à-dire faire un zoom sur la production de l’équipe.
- Quel était l’engagement de départ (nombre d’US dans le backlog de sprint) ?
- Une dizaine d’US, mais elles n’ont pas toute la même…
- Peu importe la taille, pour l’instant on veut connaître le nombre.
- 12
- Et sur les 12, combien ont été livrées ?
- Mais elles ne sont pas de la mê…
- La taille des US n’est pas le sujet pour l’instant, combien ont été livrées ?
- 5
Dans notre exemple, nous avons un taux de respect de l’engagement de 41,6 %. Pour le dire autrement, l’équipe a délivré 41,6 % de ce qu’elle avait prévu de fournir à son client à la fin du sprint, soit moins de la moitié.
- Combien d’US ont été marquées comme KO par le Product Owner lors de la sprint review ?
- Mais tu sais, on n’a pas pu toutes les tes…
- On n’en est pas encore là, combien d’US KO ?
- 3…
Est-ce grave ? Non. Ce qui est grave, vis-à-vis du client et de l’équipe elle-même, c’est de ne pas s’occuper des problèmes rencontrés, pour utiliser le vocabulaire du Scrum Guide et du Lean.
Résoudre les bons problèmes de l’équipe
Nous voilà donc avec 2 écarts (5 US délivrées sur 12 et 3 KO lors de la sprint review). En Lean, nous disons qu’un problème est un écart entre une situation voulue et la situation réelle. Nous (en fait l’équipe) avons 2 problèmes factuels à résoudre. C’est là que débute l’amélioration continue de l’équipe.
C’est ce type de problème que l’on cherche avec l’Agile et le Lean ; encore faut-il accepter de les rendre visibles ! D’où la nécessité d’un vrai Management Visuel et pas simplement d’un To Do / Wip / Done qui n’est, in fine, qu’un gestionnaire de tâches dans lequel on ne sait pas ce qui se passe réellement.
Je vous invite à écouter l’excellente interview de Marek Kalnik CTO de BAM, Compter les bugs jusqu’à 0 pour compléter ce sujet.
Le Lean renforce la rétrospective
Dans ce contexte de la rétrospective, la résolution de problème pratiquée en Lean vient renforcer celle de l’Agile. Elle est plus rigoureuse et permet surtout de se concentrer sur les vrais problèmes qui vont faire progresser l’équipe pour satisfaire les clients et l’amener au niveau du rythme soutenable.
Suis-je le seul à constater cela ? Que nenni ! Mon ancien collègue, coach Lean et Agile, Cecil Dijoux en parle dans son article Les dérives psychologisantes de l’Agile : étude de cas. Nicolas Ploquin, également coach Lean et Agile, ne dit pas autre chose dans Retrospective Agiles vs Amélioration continue.
Ouvrez vraiment les yeux sur vos rétrospectives et demandez-vous « Et si on ajoutait du Lean dans la rétro de sprint ? »