Soirée en finir avec : le “sprint”
Jeudi dernier, j’avais mon premier meetup de l’année organisé par FSUG et animé par Christophe Addinquy. Je suis un peu arrivée les mains dans les poches, sans avoir potassé ni le sujet ni le déroulé. Et je n’ai pas été déçue du tout. L’objectif était de s’interroger sur des pratiques agiles afin de mieux les comprendre et les challenger. 3 pratiques ont été décortiquées par les personnes présentes : le product owner, le sprint, les estimations.
PRATIQUES AGILES À REMETTRE EN QUESTION : LA LISTE EST LONGUE
Après une courte introduction de la soirée, chacun a proposé un ou plusieurs sujets : en finir avec le PO, avec le scrum master, avec la roadmap, les coachs, la disparition de la conception technique, le planning pocker, etc… Cette première étape était amusante. On se rend compte que notre quotidien d’agiliste est truffé de pratiques que l’on considère évidentes, naturelles et qu’il serait pertinent de peut-être remettre en question.
Nous avons formé trois groupes. Malheureusement nous ne pouvions choisir qu’un seul sujet chacun. Et il fallait se décider vite. Mon groupe ayant voulu appliquer la règle du dot voting, nous nous sommes rapidement retrouvés avec les sujets mis de côté par les autres. Je n’étais à priori pas emballée par le sujet “en finir avec les sprints”. Mais je n’ai pas mis longtemps à y trouver un réel intérêt.
PITCHER SON SUJET POUR FAIRE DU TEASING AUPRÈS DES AUTRES GROUPES
L’objectif de cette première itération consistait à faire un teasing du sujet. Trouver un moyen de présenter l’analyse à venir, aux autres, de façon à les intéresser… Cette méthode a au moins la vertu de briser la glace quand on ne se connaît pas bien les uns les autres. Et d’identifier à peu près la personnalité de chacun. En revanche, je n’en n’ai pas retiré grand chose d’autre. Ce qui m’a plu c’est l’exercice du perfection game (donner une note sur 10, exprimer ce que l’on a aimé sur le sujet/produit, proposer ce qui pourrait le rendre meilleur) que chaque groupe a exercé sur l’autre. Une pratique que j’utiliserais bien en revue lorsque aucun des participants ne donne de feedback... Ou en alternative à un ROTI.
EN FINIR AVEC LES SPRINTS
J’ai vraiment beaucoup aimé les 20 minutes que nous avons passées à construire le mindmap et le dialogue autour de ce sujet. Nos idées partaient dans tous les sens mais nous avons tout de même réussi à les structurer :
D’abord qu’est-ce que c’est un sprint ? Je partais plutôt fermée sur l’idée “d’en finir avec” la notion d’itération. Je trouve que cela donne un vrai rythme à la vie d’une équipe. Mais il est vrai qu’un sprint ce n’est pas qu'un rythme : c’est aussi un objectif, un engagement, un incrément, un périmètre, une time box, une valeur délivrée, un DOD.
On entend parfois : “nous sommes une équipe agile : nous travaillons en sprint”. Comme s’il s’agissait d’un élément clef d’une démarche agile. De la pierre angulaire.
Un sprint a l’avantage d’agir comme un métronome sur l’équipe. Il crée un rythme de production, donne de la visibilité sur les 2 ou 3 semaines à venir. Sur le plateau de développement où j’interviens, j’entends souvent les équipes dire :"j’aime bien savoir au moins une semaine à l’avance sur quoi je vais travailler".
Le constat en fin de sprint d’avoir pu ou pas tenir l’engagement initial va permettre d’identifier d’éventuels blocages qu’il est toujours plus efficace de découvrir au plus tôt.
Une personne de notre groupe a argumenté ironiquement que le sprint permet de voir le PO lors des rendez-vous du sprint.
Assez rapidement nous avons discuté des aspects négatifs du sprint :
De cette notion d’engagement qui n’apporte pas grand chose et qui met sous pression l’équipe au détriment, peut-être, de la qualité.
De la durée idéale, débat sans fin pour les mauvaises raisons
Du risque de repartir sur un mini cycle en V : développements, recette puis démo
De la difficulté pour le PO de définir un objectif pour le sprint. Cette notion d’objectif, nous en avions discuté dans cet article. Un objectif va potentiellement être à cheval sur plusieurs sprints. Ce n’est pas toujours évident de donner du sens à une itération.
Le sprint crée le besoin de figer un périmètre et donc ensuite de potentiellement négocier. Est-ce que cette négociation a de la valeur ? Est-ce que c’est réellement important d’avoir terminé un sprint en ayant réalisé l’engagement de départ ? Pourquoi se focaliser sur le reste à faire au détriment de la valeur déjà produite ?
Les équipes de développement expriment souvent que le “sprint”, comme son nom l’indique, est une course contre le temps. C’est fatiguant, stressant.
Passées les 20 minutes de mindmapping, nous en sommes venus à la conclusion suivante : “vive le flux continu !” Et pourquoi pas en gardant quelques bonnes pratiques du sprint comme un rythme régulier de démos pour conserver une cadence au sein de l’équipe, un rendez-vous avec le métier.
EN FINIR AVEC LE PRODUCT OWNER ? EN FINIR AVEC LES ESTIMATIONS ?
Je ne vais pas détailler les deux autres sujets : le product owner et les estimations. Chaque groupe a fait ensuite une restitution. Pour les voir en vidéo, vous pouvez consulter le compte-rendu de Christophe.
J’ai été très intéressée par le résultat du groupe qui a travaillé sur le sujet "product owner". Chez mon client, on ne démarre pas un projet sans que celui-ci ait été nommé, formé. On a aussi tendance à pointer du doigt un PO qui n’aurait pas les moyens de couvrir tous les aspects de sa fiche de poste. Alors que finalement, nous devrions peut-être focaliser nos efforts pour essayer de trouver une alternative au problème récurrent : les sachants sont pris par l’opérationnel et ne peuvent pas être partout.
Suite à ce meetup, je repars avec une véritable envie de questionner toutes les habitudes qui commencent à s’installer chez moi, toutes les croyances que je commence à cumuler (j'aime beaucoup l'image des zombis utilisés par Christophe, slide 6). Pour “les utiliser avec le véritable état d’esprit agile” comme le dit Christophe.
Je considérais jusqu’à présent l’exercice du mindmapping comme une sorte de méthode pour tracer les réflexions d’un groupe. J’y vois désormais un potentiel outil personnel pour me pousser à creuser mes réflexions. Comme l’a fait Christophe sur de nombreux sujets. A creuser… Peut-être dans un prochain article.
Au final je pense que j’aurais préféré que l’on commence la troisième itération plutôt que de passer du temps sur la première (le teasing des sujets). Il s’agit de développer les arguments issus du mindmap pour en faire une vraie analyse.
Par curiosité j’aurais beaucoup apprécié travailler sur “en finir avec le scrum master”. Tout simplement parce que c’est le rôle que je joue au quotidien et que j’imagine bien évidemment indispensable ! (Zombie à l’approche !!)