Right-sizing kesako ?

Le concept repose sur la notion de niveau de service attendu (SLE en anglais pour Service Level Expectation) pour amener un élément de son flux de travail du point de départ au point d'arrivée. Ce niveau de service attendu est une durée associée à une probabilité de finir le travail dans cette durée.

Exemple de SLE : 10 jours ou moins avec 85% de probabilité.

En prenant l'exemple du SLE ci-dessus, "right-sizer" veut dire que l'équipe cherchera à découper ses éléments en éléments de valeur pouvant être terminés en une durée inférieure ou égale à 10jours.

Ce mécanisme de découpage pour respecter son SLE est la pratique de "right-sizing".

C'est une pratique continue, qui ne se fait pas uniquement avant de commencer à travailler sur un élément. En effet, lorsque l'équipe réalise un élément, elle acquiert des connaissances plus précises sur la complexité du sujet, sur les dépendances, sur les choses à tester, sur ce que souhaitent vraiment les utilisateurs finaux etc. Si, en acquérant ces connaissances supplémentaires, l'équipe se rend compte que l'élément ne pourra être fini dans son SLE, elle doit alors se questionner :

• Peut-on le découper en éléments de valeur respectant notre SLE ?
• Doit-on faire quelque chose avant qui permettrait à cet élément de traverser plus rapidement notre flux ?
• Doit-on augmenter le nombre de personnes de l'équipe qui bosse dessus ?
• Doit-on demander de l'aide à quelqu'un extérieur à l'équipe ?
• Doit-on abandonner le sujet, car nous ne serons pas à temps au rendez-vous, ou il devient trop coûteux par rapport au ROI escompté ?
• Doit-on ne rien faire et accepter d'entrer dans les 15 % de risque à dépasser notre SLE ?

Le "right-sizing" est un concept pouvant s'appliquer à différents niveaux de granularité du travail réalisé par une équipe, un département, une organisation. Cela peut être au niveau User Stories, Tâches à valeur, Pré requis technique, mais aussi fonctionnalité, EPICS, initiatives, produits, projets... bref le concept et la pratique sont "scalable".

Au niveau fonctionnalité, EPICs ou initiative, etc., bref à un niveau où le temps nécessaire pour traiter un sujet est a priori de plusieurs semaines et même mois, "right-sizer" en temps devient compliqué et peu précis. Dans ces cas, il est préférable de right-sizer en quantité d'éléments de travail de niveau plus fin qu'il faudrait faire. Par exemple, poser une taille attendue de l'élément par rapport aux éléments du niveau d'en dessous : "85 % des fonctionnalités doivent faire la taille de 10 User stories ou moins".

Ne pas right-sizer, avoir des éléments, features, initiatives etc. très gros, cachent la véritable valeur du nombre de sujets en cours (WIP). Si un élément pouvait se découper en 4 éléments plus petits alors en mettant cet élément en cours on augmente son WIP en réalité de 4 unités et non de une.

L'impact d'un WIP trop élevé pour votre système sera un allongement du temps de cycle, en d'autres termes plus votre WIP sera grand plus tout ce que vous entreprendrez prendra du temps à se terminer. Voir mon article sur la loi de John Little.

Alors si vous voulez devenir plus efficace et plus prédictible, vous devriez commencer au plus vite à "right-sizer" les éléments qui vont circuler dans votre flux de travail.

Vous voulez creuser le sujet ?

Rejoignez-moi dans l'une de mes classes certifiantes à laquelle je suis accrédité de https://ProKanban.org