Publié par
Il y a 1 année · 9 minutes · Agile

Scrum ou Kanban : Je hais les colonnes

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.

Continuum-of-flow.png

 

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).

 

sprint

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 » ?

 

t-shaped.JPG

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

Grégory FONTAINE
Grégory a 10 ans d'expérience au cours desquels il a été Chef de Projet puis Responsable Qualité avant de se trouver une passion pour l'agilité et de devenir Scrum Master et Coach. Développeur sur son temps libre, Grégory aime aussi bien accompagner des équipes de développement dans l'implémentation de pratiques d'ingénierie que travailler sur des transformations organisationnelles à grande échelle.

3 réflexions au sujet de « Scrum ou Kanban : Je hais les colonnes »

  1. Publié par Castier, Il y a 1 année

    Mmm tu peux fixer un nombre de limites de ticket sur la colonne pour eviter ce problème : (seulement 3 tickets en cours seulement 2 en revue. ça permet de favoriser le pair programming aussi. ) et de voir directement s’il y a un blocage. Il y a aussi la revue qui permet de prendre des actions sur les problèmes du sprint sans pour autant attendre 107 ans. Je suis en SCRUM et on peut faire du TDD donc je vois pas le rapport non plus avec les colonnes.. ^^. Nous c’est l’inverse on avait pas de colonne « revue » et on en a créé une, mais le fait qu’elle existe, ne nous empeche pas de nous parler et de prendre la PR dans les 10 minutes qu’elle soit crée. C’est pour marquer l’obligation, ça nous évite de créer la tache « revue » à chaque fois. Bref … Chacun a son interpretation de la méthode Scrum…

  2. Publié par Nicolas Friot, Il y a 1 année

    Tous les reco sur la collaboration en dehors du board, les échanges verbaux et informels, le LEAN, etc. sont pertinentes, la compétence en T aussi, très intéressante.
    Mais franchement je ne vois pas le rapport avec le nombre de colonnes dans un board. Il semble partir du principe que les membres de l’équipe ne comuniquent que lors des mêlées. Soit il a eu une mauvaise expérience, soit il n’est pas full scrum.

  3. Publié par Grégory FONTAINE, Il y a 1 année

    Bonjour,

    l’un comme l’autre, ce que vous dites si je vous lis bien, c’est que vos colonnes ne posent aucun problème. Qu’elles ne font de mal à personne.
    C’est possible …

    Mais je préfère poser une autre question: Qu’est ce que ces colonnes vous apportent ? Quels avantages avez-vous à les conserver dans vos tableaux ?
    Se poser la question en ces termes permet d’atténuer le biais de status quo dont nous sommes tous victimes.

    En l’occurrence, si c’est pour marquer l’obligation (de la code review par exemple), alors je suppose que c’est temporaire. Auquel cas, pourquoi pas en effet … n’oubliez juste pas de la supprimer à un moment :) Le découpage du flux de travail n’ayant pas vocation à palier à un simple déficit de connaissance (ou de respect) de la Definition of Done.

    Si c’est pour « éviter de créer la tâche revue », ça me parait assez superficiel. Et puis on peut s’interroger sur l’intérêt de « créer la tâche revue » dans l’absolu. Peut-être est-ce encore une habitude d’utilisation de l’outil qui n’apporte pas grand chose elle aussi ?

    Si vous ne trouvez pas de bonnes raisons de garder une colonne, alors je vous invite à essayer l’étape 2 ! Sinon, je suis curieux de savoir lesquelles et d’en discuter.

    Grégory

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *