Je vous explique dans cet article comment reprendre le contrôle et le sens de votre daily Scrum en vous appuyant sur la stratégie Kanban.

1 ) Le daily Scrum c'est quoi ?

L'objet du Daily Scrum est de permettre à l'équipe de s'organiser ou se réorganiser pour avancer vers l'atteinte l'objectif du sprint dans la timebox du sprint.

L'équipe est un collectif qui réussit ou échoue ensemble, il n'y a pas de responsabilité individuelle, mais une responsabilité de l'équipe sur cet objectif et la qualité de l'incrément.

Le Daily Scrum sert au quotidien à l'équipe à piloter ses travaux nécessaires pour réussir ensemble à atteindre l'objectif du sprint, par conséquent la présence de tous les membres de l'équipe est obligatoire à cet évènement.

Attention donc ce n'est pas un évènement de reporting, mais un évènement court pour s'organiser de façon collaborative afin de travailler sur ce qui est le plus pertinent pour les prochaines 24h.

2 ) Améliorer le daily Scrum avec Kanban

Pour un daily scrum plus efficace et efficient :

1. Ayez tous l'objectif du sprint sous les yeux et le sprint backlog
2. Ayez une visualisation de vos éléments dans votre workflow avec notamment l'âge des éléments et un moyen simple de visualiser les éléments "bloqués"
3. Plutôt que de répondre aux questions courantes d'un Daily Scrum à savoir :
   • Qu'ai je fait hier ? (question amenant à du reporting)
   • Que vais-je faire aujourd'hui pour avancer sur l'objectif ? (pas mal, mais un peu trop individuel)
   • Suis-je bloqué et ai-je besoin d'aide ? (celle la est à garder)

Prenez les questions suivantes :

1. Quelque chose vieillit-il anormalement dans notre flux ?

2. Est-ce que quelque chose est coincée ? (Dépendance, problématique sur laquelle la personne ou le groupe qui travaille dessus n'arrive pas à trouver de solutions, etc.)

3. Si oui, que se passe-t-il brièvement ? As-tu ou avez-vous identifié(s) quelqu'un pour aider ? Comment peut-on travailler ensemble pour débloquer la situation et finir ce travail ?

4. Quelqu'un pense-t-il avoir besoin d'aide et sur quoi ?

5. Quelle est la chose la plus importante que l'on doit accomplir aujourd'hui ?

6. Comment on augmente les chances de finir cette chose la plus importante aujourd'hui ?

Pour le 1) en ayant le sprint backlog sous les yeux et une visualisation de l'âge des items dans le workflow, essayez de focaliser les échanges du daily scrum pour que les éléments progressent dans votre flux dans une logique de commencer par terminer (donc de droite à gauche) ainsi que dans une logique de travailler prioritairement à faire avancer les éléments qui vieillissent anormalement.

N'oubliez pas votre objectif de sprint ! En toute logique vous n'aurez pas démarré d'autres choses qui n'y contribuent pas avant de l'avoir atteint, n'est-ce pas ?

Comment détecter qu'un élément vieillit anormalement ?

En appliquant la stratégie Kanban, une des premières choses que vous allez faire en équipe est de définir un SLE* (niveau de service attendu). C'est avec ce SLE et l'historique de débit, de temps de cycle, de WIP, d'âge des items que l'équipe va pouvoir visualiser si quelque chose vieillit anormalement et doit être un sujet de discussion et de préoccupation.

*SLE : Une quantité de temps (ex : 15jours) et une probabilité d'être dans cette timebox (ex : 85%) que l'équipe choisit et sur laquelle l'équipe se challenge à ne pas dépasser pour terminer un élément qui est entré dans son flux de travail.

Un autre apport de la stratégie Kanban pour le daily Scrum tourne autour d'une autre métrique fondamentale qui est le WIP.

Si vous avez démarré trop de choses (focus faible), vous allez avoir du mal à tenir les 15minutes du daily Scrum. Au-delà du fait que cet évènement risque d'avoir sa timebox explosé régulièrement, c'est un vrai problème pour votre efficience, efficacité et prédictibilité de démarrer trop de choses (cf mon petit post à ce sujet ici : https://www.linkedin.com/posts/jose-coignard_doug-macdonald-rice-and-traffic-congestion-activity-7138275853376839680-z6sf?utm_source=share&utm_medium=member_desktop

Oki !

Voyons tout cela dans un exemple concret de comment mieux utiliser ces 15 minutes.

3) Mise en application sur un cas réel

Prenons l'exemple ci-dessous qui représente l'état du workflow d'une équipe lors d'un daily Scrum.

Laissez-moi d'abord vous expliquer rapidement ce graphique dont le petit nom est "graphique d'âge des sujets en cours" :

• Chaque point représente un (ou plusieurs lorsqu'il y a un chiffre dans le point) élément du sprint backlog
• En abscisse (axe horizontal), on voit les étapes du workflow (En cours, dev terminé etc…)
• En ordonnée (axe vertical), on a l'information de l'âge en nombre de jours calendaires
• A droite des percentiles, indication sur la base historique des éléments qui ont été validées en recette du temps que cela a pris pour traverser le flux. 85% des éléments historiques ont pris 18jours calendaires ou moins pour traverser le flux, 10 jours ou moins pour 70% des éléments.
• Les couleurs représentent ces mêmes percentiles (vert foncé <50%, vert clair <70%, jaune clair <85%, orange <95%, rouge >95%) mais par temps passé (historiquement) au sein de l'état même du workflow. Par exemple pour rendre cela plus clair : 50% des tickets historiques étaient dans l'état "Recette" après 3 jours ou moins de circulation dans le workflow,  85% des tickets historiques étaient dans l'état "Dev Terminé" après 18 jours ou moins de circulation dans le workflow...

Considérons pour la suite que cette équipe ait choisi comme SLE 18jours ou moins à 85% du temps. Vous pouvez voir ce SLE représenté sur le graphique par des traits pointillés et l'indicateur des 85% à droite.

Faisons un focus sur les éléments 643 et 649 par exemple qui ont respectivement à 23j et 21j de vie dans le flux.

En étant dans une logique de vérifier que rien ne vieillit au-delà des 18j à 85%, des discussions devraient s'être enclenchées avant aujourd'hui afin d'essayer que ces éléments ne vieillissent pas au-delà de ces 18j à 85%.

On peut imaginer que ce n'est probablement pas ce qui s'est passé ici car ces éléments ont déjà dépassés le SLE.

On peut d'ailleurs voir qu'un certain nombre non négligeable de choses sont au-delà de ces 18j et même des 32j à 95%.

Les prochains sujets importants à faire avancer se situent donc dans la zone « orange / rouge » du graphique, comme la 557 sur l’exemple ci-dessous :

Donc en reprenant une vue globale, sur ce daily scrum en utilisant la stratégie Kanban, les discussions devraient tourner autour des items dans la zone de focus ci-dessous :

Tous ces éléments vieillissent anormalement. Les raisons peuvent être variées, mais c'est un sujet qui doit être pris au sérieux par l'équipe, des clients, utilisateurs attendent ces éléments de valeurs potentiels !

Il n'est pas nécessaire de discuter des autres sujets en tout cas pour aujourd'hui, d'autant plus que le WIP est extrêmement élevé pour cet exemple d'équipe et de situation de workflow.

L'organisation de l'équipe aujourd'hui doit être construite pour une focalisation sur l'arrêt de vieillissement des éléments et la terminaison de ce qui est commencé.

En débloquant, en faisant sortir ces vieux éléments (et en évitant de démarrer de nouvelles choses), l'équipe finira par aborder les autres sujets et rétablira un flux de livraison de valeurs potentiels.

Si elle ne fait pas cela, la situation ne fera que s'empirer, les clients deviendront de moins en moins contents, la pression sur l'équipe augmentera (ce qui par ailleurs accentuera très certainement les problématiques), la confiance envers les parties prenantes ne fera que chuter…. Etc . Etc.

En bref plein de choses que vous ne voulez absolument pas vivre !

Je vous invite à lire mon autre article sur la loi de Little (découvrir cet article ici) pour comprendre l'importance de la stabilité du flux et la limitation du nombre de sujets en cours à un instant t.

N'hésitez pas à commenter et à me donner d'autres idées d'articles !

Enfin rejoignez moi dans une de mes classes pour en apprendre plus sur la Stratégie Kanban et l'optimisation de votre flux de valeur !