Passer du kanban à un « Scrumban »

Cet article est la « suite » de l’article de l’année dernière sur le passage du Scrum au Kanban. Le projet continuant de vivre et l’équipe continuant à faire de l’amélioration continue (on ne peut pas être agile sans amélioration continue !), nous avons encore évolué !

Comme dit dans l’article précédent nous avons au début de la mise en place de la méthodologie Kanban éprouvé des difficultés afin de ne pas nous éparpiller. Ce problème a été résolu et nous avons réussi à avoir les avantages du Kanban en limitant cette dérive.

Néanmoins, en passant du Scrum au Kanban nous avons également quitté le « cadre » offert par le Scrum. Ce cadre s’est avéré à moyen terme un gros manque pour les membres de l’équipe.

Nous avons fait face à des effets indésirables inattendus en passant au Kanban, voici les principaux :

  • La présentation des User Storys est devenue bancale car non cadrée. Une US pouvait être écrite puis présentée et en développement en 30 minutes. Cela semble très bien sur le papier mais dans les faits cela entrainait un « switch context » (changement de tâche) trop fréquent et les US devenaient plus difficilement comparables et donc estimables.
  • La mise en place des rituels ou cérémonies était moins précise et donc moins bien suivie. Je pense notamment aux rétrospectives, moins présentes mais surtout au suivi des actions qui devenait plus compliqué car sans objectifs de mise en place à une date précise
  • Enfin, la raison qui a poussé notre changement : les développeurs avaient l’impression d’être dans une tâche sans fin. Là où le Scrum propose des objectifs et une vision sur 2 semaines (pour nous) d’engagement, le Kanban nous proposait toujours le même nombre d’US à implémenter, les développeurs avaient l’impression de ne pas avancer et de ne jamais voir le bout de leur travail.

Suite à ces difficultés remontées nous avions le choix entre :

  • Essayer de résoudre ces problèmes tout en restant en Kanban
  • Revenir en Scrum mais perdre les avantages que nous avions obtenus avec le Kanban (notamment une mise en ligne plus régulière et une réactivité plus forte)

Nous avons donc choisi une 3ème solution, une sorte de « Scrumban », très proche du Scrum.

Nous sommes revenus à des sprints de 2 semaines avec l’ensemble des cérémonies Scrum bien implémentées, des rétrospectives avec des actions suivies et un backlog qui diminue avec l’objectif de le finir dans le temps imparti avec le sprint.

Il restait cependant 2 choses que nous voulions absolument garder du Kanban :

  • Mettre en production le plus tôt possible : nous continuons de le faire dès qu’une US est « done » ce qui permet de ne pas attendre 1 semaine (ou plus) avant la mise en place de fonctionnalité ou les correctifs de bugs.
  • Pouvoir être réactifs suite aux retours des utilisateurs : pour cela nous ajoutons lorsque nous le jugeons nécessaire, c’est-à-dire suite à des grosses évolutions, une US « factice » à laquelle on attribue une vélocité. Cette US a justement pour but de corriger des bugs remontés par les utilisateurs mais aussi de développer des petites fonctionnalités ergonomiques demandées afin d’améliorer le fonctionnement des nouvelles grosses fonctionnalités.

Pour le moment nous sommes satisfaits de cette organisation qui correspond au besoins de l’équipe de développement mais aussi les utilisateurs !

Cette organisation sera-t-elle pérenne ? Aucune idée, l’amélioration continue est justement là pour nous permettre de faire des ajustements si besoin ?

Cette organisation est-elle adaptée aux autres produits et contexte ? Certainement pas ! Ou sûrement pour certains produits, contextes et équipes. Il ne faut pas oublier que dans les faits cette organisation est le fruit de bientôt 2 ans de travail sur le produit avec un contexte et une équipe en particulier. Si l’on doit retenir 1 chose de cette organisation c’est l’application de principes forts de l’agilité : s’adapter au changement, s’auto gérer mais surtout travailler sur la démarche d’amélioration continue !

En espérant que ce nouveau Rex vous sera utile !

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

culture générale

Exemple concret du paradoxe des pesticides – Hasnae Hasmaz

Lors de ma première mission, j’étais amenée à dérouler des cas de tests pour 4 applis qui servent occasionnellement (qui ont déjà été utilisées dans différents contextes et plusieurs fois), pendant l’entretien d’embauche, mes employeurs m’ont fait comprendre que je devais juste dérouler des tests, et surtout ne pas toucher

Lire la suite »
Retour d'expérience

Ma première expérience dans le test

Introduction J’ai découvert le test lors de mon stage de fin d’études. A cette époque je ne connaissais pas du tout le métier qui ne m’avait jamais été présenté (l’intitulé du stage n’avait d’ailleurs pas le mot « test ») et n’avait pas conscience qu’il était possible d’en faire son métier. Mon

Lire la suite »