Guide Scrum 2020 - Scrumban = Scrum

Saviez-vous que le Guide Scrum 2020 lance une OPA sur Scrumban? Tous les détails dans l'article!

Voici aujourd'hui une petite "featurette" sur le Guide Scrum 2020. C'est un changement mineur mais qui fait du bien et qui permet aussi de simplifier le nombre de variantes ou de termes que l'on a sur toutes les méthodologies lean et agile.

Scrum vs Kanban

Pour rappel, Scrum se concentre sur une approche itérative et incrémentale et donc discrète avec la notion de sprint pendant que Kanban se veut un cadre de travail se concentrant sur l'optimisation de flux qui par définition sont continus.

Avec l'émergence de DevOps et l'automatisation des pipelines d'intégration et de déploiement, il est devenu de plus en plus facile de mettre à jour les applications au quotidien. Parfois plusieurs fois par jour. Certaines organisation et équipes ont donc voulu commencer à évoluer de Scrum vers Kanban puisque la notion de sprint semblait moins pertinente. Ces équipes maîtrisant trop peu souvent les détails de Kanban, elles ont voulu garder les artefacts Scrum avec la tenue d'un backlog et d'une rétrospective et parfois aussi la tenue d'une planification et d'une revue. Et cette approche hybride est devenue "Scrumban".

Je pourrais en parler pendant longtemps, mais il n'y a rien de "Kanban" dans cette façon de travailler. L'énorme majorité des équipes que j'ai pu voir n'avait aucune gestion de queue ou n'avait aucune idée de ce qu'étaient certains paramètres clefs de Kanban comme la congestion, la cadence ou encore la synchronisation.

Bref, Scrumban a fait beaucoup de mal à Kanban en faisant croire que c'était simple et facile comme un tableau Trello avec des colonnes "To-Do", "In Progress" et "Done".

La revue de sprint n'est pas une approbation de lancement

Cette mise à jour 2020 indique explicitement que la revue de Sprint est un moment de transparence et d'inspection du travail accompli pour l'équipe pour s'adapter pour le sprint suivant. En aucun cas Scrum interdisait de déployer plus souvent qu'aux deux-trois semaines et c'est maintenant expliquer clairement. Bref imaginons que dans votre sprint vous avec 3 user stories, 2 tâches techniques et 5 bugs et que vous corrigez 2 bugs dès le premier jour du sprint, vous pouvez rapidement vous asseoir avec votre Gestionnaire de Produit pour valider le tout et pousser en production dès le même jour. Par contre vous ferez le point en fin de sprint pour voir par exemple comment éviter que ces bugs de la même nature ne réapparaissent.

À partir de là, toutes les équipes qui font du Scrumban, font en fait du Scrum et c'est très bien comme ça. On peut en tirer deux recommandations très importantes.

Déployez en production le plus souvent possible

Ça peut être vu comme une perte de temps et un peu trop intense comme pratique mais c'est la meilleure façon de perfectionner le processus et de l'automatiser. C'est aussi la meilleure façon d'accélérer la prise de feedback auprès des utilisateurs. Beaucoup trop d'équipes restent stressées à l'idée de faire un déploiement alors que l'équipe devrait au contraire avoir hâte et être en confiance. C'est une des métriques les plus distinctives entre les équipes de haute-performance et les autres. Saviez vous qu'entre une équipe de haut de tableau et une équipe de bas de tableau, l'équipe de haut niveau déploie en moyenne son code 208 fois plus souvent?

N'abandonnez surtout pas la planification et la revue de sprint

Certaines équipes profitent de ce rapprochement vers Kanban pour juste garder les principes de backlog et de rétrospective de Scrum et laissant tomber les autres afin d'avoir moins de réunions et soit-disant avoir plus de temps pour se concentrer sur ce qui doit être livré. C'est une mauvaise pratique car cela a deux effets pervers.

• Les équipes sont déresponsabilisées car il n'y a plus la notion d'engagement de sprint.

• Le travail d'équipe est réduit car il y a moins de moments collectifs.

J'ai récemment discuté avec une dizaine de CTOs et de leaders en ingénierie de start-ups montréalaises pour la préparation du contenu de ce blog. Le constat est sans appel. 100% d'entre eux ont spontanément mis de l'avant que leurs meilleures équipes ont une focus supérieur sur leur exécution et leur planification. Cela leur permet d'avoir une plus grande prédictibilité, une meilleur gestion des risques (surtout de faisabilité technique) et un plus grand sens d'implication des équipes qui prennent le temps de s'assurer qu'elles font bien leur travail.