En rétrospective j’ai l’habitude de demander à l’équipe la météo du sprint (sprint parfait, bon sprint mais…, sprint n’a pas été bon… sprint catastrophique) et donner une explication liée à cette évaluation. Les avis sont mitigés et on se retrouve avec un sprint « bon » du point de vue du scrum master mais « mauvais » du point de vue développeur pour diverses raisons et vice versa.
Je me demande si c’est une bonne idée de s’aligner tout d’abord sur un ensemble de critères d’évaluation d’un sprint avant d’argumenter et pointer sur les problématiques rencontrés.
Je m’adresse à vous alors pour avoir vos retours sur les critères sur lesquels vous vous appuyez pour conclure sur la réussite ou l’échec du sprint passé et si vous avez aussi des idées d’indicateurs tangibles , je suis preneuse
Merci bien
Pour moi, il n’y a pas de bons ou mauvais sprints… (pour ceux qui ont la ref ^^ #otis).
Selon moi, ce qui compte n’est pas le sprint en tant que tel mais la valeur délivrée en rapport à l’objectif de sprint fixé et sur lequel l’équipe s’est engagé :
A-t-on atteint notre objectif de sprint ?
—> oui ! Parfait, good job guyz ! On continue comme ça, on est les meilleurs, on déchire tout !
—> Non ! Ok… Alors pourquoi on ne l’a pas atteint ? Qu’est-ce qui a fait que nous n’avons pas pu, ensemble, compléter l’objectif que nous nous étions fixé ? Que fait-on pour que cela ne se reproduise plus ?
J’ajouterai que normalement, ce n’est pas au moment de la fin de sprint que l’on se rend compte que l’objectif n’est pas atteint ou ne sera pas atteint. Les daily scrum, sont également là pour discuter, adapter, modifier le plan de sprint au gré des découvertes et toujours dans le but d’atteindre l’obj de sprint.
Lorsque tu dis "sprint réussi ou sprint échoué, sur quoi vous vous basez pour définir cet échec ou réussite ?
Merci pour ta réponse.
Je suis d’accord avec toi sur l’importance de souligner la valeur délivrée en rapport à l’objectif du sprint qui est la raison d’être du sprint. Je retiens alors que la valeur délivrée est un critère que tu évalues en « sortie » du sprint.
En fait, je cherche à savoir quels sont les éléments qu’une équipe trouve pertinents à mesurer et à évaluer au plus tard en fin de sprint pour pouvoir s’améliorer et identifier des actions correctives. Je caricaturise mais j’imagine une sorte de check list « basique » à l’image d’une DoD qui soit parcourue en rétrospective par l’équipe ou en individuel (un SM dans son coin) pour conclure sur l’expérimentation du sprint.
En d’autres termes, en tant que SM , quels sont les aspects que vous observez, mesurez et suivez pendant un sprint (ex. réactivité des individus, des interactions inter et intra équipes, fluidité des process et des worflow…) ?
Hum, c’est une très bonne question .
Ce que je faisais avec mes équipes on regardais si on avait atteint l’objectif de sprint.
Si oui et dans quel Etat nous l’avions atteint.
Exemple :
Cool nous avons atteint l’objectif du sprint et tout le monde est contents. (Sprint OK)
Cool Nous avons atteint l’objectif du sprint mais tout le monde n’en peu plus (Sprint moyen OK)
Pas cool on à pas atteint l’objectif de sprint et tout le monde est quand même content de son travail (Sprint moyen Ok)
Pas cool on à pas atteint l’objectif de sprint et tout le monde est déprimée (Sprint pas OK)
Après à nuancer car pendant la sprint review, tu récupère le feedback des tes parties prenantes (si tu as beaucoup de chance de tes utilisateurs finaux et ça c’est à nuancer avec l’évaluation que j’ai décrite plus haut.
Après il y a beaucoup d’autre facteur à regarder, cela dit de mon point de vue si tu as une équipe qui est vraiment / qui montre des signe de : « ça ne va pas »
Je pense qu’il est important de s’en préoccuper et pas juste en retrospective.
Ce que je veux dire par là c’est de faire différents ateliers avec ton equipe (tous ensemble, un à un au choix) pour les accompagner pour que ça aille mieux.
(Sans développeurs motivée, bas il y a plus d’application …)
Si tu veux nous en dire un peux plus sur ton contexte, d’autres équipes/ dans un comité de SM etc… hésite pas on pourra mieux t’apporter un regard différents sur tes problématique.
J’aime répondre avec cette vison parfois choquante
Un sprint réussi, c’est un sprint où on atteint objectif en ayant FINI le MOINS d’user story possible.
En effet, l’objectif du sprint, c’est son objectif (Merci monsieur Lapalisse)
Et chasser le gaspillage me pousse à faire ce que je dois faire en faisant le moins d’effort possible.
En effet, une équipe qui adapte/optimise son plan en cours du sprint et arrive à atteindre l’objectif du sprint doit avoir un niveau de maturité élevé et une maitrise impressionnante de son produit
De ce que je vois, c’est plus fréquent de se rendre compte qu’il ya du travail à faire qui n’a pas été pensé et de rajouter des user stories dans le sprint
Merci @Elo pour ta réponse.
oui je nuance aussi l’atteinte des objectifs avec l’état de l’équipe tout au long du sprint. Ta grille de lecture est pertinente parce qu’elle évite de tomber dans le cas d’une évaluation de sprint bête et méchante (objectif atteint = bon sprint, objectif pas atteint= mauvais sprint) sans prendre en considération l’humain.
Pour donner plus d’éléments au contexte de l’équipe:
On est en mode solution à la demande (versus approche produit)
On a plusieurs objectifs de sprint, une équipe de 11 développeurs et 1 QA
un sprint qui dure 1 mois
Pas de sprint review, pas de contact direct avec les clients, idem pour le PO
pas de comité SM , je suis la seule SM de la boite (dédiée à une seule équipe), mais il ya un coach agile qui travaille avec une autre équipe sur un produit très différent du nôtre
et le retour des parties prenantes lors de la revue ne participe pas à l’évaluation du sprint passé lors de la rétro ?
Le ressenti de tous est primordial en particulier celui de l’utilisateur du produit réalisé.
L’équipe, à la fin de la revue, peut récolter le ressenti des utilisateurs vis à vis de l’objectif et du produit présenté …
Lors de la rétro, souvent je demandais à l’équipe une évaluation basée sur les 5 M en mettant un smiley à chacun : (à l’équipe de définir chaque M pour plus de clarté.)
On peut ajouter un autre M pour le Management qui peut être un élément impactant et d’autres M à votre convenance pourvu qu’ils aient un impact sur les effets (ex Muda : gaspillage : réunions hors Scrum, distraction (dis, tu peux me dire ce que …, réquisition sur d’autres sujets, …).
J’aime bien faire ce genre d’exercice , heureusement pas à chaque rétro, car bien souvent, la cause du pb qui revient en premier c’est : « c’est la faute de … untel » ou « il n’a pas eu le temps de … » toujours orienté sur la Main d’oeuvre en oubliant les 4 autres critères.
Pas de revue pour nous, donc pas de collecte du feedback des clients ou utilisateurs du produit réalisé. L’évaluation du sprint passé se fait en interne (PO, dev, QA…)…
L’idée d’utiliser le diagramme d’Ishikawa pour évaluer un sprint est intéressante, de mon côté je connais plus le use case classique de cet outil qui est la détermination des causes racines d’une problématique.
En revanche je n’ai pas très bien compris un point: tu demandes à l’équipe de définir chaque M spécifiquement en lien avec le sprint passé , évaluer chaque catégorie par un smiley et puis comment tu analyses et exploites ces résultats ? tu incites l’équipe à discuter la catégorie qui a le plus de smiley triste par exemple?
Arrff, j’avais pas vu, pas de feedback … En effet, cela doit être compliqué s’il n’y a pas de revue ; seul le PO porte la voix de l’utilisateur imaginaire ou non disponible … sa perception est alors démultipliée !
Chaque M doit représenter des choses concrètes aux yeux des équipiers ; à eux de les définir …
Matière : qu’est-ce que c’est pour eux ? tu peux les guider … ex : le backlog bien rangé et lisible, le récit, le récit technique, la doc, les critères d’acceptation, les descriptions, les dessins,
Milieu : équipe au même endroit ou remote, bien installé, pas dérangé, …
Méthode : application sans détours de Scrum ? méthodes pour évaluer ? 3A ? valeur commerciale ? point d’effort ? surtout comment ces infos sont captées …
Matériel : outillage adapté ? manque d’outils ? ex : cypress, postman, Xray, Figma, Jira, Confluence …?
Main d’oeuvre : équipe autonome et responsable ? cloisonnement, dépendances d’autrui, formation, compétence, disponibilité,
C’est ensemble qu’il faut définir ce que représente chaque M ; ce ne sont que des exemples …
et en effet, que l’équipe se focalise sur la recherche de solutions sur les M en souffrance.
En fin de sprint, on regarde l’output et l’outcome ; si vous n’avez pas d’indicateurs palpables alors on reste dans le ressenti. Dans cette situation, avant de juger le sprint, je fais travailler l’équipe sur la réduction des risques d’où l’usage (détourné) de Ishikawa dans le sens ou je pose le problème en amont. Quels sont les causes probables qui pourraient nuire à un sprint. On n’est pas dans du constat palpable, on est plus dans l’analyse de risques potentiels.
Bien sûr l’exercice avec le speed boat est très ludique et efficace aussi.
On joue ici plus sur identifier les facteurs clés de succès que sur l’analyse d’indicateurs (qu’il faut mettre en place … voir les OKR) qui permettraient de mesurer si un sprint a été bon, moyen, médiocre mauvais …
C’est vrai que cela ne répond pas à ta demande initiale qui est de te fournir des critères pour évaluer un sprint, mais est-ce réellement le meilleur moyen à court terme ? Perso je préfère tenter de mettre l’équipe dans les meilleurs conditions possibles (en regardant chaque M) pour l’atteinte de l’objectif de sprint.
Déjà, si vous dites ce que vous faites et que vous faites tout ce que vous dites alors c’est déjà magnifique !
(ex en sprint plan, si vous prévoyez de délivrer 60 points de Valeur Commerciale qui coûte 40 Points d’Effort et qu’en rétro vous constatez que vous n’avez délivré que 40 points de VC pour 60 PE, là on peut objectivement dire que le sprint ne s’est passé comme planifié. Ishikawa pourra aider à analyser pourquoi.)
Comme le mentionne @Moosh , le plus important est de délivrer le plus de valeur au moindre effort.
Je ne sais pas si le PO pratique l’analyse de la valeur (VC) et l’équipe les points d’effort (PE) mais je trouve que ce sont 2 informations essentielles pour répondre à ces 2 objectifs :
1/ trier le backlog : mettre en haut ce qui rapporte le plus et qui coûte le moins (VC et PE en Fibonacci)
2/ délivrer au plus tôt la plus forte valeur
Au fait, si le PO est content n’est-ce pas l’essentiel ? C’est bien lui qui donne ses critères d’acceptation à chaque récit ; en d’autres termes, si l’équipe déroule les critères d’acceptation et que ça passe alors ça roule, le PO sera content et si tous les récits prévus sont faits alors la pression, elle sera dans un verre !
Le prescriptif, c’est cool, mais en fait, perso j’aimerais bien savoir pourquoi l’équipe de dev considère que le sprint était pas bon. @Manel_BEN_OSMAN , tu pourrais nous en dire plus à ce sujet ?
En fait, l’équipe de dev a remonté que le sprint était « bof » parce que les sujets traités dans le cadre du sprint ne sont pas challengeant techniquement pour eux ce que je comprends mais ce sont les priorités du moment données par le PO et qui ont des deadlines de livraison non flexibles , en gros l’équipe est attendue sur ce périmètre de livraison, c’est le job demandé, on ne peut rien y faire. D’un autre côté, certains objectifs étaient atteints ce qui est un point positif mais personne n’en parle
Il me semble que c’est le PO qui peut dire si un sprint est réussi ou non. De même si les objectifs sont atteints ou non
C’est en tout cas un point qui doit être débattu lors du sprint 0 avec les membres de l’équipe
Détermination de la définition of done (Dof) !
@Rambal
Bonsoir,
Le PO peut bien dire si un sprint est réussi ou pas en se basant sur l’atteinte des objectifs (ou pas!) , tout comme n’importe quel autre membre d’équipe, les développeurs. Selon moi, cette évaluation se fait par consolidation en interne et ne doit pas être réalisée uniquement par le PO. Il n’ya pas mieux d’une équipe de réalisation pour trancher sur le sujet.
J’ai l’impression qu’on est loin de l’esprit Agile … que l’équipe n’a, semble-t-il, pas les moyens de ses responsabilités. on est probablement dans une cloison MoA / MoE avec des contraintes de délai et de périmètre (et sans aucun doute une contrainte de budget). Le fameux triangle infernal.
Si l’équipe trouve que le sprint n’est pas bon (de son point de vue), a-t-elle les moyens de faire mieux ?
le Sprint planning est-il bien mené ? le PO est souvent challengé à ce moment là.
Je peux comprendre :
que le SM puisse trouver le sprint bon si Scrum a été respecté … et que l’équipe tend vers l’autonomie et la responsabilisation
que le PO soit content si l’objectif fixé ensemble a été atteint
que les réalisateurs ne le soient pas car le sprint ne les a pas séduit
Espérons que l’utilisateur le soit en review mais tu me dis qu’il n’y en a pas … d’ou le manque de feedback
Je rejoins totalement @Elo : si l’équipe est en souffrance (chacun affiche un emoticon à chaque daily) cela doit être creusé au plus tôt et suivi en rétro.
Une astuce comme une autre ; au démarrage du sprint, je reliais la page de rétro afin de permettre aux équipiers de s’exprimer à tout moment, dans le feu de leurs peines ; cela permettait aussi au daily d’être consacré aux moyens d’atteindre l’objectif du sprint et la rétro, de gagner en efficacité.
Si l’équipe trouve le sprint pas bon, il a sans doute de bonnes idées pour que les prochains le deviennent ; au SM de guider l’équipe à ce qu’elle trouve elle-même les causes et qu’elle imagine elle-même les actions à tester. Les outils que j’ai mentionné peuvent aider en cela.
Je suis aussi très étonné que le coach Agile ne soit pas plus sollicité ? n’est-il pas pris pour un SM sur une autre équipe ? au détriment de son rôle de Servant Leader pour l’entreprise ?
@fdav087
Je suis intéressée par l’astuce que tu mentionnes ici à propos de la page de rétro. Si je comprends bien tu crées une sorte de journal de sprint qui va être alimenté tout au long du sprint par des remontées de l’équipe (points de souffrance, problèmes rencontrés, idées à creuser…) pour trouver de la matière à travailler le jour de la rétrospective ?
.
…)
j’aime bien