L’approche Scrum insiste sur l’efficacité de bien définir les priorités du produit en un endroit unique, le product backlog, et de travailler en respectant les priorités définies précédemment.
L’approche Lean se focalise sur la satisfaction du client final, et en particulier cherche a éliminer les gaspillages de temps et donc à livrer le plus rapidement possible au client final.
Il m’a toujours semblé qu’il n’y avait pas d’antinomie entre les 2 approches … et pourtant !
En Scrum, lorsque les items du Backlog sont déclinés en tâches lors du Sprint Planning Meeting, il est recommandé à l’équipe de choisir en premier les tâches associées aux items de priorités les plus fortes et de respecter ces choix quoi qu’il arrive. Le Product Backlog est renseigné avec différents éléments, des exigences fonctionnelles, des besoins non-fonctionnel et des bugs.
Cette façon de procéder est basée sur quelques principes :
- Répondre aux attentes du Product Owner qui cherche à produire de la valeur ajoutée rapidement
- Éviter les changements de contexte qui consomme beaucoup de temps à l’équipe
- Assurer que des items du Backlog seront réellement terminés et qu’il ne sera pas nécessaire de revenir dessus
De plus,à titre personnel, je note bien souvent un intérêt grandissant au sein de l’équipe lorsque tous les membres travaillent sur le même item, l’écoute et l’entraide sont alors nettement meilleurs.
Pour le Lean, la satisfaction du client et la réduction des coûts passent en premier, et il est donc nécessaire de chercher à réduire les temps moyens d’attente. Lors du XP Days, Marie-Pia nous a présenté un exercice simple pour illustrer ce principe qui consistait à faire passer 15 passagers à la douane avec le moins d’attente possible sachant que les certains passagers passent en 1′, d’autres en 4′ à 7′, et certains entre 15′ et 25′. La solution optimum pour réduire le temps d’attente moyen des passagers consiste à spécialiser un douanier dans les passagers rapides.
En général, la correction des bugs prend moins de temps que la réalisation des exigences fonctionnelles, dans la logique du Lean, il serait plus efficace de gérer un backlog de bugs indépendant et dédier 1 ou 2 membres de l’équipe à leur correction. De plus, cela pemettrait d’éviter de dire aux utilisateurs que leur « petit » bug ne sera corrigé que dans 4 sprints compte tenu des priorités existantes, ce qu’en général il ne comprend pas … à juste titre.
Coté méthode Scrum, la recommandation est de gérer les priorités de tout ce qui est à faire – bugs inclus – à un seul endroit, le Product Backlog, puis de respecter les priorités … et donc de ne pas choisir la solution qui réduit le temps d’attente moyen des clients au minimum.
Etonnant non, comme dirait Mr Cyclopède 🙂
Le « bug ne sera corrigé que dans 4 sprints compte tenu des priorités existantes » ???
s/4 sprints/$x mois/
Deja entendu ca cette semaine… et les autres avant…
La satisfaction client necessite en effet d’adresser immediatement les « petits » bugs et les demandes de support. Cela rentre en conflit avec le management « traditionnel » qui tente de tout planifier et d’occupper son equipe a 100% sur ses « dev ». Il n’y a alors plus de place pour traiter l’imprevu.
Manager et planning a tenir vs Client en attente ! Un duel difficile a arbitrer. Il y aura forcement un mecontent. Mais le quel ? Quelles pratiques pousse t’on dans votre organisation ?
Dans le cas évoqué, il s’agit de bugs connus qui ne sont pas toujours mis en plus haute prio dans le Product Backlog (c’est un constat pas une recommandation)
Par contre, je recommande à toutes les équipes de prévoir un buffer lors du Sprint Planning Meeting pour traiter les urgences éventuelles (bugs à corriger immédiatement)
Bonjour,
N’étant pas spécialiste de Scrum, je vais peut-être poser des questions naïves dans la suite de mon commentaire…
Dans ce cas, si je me réfère à tes articles précédents sur la gestion des anomalies, cela revient, sur le sprint, à avoir une vélocité inférieure, non ?
Mais, dans les bonnes pratiques que j’ai pu lire, il est expliqué que la vélocité est un indicateur important, car il permet de mettre en lumière un dysfonctionnement dans la façon de travailler. C’est donc là que ma question surgit…
Pour nos clients, nous avons souvent à traiter deux types de demandes « perturbatrices » qui entrent en jeu dans la perception du service par le client :
– Les defects : qui font naturellement baisser la vélocité : je ne reviens pas dessus
– Les demandes de soutien : qui permettent d’aider le client à utiliser le logiciel, et à mieux le tester
Si un client est particulièrement pointilleux et demandeur d’information, cela fait donc diminuer la vélocité, alors qu’en définitive, la qualité du travail n’est pas en cause…
L’indicateur « vélocité » perd donc, pour moi, un peu de son intérêt. Qu’en penses-tu ?
Oui, toute correction de bug diminue la vélocité.
Pour ce qui est des demandes de soutien, le mieux est d’utiliser un buffer (le même que pour les urgences). La vélocité va donc baisser puisque l’équipe aura moins de temps pour produire. Si les demandes de soutien contribue à l’amélioration de la qualité, cela se traduira naturellement par une augmentation de la vélocité et une réduction de la taille des buffers … si cela ne se produit pas … il y a un dysfonctionnement.
Ces discussions me rappellent un passage de Scrum & XP depuis les tranchées, qui traite de la gestion des bugs dans les sprints en présentant divers scenarii.
Pour ma part, je pense que les bugs ont des différences caractéristiques avec l’assistance utilisateur, dans le sens où la plupart peuvent facilement attendre un peu (ne serait-ce que la fin d’un sprint), et il sont très proche du développement, donc de l’équipe. A l’inverse, un utilisateur a un besoin bien plus spontané, demande une réponse rapide, et il n’est pas nécessaire de connaître la technique pour répondre aux questions fonctionnelles.
Ma proposition serait qu’une partie de l’équipe soit dédiée au support utilisateur, et que cela ne soit pas pris comme une charge de l’équipe Scrum. Du coup, les bugs légers pourraient être traités par cette équipe, et les plus lourds chiffrés et priorisés dans le backlog à la Scrum… la « partie de l’équipe » peut en fait tourner (1 jour chacun).
Au final, on a bien une baisse de vélocité par réduction de l’équipe, mais pas de baisse de vélocité « nominale » (moyenne par personne). Si on veut garder la vélocité initiale, il faut augmenter la taille de l’équipe conformément à la charge d’assistance.
Les questions seraient alors la gestion de l’activité assistance en mode scrum (je ne vois pas de backlog), son calcul de vélocité (sur le nb d’évènements traités). Une idée complémentaire serait l’exécution de tests en période d’inactivité : étant proche des utilisateurs…
En même temps avec Lean, compte tenu de la recherche de perfection et de valeur (donc la chasse au gaspillage) le problème évoqué ici ne se poserait pas : au premier bug détecté on arrête la chaîne, on procède aux « cinq pourquois »…
… bref pas de place pour eux, et oui arrêter la chaîne c’est avoir une vélocité mal en point, ce qui nous assure qu’on ne veut pas que ça recommence 😉
Plus sérieusement :
– si on utilise des time-box (qui ne sont finalement que des lots), alors tant que le nombre de story-points sortis est celui désiré, où est le problème ?
– par contre, si on est dans une logique de flux, là on a tout à craindre de la variabilité, et du coup le fait de créer des files spécialisées devient une nécéssité. (Lors d’une discussion avec François Bachmann lors des XPDay France 2009, il disait que les « classes de service » de Kanban servent à ça, je suis encore divisé)
Je partage le point de vue de Yann : la question à se poser est « qu’est-ce que l’équipe décide pour ne plus générer de défaut? », plutôt que « comment allons-nous gérer les défauts? ».
Selon moi, le « stop the line » est justifié pour un défaut : si cela n’est pas justifié dans un contexte particulier, alors ce n’est surement pas un « vrai » défaut, mais plutôt une amélioration, voire une attente pas bien exprimée/comprise par l’équipe.
Je suis assez troublé par les propos que tu rapportes car dans nos métiers de services et de conception (ce qui est produit c’est de la matière grise en fait), on a intérêt à rallonger le temps de cycle (baisser la vélocité) au début pour faire monter l’équipe en compétence, pour réduire les réapprentissages, bref investir aujourd’hui pour aller plus vite demain. Après c’est probablement une valeur moyenne dans le temps du projet/produit que l’on cherche à optimiser, comme tu le dis.
J’ai utilisé l’exemple des bugs, mais le raisonnement s’applique également à tous les items du backlog de complexité 1 (voir 2) qu’il serait plus efficace de gérer à coté pour être plus efficace.
Alex
On dirait que le troll des bugs était tellement beau que le reste du message n’est pas passé 😉
Si je devais résumer (corrige-moi si j’agrave les choses) :
1) SCRUM -> lots (les “sprints”) -> contrôle de la priorité uniquement
2) Lean -> flux -> contrôle de la variabilité (pour avoir un flux régulier) ET des priorités
Et là on retrouve le discours de Womack et Jones au sujets des coûts engendrés par les lots…
… notamment à cause des défauts cachés (OK j’arrête 😉
Histoire d’apporter quelque chose :
Je dirais que l’avantage de SCRUM dans ce cas là est de pouvoir faire face à des workflow non-répétitifs et d’appuyer sur le bouton “reset” à chaque fin de sprint (normale ou pas), d’où une ré-orientation facile (c’est une méthode agile, après tout :-).
Tu as tout bon Yann 🙂
Et j’aime bien ta conclusion sur les workflows non répétitifs, car c’est effectivement un avantage de Scrum que je n’avais pas « visualisé » de cette façon, merci 🙂
Cette problématique a été évoquée dans scrum depuis les tranchées. D’après l’auteur, il est plus classe de laisser le Client ou son représentant de juger la priorité d’un bug par rapport aux US en cours de sprint. Selon Scrum à chaque fin d’une itération le client peut décider de mettre en production son produit. Si un bug est bloquant alors il peut passer en top priorité. Scrum recommande que l’équipe travaille sur une seul radiateur. Le bug devra être transformé en US pour répondre au normes INVEST et découpée en tâche. La vélocité ne baissera pas forcément vu qu’une fois estimée le client décide d’ajouter le bug dans le sprint en cours mais le scrum master informera au client de retirer une US fonctionnelle de même poids afin que la vélocité soit stable. Surcharger l’équipe entraînerait une fatigue de l’équipe, développement rapide des US pour finir le sprint, moins l’accent sur la refactorisation de code, des tests baclés,etc. Bref la qualité du produit est impactée.
Lors de la rétro l’équipe établira des axes d’améliorations.