Et si vous contrôliez votre WIP (Work In Progress) ?
Depuis quelques semaines, vous avez constaté un goulot d’étranglement dans votre Kanban et vous souhaitez l’éviter ou l’éradiquer ? Vous ne savez pas combien de Userstories doivent être préparées pour bien alimenter votre équipe de Réalisation ?
L’indicateur sur la limite minimale et maximale de votre travail est fait pour vous !
Limiter votre travail en cours, qu’est-ce que cela veut dire ?
Il s’agit de mettre en place un indicateur sur la limite minimale et maximale du travail en cours de l’équipe.
Pour quelles raisons ?
- Pour maitriser la fluidité du débit de votre kanban. Quand il y a fluidité, l’écart type se réduit et l’on devient beaucoup plus prédictible,
- Pour informer d’une sous-charge ou une surcharge de travail de l’équipe,
- Pour prévenir des goulots d’étranglement et remonter des risques,,
- Pour éviter de lancer des sujets qui ne seront pas terminés, faute de disponibilité de l’équipe (lire l’article Stop starting, Start finishing),
- Pour obliger l’équipe à se concentrer sur un nombre de stories restreint afin de ne pas s’éparpiller.
Mais, comme tout indicateur, il nécessite une discussion et une interprétation par l’équipe. L’intérêt est de comprendre à quel moment et pourquoi l’équipe a atteint ses limites WIP.
Comment ajouter ces limites sur les colonnes de votre Kanban ?
Si nous prenons l’exemple de l’outil Jira, vous avez la possibilité d’ajouter ces limites par colonne.
Les limites, en quelques exemples
Prenons l’exemple d’une équipe qui a décidé de mettre sur la colonne “Développer — En cours” pour fluidifier son travail en cours :
- Une limite basse à 2 stories,
- Une limite haute à 5 stories.
L’équipe est constituée de 5 développeurs, c’est pour cette raison qu’ils ont considéré ce chiffre comme la limite haute. Pour la limite basse, ils ont considéré qu’il faudrait régulièrement alimenter au minimum de 2 stories les 2 testeurs.
Lors de son daily, l’équipe analyse son kanban et elle constate que :
Le nombre de stories est inférieur à 2
Attention, il y a un risque d’une sous-activité de l’équipe de développement, mais aussi par la suite de l’équipe de test.
Quelques raisons possibles
Un soucis dans l’écriture des stories. Le besoin fonctionnel n’est finalement plus si clair,
L’absence du Product Owner ou du Business Analyst,
La majorité de l’équipe est en congés. C’était prévu, donc pas d’inquiétude,
L’équipe a décidé de consacrer du temps pour son amélioration continue, ou pour de la veille en participant aux CoP,
L’équipe a décidé de consacrer du temps pour des analyses de futurs sujets,
L’arrivée de nouveaux membres dans l’équipe : du temps de formation, de montée en compétence.
…
Le nombre de stories est compris entre 2 et 5
Tout va bien, il n’y pas de goulot d’étranglement. La gestion des stories est fluide. Il n’y a pas d’impact sur l’équipe.
Le nombre de stories est supérieur 5
Attention au goulot d’étranglement. Le débit va perdre en fluidité puisque des stories vont stagner dans cette colonne pendant un certain temps car :
- L’équipe de développement va se disperser puisqu’elle devra gérer plusieurs sujets à la fois,
- L’équipe de test ne pourra pas gérer plus de 5 stories à la fois,
- Le contenu de la carte stockée trop longtemps peut perdre du sens et être finalement dépriorisée.
Quelques raisons possibles
Un soucis dans l’écriture des stories (elles sont peut-être bloquées car en attente de précisions ou ont été redécoupées …),
Se poser la question d’une activité mal découpée,
L’équipe a gardé la même limite alors qu’elle a embarqué de nouveaux arrivants (temps de formation, montée en compétence …)
On attend le développement d’un contributeur,
Des stories ont peut-être été poussées à tort vers le développement,
…
Comment définir ces limites ?
Il n’existe pas de calcul automatique pour définir cet indicateur et vos limites. Ces indicateurs étant propres à votre équipe, tout va dépendre d’elle et de son expérience. Aussi, prenez le temps de discuter ensemble.
L’idée est de trouver le bon équilibre pour chaque étape afin de fluidifier au maximum le travail de l’équipe.
Pour vous aider, n’hésitez pas à consulter l’indicateur sur le débit de votre équipe.
Pour en savoir plus : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Jun, 2022 | Medium
Vous constatez un goulot d’étranglement ?
Vos testeurs ne peuvent pas traiter plus de 3 stories, alors que vos développeurs en traitent 6 ? La limite haute va dépendre de la capacité de l’équipe qui souffre.
Des membres de l’équipe sont en sous-activité ?
Il sera intéressant de connaitre combien de membres sont concernés et sur combien de temps pour calculer le nombre minimal de storie à indiquer pour éviter ce genre de situation.
L’équipe considère qu’elle a trop de tâches en cours ?
Vous constatez qu’il n’y a pas de fluidité, que vos stories stagnent longtemps dans une même colonne. Pour pouvoir représenter simplement cette alerte, la colonne avec un dépassement d’une limite haute sera automatiquement en rouge dans votre kanban !
Cela déclenchera une discussion au sein de l’équipe pour trouver des solutions pour lever l’alerte dont, éventuellement, reprendre un partie des activités trop lourdes pour le/les membres qui souffrent.
L’équipe va bientôt changer ?
Une équipe qui se renouvelle ne sera donc plus l’équipe qui aura mis en place l’indicateur. Il sera nécessaire de revoir les limites basses et hautes avec cette nouvelle équipe, le temps de retrouver le débit optimal.
Une colonne est toujours en rouge, pourtant le débit est fluide
Votre équipe est de plus en plus performante et délivre plus ! Il serait bon de revoir les limites à la hausse.
Je n’ai pas de colonne rouge, alors que j’ai des goulots d’étranglement régulièrement !
N’hésitez pas à revoir les limites que vous avez mis en place avec votre équipe car elles ne semblent pas bonnes.
Quelques conseils
N’hésitez pas à tester, à adapter ces limites pour trouver les bons chiffres avec votre équipe ! D’autre part, sachez qu’il n’est pas nécessaire de les ajouter sur toutes les colonnes, mais bien sur celles qui sont sensibles pour vous.
N’oubliez pas non plus de définir vos règles d’équipes et vos “Definition of done” pour avoir une compréhension mutuelle du bon déplacement de vos tickets.
Pour aller plus loin
Reduce Cycle Time with Little’s Law (opexlearning.com)
Vidéo — Le Kanban et le WIP, on en parlait déjà dans les années 1980 … la preuve chez Hewlett Packard (à écouter à partir de la 48ème seconde) : https://youtu.be/PbAStO3EMMs
Un simulateur de flux dans un Kanban pour expliquer à votre équipe les goulots d’étranglement, le Lead time, etc : Simulateur Kanban — Coach agile (coach-agile.com)
