Je vous ai déjà parlé du livre Rupture Douce, que j’ai eu le plaisir de co-écrire avec d’autres coachs Agiles. La saison 2 du livre étant maintenant en préparation  (lire le teaser de la prochaine saison), je vous livre maintenant mon histoire « L’agilité, même pas mal ! » sans illustration mais avec une version podcast audio (à la fin du post).

Rupture douce : L’agilité, même pas mal
  • Twitter
  • LinkedIn
  • Google+
  • Facebook

Rupture douce : L’agilité, même pas mal

Dans ce livre, je vous propose de découvrir le récit d’une transition silencieuse d’une équipe vers l’agilité. Et de découvrir comment l’approche Kanban a permis ce changement en douceur.

Episode #1 : Lancement du prototype opérationnel


L’agilité, même pas mal ~ épisode #2

 

Seconde phase: Le pilote opérationnel

Ce prototype a été suivi d’un pilote opérationnel de quelques mois ayant pour objectif de préparer la phase industrielle. Le pilote non plus n’est pas jetable. Son code doit être pérenne et construit sur la base du prototype.

L’approche pour ce pilote est itérative et incrémentale avec des cycles de trois semaines, de manière à stabiliser le processus de réalisation, sur le principe Scrum. Sur le principe seulement : en migrant des écrans, on tire une grappe de code legacy à migrer, la grappe peut être bien plus importante que prévue. Difficile de s’engager ou de figer le périmètre fonctionnel d’un incrément.

Des rétrospectives, découplées des livraisons, jalonnent cette phase. L’équipe est de vingt deux personnes réparties en trois couloirs fonctionnels (intégrant trois profils : analystes concepteurs, développeurs, homologation et un chef d’équipe).

Le moral remonte et la direction commence à y croire. Si le client voit l’avancement, il voit également le code produit que les consultants externes auditent. Le résultat est mitigé, car il n’est pas encore à la cible technique contractuelle. Normal, c’est un pilote dans une approche itérative !

A nouveau, mais pour d’autres raisons, il faut expliquer la démarche pour rassurer. Rappeler que nous allons revenir sur le code, le remanier, lui faire passer les seuils qualimétriques, appliquer les préconisations des consultants…

La transparence est difficile dans ce contexte à ce stade du projet. La tentation est grande de ne pas tout dire, ni tout montrer. « La transparence d’accord mais jusqu’à un certain point…attention au retour de bâton » me prévient la direction de projet.

Car le client, lui, est plus habitué à ce qu’on lui cache les mauvaises nouvelles. Alors, il imagine facilement la partie cachée de l’iceberg. Or ce que nous lui montrons, c’est l’iceberg tout entier. Rien à voir avec le Titanic, notre projet c’est bien l’Everest. Tout est là, bien visible.

Alors il faut tenir bon car cette transparence, c’est la fondation pour construire la confiance dont nous aurons besoin pour les moments plus difficiles du projet. Et il y en aura, bien sûr. Alors on communique, on explique, on fait évoluer les points de vue. Cela prend du temps, car ils sont bien ancrés.

 

Troisième phase : la phase industrielle

A la suite de ce pilote, notre camp de base, une phase industrielle de plusieurs mois débute. L’équipe est acclimatée à l’altitude. Commence la vraie ascension et le temps de l’effort continu.

Elle est l’occasion pour moi d’enclencher réellement la démarche Kanban afin d’améliorer le processus mis en place et stabilisé.

L’amélioration continue, cela va de pair avec l’approche itérative. S’il n’y a pas de statut quo sur la cible et la qualité de la production, il ne doit pas y en avoir non plus sur la manière de produire. J’ai toujours en tête, pour cette migration, la cible d’une approche en flux tiré, dont la portée serait limitée à la recette métier.

La cadence de livraison est mensuelle. La définition de « finie » se rapproche de plus en plus de celle attendue pour la mise en production.

Au plus fort, trente huit personnes sont sur le projet, réparties en quatre couloirs fonctionnels. Un premier comportement émerge de l’équipe : quelques jours avant chaque livraison, ceux qui ont fini leur travail vont aider les autres couloirs. Cela se décide ensemble lors de la réunion quotidienne. Pendant la phase de stabilisation de la livraison, la notion de couloir est presque oubliée et toute l’équipe travaille ensemble. Au sprint suivant, tout le monde retrouve son couloir. Le couloir est un attracteur, non une barrière. Nous travaillons ensemble pour la réussite du projet.

 

Le point d’inflexion avec le challenge Kanban

Longtemps, le management s’est posé des questions. Mais ma vision est forte et ne change pas. Je sais où je veux emmener l’équipe et je sais qu’elle a les moyens d’y arriver. L’implémentation de cette vision, elle, a évolué. Mon levier d’ajustement est le rythme du changement que l’équipe peut accepter.

Mon accompagnement s’est d’abord focalisé sur l’équipe de développement. Car c’est la contrainte du système dans une migration en phase industrielle, lorsque l’outillage commence à être stable. Cela porte ses fruits en quelques semaines. Le travail en cours diminue. Les dysfonctionnements deviennent visibles aux interfaces avec l’équipe de conception et d’homologation.

Malgré des rétrospectives, des équipes fonctionnelles, des réunions quotidiennes communes, nous n’arrivons pas à franchir le cap d’une amélioration plus globale intégrant tous les acteurs.

Et puis, cette finalité n’est pas complètement partagée par chaque chef d’équipe. Le paradigme d’optimiser le travail des individus ou des groupes de profils plutôt que le flux de projet est toujours bien présent. Et puis ce sont des experts dans leur domaine, réellement. L’alignement marche dans les deux sens, la compréhension profonde de leur métier vaut pour moi également. Cela dure quelques mois. Patience. Arriver à ce camp de base avancé est difficile.

Pour s’aligner, je décide d’animer un atelier « Challenge Kanban » avec tout le management. Il est suivi d’un atelier de réflexions.

Trouver le bon élément de travail a été long. Les analystes travaillaient sur des règles de gestion à rétro documenter, les développeurs sur du code migré à remanier, les testeurs sur des plans de tests à passer.

Le bon vecteur de communication fut l’écran à migrer. L’acceptation par les différentes parties prenantes de cet élément a pris plusieurs mois. Près de mille écrans ont été migrés soit un peu plus de cinq écrans par équipe et par semaine.

L’adoption de cet élément a réellement permis de passer en flux de travail avec les trois profils de collaborateurs (analyste, développeur et testeur).

Et l’essai se transforme finalement en un troisième remaniement du système Kanban. Plus profond et porté cette fois par tous les chefs d’équipe, il se traduit par une simplification du tableau Kanban.

Les bénéfices sont significatifs en termes de performance globale, délai, stock, …bien qu’il nous faille attendre quelques semaines avant de pouvoir le vérifier.

Au-delà des efforts continus, ce troisième remaniement a été une percée dans l’amélioration des processus. Son déclencheur, un serious game : le challenge Kanban. Il a permis en quelques heures de faire passer des messages qui touchent une motivation plus profonde que tous les discours que j’avais pu avoir auparavant. Ce serious game a levé des freins de part et d’autres. Le camp de base avancé est enfin établi.


à suivre…

Vous pouvez également écouter la version audio de ce podcast L’agilité, même pas mal ci dessous ou sur iTunes 

Restez informé

Restez informé

Actualité Agile - Kanban - Lean startup à ne pas rater, chaque semaine

Merci pour votre inscription.

e914b0951af59a4ae275d21b0c5998ac||||||||||||||||||||||||||||