Sur ce sujet :
Il n’existe pas de processus permettant de tout livrer sans bug.
Exactement, d’un point de vue extérieure, c’est l’équipe qui doit être tenue responsable.
Mais en interne les développeurs ne doivent pas avoir peur de se dire les choses. Ensuite, l’équipe doit faire en sorte que cela ne se reproduise plus.
ce site est extra ! 
1 « J'aime »
Et pourtant tellement méconnu… autant sur le fond que sur la forme (l’histoire de comment il a été créé et de tout ce qu’il y a derrière est vraiment passionnante).
…
Perso c’est un classique pour moi et ce pour la simple raison que, quasi systématiquement, quand une question comme celle là se pose, ma machine interne à « 5-pourquoi » m’amène à chercher la cause réelle. Et donc souvent je parle d’un sujet qui est différent de celui de la question de départ. Et j’ai l’impression de retomber sur les mêmes « fondements », les « pourquois » d’origine de l’Agilité, du Lean, du DevOps, du Mangagement 3.0 …
1 « J'aime »
Merci à tous pour vos contributions passionnées sur ce sujet et pour la vidéo 
.
Pour vous donner un petit feedback sur la situation : on est évidemment parti sur le comptage des story points une fois les story effectivement « done » et pas avant. Cela impacte le sprint planning (on note sur un papier le delta entre les SP affichés et les SP RAF des éventuelles US déjà entamées) et on utilise la vélocité historique pour challenger la crédibilité globale de l’engagement qui est ensuite affiné et confirmé/modifié par l’équipe (souvent l’équipe est plus optimiste que ce que la vélocité pourrait nous amener à prendre, et c’est la vélocité qui aurait eu raison…).
Cela impacte également le burndown du sprint qui est un peu plus difficile à suivre mais rien d’insurmontable avec une équipe qui se focalise sur l’avancement vers l’objectif de sprint, ce qui effectivement reste l’essentiel.
En bref rien d’impossible et l’équipe semble s’y faire en attendant que la vélocité se stabilise et qu’on converge vers les 100% de tenue des engagements .
Il y a quand même quelques passages de la vidéo avec lesquels je ne suis pas à l’aise et qui rejoignent 2 interrogations plus larges :
-
Comment, dans la vraie vie, on définit un objectif de sprint qui colle à 100% (ni plus ni moins) avec la capacité de l’équipe (puisque équipe stable et durée de sprint fixe, on est grosso modo dans une capacité de production fixe). Celà veut à mon sens dire qu’on doit forcément régulièrement rajouter des US moins prioritaires (mais générant pourtant énormément de valeur utilisateur, puisque elles sont priorisées dans le sprint en cours), qui ne contribuent pas forcément à l’objectif de sprint. Dans ce cas, je trouve souvent qu’on essaye de générer des sous-objectifs qui au final tournent vite à des listes d’US (ou de la gestion de priorité)
-
Comment peut-on considérer qu’une équipe dont les individus sont individuellement incapables d’estimer la moindre tâche (un des principes fondateurs du #noestimates), est capable de prendre collectivement à 6 ou 7, sur un plan de travail complexe avec les éventuels congés un engagement qui soit plus fiable que celui donné par un historique de vélocité et une estimation des tâches unitairement ?
Mais ça mériterait surement 2 sujets à part !
Oulah, peut être qu’il y a eu mésentente mais:
- l’engagement existe UNIQUEMENT sur le sprint goal
- mathématiquement, une équipe est censé finir complètement ses SBI seulement 50% du temps. C’est la définition même d’une moyenne et de sa variance. Si l’équipe réalise 100% des SBI de son sprint à chaque fois, elle est paradoxalement en sous-performance.
1 « J'aime »
Ce n’est ni le but, ni forcément souhaitable, justement pour les raisons que tu cites plus bas (petit SBI pouvant ajouté énormément de valeur et qui ne ferait pas forcément l’objet d’un goal en soit.
Mais si tu souhaites réduire la portée de tes buts de sprint, j’ai deux possibilités :
- Créer un product backlog sous la forme de sprint goal: plus de questions à se poser, ils sont déjà là.
- Réduire la taille des sprints: ça réduira le ratio SBI servant au sprint goal vs SBI annexe puisque moins de temps sur un goal demande plus de focus sur ce dernier.
J’aime bien donner la comparaison avec l’utilisation du GPS comme outil pour partir en vacances, ou en moins fun, pour revenir de vacances.
Ton GPS t’affichera un itinéraire et une durée pour arriver à ta destination. Si tu pars de suite, il t’indique à quelle heure tu arriveras.
Tu sais bien que l’heure indiquée ne sera que très rarement respectée, mais c’est une indication…
Quand on te demande à quelle heure tu arrives, tu te bases sur l’heure indiquée, mais tu ajoutes toujours un peu de marge, les enfants qui veulent faire pipi, les pauses pour le repas, pour changer de conducteur, les bouchons…
Ton objectif est d’arriver, pas d’arriver exactement à l’heure indiquée.
Ton objectif est que tout le monde arrive sain et sauf et qu’il n’y ait pas d’accident, pas de dégâts, que la route soit agréable pour tout le monde et que tu ne sois pas trop fatigué en arrivant pour tout décharger.
C’est très rarement que tu vas te mettre comme objectif d’arriver exactement à l’heure indiquée et à part te mettre une pression tout le long, tu ne la tiendras quasiment jamais, il y a toujours un événement extérieur qui viendra mettre la pagaille.
En revanche, l’élément important à avoir en tête est que tu n’as pas mis cette destination sur ton GPS pour le fun, pour rien, tu ne vas pas à cet endroit, pour rien !
Si l’idée de mettre une destination au hasard et essayer de passer par toutes les villes intermédiaires qu’il t’indique en respectant l’horaire pour atteindre ton objectif, tu comprends bien qu’il n’a aucun intérêt et que les passagers ne comprendront pas où tu vas, pourquoi tu passes par là et à quoi ça sert d’être parti !
L’objectif du sprint a cette importance capitale qu’il est le but à atteindre et qu’il donne sens à tout ton voyage… et que tout doit être organisé autour pour l’atteindre !
Tu ne détermines pas l’objectif du sprint à partir de toutes les contraintes qui sont autour de toi et des étapes que tu dois accomplir pour dire j’ai tout coché.
Et évidemment, même si tu n’as pas eu un voyage parfait, où tu as du t’arrêter plus souvent que prévu et où tu as eu des bouchons qui t’ont fait perdre 2h, au final, tout le monde est arrivé sain et sauf sur le lieu de vacances ou à la maison et c’est ça qui compte ! le comment tu y es arrivé, une fois à destination, tout le monde s’en fout ! Tu seras plus fatigué et la prochaine fois tu prévoiras un peu plus de marge, un pique nique dans la voiture au cas où vous serez coincés sur l’autoroute, à boire, s’il fait super chaud et que c’est l’été, pour arriver plus serein à ta prochaine destination.
C’est comme ça qu’il faut voir le système et l’utiliser pour qu’il t’apporte quelque chose et te permette d’arriver à destination.
Tu as utilisé ta voiture, tu peux également prendre le train, un avion, un vélo, un gps ou une carte, ce ne sont que les outils pour atteindre ton but… mais sans but, sans objectif, il manque quelque chose.
Si ton voyage dure plusieurs jours car la destination est très loin, tu arrives à la notion de sprint, qu’est ce qui rentre dans une journée (pour le voyage) ou dans le sprint (pour le produit) pour atteindre l’objectif du jour (ou du sprint).
En souhaitant que mon exemple aura permis de mieux comprendre certains parallèles.
3 « J'aime »
J’adore l’idée du GPS, très bonne image!
1 « J'aime »