Amis Agilistes, il faut que je vous fasse une confidence. Je hais les colonnes dans vos boards ! Chaque fois que vous me montrez fièrement vos tableaux de 4 mètres de large et que vous me voyez dodeliner de la tête, je n’ai qu’une envie, c’est de prendre des ciseaux (ou hache, scie à métaux, brosse, gomme, selon le support utilisé) et d’en enlever les trois quarts.
Voilà pourquoi …
Parmi ces colonnes, certaines matérialisent un travail réalisé par l’équipe, d’autres sont des colonnes d’attente, des queues. Kanban commençant « là où vous êtes », et le board Kanban ayant vocation à visualiser le process (ce qui apporte déjà de nombreux bénéfices en soi), il n’est pas surprenant d’y voir de nombreuses colonnes me direz-vous. Par exemple, si aujourd’hui vos phases de « tests de non-régression » n’ont lieu qu’une fois par semaine, il vous faut bien une colonne « En attente de test » ! Le hic, c’est que trop d’équipes (et d’organisations) s’arrêtent là. Où en tout cas, ne sont pas plus affolées que cela par les multiples files d’attente dans le flux de travail, et ce qu’elles engendrent comme inefficacité.
Dans de nombreuses équipes Scrum, c’est la même chose. On fait s’asseoir tout le monde dans un même bureau, mais on continue de travailler chacun dans son coin et d’être réticent à l’idée d’interrompre son voisin. Etat de fait que l’on se sent obligé de matérialiser par des colonnes « En attente de Code Review » et autres « En attente de Test ».
On passe donc selon moi à côté de l’essentiel : la recherche du « One Piece Continuous Flow ». L’état idéal dans Lean. Dans lequel chaque élément traverse le board sans interruption pour minimiser le Temps de Cycle, minimiser l’inventaire, et accélérer.
Extrait de « The Toyota Way », Jeffrey Liker
Trèves de bavardages, je vous propose donc 4 étapes pour vous aider à réduire le nombre de colonnes dans vos boards, et, lentement mais surement, vous rapprocher du Continuous Flow !
Etape n°1 : Mesurez !
Avant toute chose, mesurez votre Temps de Cycle actuel. Si vous entreprenez de convaincre vos collègues qu’il y a un problème avec votre manière actuelle de travailler, il va vous falloir être percutant et convaincant. Or il y a fort à parier qu’un pitch théorique dans le genre de mon introduction ci-dessus n’interpelle pas grand monde. En revanche essayez de dire à vos collègues « le dernier bug majeur en production, il nous a fallu 11 jours pour le corriger », ou encore « si le Product Owner veut changer une virgule dans l’interface, il doit attendre 6 jours en moyenne ». A mon avis, vous aurez plus de chance.
De plus, ne vous contentez pas de mesurer le Temps de Cycle global. Mesurez le temps passé dans chacune des colonnes. Vous pourrez alors identifier les colonnes les plus problématiques. Vous pourrez aussi calculer le ratio entre le temps passé dans les colonnes « productives » et le temps passé dans les colonnes d’attente. Vous serez alors en mesure de dire : « le dernier bug majeur en production, il nous a fallu 11 jours pour le corriger… et 70% du temps, on ne travaillait même pas dessus ! ». Et ça, c’est percutant.
Ces métriques seront par ailleurs nécessaires pour vérifier que les actions correctives que vous entreprendrez ont réellement l’effet escompté.
Etape n°2 : Enlevez des colonnes et voyez ce qui se passe
Dans certains cas, les colonnes sont là par habitude. Typiquement : la colonne « Code Review » (et son amie « En attente de Code Review »), ou encore les colonnes « Merger » / « A Merger ». Mais leur simple présence dans le board conduit l’équipe à appréhender le travail de manière séquentielle. Elles créent par ailleurs une occasion pour le développeur de changer de sujet : « puisque cette User Story est en attente que quelqu’un se libère pour faire la Code Review (et comme il est mal vu de se tourner les pouces), je vais commencer autre chose ».
Si au contraire vous décidez d’intégrer l’activité de Code Review dans la colonne précédente (typiquement « En cours » ou « Implémentation »), alors vous réduisez ce phénomène. Le développeur ne pourra pas faire avancer « sa » User Story dans le board. Il sera encouragé à trouver rapidement un moyen de faire revoir son code.
Etape n°3 : CO-LLA-BO-REZ
La chose qu’on me répond lorsque je parle de supprimer la colonne Code Review, c’est que cela signifie que l’on va devoir interrompre ses collègues. Et que tout le monde sait bien que les interruptions c’est mal !!!
Oui … mais Non ! Si vous interrompez votre collègue MAINTENANT, afin de vous éviter à vous d’être interrompu PLUS TARD, lorsque vous serez passé à autre chose, pour prendre en compte les remarques qu’il aura faites sur votre code (code qui aura pris un peu de poussière dans votre esprit entre temps), et si cela permet de réduire le Temps de Cycle, alors interrompre votre collègue est la meilleure chose à faire ! Pour cadrer ces interruptions sans perdre grand chose en terme de réactivité, vous pouvez également essayer la technique Pomodoro.
Plus généralement, chaque membre de l’équipe doit arrêter de chercher à optimiser l’allocation de son temps à lui. Etre Lean, c’est optimiser le Temps de Cycle global !
Vous pourriez même vouloir essayer des pratiques plus radicales, comme le Pair Programming en remplacement (total ou partiel) de la Code Review. Et si vous avez peur que cela impacte négativement votre Vélocité, pourquoi ne pas essayer pendant quelques temps et voir ce que ça donne ? Vous pourriez bien être surpris.
Même chose concernant le test. Trop d’équipes Agile continuent de considérer le test comme une étape; une étape arrivant nécessairement après l’implémentation du code, et devant nécessairement être réalisée par un « testeur » (cf. 2 dans le graphe ci-dessous). A l’aide de pratiques telles que l’Acceptance Test-Driven Development (ATDD), l’équipe est amenée à collaborer et à reconsidérer l’ordre dans lequel elle écrit le code et le teste, avec un impact important sur le Temps de Cycle et l’efficacité (cf. 3 dans le graphe ci-dessous).
Etape n°4 : Développez progressivement une équipe de “T-shaped specialists”
Les équipes les plus performantes avec lesquelles j’ai travaillé étaient composées de gens à la fois très bons dans leurs spécialités respectives, mais relativement compétents aussi dans les spécialités de leurs collègues. Un « Développeur back-end » avec des connaissances en « front-end », une sensibilité pour l’UX, et une appétence pour le test par exemple. Ou encore un « Ingénieur Qualité » capable de participer à des revues de code ou de faire une première analyse des anomalies en lisant des logs.
On parle de « T-shaped specialists ».
Mais pourquoi a-t-on besoin de « T-shaped specialists » ?
D’abord, car les colonnes matérialisent bien souvent des passages de mains. D’un corps de métier à un autre, d’une expertise à une autre. Or pour qu’une équipe collabore et commence à envisager sereinement de supprimer ces passages de mains, il est nécessaire que chacun comprenne un minimum les problématiques de l’autre.
Par ailleurs dans une équipe mélangeant plusieurs spécialités, à chaque instant, l’une des spécialités est forcément sur le chemin critique de l’équipe. Impactant de fait le Temps de Cycle. Avec des « T-shaped specialists », l’équipe gagne donc en souplesse, et s’ouvre des portes en matière de répartition du travail au quotidien.
Pour développer une équipe de « T-shaped specialists », la première chose que je recommanderai – la solution de facilité en quelque sorte – c’est de chercher les « T-shaped specialists » dès l’embauche. Le candidat a-t-il l’habitude de travailler en équipe ? De sortir de sa zone de confort ? Y voit-il un intérêt pour l’équipe ? Y consent-il par nécessité ou en tire-t-il de la satisfaction ?
Avec une équipe existante, commencez par mettre en évidence le manque éventuel de redondances, à travers par exemple une matrice des compétences [1] nécessaires à la réalisation du travail de l’équipe. Puis, demandez à chaque membre de l’équipe quelles compétences il possède, et celles qu’il souhaite acquérir. Vous aurez souvent de bonnes surprises. Beaucoup de gens se déclarent intéressés par le travail des autres, mais regrettent simplement d’être pris par le quotidien et de manquer de temps pour monter en compétences. Vous identifierez aussi certainement des activités ou compétences sur lesquelles personne ne souhaitera s’investir d’avantage. Vous aurez au moins rendu le problème visible. Le premier pas ! L’équipe pourra alors réagir de différentes manières :
- Chacun consentira peut-être à « prendre sur lui », en mettant la main à la patte, à tour de rôle par exemple, sur ces activités qui ne l’intéressent pas, pour le bien du groupe.
- L’équipe trouvera peut-être un moyen de, tout simplement, ne plus avoir à faire ces activités. S’il s’agit de l’exécution d’une tâche manuelle, l’équipe décidera peut-être de l’automatiser. Si c’est lié à une technologie obsolète, l’équipe décidera peut-être de refaire la chose dans une autre technologie. Etc.
Au quotidien, vous pouvez aussi faire remarquer à l’équipe chaque fois qu’une compétence se retrouve sur le chemin critique, et encourager à débloquer la situation. Petit à petit, par la force des choses, chacun progressera de fait dans des domaines autres que son domaine de prédilection.
Voilà, j’espère vous avoir donné quelques pistes pour réduire le nombre de colonnes dans vos boards et par la même devenir plus « Lean ». Alors tous à vos ciseaux (ou haches, scies à métaux, brosses, gommes, selon le support utilisé).
[1] Pour aller plus loin, je vous recommande vivement la lecture de cet article d’Anders Laestadius : Market of skills and competence matrix