Org Topologies & Stratégie Kanban pour augmenter son agilité business - Second volet

Chapitre 2 : Projet de refonte et première modification d’organisation

L'organisation, qui était loin d'être performante, avait de plus entraîné l'application numérique dans une dette technique importante. Les clients en subissaient très fortement les conséquences, avec des incidents critiques qui étaient de plus en plus fréquents. Paul lui aussi en faisait les frais, de plus en plus de tests de non-régression étaient poussés à l'unité de testeurs, espérant ainsi éviter d'amener des problématiques importantes sur l'application jusque dans les mains des utilisateurs.

La direction, au regard de cela et ayant de plus en plus d'écho que l'organisation n'était pas efficiente, décida de lancer un vaste projet de refonte.

Elle en profita pour faire quelques modifications d'organisation afin de rapprocher des personnes qui avaient pour objectif de mener à bien ce projet. Les BA/Chef de projet SI fusionnèrent avec les personnes en expertise de test, pour former une unité fonctionnelle (B1) (Pour la suite, cette unité sera appelée l'unité de BA).

Paul, qui avait acquis beaucoup de connaissance sur le périmètre, se vit offrir une possibilité de rejoindre l'équipe et en finir avec sa vie de consultant. L'idée lui plaisait d'autant plus qu'au niveau interlocuteur métier, la direction avait entrepris des actions pour qu'une unité de connaissance client se fédère autour d'une personne, un chef de projet métier (C0).

Cette personne par son travail avec les commerciaux, les personnes du marketing, de la hotline et bien évidemment des clients devait rapidement acquérir une connaissance élargie des attentes et problématiques des clients. Elle allait travailler par ailleurs étroitement avec l'équipe dont Paul faisait partie pour amener du sens au travail réalisé et prioriser les développements les plus pertinents par rapport à ce qui était attendu par les clients.

Paul n'avait jamais eu l'occasion d'avoir un interlocuteur lui faisant aussi bien prendre conscience des attentes des clients, sa motivation ainsi que celle de ses collègues devint rapidement bien plus importante.

Paul avait vu dans ses précédentes expériences des équipes qui utilisaient un management visuel physique pour gérer leur projet. Il proposa au reste de son unité de BA de mettre ce management visuel en place.

L'idée de Paul et la collaboration avec le reste de l'unité les amena à mettre en place un simple workflow "A faire", "En cours", "En attente", "Terminé".

Côté unité de développement, ils avaient eu, eux aussi, écho de cette approche et Paul se souvient qu'ils avaient à peu près mis la même chose en place.

Paul découvrit un peu plus tard qu'ils avaient initié la mise en place d'une stratégie Kanban, cependant 

"Nous n'étions clairement pas dans une stratégie Kanban, tout simplement parce qu'à cette époque personne ne connaissait ce qui s'était mis en place chez Corbis* et l'émergence de Kanban pour le domaine du product management. Si cela avait été le cas, nous n'aurions certainement pas eu cette colonne ("En attente").

Nous n'avions par ailleurs pas de règles de passage très explicites entre nos états, il y avait beaucoup d'implicites autour de ce workflow. Enfin, il nous manquait tous les autres éléments d'une véritable stratégie Kanban. Comment limiter l'encours? Des règles de tirage explicites, un niveau de service sur lequel l'unité se challenge etc.

Nous aurions pu et dû à cette époque fusionner nos workflows afin d'avoir une vision globale de ce qui se passait, car au final quand nous (BA) terminions quelque chose, c'était une spécification, une explication d'une anomalie que nous donnions à l'équipe de dev et qui donc pour eux aller apparaître dans leur "A faire". 

Quand ils terminaient, cela revenait chez nous (BA) pour que nous testions. Nous faisions alors entrer un ticket de recette qui traversait notre workflow (d'où la colonne en attente que nous utilisions lorsqu'un bug était trouvé et que nous attendions la livraison d'un correctif pour reprendre les tests)."

*Si vous voulez en savoir plus sur la naissance de Kanban pour le domaine du product management qui s’est passé chez Corbis (une compagnie de Bill Gates), l’histoire est très bien raconté dans le guide de poche Kanban (https://prokanban.org/kpg/)

Si ces deux unités avaient juxtaposé leur workflow, ils auraient obtenu quelque chose comme :

Difficile par cette juxtaposition d'avoir une vision de bout en bout pour savoir combien de temps ce collectif mettait pour terminer un sujet qu'attendait des clients où qui était utile dans le cadre de la refonte de l'application.

Paul raconte : "On avait parfois jusqu'à 4 ou 5 allers et retours avec des corrections à réaliser et des nouveaux tests à faire, autant de post-its qui circulaient sur notre management visuel. On avait ajouté des dates de création de sur nos tickets, mais si on voulait savoir combien de temps avait pris le développement, le test et la correction du Dev A, on était en difficulté pour avoir cette information.

La simple mise en place de cela avait tout de même un gain non négligeable par rapport à la visibilité dans chaque unité de ce qu'il y avait à faire, de ce qui était en cours. La collaboration au sein de nos unités était devenue meilleure, les personnes étaient de plus en plus capables d'intervenir globalement sur l'application existante, mais aussi sur la nouvelle que nous construisions"

Paul relate par contre, que le chef de projet métier s'agaçait régulièrement, car il était impossible pour lui d'avoir une information claire de quand un sujet allait être bouclé. Il voyait qu'il y avait beaucoup de travail réalisé, qu'il y avait des avancements, mais s'il voulait communiquer à la direction ou aux clients quand la fonctionnalité F allait sortir, il ne pouvait toujours pas avoir de réponses fiables. Ce qui l'amenait à devoir revenir sur sa communication régulièrement.

Le temps réellement pris pour terminer une fonctionnalité était bien souvent largement en écart à l’estimation initiale qui avait été faite… et malheureusement pas dans le bon sens, plusieurs semaines assez fréquemment.

La direction de son côté commençait à douter de la capacité à mener à bien le projet de refonte, de nombreux décalages de planning survenaient encore et toujours.

Paul : "L'agacement de plus en plus fréquent du chef de projet métier et le doute de la direction (qui nous redescendait sous forme de pression) nous fit ressentir fortement que nous avions un axe d'amélioration important à mettre en place rapidement.

En discutant avec les collègues de l'unité de BA et ceux de l'unité de développement, nous faisions surgir le besoin de casser nos silos et de devenir une seule et même unité multi-compétente, qui allait s'aligner sur un même objectif à court terme afin de rassurer sur notre capacité à mener à bien ce projet. Nous espérions aussi que cela allait nous permettre d'avoir une vue d'ensemble nous permettant d'être plus fiable dans nos réponses à la question du quand, qui nous était souvent posée?"

La suite au prochain chapitre...

Consultez mes classes certifiantes à mon catalogue sur la stratégie Kanban,  je peux aussi enseigner les classes ASPK et APV du catalogue de ProKanban. Contactez-moi pour arranger une classe privée inter-entreprise, ou si vous voulez suivre une classe publique mais n'avez pas les moyens de vous l'offrir.