Je suis tombé sur Twitter sur un article décrivant le passage de Scrum à Kanban par une équipe qui a expérimenté Scrum pendant 3 ans, avant de se heurter à des limites qui les empêchaient d’évoluer.
L’histoire est très intéressante à plusieurs points de vue:
- L’équipe n’a pas renié l’Agilité puisqu’elle est passée de Scrum à Kanban qui est elle aussi une autre méthode Agile.
- Ce n’est pas ici une histoire de transformation Agile qui n’aurait pas fonctionné puisque l’équipe a expérimenté Scrum en suivant correctement tout le cadre de la méthode pendant 3 ans.
- Enfin l’équipe a su identifier les points qui les bloquaient dans la méthode Scrum pour pouvoir aller vers plus d’agilité tout en restant conforme à la philosophie.
Quelques points surprenants tout de même:
- 3 à 4 heures de réunion à chaque rétrospective d’un sprint de 2 semaines, c’est un peu riche. Il aurait sans doute fallu “timeboxer” la réunion et se concentrer uniquement sur le ou les 2 problèmes principaux.
- De même la durée des réunions d’estimation est assez étonnante, peut être estimaient ils trop en avant dans le backlog au lieu de se concentrer uniquement sur ce qu’il est plausible d’embarquer dans les 2 sprints suivants.
5 Commentaires
Passer au formulaire de commentaire
Cette équipe a eu raison, je ne pense pas que cela puisse permettre une autre conclusion que de comprendre pourquoi on fait les choses, de se faire conseiller d’expérimenter, dès qu’on a atteint une maturité suffisante pour ne pas se mettre soi même en danger. ( Performing donc)
En effet, le fait en Scrum de ne livrer qu’à la fin du sprint est une interprétation à mon gout un peu littérale. Cela crée certes une émulation mais entraine une procrastination et un danger sur la qualité. Ce n’est pas à mon gout “Agile”. L’itération n’est qu’un time box, J’aime soumettre au PO des “stories” qui ont atteint leur DOD pour feedback et acceptation. Reste que cadencer les revues simplifie la communication aux autres clients de l’équipe. Comme Kanban cela vient de Lean.
La planification par intervalle ( optimiste/ pessimiste) est aussi un must. Car cela évite la course au points surtout si le management n’est pas suffisamment formés sur Agile et je n’ai jamais vu une équipe qui ne faisait rien à cause du fait d’être en sprint. Je ne parle pas de cas de blocage, le miracle n’étant pas de ce monde.
Sur les daily et la colocalisation, effectivement trouver l’horaire est un casse tête, j’imagine que tout les autres meeting formels avaient déjà disparu ( ce n’est parfois malheureusement pas le cas .Le rapport gain/ cout ( ROTI) doit compenser la perte évidente. N’oublions pas que nous autres ingénieurs préférons démarrer la tâche plutôt que de prendre du recul et comprendre la dynamique de l’équipe, pourtant un observateur externe voit en quoi cela génère du gaspi.
Le daily permet de revoir le plan quotidiennement. Oui les outils collaboratifs ont énormément progressé. Et oui je crois que nous aurons de plus en plus d’équipe Scrum distribuées. La encore, nous ferons bien attention à ne pas généraliser trop vite: Rien n’est aussi efficace qu’un discussion rapide pour faire avancer le task (ou mieux un kanban) board, le post-it reste simple à suivre et bon marché. Je crois juste que la technologie va encore énormément progresser.
Reste le problème de l’apprentissage ( le fameux profil en T) . Prendre la story de plus forte priorité sans avoir aucune des compétences requises requière un acte de courage. Je veux bien croire que certaines personnes arrivent à travailler en binôme à distance, c’est en tout cas un grand signe de maturité. En tout cas cela ne doit pas être au détriment de l’idée de prendre les story selon l’ordre défini avec le PO et sans colocalisation au moins partiel c’est un joli défi. Bravo donc à cette équipe pour cela. Nous avons à apprendre et c’est ça à mon gout qui fait de scrum un outil au service d’une réel organisation apprenante.
Se voir à intervalle régulier pour planifier ou raffiner les stories est une bonne idée encore une fois pour gagner du temps.
Bref Je suis d’accord que Scrum a une grosse faiblesse: Scrum ne limite pas le Work In process et peut pour peu que le PO ne soit pas présent ( mais dans ce cas kanban ne fera pas mieux) peut créer des mini Waterfall. Mais si on parle de Kanban avec itération/ estimation relative/Retrospective/Pairing, C’est peut être bien du Scrumban non ?
En gros là où l’on oppose Scrum et Kanban, je les trouve parfaitement complémentaire, même si je suis un fan de development flow avant tout.
Auteur
Merci Yves pour cette analyse poussée 😉
Un des points qui m’a étonné pour justifier leur abandon de Scrum était la durée des meetings. 3 à 4 heures de rétrospective pour des sprints de 2 semaines, ca me parait vraiment très long. Dans mon ancienne équipe (celle qui faisait réellement du Scrum), la rétro était elle aussi timeboxée à 1 heure et nous n’en sortions qu’avec une ou deux maximum actions d’amélioration.
A mon avis ce qui les a fait changer c’est peut être tout simplement la lassitude du cadre (carcan ?) Scrum qui devient lourd quand on en a atteint les limites.
Et après tout, à la limite, Kanban c’est un peu du Scrum avec des sprints de 1 jour 🙂 (ok il y a aussi le WIP !)
Oui Kaizen, Kaizen et Kaizen encore. Le scrum Guide invite à des rétrospectives allant jusqu’à 4h pour 2 semaines il me semble. Personnellement la rétrospective est la seule réunion que j’invite à ne pas timeboxer. Une Définition Of Done me parait une meilleure idée: Par exemple j’aime travailler pour en sortir avec 2 expérimentations (interne à l’équipe donc), et le point le plus urgent proprement quantifié où l’on souhaite de l’aide extérieur. Avec de la technique, 1 heure est généralement suffisant. Parfois plus: quid par exemple de l’élection d’un nouveau pape. C’ est bien une forme d’expérimentation? Avant la fumée blanche, Il est important que chacun puisse s’exprimer. Dans certains groupes cela demande du temps. Si trop long peut-être l’équipe est en phase de storming, là ou les conflits apparaissent et qu’aucune décision collégiales ne ressort. Un “coach” extérieur à l’équipe en général aide énormément surtout le Scrum Master est partie prenante: Dans sa célèbre série, Dr House fait venir l’homme de ménage dans une scène mémorable pour trancher sur un conflit de diagnostic médical.
Bilan très intéressant !
Peut on avoir un lien vers l’article de référence ?
Auteur
Bonjour Alice,
L’article de référence est à la fin de l’article, vous n’arrivez pas à y accéder ?
Voici le lien en direct: https://medium.com/doyoubuzz-open/l-histoire-de-l-agilit%C3%A9-chez-doyoubuzz-839b5dd1a0d9
Fabien