J’ai comme une difficulté à déchiffrer certains concepts et les exemples qui sont souvent donnés pour les illustrer par rapport au contexte du projet qu’il soit à ses débuts (Build) ou bien de son vivant (Run).
La plupart du temps, ça parle de projets en Build.
Seulement, je suis actuellement dans une phase d’agilisation d’un projet en Run.
Pour le Product Goal, ce sont de nouvelles fonctionnalités, des améliorations/optimisations/finalisations de celles qui sont existantes.
J’ai en ce sens 6 des objectifs produits pour 2023 qui sont en relation avec des échanges avec des partenaires de notre produit.
Chacun des sujets évolutifs (les parties ayant arrivées à maturité et donc une synchronisation avec le partenaire est actée) entrent souvent dans un Sprint (j’ai des Sprints de 3 semaines).
Souvent j’embarque 1 ou deux évolutions majeures.
Et parfois, un petit sujet évolutif ne faisant même pas partie des Product Goals mais repérés comme apportant de la valeur au produit par les remontées utilisateurs.
L’objectif du Sprint est souvent multiple et difficile parfois de dire si on peut définir un unique Sprint Gool comme le préconise le Scrum Guide.
Également, dire que le Sprint doit se consacrer à un seul Product Goal, c’est difficilement réalisable.
Comment ces deux notions sont-elles censées vraiment s’opérer dans une logique de RUN ?
Ou bien je prends les choses par le mauvais bout ?
Merci pour vos retours.
Ces évolutions sont le fruit des demandes des applications partenaires pour apporter de la valeur à leurs utilisateurs qui peuvent être les mêmes que les nôtres (transmission de données de notre SI via des API), ou bien une réception de données d’autres partenaires qui vont ajouter de la valeur au notre.
Ma Squad est au cœur de ce l’on nomme souvent des échanges inter applicatives dans les SI.
Cette valeur est donc bien identifiée et fait l’objet de plusieurs échanges et arbitrages avant d’atterrir dans la Squad.
Je ne comprends pas très bien cette question dans ce contexte.
Il n’y a pas eu vraiment de discussions quant à la durée du Sprint. Nous avons hérité de ce time boxe du fait que c’est la norme dans l’organisation. La cellule d’agilisation a recommandé cette durée.
C’est PO, dans la priorisation des sujets du Backlog.
Mais cela dépendons également de la synchronisation des travaux avec les partenaires lorsque c’est nécessaire.
Ensuite de la maturité technico-fonctionnelle des sujets.
Nous en sommes pas encore arrivé à ce stade mais ce besoin a clairement été identifié et en cours de mise en place. Un club d’utilisateur est entrain d’être formé pour pouvoir avoir de vraies échanges et de vraies feedback. Jusqu’à maintenant, c’est la MOA qui endossait ce rôle, qui produit donc un filtre avec des feedback tardifs et parfois loin du ressentie ou des aspirations des utilisateurs finaux.
Là où je cherche à amener la réflexion à travers ces questions, c’est que si vous « savez » ce qui doit être fait et comment, l’agilité va seulement vous mettre des bâtons dans les roues. Les surcoûts et la complexité que cette approche apporte sont des désavantages à prendre en compte. En l’absence d’espaces de pivot (exploration des solutions alternatives, cycles hypothèse => preuves => replanning) qui sont les principaux avantages que l’on tire de cette approche, les désavantages sont clairement plus nombreux que les avantages.
Je met bien sûr l’emphase sur le « savez » parce que tout le nœud du problème se trouve ici. La première étape est de comprendre que vous ne faites que supposer savoir ce qui doit être fait et comment. C’est là que la prise de feedback est essentielle dans cette approche. Tant qu’une organisation n’intègre pas ce fait, rien ne sera moins « efficace » que de « dépiler du ticket » comme on dit grossièrement.
Ma Squad peut en effet être dans cette configuration pour 30% des sujets évolutifs seulement. La plupart du temps nous partons avec un contrat d’interface pour initier un nouvel échange ou une mise à jour.
Une autre Squad, axée sur l’évolution du SI lui-même serait la plus adaptée.
Nous sommes actuellement au Sprint 6 et les résultats sont là.
Nous produisons bien des incréments de qualité et en comparaison du monde Waterfall d’où nous venons, nous sommes bien convaincu d’avoir emprunté un meilleur chemin.
Mais je note que la prudence est de mise pour que notre travail reste efficient avec cette méthode.
Pour revenir à ma question initiale, est-ce qu’il y a bien un biais dans la traduction des Goals dans un contexte de RUN ? Les concepts de cette méthode ne sont-ils pas plus orientés vers des projets en Build ?
Ma réponse pourrait ne pas te convenir mais: avec une approche produit, il n’y a pas de build et de run, il n’y a que le produit et cette dichotomie n’existe pas. Du coup, ma question suivante serait: êtes-vous bel et bien sur du projet ou sur du produit ?
Je dirais que nous sommes encore sur les deux modes.
Nous introduisons la vision produit en privilégiant des sujets à forte valeur ajoutée pour les utilisateurs mais nous nous sommes encore entrain de dépiler des sujets déjà convenus avec les partenaires et ‹ budgétisés › sans notion de priorisation par la valeur.
L’organisation n’est pas encore à ce niveau là de l’agilisation.
J’en ai bien conscience.
Ma Squad/Impact_Team gère en effet les deux aspects sur le produit.
D’une manière générale j’ai envie de vous dire à tous que vous avez le don de retourner le cerveau des personnes posant des questions sur le forum.
J’en ai déjà vu certains en perdre le fil et ce fut le cas pour moi à un moment donné.
Mais vos retours subtils ont le don de nous remettre sur le droit chemin ?
Désolé pour la réponse tardive, vous m’avez donné du fil à retordre.
J’ai bien suivi vos recommandations notamment regardé attentivement les prérequis énoncés par @jplambert .
J’ai du également relire, comme il le préconise assez souvent, le Scrum Guide et passé ma certification le Scrum Master au passage .
Le premier prérequis n’est pas vraiment atteint pour nous, concernant l’excellence technique.
Nous avons dû pain sur la planche.
Sur les autres points m, nous sommes plus matures.
?