Écrit par Sacha, Coach Agile.

Aujourd’hui j’avais rendez-vous avec Morgan le PO.

Les premières questions tournent toujours autour de la qualité:

“Alors ce virage vers l’agilité ça donne quoi en terme de performance ?

– Nous voulions des équipes plus performantes et pouvoir mettre à disposition plus rapidement nos applications à nos utilisateurs et c’est un succès _ cela a amélioré l’efficience de nos équipes en se concentrant en priorité sur ce qui apporte le plus de valeur pour nos utilisateurs. Et en travaillant sur ces cycles plus courts nous avons obtenu plus rapidement du feedback de nos utilisateurs dont des bugs…

– C’est une bonne chose mais attention. »

Je préviens Morgan qu’il faudra qu’il fasse attention à bien garder un équilibre entre la nouveauté et la fiabilité du produit.

Les équipes du Métier vont très vite être sollicitées pour participer à différents ateliers de définition de nouveaux  besoins et de priorisation. Contrairement à des organisations projets où ces personnes vont être très sollicitées au début du projet et à sa livraison, là l’activité va être constante et les contacts seront beaucoup plus nombreux avec les équipes IT et il se peut que l’attrait de la nouveauté prime sur l’opérabilité du produit.

Viennent les premières question de Morgan :

“ Comme tu nous l’as si bien expliqué, à l’échelle d’une équipe les méthodes les plus utilisées sont Scrum et Kanban. Kanban va permettre de livrer au plus tôt chaque ticket qui arrive en priorité en haut de la pile, ce qui est utile pour des équipes qui ont notamment à gérer de nombreuses anomalies de production à corriger en urgence. Pour concevoir le nouveau produit nous avons utilisé Scrum.

Maintenant que notre produit est sur le marché, quelle méthode doit  t-on adopter ? Doit-on découper l’équipe en 2 ? Une qui développe les nouveautés et une autre qui corrige les incidents de production ?

Résultat de recherche d'images pour "sav des emissions"

– Le découpage en deux équipes peut paraître de prime abord une idée simple et efficace car déjà usitée mais elle va à court terme se révéler négative en termes de qualité de construction du produit.

En effet l’équipe “produit” priorisera naturellement les nouvelles fonctionnalités en voulant répondre au mieux à ses clients.

Sa capacité à faire n’étant pas infinie elle  mettra de côté des actions de fiabilisation du produit ou de son activité.

C’est un frein à l’amélioration continue et cela peut créer des tensions inter-équipes.

En effet l’équipe en charge du SAV va au bout d’un moment se lasser de son rôle de pompier et adopter une posture fermée vis à vis de l’équipe produit et la collaboration va se dégrader.

Ce modèle a été adopté par de nombreuses organisations et   les exemples de réussites sont rares sur le plan qualitatif pour le produit.

Ce type d ‘organisation est rarement propice à l’épanouissement des salariés sur le moyen et long terme.

Une approche produit portée par l’équipe sur l’ensemble de son cycle de vie me semble  plus efficiente.

En effet les bugs font partie du produit (comme un faux rebond au Rugby…). Il faut donc que l’équipe soit consciente que les défauts constatés en production seront corrigés par l’équipe dans les sprints à venir et que si elle veut garder une capacité à produire il faut qu’elle limite les sur sollicitations de toute sorte : surproduction, non qualité,….

Il faudra bien évidemment deux modes de déploiement : une voie d’urgence pour les correctifs bloquants ou critiques et un autre pour les évolutions produits et les corrections mineures.

C’est à toi en tant que PO de décider sur chaque sprint où intervient un incident dont la correction est urgente quelle feature va être dé priorisée pour en permettre la résolution.

Ce type d’organisation a produit des résultats tangibles sur la qualité du produit et le bien être des membres des équipes.

Quant à la méthode à appliquer, une approche ScrumBan me semble intéressante à explorer.

Je pourrais te la présenter dans un prochain échange. »