La taverne du testeur

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 *

Automatisation

Livre CFTL: Évolution et état des lieux de l’automatisation

Article écrit à 4 mains avec Bruno Legeard Introduction : L’automatisation partie intégrante du test L’automatisation de l’exécution des tests constitue une large part de l’activité des testeurs comme on peut le constater avec l’enquête du CFTL de 2019 où moins de 10% des organisations n’ont pas de tests automatisés, mais

Lire la suite »
recrutement

Recruter un testeur

Avant de commencer cet article je souhaite rappeler que je ne suis pas RH que je ne suis pas spécialiste du recrutement, que ce n’est pas mon métier. Néanmoins de par mes activités je suis amené à faire passer des entretiens techniques ou à conseiller sur des types de profils

Lire la suite »
ISO 25010

Types de tests (ISO 25 010): Les tests de portabilité (8/8)

Aujourd’hui nous abordons une famille que j’affectionne particulièrement car elle fait écho à mes expériences mobiles mais aussi à mon statut de joueur de jeux vidéo. Cette famille qui est aussi la dernière famille définissant la qualité au sens ISO – 25 010 est la famille  des tests de «

Lire la suite »