Coach Agile : Stop Starting, Start finishing !

Coach Agile, Scrum Master, connaissez-vous le livre “Stop Starting, Start Finishing” ? Non ?
Vous découvrirez au travers de cet article le principe de vie proposé par Arne Roock.

Avant toute choses, n’hésitez pas à aller vous procurer le livre en suivant le lien ci-dessous :

Achetez le ici

Il ne vous reste maintenant plus qu’à découvrir la vie de Justin. Justin est un chef de projet qui a sauvé un projet tout entier en faisant des choses très simples… voyons ensemble ce qui s’est passé :

La découverte du problème

Justin travaille comme manager de projet. Il y a un an, il était en charge d’un très gros projet de logiciel. Son équipe était complètement débordée avec plusieurs problèmes :

• La planification n’était plus suivie
• Le projet était en danger car l’équipe était de plus en plus en retard sur les délais clients

Justin a essayé de pousser ses équipes en leur mettant la pression, en leur demandant de faire des heures supplémentaires, il leur a même offert des bonus pour qu’ils travaillent avec encore plus d’efficacité. Ces tentatives n’ont eu que peu d’effets positifs !

L’idée

Un jour, alors qu’il était en train d’imprimer un énième plan d’action, il observa l’imprimante et eu une idée : l’imprimante imprimait les feuilles une par une et chargeait les nouvelles feuilles vierges au fur et à mesure des besoins d’impression. Il voyait un beau processus, linéaire et fluide : les nouvelles feuilles étaient introduites d’un côté et les feuilles imprimées sortaient de l’autre. Il se dit « cela ressemble bien à un flux ». Bien sûr il aurait aimé que cette imprimante aille plus vite, mais il était certain qu’elle avait une capacité limite d’impression et qu’il serait complètement inutile, voire dangereux, d’essayer d’accélérer sa cadence en mettant plus de feuilles à l’entrée. Cela aurait même probablement pour conséquence de diminuer la qualité des impressions et finirait par provoquer un bourrage papier.

Capacité limite

Cela ne viendrait à l’idée de personne de provoquer un tel bourrage papier. Mais c’était exactement ce qu’il était en train de faire avec son équipe : chaque jour, il donnait de nouvelles tâches à ses collaborateurs alors que ceux-ci n’avaient pas terminé les tâches de la veille. Ses collaborateurs se mettaient alors à aller plus vite et finissaient par faire des erreurs.
Il fit ce premier constat que les êtres humains ont une limite de capacité, toute comme les imprimantes !
On peut dire que tout travail, qu’il soit intellectuel ou matériel, peut être vu comme un système avec une capacité limite de production. Pousser ce système à faire plus que cette capacité l’amène à un moment ou à un autre à diminuer en efficacité et en qualité.
Justin se dit qu’il devait trouver un moyen d’identifier la capacité limite de son système et s’assurer qu’il ne la dépasserait pas.

Management Visuel

Mais comment peut-on identifier la capacité limite d’un travail intellectuel ? En industrie, si vous demandez au système plus qu’il ne peut faire, il y aura des piles d’attente, cela est facile à observer. Mais pour ce qui est du travail intellectuel, on parle le plus souvent de choses abstraites. La plupart du temps, il est impossible de voir le travail réalisé et donc de détecter une surcharge. La première chose à faire pour Justin était de trouver un moyen pour représenter le travail fait par ses collaborateurs sous une forme visuelle. Il savait comment faire cela car il avait déjà vu cela dans d’autres équipes de travail.
Il acheta un grand tableau blanc et l’afficha dans la pièce où travaillaient ses collaborateurs. Il fit des colonnes pour décrire les différentes étapes d’avancement de ses projets : à faire, élaboration, étude, analyse, travail en cours, expérimentation, validation, terminé.
Il demanda ensuite à tous ses collaborateurs d’écrire sur des post-it toutes les tâches sur lesquelles ils travaillaient. Ils placèrent toutes les tâches pas encore commencées dans la colonne « à faire » et ainsi de suite jusqu’à la colonne terminé.
Il se passa alors quelque chose d’incroyable : tous se rendirent compte du nombre de tâche en cours de progression qui débordaient du tableau. Le tableau était complètement saturé. La bonne nouvelle était que maintenant au moins, ils avaient une vue réaliste de l’état d’avancement de leurs projets sur le tableau Kanban. Cela était d’ailleurs bien plus explicite que la liste de choses à faire qu’ils avaient chacun séparément ou encore les diagrammes de GANTT qui ressemblaient à des vœux pieux.

Limites du travail en cours

Justin posa alors à son équipe la question suivante : « Combien de tâches en cours pouvez-vous traiter en même temps ? ». Certains dirent 3, d’autres 2 ou encore 5. Ces nombres furent écrits en hauts des colonnes correspondant aux étapes des projets. Ils définirent alors une règle très simple : « à aucun moment, on ne peut accepter plus de tickets dans une colonne que le nombre indiqué en haut de la colonne ». En respectant cela, ils limitèrent ce qu’ils définirent comme leur « travail en cours ».
Ils se mirent d’accord sur un nombre limité de tâches qu’ils pouvaient accepter pour l’équipe entière. Cela représentait désormais leur capacité maximale de travail. Mais comme les chiffres avaient été donnés de manière empirique, ils décidèrent de s’autoriser à les modifier si cela était nécessaire.

Réduire les encours

Un nouveau problème apparu : ils constatèrent qu’ils avaient bien plus de tâches en cours qu’ils n’avaient autorisé dans les colonnes. Ils avaient le choix entre deux approches : l’approche dure aurait mené à réaffecter tous les tickets dans la colonne amont « à faire ». Ils choisirent une solution plus douce mais qui semblait plus appropriée : ils gardèrent tous les tickets en cours sachant qu’ils étaient effectivement en surcharge. Et cela les amenèrent à fixer une nouvelle règle : « Nous ne prenons pas de nouvelle tâche tant que nous ne sommes pas en dessous de la limite de charge ».
Cette règle fut écrite juste à côté du tableau Kanban.

Arrétez de commencer

Le fait d’afficher cette règle eut un impact très fort sur l’équipe : chacun se concentra sur son travail afin de terminer ses encours et personne n’entreprit de nouvelle tâche comme cela arrivait souvent auparavant. Toute l’équipe coordonna son travail. Ils se réunissaient tous les matins devant le Kanban en « stand-up meeting » en balayant les tickets en cours de gauche à droite et en posant la question suivante : « que peut-on faire pour finir cette tâche ? ».
Justin découvrit un slogan sur internet qu’il s’empressa d’écrire sur le mur au-dessus du Kanban. Ce slogan était le suivant : « STOP starting, START finishing ».

Une chose à la fois

Progressivement le tableau Kanban se vida et l’équipe se sentit de mieux en mieux. Après quelques jours, ils finirent par avoir terminé suffisamment de tâches pour respecter toutes les limites affichées. Il était clair que tout le monde se sentait désormais de mieux en mieux. Le travail sortait bien plus rapidement maintenant que le nombre de tâches par personne avait était réduit. Justin attribua cela au fait que chaque collaborateur avait nettement réduit ses encours. Il y avait moins de zapping d’une tâche à une autre et par conséquent moins de fatigue mentale.

La loi de Little

La loi de Little est un principe fondamental de gestion des flux utilisée dans le Lean Kaizen et le Kanban. Cette loi établit le rapport entre le flux d’entrée, le temps de production et le nombre de tâches en cours :
T = F x Tp ou Tp = T / F

T : nombre de tâches en cours (ou d’articles en cours de production sur une chaîne de production)
F : Flux d’entrée ou de nouvelles demandes.
Tp : Temps de production ou temps nécessaire pour réaliser complètement une tâche.
On peut aussi prendre les moyennes : m(T) = m(F) x m(Tp) ou m(Tp) = m(T) / m(F)
Ainsi si l’on veut réduire le temps de production, donc le temps nécessaire pour traiter une tâche, on peut soit augmenter la cadence (Justin a expérimenté cette solution en poussant, en faisant faire des heures supplémentaires et constata les faibles bénéfices) soit réduire le nombre de tâches en cours. Réduire le nombre de tâches fut en effet assez simple à mettre en œuvre et eut un fort impact.
En plus de cela, Justin observa une nette amélioration de la qualité (moins d’erreurs) due notamment au fait que les retours d’expérience étaient plus rapides et qu’il y avait moins de multitâches.
Justin avait lu à ce sujet dans le livre « Brain rules » de John Medina que lorsqu’un collaborateur augmentait le nombre de tâches en cours, non seulement il passait 50% de temps en plus par tâche mais en plus faisait 50% d’erreurs en plus !

Tirer le système

Le troisième grand avantage d’avoir établi des limites aux nombres de tâches en cours était que les membres de son équipe étaient beaucoup moins débordés qu’auparavant et qu’ils prenaient bien plus de plaisir à faire leur travail. Maintenant, il y avait une limite explicite au travail qu’ils devaient accomplir et personne n’était autorisé à donner plus de travail que la limite autorisée.
Justin dû faire des efforts de lâcher-prise car désormais il devait rester en retrait et avoir confiance dans le fait que ses collaborateurs faisait de leur mieux. Au bout d’un certain temps, il n’eut aucun doute : ils prenaient un nouveau travail à faire dès qu’ils étaient libérés d’une tâche en cours et toute l’équipe n’avait jamais travaillé aussi bien !

La prédictibilité

Un peu plus tard, Justin découvrit un autre avantage : la prédictibilité. Grâce à cette vision du travail en cours, la quantité de travail restait plus ou moins stable au fil des semaines. Il était maintenant beaucoup plus facile de prévoir quand une tâche serait terminée, ce qu’il l’aida grandement à établir des accords de niveau de service avec ses clients. Et il était également beaucoup moins stressé sur par planning même s’il savait bien que l’on ne peut jamais tout prévoir à 100%.

Le feedback

Justin observa également un autre grand avantage pour son équipe. Et cet avantage devient de plus en plus important. Avec des temps de production raccourcis, l’équipe recevait très rapidement le retour de ses clients sur les produits qu’ils leur fournissaient. A présent, ils savaient très rapidement s’ils avaient fait du bon boulot, s’ils avaient bien répondu aux attentes de leurs clients, ou s’ils s’étaient trompés. En un mot, ils apprenaient de plus en plus vite et de plus en plus souvent ; cela leur permettait également d’améliorer régulièrement leurs compétences professionnelles.

Le temps libre

Un jour, il se passa quelque chose qui inquiéta Justin : bien sûr tout se passait bien mais ses collaborateurs commencèrent à moins travailler dans la journée. Justin se demanda ce qui avait bien pu se passer. Il ne pouvait pas augmenter les tâches à causes des limites affichées. Il était pourtant convaincu qu’un bon manager devait maintenir une charge de travail suffisante pour ses collaborateurs.
Il réfléchit au problème et examina la situation : le temps de production avait été réduit, le travail sortait plus rapidement qu’auparavant. Alors pourquoi s’inquiéter ?! En fait il était presque heureux que ses collaborateurs aient un peu de temps libre, le travail n’avait jamais été aussi bon et ses collaborateurs n’étaient plus surchargés. Il se dit finalement que la situation est bien meilleure maintenant. Et c’était encore meilleur que cela : ses collaborateurs profitaient de leur temps libre pour aider leurs collègues s’ils le pouvaient, pour se documenter, développer leurs compétences et améliorer l’organisation de l’équipe. Il comprit alors ce que voulait dire David Anderson quand il disait « le temps libre est une arme fatale ».

Les anciens

Tout se passait très bien mais au bout d’un certain temps Justin constata que tous les membres de l’équipe n’avaient pas évolué à la même vitesse. Certains n’avaient pas vraiment réduit leur charge de travail. Ces collaborateurs travaillaient depuis très longtemps dans la société, ils connaissaient l’ensemble du système par cœur et ils étaient très souvent sollicités pour des questions techniques, des dépannages etc. Justin réunit toute l’équipe pour en parler et tous les collaborateurs décidèrent qu’il fallait fixer des limites individuelles pour ces deux personnes. En ajoutant des avatars aux tâches sur lesquelles les deux collaborateurs travaillaient, ils limitèrent leur charge de travail. Désormais, personne ne pouvait solliciter ces collègues s’ils étaient déjà en saturation de travail. Ils ajoutèrent un point d’exclamation rouge sur toutes les tâches sur lesquelles ils travaillaient. La grande quantité de point d’exclamation leur montra à quel point leurs deux collègues étaient largement en surcharge. Ils déclarèrent : « notre organisation a la rougeole ! ». Ils instituèrent une nouvelle règle pour remédier au problème : « Les anciens ne devaient plus travailler seul sur une tâche. Ils devaient travailler en binôme avec un jeune collègue jusqu’à ce que toute son expertise soit transférée ». Justin n’avaient jamais vu autant de collaboration et de partage de compétences entre les collaborateurs, et il en était ravi.

Approfondissements

Plus Justin étudiait les limites de travail en cours, et plus il apprenait. Par exemple, un collègue lui parla de la méthode SCRUM et comment ils planifiaient leur travail en courtes itérations. Pendant le planning, ils planifiaient combien de tâches ils pensaient pouvoir faire dans la période de sprint. Et personne n’était autorisé ensuite à ajouter des tâches pendant le sprint. Justin réalisa que c’était une autre forme de mesure de la limite de travail. Le fait de ne pas pouvoir ajouter de travail pendant le sprint était un mécanisme de protection pour éviter de surcharger les équipes. Justin se dit qu’il était « possible d’allier ce concept d’itérations programmées avec les autres outils de mesure du temps de travail ».

Trop de Projet

L’équipe continuait à s’améliorer et tous les collaborateurs commençaient à entrer dans une véritable culture Kaizen : l’amélioration en continue. Et Justin voulait aller encore un peu plus loin… Il trouvait que son équipe travaillait sur trop de projets en même temps, ce qui tendait à remettre ses collaborateurs dans la même situation qu’avant, mais à un niveau plus haut. Il imagina un portfolio de ses projets en cours dans lequel il représenterait les projets dans un Kanban similaire mais dans lequel cette fois-ci, chaque carte représenterait un projet.

Portfolio Kanban

Bien sûr, le porfolio kanban se présente différemment du kanban projet. Les colonnes ne sont pas les mêmes, elles furent appelées : vision, formulation des objectifs, développement, lancement. Chaque département avait une couleur différente de cartes et personne ne pouvait voir d’un seul coup d’œil combien de temps était alloué à tel ou tel projet. Justin se dit qu’il faudrait également mettre des limites sur les colonnes. Mais les autres managers n’en avaient pas envie. Justin dû réfléchir à un autre mode de suivi. Les managers se retrouvaient chaque semaine autour de leur portfolio kanban et à chaque fois que quelqu’un voulait lancer un nouveau projet, Justin posait la question : « avons-nous la capacité de prendre ce projet maintenant ? » et si la réponse était non : « Lequel des projets déjà en cours devons-nous stopper pour commencer le nouveau ? »
Ces questions amenèrent des discussions intéressantes et instructives. Justin observa que la collaboration s’améliorer nettement entre les managers et qu’ils prenaient de meilleures décisions. Ils venaient juste d’implémenter une limitation du travail en cours basée sur la discussion.

En conclusion

Pourquoi faut-il limiter le travail en cours ?

• Pour réduire le temps de production, ou temps passé sur un projet.
• Eviter le zapping de tâches.
• Améliorer la qualité.
• Prévenir les surcharges de travail.
• Améliorer la prédictibilité.
• Avoir des retours d’expérience plus rapidement et apprendre.
• Créer du temps libre pour monter en compétences.

Comment pouvons-nous réduire le travail en cours ?

• Limiter le système tout entier.
• Mettre des limites dans les colonnes du kanban.
• Etablir des limites personnelles.
• Travailler en mode SCRUM avec des itérations et de sprints.
• Discuter.