Hello tout le monde,
toujours un plaisir d"échanger avec vous.
Je viens vous demander si vous avez déjà expérimenté une posture, une approche ou que sais-je pour permettre aux membres d’une équipe de rester concentrés sur le contenu du board qui a été défini en début de sprint.
Je m’explique : j’ai rencontré plusieurs équipes dernièrement qui, lors d’un sprint planning, participent à la sélection des stories pour le sprint et qui, quelques jours plus tard, font autre chose que ces fameuses stories.
Avez-vous déjà vécu cela ? Qu’avez-vous fait pour ramener la concentration sur le board ?
Quand c’est une équipe Kanban, il n’y a pas vraiment d’objectif → ca aiderait ?
Dans le cadre d’équipes Scrum qu’il y en a dans certaines et je comprends ta question qui me donne déjà un indice à renforcer sur l’objectif commun. Merci déjà.
En fait ce que je me demande c’est quelles sont les méthodes que vous utilisez pour éviter de répondre froidement : « je ne peux pas t’aider parce que c’est pas dans mon sprint » :-).
une idée comme cela qui pourrait peut être aider (mais peut être quelqu’un l’a t’il déjà expérimenté et pourra faire un retour positif ou négatif)
Leur faire comprendre que le sprint backlog leur appartient et qu’il doit faire apparaître ce sur quoi ils travaillent - les items non prévus, c’est du boulot après tout ! Cela permettant durant la review (« Regardez tout le boulot qu’on a abbatu ») et surtout la retro de se pencher dessus et pouvoir discuter du « voila ce qu’on a fait durant la durée du sprint, les difficultés que l’on a rencontré et voila ce qu’on a pu faire » et en tirer des leçons le cas échéant.
S’ils constatent qu’ils ne parviennent pas à livrer ce qu’ils avaient pris en début de sprint (je parle de l’objectif dans l’absolu mais indirectement des éléments permettant d’y arriver) mais qu’une partie non négligeable du temps du sprint a été consommé à faire « autre chose », normalement, en ayant rendu transparent la chose, ils devraient arriver d’eux même à la conclusion qu’il faut arrêter ou alors convenir que c’était ça la priorité et que l’objectif/PBI embarqués n’auraient pas dû l’être.
Si par contre, ils ne veulent surtout pas rendre la chose transparente, c’est qu’il y a une raison plus profonde qu’il va falloir creuser
Ce qui me vient comme question, c’est pourquoi ce qui a été choisi par le développeur quelques jours après le sprint planning lui a semblé plus important que ce qui avait été convenu en sprint planning ?
La posture que j’aurais en tant que SM c’est bien une posture de « je ne comprends pas pourquoi vous fonctionnez comme ça, il a un défaut dans la matrice, tel que le prévoit le scrum guide ou le kanban guide for scrum teams il me semble, expliquez-moi votre fonctionnement »
Typiquement, on est en rétro, on constate que ce qui a été pris n’était pas prévu à la base, y-a-t-il des raisons à cela (bug urgent, feedback customer,…) ?, est-ce que le sprint planning sert à quelque chose du coup ? du coup ré-expliquer l’intérêt des artefacts scrum et des événements qui permettent de les construire, réexpliquer les piliers scrum (notamment l’intérêt de la transparence)
En tout cas j’aurais pas une posture dogmatique, et en plus dans ton message rien n’indique que l’équipe ne livre pas de valeur, ce qui est l’essence de l’agilité quand même
Lors de la rétro suivante, le constat est réalisé (avec bienveillance) et généralement l’équipe décide d’un mode de fonctionnement évitant que cela se reproduise.
Je pense qu’il y a confusion ici. Le sprint backlog n’est pas « Ce sur quoi l’équipe travail ». C’est « Ce que l’équipe s’est engagé à livrer ». Et il y a une très grosse subtilité.
Rentrer des tickets sur ce sur quoi on travaille revient à mesurer le temps consommé. Ca rassure tout le monde, car on ne peut pas se tromper, mais ça n’aide pas à être prévisible
En Scrum, le sprint backlog est un engagement. Si l’équipe ne comprend pas ça, elle continuera à travailler sur autre chose, car elle ne verra pas en quoi le sprint backlog serait plus important que le mail qui vient d’arriver sur un bug à fixer ASAP pour la veille.
Tu peux tenter « Quelle est ta deadline pour ce problème ? »
La pluspart du temps on te répondra « Il me le faut pour la démo du mois prochain », ou « ça serait bien si ça pouvait être dans la release de Q3. » Bref, 90% du temps, les problèmes à fixer ASAP pour la veille peuvent attendre 2 ou 3 semaines. Donc on ouvre un ticket et on target pour le sprint prochain.
L’engagement c’est le sprint goal !
Le sprint backlog c’est le plan initial qui émerge du sprint planning pour atteindre le sprint goal, et ça peut changer
Là on joue sur les mot. Tu met dans ton sprint backlog les items te permettant d’atteindre ton objectif, objectif qui est matérialisé par les items qui sont dans le backlog… on peut tourner longtemps comme ça…
« The Sprint Backlog is composed of the Sprint Goal […] It is a picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. ».
Le sprint backlog n’est pas gravé dans le marbre, mais il représente le plan de bataille pour atteindre l’objectif de sprint. Il ne représente pas forcement ce sur quoi les dev sont en train de bosser.
Pour revenir à la question initiale de @Nicolas, Si un dev en a marre en fin de journée et a envie de se prendre 1 ou 2h pour faire un proto, fixer un bug, ou cleaner un bout de code, il n’a pas à le mettre dans le sprint backlog. Il fait bien ce qu’il veut, du moment qu’à la fin du sprint, l’objectif du sprint est rempli. La responsabilité du développeur va de pair avec sa liberté.
Tout ce que tu viens de dire me va a une exception: ce n’est pas jouer sur les mots.
La dynamique induite quand tu t’engages sur un objectif est bien plus libre que l’engagement que tu pourrais avoir sur un sprint backlog, tout simplement parce que (pour reprendre une marotte de @const ) le biais des coups irrécupérable sera sensiblement plus important devant une liste d’items concrète que devant un objectif là pour apporter un cap.
Je ne suis pas certain de comprendre la subtilité que tu mets içi, peux tu développer ? Le sprint backlog comprend l’engagement qui est le sprint goal (Why), les PBI permettant d’y arriver (what) et le plan (how)
A priori, l’équipe va travailler sur ce qui va lui permettre d’atteindre l’objectif et en début de sprint, cela correspond donc aux PBI embarqués en grande partie et ça peut évoluer en cours de sprint en fonction de ce que l’on découvre.
Le sprint backlog est le plan de l’équipe pour atteindre l’objectif et il est mis a jour chaque jour mais j’y vois un autre intérêt (et là c’est mon point de vue, je ne pense pas que ça soit écrit quelque part), c’est qu’on peut se servir de ce plan en rétro pour dire « voila ce qui s’est passé au cours du sprint, on en discute ? ». D’où ma proposition
Evidemment, on peut y arriver autrement
C’est la tournure « Le backlog doit faire apparaître ce sur quoi les dev travaillent » qui me gêne.
D’expérience, cette tournure est interprétée comme « Lorsque je travaille sur quelque chose, je mets un ticket dans le backlog ». En conséquence, le backlog devient une mesure du temps consommé, plus un outils de planification. Cela a 2 effets pervers :
Si une demande arrive en cours de sprint, même si elle n’a rien à voir avec l’objectif, le dev va se mettre à travailler dessus en rajoutant un ticket dans le backlog, pensant faire une bonne chose. Résultat, on arrive en fin de sprint avec plein de chose terminé, mais pas ce qui était prévu initialement. Mais comme on a plein de ticket vert, personne ne voit le problème. En d’autre terme, « Super, on a consommé tous le temps imparti ! »
Le dev qui veut prendre 1h de son temps pour « autre chose » (dette technique, proto, amélioration, etc…), afin de se vider la tête se verra dire « Faut que tu rentre un ticket ». Finalement, il préfèrera regarder des vidéos de chats à la place, parce qu’on lui reprochera moins d’avoir rien fait que d’avoir fait quelque chose non traqué.
Oui présenté comme cela, je suis d’accord, ca n’est pas l’idée que j’ai en tête en l’énoncant, l’idée n’est pas de tracker chaque minute utilisée mais de mettre de la transparence sur ce qui a permis ou non d’atteindre l’objectif, pour en tirer des leçons
Sensibiliser la personne concernée qu’elle met en péril l’engagement de l’équipe et qu’il joue Solo et que ce n’est pas sympa pour le groupe
Les sensibiliser sur la promesse faite au client dans le Sprint et qu’ils devront justifier des dérives en fin d’itération. Et qu’il est important de conserver un haut niveau de confiance afin d’être reconnu comme expert. ça facilite plus tard les négociations de budget de planning et de stratégie technique
Les forcer à faire sortir une US si une autre US rentre dans le Sprint. ça l’oblige à redéfinir les priorités et le responsabilise sur ces choix, ce qui peut en freiner certains.
Identifier les influenceurs (potentiellement externes) qui ont provoqué ce changement et les faire participer à la définition des priorités en Sprint Planning ou en COPIL
S’assurer qu’il a suffisament de travail dans le Sprint pour éviter qu’il fasse autre chose
Lui donner le Lead sur la définition des objectifs de Sprint
Dans les faits, il y a une différence entre « visualiser le travail » et « mettre dans le Sprint Backlog ».
Evidemment, quand on utilise un outil comme Jira, ça brouille les pistes, puisqu’il faut mettre le travail dans ce que Jira appelle « Sprint Backlog » pour pouvoir le visualiser dans le tableau Jira de l’équipe.
Mais il y a bien une différence, il y a le Sprint Backlog qui est le plan à date pour atteindre le Sprint Goal, et les choses à côté que l’on fait aussi pour diverses raisons (normalement Scrum nous dit quand même que ça doit être en lien avec le Product Goal), qu’on veut absolument visualiser sinon on ne peut pas en faire le suivi ou détecter que ce travail est problématique. (que cela impacte négativement l’atteinte du Sprint Goal)
Ensuite, on peut jouer sur les indicateurs et autres outils de visualisation pour ne pas se perdre. Par exemple un burn-down chart qui ne prend en compte que les éléments de backlog en lien avec le Sprint Goal – donc uniquement le Sprint Backlog et pas les autres choses à côté. Ca permet ainsi de favoriser le focus de l’équipe vers l’atteinte du Sprint Goal. Là encore, compliqué à faire dans Jira qui va considérer que tout ce qui est mis dans ce qu’il appelle « Sprint Backlog » (parce que sinon on ne le visualise) est à prendre en compte dans le burn-down chart.
