Être Agile : avoir un DoD qui se focalise sur les problèmes à résoudre
Plutôt que Faire de l’Agile et respecter une checklist décrivant la solution !
Les équipes web du Player ont récemment repris leur Definition of Done ou DoD. C’est super d’abord parce que cela dénote une appropriation de la part de l’équipe : je ne les ai pas encouragés à refaire leur DoD, ni n’ai participé à la conception de ce nouveau DoD.
Mais plus important encore, c’est le contenu du nouveau DoD qui m’a fait le plus plaisir : il prend de la hauteur, il est plus abstrait.
Je vous laisse comparer l’ancien et le nouveau DoD :
Ce sont notamment les sous-titres du nouveau DoD qui attirent mon attention. Ils résument bien le comportement qu’on attend de l’équipe de développement, au-delà de la checklist qui liste les outils mis en place.
Pourquoi est-ce une bonne chose me direz-vous ?
La formulation du DoD comme critère de maturité
Parce que la formulation du DoD est un critère de maturité d’une équipe. Mon très brillant collègue Xavier Pigeon l’explique avec brio à l’aide du diagramme suivant :
Une jeune équipe, novice, va créer une DoD minimal, si tant est qu’ils aient un DoD.
Puis, prenant de l’expérience, l’équipe va enrichir sa DoD, au fur et à mesure des déboires qu’elle rencontrera. Mais aussi parce qu’elle prendra mieux en main ses outils, ses manières de travailler, son environnement… Bref, son contexte. Petit exemple fictif :
On s’est rendu compte qu’il faut absolument une doc parce qu’une des parties prenantes en a un besoin réel pour se synchroniser avec l’équipe.
Et que cette doc doit être revue parce qu’on s’est rendu compte que quand il y avait des bêtises dans cette doc, les conséquences pouvaient être énormes.
Et qu’un mail de notification avec le lien vers la nouvelle doc doit être envoyé pour limiter les risques de désynchro entre les équipes.
Petit à petit, le DoD de l’équipe se met à ressembler à une longue checklist, très longue mais exhaustive. L’équipe ne laisse rien passer, même si le passage en revue du DoD pour chaque US est fastidieux.
L’équipe mature s’assure d’avoir corrigé le problème, plutôt que de vérifier qu’elle a suivi la solution.
Et puis finalement, l’équipe gagne en maturité et se met à réduire la complexité du DoD. L’équipe a moins à se préoccuper des détails, et se contente désormais de prendre de la hauteur et de répondre aux besoins réels. On s’assure qu’on a corrigé le problème, plutôt que de vérifier qu’on a suivi la solution.
Si on reprend l’exemple précédent, la gestion de la doc pourrait se résumer au plus simple :
☐ Synchro avec les autres équipes
… ce qui va impliquer tout ce qui était auparavant explicité : il faut une doc, bien à jour et sans erreur, qu’on communique dès que possible.
Mais, mieux encore, ce DoD qu’on pourrait qualifier de holistique permet de répondre encore mieux aux problèmes.
Ainsi dans l’exemple précédent, on pourrait se demander si faire et communiquer une doc est systématiquement la meilleure solution ? Est-ce que parfois il ne serait pas plus pertinent d’organiser un workshop à la place ? Ou n’importe quelle autre approche qu’une doc, comme un tutorial interactif ou pourquoi pas un chatbot ? C’est à envisager au cas par cas, sans dogmatisme.
Faire de l’Agile ou Être Agile ?
On peut faire le parallèle entre cette formulation du DoD et le fonctionnement global de l’équipe Agile.
Dans notre milieu on retrouve une opposition classique sur la mise en place de l’Agilité :
Faire de l’Agile vs. Être Agile
Par Faire de l’Agile on entend un fonctionnement basé sur les pratiques alors que par Être Agile on entend l’appropriation de la philosophie de l’Agilité, le mindset en anglais.
L’évolution du DoD que je présentais plus haut est totalement alignée avec ces deux visions :
DoD — Faire de l’Agile : on est done quand on a suivi une procédure qui est sensée résoudre le problème. On s’assure d’avoir suivi la procédure, parfois en oubliant de vérifier que le problème est résolu.
DoD — Être Agile : on est done quand on s’est assuré qu’on a résolu le problème d’origine. Sans être contraint dans la solution, mais surtout en vérifiant que la solution choisie corrige bien le problème.
Être Agile apporte forcément plus de valeur, mais est aussi plus difficile puisqu’il faut prendre du recul et réfléchir.
Voilà pourquoi ce débat est aussi important dans la communauté : parce qu’Être Agile apporte forcément plus de valeur, mais est aussi plus difficile puisqu’il faut prendre du recul et réfléchir.
À propos de Jean-Pierre Lambert
Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.
Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !
J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…