L'art d'inspecter son Value Stream : stratégies pour avoir de l’impact

Préambule : Peut-être que ce genre de situation vous est familier, en tout ou en partie :

Vos équipes sont bien occupées, mais les délais de livraison ne s’améliorent pas ou sont en régression. Que se passe-t-il?

Votre équipe a cartographié sa chaîne de valeur (Value Stream). Les mesures DORA sont mises en place. Beaucoup de données sont visibles provenant de vos différents outils tels que Azure DevOps, Jira, Gitlab ou autre. Mais en voir trop, c’est comme pas assez. Vous ne savez par quel bout commencer…

Bref, cette situation et certaines de vos données vous choquent. Que faire ?

Dans cette présentation, nous allons voir une série d’astuces et de façons de faire pour inspecter votre Value Stream(chaîne de valeur) et se démêler dans les données présentées.

Transcript

1. L’art d'inspecter son Value Stream Stratégies pour avoir de l’impact
2. Qu'est-ce qui vous choque vous regardez les indicateurs agiles de votre équipe ? (ou de l'une de vos équipes)
3. INTRO & PRÉAMBULE
4. Situation familière ? Équipe occupée mais les délais de livraison sont en régression… Value Stream cartographié, indicateurs DORA en place. Trop de choses à voir en même temps ! Par où commencer ? On a « installé » Scrum et l’agilité à l’échelle, mais l’efficience tarde à se montrer
5. Constats sur le terrain Il est donc important d’avoir les compétences pour se servir des indicateurs afin de s’améliorer Les organisations recherchent à être davantage efficientes mais plusieurs facteurs sont en jeu Variabilité et incertitude Mesurer la complexité des systèmes Sous-estimation des risques
6. Votre conférencier : Karl Métivier • Coach Agile Senior • Enthousiaste du Value Stream et du Kanban • Promoteur du DevOps et de la Livraison en continu • Travaille chez Beneva depuis quelques jours…
7. Au menu aujourd’hui • Exemples d’inspections (avec votre participation) • Stratégies dans la sélection d’indicateurs • Posture “Data-Driven” • Conclusion
8. EXEMPLES D’INSPECTIONS
9. Notation Value Stream (Chaîne de valeur) Dev Code Review Build & Test PT: 2j %R: 40% 2j PT: 0.25j 0.5j 0.5j 3j Process Time (PT): Temps pour faire le travail sans interruption, ni délais Temps de délais: Temps écoulé entre la fin d’une activité et le début de l’autre. % de Reprise (Rework): % du travail qui a dû être repris avant de poursuivre
11. Celui avec autant de temps de validation que de réalisation
13. Celui avec un temps de déploiement élevé
15. Celui avec un long temps passé dans le « Upstream »
17. Celui avec une colonne bloquée • Inspecter quand les colonnes du « board » de l’équipe ne correspondent pas au processus • Une colonne bloquée peut devenir un fourre-tout que l’on oublie • Un item avec un « tag » bloqué qui compte dans la limite de WIP d’une colonne
18. Débit / Flow Velocity Items de travail complété par semaine
19. Celui avec un flux ou flux ou débit instable • Investiguer pour savoir pourquoi le flux est relativement inégal. Hypothèses probables: • Beaucoup de « restants » de sprint qui bascule (et se font fermer dans le prochain sprint) • Instabilité dans les environnements ou dépendance externe ? • Surestimation de la capacité de l’équipe • Que dit la tendance (« Trend ») ? Vers le haut ou le bas ?
21. Celui avec un nombre élevé d’étapes (18) • Le nombre d’étapes ou d’activités peut dénoter la complexité (lourdeur) de notre processus. Il faut alors se questionner: • Davantage en contrôle qualité qu’en assurance-qualité • Silos basés sur l’expertise (analyse, design, code, test) • Culture de non-confiance dans l’organisation ?
22. Parmi les exemples mentionnés, lequel est le plus fréquent dans votre contexte:
23. STRATÉGIES DANS LA SÉLECTION D’INDICATEURS
24. Suivre une seule mesure (ou une seule sorte) • Mettre le focus sur une seul mesure nous rend myope dans notre amélioration du système
25. Suggestions de Troy Magennis (math coach) • Plusieurs indicateurs et non un seul et unique • Tendance plus que les chiffres • L'équipe plutôt que l'individu • Un contexte similaire pour tous les items et équipes • Montrez-moi quand il faut s’inquiéter !
26. The Flaw of Averages Alternatives aux « moyennes » • Analyse sur la distribution (ex: histogramme) pour éviter le focus sur un seul nombre • Prévisions avec des simulations Monte Carlo • Toujours tenir compte de la variabilité avec des données historiques • Utiliser les percentiles (70e, 85e) https://sketchplanations.com/sneaky-averages
27. On peut faire dire n’importe quoi aux indicateurs • Il y a plusieurs manières de faire varier les indicateurs • Intervalle de dates • Filtrer des types d’items • Éviter de tomber dans le piège des indicateurs « melon d’eau » et plutôt rester transparent. • Faut faire attention à tout cela et se rappeler les objectifs avant tout. • Porter attention aux « patterns » au lieu de la précision https://sketchplanations.com/you-get-what-you-measure
28. Indicateurs DevOps (DORA) 2. Fréquence de déploiement 1. Délai de changement 4. Temps moyen de restauration 3. Taux d’échec des modifications Ref: https://dora.dev/guides/value-stream-management/
29. Sélection d’indicateurs pour une équipe Troy Magennis
30. En bref, quand on investigue un value stream • Analyser et mettre des hypothèses sur des corrélations potentielles. • Les données ont de l’importance car elles nous permettent de • Comprendre davantage notre réalité • Voir les opportunités • Poser des questions pour mieux comprendre ce qui se passe • Avoir des discussions d’équipe avec des faits • On doit alors être critique de la manière donc on recueille nos données.
31. DATA-DRIVEN COMME POSTURE DE COACHING
32. Quantitatif • Objectivité • Outils • Données • Perception • Expérience • Storytelling Qualitatif Tout ne doit pas être objectif dans notre analyse !
33. La discussion doit faire partie des indicateurs • Aller chercher l’opinion des gens et le côté qualitatif • Discuter des indicateurs fait partie d’une bonne gestion du changement. Ne pas le faire pour embarrasser le gens. • Le but est de s’améliorer et être plus efficient, non pas d’évaluer une équipe et des personnes. • Rappeler qu’on mesure les tâches dans le système, pas les gens • La direction veut aussi comprendre comment les affaires vont, ce qui vous ralenti, les liens inter-équipes pour identifier des améliorations à l’échelle.
34. Exemples de formulation invitant à la discussion: • Qu'est-ce qui vous fait le plus mal en ce moment ? • C'est quoi le lien que vous faites avec ces indicateurs • Voici les données du dernier sprint. Qu’en pensez-vous ? • Est-ce que cela représente votre expérience vécue durant le sprint ? Pourquoi ? • Je remarque ceci (…). À votre place j’essayerais de (…)
35. Informez-vous des objectifs de la direction • Toujours aller s’informer sur les enjeux au niveau de la gestion/direction. • Cela ne donne pas d’impacts de travailler sur des éléments qui importes peu pour la direction. • La direction veut parler en dollars, en temps et en capacité. • Traduire les indicateurs et les pratiques en ces termes
36. Même une mauvaise qualité des données est un indice • On ferme les « work items » uniquement à la fin du sprint, c’est pour cela que tout prend environ 3 semaines • Hmm. Et si vous les fermiez au fur et à mesure pour avoir des données qui représentent vraiment votre travail ? • Attachez cela à un comportement existant. • Ex: le daily du lundi, on valide le statut des divers « work items » : tâches, user story, feature, epic, etc.
37. Imposer des cibles avec des limites https://sketchplanations.com/goodharts-law Exemples de mauvais usages: • Couverture de code minimale pour permette un Pull Request • Nombre de défauts avec une limite de contrôle • Ratio de tâches planifiées vs. défaut/bogues
38. L’équipe « game » les indicateurs • Oui, l’humain est astucieux par moment pour « gamer » d’une mauvaise manière les mesures. • Assurez pour chaque indicateur d’expliquer: • C’est quoi ce graphique (“chart”) ? • Quel est le comportement attendu ? • Comment on la “game” ? (positivement) • Le but est de mesurer pour s’améliorer et non pas changer la façon dont nous mesurons pour atteindre les objectifs…
39. Accompagner l’équipe dans la sélection des indicateurs • Ex. : on regarde à diminuer la taille des lots. • Good. On va donc suivre les indicateurs suivants: • Débit / vélocité • Temps de cycle des items • Temps de QA ? Ou dans une étape de validation • Délai de Déploiement • Temps de planification des items • On essaie des choses, on se mesure et on analyse le tout par la suite. • On évolue, un pas à la fois.
40. Les indicateurs sont un guide avant tout • Pour nous aider dans certains objectifs comme l’amélioration continue • Permet une introspection profonde du processus, permettant de se pencher sur leur réalité et de la saisir plus clairement • L’équipe voit ce qui se passe, l’impact de ce qu’ils font et quel endroit améliorer. • Créer un lien entre la théorie et le contexte de l’équipe en utilisant des indicateurs • Utiliser les indicateurs à bon escient. Nous ne voulons pas détruire la culture et démoraliser les gens
41. CONCLUSION
42. Comment inspecter son Value Stream ? • Regarder les indicateurs et de comprendre (et analyser) son flux de travail. • Les indicateurs ont divers angles morts et une raison d’être. • Voir les données et les indicateurs comme un outil d’aide à la décision qui génère des options • Ne négligez pas le facteur humain et la gestion du changement !
43. La voie de la maturité par un modèle simple 1. Cartographie de chaîne de valeur (VSM) pour rendre visible à l’équipe leur processus de travail. Ou un STATIK. 2. Identifier les goulots d’étranglement et les inefficiences 3. Standardisation des données source (Azure DevOps, Jira, GitLab) 4. Évolution des comportements (Ways of Working) et les pratiques dans l’équipe en suivant un ensemble d’indicateurs 5. Inspection en continu grâce aux données. On revoit notre sélection d’indicateurs au besoin
44. Réflexions • L’efficience est recherchée par les entreprises • Le coaching a encore sa place selon moi. Et le « data-driven coaching » est une posture à avoir dans son coffre à outil pour tous. • Davantage viser à évoluer par petits pas que se transformer à grande enjambée
45. RÉFÉRENCES
46. Troy Magennis Expert on Agile predictability, metrics, and probabilistic forecasting. • Vidéos • Metrics-driven Coaching with Troy Magennis (30 min) • Cycle Time Analytics - Fast #NoEstimate Forecasting & Decision Making ( 58min) • Agile Physics - The Math of Flow (formation en ligne gratuite environ 2h) • Notebooks • Github On a juste besoin de cela au minimum
47. Data-Driven
48. Value Stream
49. Vidéos pertinents • When Not To Use DORA Metrics (44 min) • How We Use Data To Ignite Action (28 min) • How to Misuse DORA DevOps Metrics (38 min)
50. Questions ? Commentaires ?