Votre Scrum souffre-t-il de faible productivite ? Votre probleme pourrait etre le WIP
Il a ete prouve que plus une personne ou une equipe a de travail en cours, plus il faut de temps pour terminer les taches. D’une part, si nous effectuons plusieurs taches en meme temps et que nous les livrons au meme moment, le delai de livraison sera la somme du temps necessaire pour realiser les deux taches. Cependant, si nous travaillons sur les taches de maniere sequentielle, la premiere tache sera livree plus tot, et le delai de livraison moyen sera egalement plus court.
De plus, le multitache peut entrainer des inefficacites qui ne se produisent pas lorsqu’on travaille sur une seule tache. L’une de ces inefficacites se produit lorsque nous effectuons des changements de contexte entre les taches : il a ete demontre que notre cerveau a besoin de temps pour s’adapter au contexte de la nouvelle tache, et ce temps n’est pas productif, il est inefficace. Il arrive que nous soyons bloques sur une tache et decidions de passer a une autre tache, pour ne pas perdre le flux et voir si nous obtenons l’illumination qui nous debloque. Cela peut etre une bonne approche dans certains cas, mais il est important d’etre conscient que nous aurons desormais deux contextes a garder en tete.
Lorsqu’on travaille en equipe, ce probleme persiste et peut meme etre exacerbe. Par exemple, si nous travaillons sur deux taches dans deux branches differentes et que l’equipe apporte des modifications au code, nous aurons deux branches a mettre a jour. Si, en plus, notre code est compile, nous devrons peut-etre recompiler chaque fois que nous changeons de branche, ajoutant du temps improductif. Si nous calculons ce temps et le multiplions par le nombre de developpeurs dans notre equipe, le temps perdu par mois peut facilement atteindre l’ordre de jours de travail.
En Scrum, par exemple, le travail en cours (ou WIP) est limite en fixant le perimetre du Sprint et en le protegeant des injections. Si le Sprint dure deux semaines, nous savons que pendant ces deux semaines, si tout se passe bien, il n’y aura pas de nouveau travail injecte. Le probleme est que deux semaines de travail, c’est deja trop si nous ne gerons pas bien le WIP. Scrum ne prescrit pas de pratiques pour limiter le WIP au sein d’un Sprint, rien n’empeche un developpeur de travailler sur plusieurs taches en parallele. De plus, sur le tableau du backlog de Sprint, il n’est pas si evident de voir combien de travail en cours il y a a un moment donne. C’est pourquoi depuis un certain temps, des outils comme Jira ou Clickup ont inclus des visualisations de tableau kanban pour les Sprints Scrum. L’utilisation de ces tableaux est fortement recommandee car ils donnent une bonne visibilite du WIP et des goulots d’etranglement qui apparaissent au sein du Sprint, en temps reel, sans avoir a attendre la fin.
Mais les tableaux kanban ne sont pas le seul mecanisme disponible pour ameliorer le flux de travail au sein d’un Sprint. L’ideal est d’incorporer l’ensemble de la methodologie Kanban qui, a travers la visualisation du flux de travail et la limitation du WIP, rend l’equipe consciente et lui permet de s’approprier la chaine de production. Cela permet a l’equipe de travailler a debloquer rapidement les goulots d’etranglement des qu’ils se produisent, et d’avoir un tres bon ressenti de la facon dont le flux de travail fonctionne, afin qu’il puisse etre continuellement revu et ameliore.
Lorsque Kanban est combine avec Scrum, nous obtenons ce qu’on appelle Scrumban, qui maintient les ceremonies et le travail en Sprint de Scrum avec l’observabilite et l’amelioration du flux de travail de Kanban. Si vous constatez que le Scrum de votre equipe donne des performances decroissantes et mediocres, envisager Scrumban pourrait etre une bonne alternative pour changer la tendance.