Bonjour, je réagissais sur un Slack à une vidéo sur le sprint goal et j’ai remarqué un truc sur lequel on n’appuie pas forcément assez pour aider les équipes à définir de bon objectif de sprint :
L’objectif ne doit pas forcément occuper TOUT le sprint !
Pour ma part, je pense qu’on peut très bien faire d’autres choses dans un sprint, mais que LE PLUS IMPORTANT POUR TOUT LE MONDE EST L’OBJECTIF.
D’ailleurs, corrigez moi si je me trompe, mais je ne crois pas comprendre dans le Scrum Guide que celui-ci imposerait de n’avoir QUE des éléments en relation direct avec le Sprint Goal dans le sprint. Qu’en dites-vous ?
Non seulement ça, mais surtout, et plus dur à comprendre et à mettre en place : le sprint goal ne doit pas forcément se traduire en un output produit. Dans le domaine du Kaizen, avoir un sprint goal qui serait « réduire le temps de mise en prod d’une semaine à un jour » est tout aussi valable que « permettre à un utilisateur de passer une commande ».
Je retirerai « forcement ». L’objectif ne doit pas occuper tout le sprint.
Dans le sens où l’équipe de developpement doit être en mesure d’ajuster le travail à réaliser au cours du sprint. « Bien que l’Objectif de Sprint soit un engagement fait par les Developers, il offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif » (C) Scrum Guide 2020.
Je ne sais pas ce que tu veux dire par « output » dans ce cas. D’autant que ton exemple me sied bien.
Tout ce que fait l’équipe devrait apporter un résultat (outcome) pour améliorer la valeur du produit. Output-vs-Outcome-vs-Impact-1024x557.png (1024×557) (crisp.se)
Je travaille récemment à changer mon vocabulaire pour parler de « capacité » au lieu de fonctionnalité.
Dans le sens que le sprint goal doit permettre à un (des) stakeholder(s) d’être capable de …
Dans le scrum guide, il te demande d’être focus dessus. Du coup, c’est un peu gênant comme formulation. « L’Objectif de Sprint crée également de la cohérence et du focus » (C) Scrum Guide 2020.
Mais d’un autre côté, via la rétro, « Les améliorations ayant le plus d’impact sont abordées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint. » (C) Scrum Guide 2020.
Mon point était pas tant sur le mot outcome que sur le mot produit. En améliorant le process d’une équipe, tu n’améliores pas intrinsèquement la valeur du produit à court termes. Si je ne livre rien de plus que ce que le produit est déjà capable de faire mais que j’ai amélioré la façon dont on build le projet, je n’ai, en soit, ajouté aucune valeur au produit à l’instant T. C’est cette notion productiviste et orienté « produit » que je n’aime pas.
Pour moi, l’amélioration du process comme Sprint Goal est tout à fait valable, et c’est tout autant entendable par les users : grâce à ça, on pourra mieux livre/éviter des bugs, etc.
D’ailleurs, ça pose la question de savoir à quel point les outils, par exemple de déploiement, font partie du produit ou non.
Justement, ils n’en font pas partie. Ce serait aussi idiot que de dire que l’usine qui a créé la voiture fait partie de la voiture. En effet, elle est un des facteurs qui pourra jouer sur la qualité d’assemblage, la finition etc… mais en soit, quand une cliente achète la bagnole, elle ne va pas « acheter » l’usine avec.
Non mais par exemple dans le cas de Tesla, tu achètes aussi la structure de rechargement dédiée, que je considère comme faisant parti du produit.
Contrairement à une usine de voiture, le logiciel est dans une structure qui est utilisée par l’utilisateur.
Y’a une différence entre outils de développement et infrastructures. Sans parler des outils fonctionnellement nécessaires au fonctionnement du produit. L’IDE que tu t’utilises n’est pas utilisé par l’utilisatrice, pas plus que ta suite de test ou ton pipeline de build.
L’idée est d’éviter aussi la surproduction, il faut donc un lien entre l’objectif et le produit.
« un plan d’action pour la réalisation de l’Increment » (c) Scrum Guide 2020.
Je comprend qu’il faut livrer un incrément à chaque sprint.
Pour moi, tu peux avoir des objectifs de sprint qui permettent d’améliorer le fonctionnement de l’équipe si le produit y trouve un bénéfice (livrer des fonctionnalités plus puissante, livré plus rapidement, réduire le délai de support).
Mais tu peux aussi l’aborder autrement, je livre toujours de la valeur au produit. Mais je (en tant qu’équipe de dev) décide d’améliorer mon socle technique (feedback de la retro).
Alors je décide de jouer sur un périmètre fonctionnel très petit avec beaucoup d’espace pour la partie technique. Je m’assure ainsi qu’il n’y a pas de rupture dans ma capacité à délivrer de la valeur.
Il ne faudrait pas partir sur un changement technique qui m’empêcherait d’apporter de la valeur pendant une certaine période. Ce serait alors contraire aux principes de création d’incrément de valeur à chaque sprint.
Pour ma part avoir une vision outup ou uniquement sur les fonctionnalités du produit c’est faire fi de la qualité. Un bon artisan a de bon outils pour fabriquer un bon produit de qualité.
La course aux fonctionnalités crée la plupart du temps des produits monstrueux, ce que j’appelle l’effet Frankenstein, produits qui au bout d’un moment sont très complexes à faire évoluer et à maintenir.
C’est une des causes de faillite de nombre d’entreprises qui souvent se dépêchent de se faire racheter avant de mourrir.
C’est la definition of Done qui vous aide pour cela.
C’est aussi que les équipes sont autonomes et décisionnaires du sprint goal. Elle décide d’un sprint goals leur permettant d’éviter des « produits monstrueux ».
Non. Livrable ne veux pas dire livré. C’est subtil mais ça a son importance.
On en vient au cœur du problème, qui est la taille de ton sprint. Réfléchir à ce sujet sur un cadre de temps d’un mois n’est pas le même sujet que pour un cadre d’une journée.
Je suis d’accord un sprint se concentre sur un objectif. Pour l’atteindre il faut sûrement plusieurs incréments mais qui néanmoins, assemblés ensembles deviennent l’incrément du sprint. Cet incrément, une fois ajouté au produit, c’est ce nouvel état du produit qui devient l’incrément !
