Scroll to top

Rex d’une équipe qui cherche son modèle (1/2)

Une méthode de production est comme un outil. Certains outils sont bons pour enfoncer des clous, d’autres pour tourner des vis. Vous pouvez peut-être enfoncer une vis avec un marteau mais nous vous conseillons quand même d’essayer avec un tourne-vis en premier.

Avant de nous orienter vers telle ou telle méthode, il faut donc déterminer si notre objectif est d’enfoncer un clou ou bien tourner une vis et quels sont nos contraintes.

Comprendre notre environnement et nos objectifs.

Pour vous donner un peu de contexte, notre environnement était celui d’un projet déjà commencé avec de fortes échéances, relativement peu de définition et un cadre variable.

Nous faisions la migration de plusieurs briques essentielles d’un grand e-commerce français qui dispose de certaines spécificités induites par son activité et d’autres accumulées au fil de ses 15 ans de vie sans documentation extensive.

Nous étions donc à la fois en phase de migration et à la fois en phase d’exploration du passé et d’une manière ou d’une autre nous devions réussir à livrer le meilleur produit possible aux dates attendues.

Exit le cycle en V.

Nous n’avions pas le temps de faire une phase de cadrage et définition. Le terrain était trop mouvant pour faire un cadrage crédible qui tienne sur le long terme et les échéances trop importantes pour que nous les manquions à cause d’un dérapage.

Si à l’époque nous percevions toutes ces difficultés, voici une image rapide de ce qu’il s’est réellement passé, venant conforter nos intuitions :

Plan de mission

 

 

Scrum, Kanban … que faire ?

La question s’est posée en considérant principalement la prévisibilité et la facilité de priorisation.

Nous étions dans une phase de découverte avec l’équipe. Nous mettions graduellement en place de nouvelles étapes dans le cycle de production pour augmenter la qualité du produit ou faciliter sa production. Avec ces nouvelles étapes venait le risque de perdre en vélocité de manière imprévisible. L’un des piliers de scrum étant la prévisibilité et kanban de réduire le temps en production en améliorant les process, notre choix à commencé à se former. Nous n’étions pas une équipe mature et nous en étions conscient.

Aussi, nous avions une grande imprévisibilité sur certains sujets qui se bloquaient ou se débloquaient parce que nous attendions une décision, une API d’une autre équipe, un contact avec une personne externe. Imaginez qu’en milieu de sprint, une décision ou un blocage vienne rendre obsolète le sprint goal. Ou qu’en milieu de sprint, une API se libère et que si elle avait été libre plus tôt, votre sprint goal aurait été différent. Au lieu de cela, nous avons choisi de ne commencer un sujet que quand il était 100% validé et de nous focaliser sur notre rapidité d’exécution entre le feu vert et la date espérée de livraison.

Bonjour Kanban.

En kanban, l’équipe se focalise sur toutes les étapes qu’il faut franchir afin de transformer un besoin en fonctionnalité. Nous avons donc listé toutes ces étapes en les matérialisant dans un tableau et au fur et à mesure que nous faisions muter notre cycle, nous rajoutions ou modifions les colonnes de notre tableau pour qu’il représente exactement ce que nous faisions.

Tant qu’une feature n’est pas rentrée dans le cycle, elle n’existe pas. A ce titre, le design, la conception technique et toutes les étapes « annexes » du développement, font parties du cycle et sont aussi représentées. Ce qui permet de nous améliorer sur tout le cycle de production et aussi de changer rapidement la priorité sur la prochaine feature sans perturber les features en cours.

Evidemment, le flux tendu ne fonctionne pas à 100%. Parfois en conception nous nous rendions compte qu’une feature qui semblait prête à être développée avait en fait une dépendance non résolue, ou bien quelqu’un est malade, la priorité change, la météo est mauvaise … beaucoup de choses peuvent arriver. C’est pourquoi nous avions, malgré le flux tendu, un petit backlog de choses définies (donc déjà en milieu de cycle) à faire. De sorte que si une déconvenue temporaire arrive, nous puissions réagir en attendant que la perturbation passe. Ce stock de « petites » tâches ou tâches de remplissage nous servait aussi de tampon pour les bugs non urgents et les sujets d’amélioration continue.

 

Workflow_watto

Le prix du kanban.

Kanban est une méthode de production relativement plus flexible que le scrum et elle nous a permis de faire face à beaucoup d’imprévus sans mettre en péril la chaine logistique de nos features.

C’était exactement ce que nous recherchions et pour cela, nous avions réussi. Par contre, nous avions de grosses échéances à tenir. La prochaine question était donc, comment prioriser, déprioriser et réussir à livrer selon nos échéances ? Avec notre scope de features instable et nos use cases cachés, la tâche n’allait pas être facile.

Un vaste sujet qui mérite un deuxième épisode pour lui rendre honneur.

Author avatar
Clément Brottier
Product Owner chez Oscaro 🚙
En naviguant sur notre site, vous acceptez les cookies 🍪