Category: Agile @Scale

Comprendre la loi de Little

L’un des principaux objectifs de Lean est de diminuer le Lead Time c’est à dire le temps de latence entre la prise en charge d’une tâche et son execution totale. Si l’on suit une stratégie Lean, diminuer ce lead time permettra d’un part d’augmenter notre capacité à produire mais aussi d’augmenter notre niveau de prédictibilité. La première façon de diminuer le Lead Time est de réduire la taille des tâches (batch size), la seconde est de comprendre la loi de Little :

Comprendre la loi de Little

Pour l’historique, cette loi fut trouvée par John Little dans les années 60. Son principe est simple : le nombre de clients dans une file d’attente (l) est égale au taux d’arrivée moyen des clients (λ) multiplié par le temps de traitement (ω).

l = λω

En résumé, si je prends l’exemple d’une caisse de supermarché, si j’ai 3 clients par minutes qui arrivent à la caisse et que le traitement d’un client prends 2 minutes, le temps d’attente moyen d’un client est de 6 minutes.

Voici un très bon article sur la loi de Little et les processus Stochastiques. Si vous voulez vous remettre au maths, cela ne fait pas de mal :).

Et Lean dans tout ça ?

Dans une équipe Agile, le lead time est déterminé à partir du moment où l’implémentation d’une fonctionnalité est prise en charge par l’équipe de développement. Il s’en suit l’implémentation, les tests et le déploiement pour que celle ci soit totalement finalisée.

Imaginons une équipe qui délivre 10 fonctionnalités (Features) tous les 3 mois. Si l’équipe prends en charge 20 fonctionnalités en même temps, il lui faudra probablement au moins 6 mois afin de finaliser les fonctionnalités associées. Le temps d’attente moyen (Lead Time) sera donc de 6 mois quelle que soit la fonctionnalité à développer.

Limiter le WIP

Le WIP ou Work-In-Process/Progress est le nombre de tâches exécutées en parallèle par une équipe de développement. Sur un Kanban, on cherchera à mesurer ce WIP et à le limiter. En effet, limiter le nombre de tâches à traiter en parallèle est clé si l’on veut conserver un bon niveau de productivité sans mettre à mal la qualité.

Revenons à notre équipe agile, si je cherche à limiter mon Lead time, je peux jouer sur deux facteurs :

  1. Le niveau de productivité de l’équipe. Sa vélocitié de façon à ce qu’elle délivre plus de fonctionnalités en une itération donnée
  2. Le nombre de fonctionnalités sur lesquelles l’équipe travaille

Chercher à augmenter la vélocité d’une équipe agile n’est clairement pas l’option la plus satisfaisante (voir mon article précédent). Nous allons donc facilement pouvoir jouer sur le nombre de fonctionnalités dans la file d’attente.

Exemple:

  • L’équipe délivre 10 fonctionnalités tous les 3 mois
  • L’équipe travaille sur 8 fonctionnalités

Par conséquent, le temps de traitement (Lead Time) moyen sera de 2,4 mois. Il a donc de forte chances que l’équipe arrive à délivrer à l’issue de cette itération de 3 mois avec un bon niveau de confiance.

En résumé

En résumé, la loi de Little met en évidence que plus le travail en cours (WIP) est limité, meilleur est le Lead Time et notre capacité à produire.

DevOps – Comment joindre l’ITIL à l’agréable ?

Le chemin vers le DevOps peut être long et sinueux. Nous ferons face à de nombreux obstacles, à la fois culturels et organisationnels.  Une équipe DevOps doit être avant tout Agile et s’adapter en toutes circonstances. L’objectif de cet article et de partager une vision long terme et les étapes qui nous y amènent.

Pourquoi l’ITIL ?

La plupart des grosses structures ont, par définition et d’un point de vue RH, des groupes d’entités « métier » et « techniques ». Les entités métiers ont pour but d’apporter de l’innovation dans le métier de l’entreprise, d’augmenter le chiffre chiffre d’affaire et optimiser les dépenses. Les entités techniques, quant à elles, ont pour objectif d’implémenter, d’héberger et d’assurer le fonctionnement des outils nécessaires aux entités métiers pour exercer leurs fonctions. Les besoins sont multiples : performance, stabilité, sécurité, disponibilité. Afin que l’ensemble de ces critères soit satisfait, des méthodes et process ITIL ont été mis en place dans le but de contrôler et canaliser les changements pour plus de stabilité opérationnelle.

Un peu d’historique

Avant l’avènement des méthodes agiles, la plupart des projets suivaient un cycle de livraison en V. Les principes de cette méthode s’inspirent directement de l’industrie. On commence par recueillir le besoin initial puis définir des Blueprints d’architecture. L’ensemble des besoins est ensuite détaillé à la fois sur les aspects fonctionnels et techniques. Vient ensuite les phases d’implémentation, de test et de déploiement.

Cette méthode couplée à des processus ITIL permet une stabilité opérationnelle optimale. On modifie peu la production et lorsque cela arrive on canalise au maximum le changement via des processus définis. Cette façon de fonctionner a fait ses preuves durant de nombreuses années. Cependant, elle est de plus en plus controversée au bénéfice d’approches plus agiles. En effet, la plupart des équipes de développent travaillent en agile au plus près du métier. Elle délivrent des incréments régulièrement et sont souvent confrontés à la latence des process une fois l’incrément livré. Cela apporte de la frustration à la fois au niveau métier mais aussi au niveau des équipes de développement.

« Individuals and interactions over processes and tools »

Il s’agit du premier concept souligné par l’agile manifesto. Les fondements de l’agile sont la transparence, l’inspection et l’adaptation. Le principe est d’analyser les situations, d’apprendre de ses échecs et d’évoluer de manière empirique dans des environnements complexes. Le chemin vers l’agile et de DevOps peut être long et complexe, voici quelques étapes à franchir en s’inspirant de l’échelle de Tuckman :

Forming – Démarrer du bon pied

Devops est une histoire de personnes et de compétences avant tout. La formation est nécessaire afin que l’ensemble des équipes adoptent l’état d’esprit et la philosophie portée par le DevOps.

Storming – Etre confronté à la réalité

Une fois sur le terrain, les équipes formées feront face aux vraies difficultés. Durant cette phase, les interactions devront se mettre en place et les rôles et responsabilités de chacun en découler.

Norming – Mettre de l’huile dans les rouages

Une fois les process éprouvés, chaque équipe DevOps devra :

  • Mettre en place des processus d’amélioration continue.
  • Mesurer pour mieux améliorer.
  • Adapter et simplifier les process devant l’être.
  • Être pragmatique. Les objectifs communs seront l’augmentation de la réactivité des équipes et la diminution du Lead Time à son minimum.

Performing – en route vers l’excellence

À ce stade, l’équipe tire les fruits des changements opérés dans l’étape Norming. Les processus d’amélioration continue tireront l’équipe DevOps vers l’excellence, à la fois technique et collaborative. L’objectif : Changer son métier pour plus d’innovation et de performance !

Exemples à suivre: Amazon, Netflix, Spotify

En conclusion, DevOps est une histoire de personnes avant tout ! Les process ne doivent pas en bloquer l’adoption. Ils devront être au cœur de la transformation et potentiellement adaptés grâce à l’expérience des équipes. Une vision long terme est déterminante dans le succès d’une transformation Agile et DevOps. Changez votre métier pour le meilleur !

Comment prioriser son Product Backlog à l’aide du WSJF ?

WSJF ? Qu’est ce que c’est ? Encore un acronyme de plus dans notre vocabulaire. J’ai découvert cette technique dans le Framework SAFe. WSJF veut tout simplement dire « Weighted Shortest Job First » ou en français « la plus importante ou la plus courte fonctionnalité d’abord ! ». Organiser ou prioriser le Product Backlog est souvent un casse tête pour le Product Owner. Sur des projets complexes avec beaucoup de fonctionnalités, il est parfois très chronophage de faire l’exercice de raffiner son Product Backlog de manière efficace. Cet outil pourra nous y aide. Je vois plutôt le WSJF comme un outil plutôt qu’un indicateur. Il permet de déterminer un chiffre représentant le bon compromis entre la valeur qu’apportera la fonctionnalité si on la livre et le temps que l’on prendra à la développer.

D’où vient le WSJF ?

SAFe part du principe que toute fonctionnalité non livrée à temps à un coût : The Cost of Delay. Dans la philosophie de Lean, l’objectif est donc de réduire ce coût au minimum pour augmenter notre efficacité et livrer le maximum de valeur à l’issue d’un Sprint. Prenons quelques exemples simples. Imaginons que nous avons deux fonctionnalité à développer. Elle ont la même valeur métier mais l’une d’entre elle est plus courte à développer. Le product Owner priorisera sans aucun doute la plus courte. Par contre, si l’une des fonctionnalité prends moins de temps à développer mais est aussi moins prioritaire, il est difficile de la prioriser dans le Product Backlog. Le Product Owner devra trouver le bon compromis. L’idée du WSJF est de lui fournir un outil factuel permettant de l’aider dans cette tâche!

Comment se calcul-t-il ?

Le calcul du WSJF prends en compte les critères suivants. On utilisera pour tous ces indicateurs une notation suivant une suite de Fibonacci par ordre croissant:
– User-Business Value : la valeur métier de la fonctionnalité.
– Time Criticality : détermine si la fonctionnalité doit être livré rapidement ou non.
– Risk Reduction or Opportunity Enablement: Détermine si cette fonctionalité réduit le risque ou facilite le développement d’autres fonctionalités par la suite
– Job Size : Taille de la fonctionnalité à développer. On parle aussi d’effort. Cette valeur peut être estimée par l’équipe de développement.

Calcul du « Cost of Delay »

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Oppty Enablement
WSJF = Cost of Delay / Job Size

Plus le WSJF a une valeur importante, plus la fonctionnalité pourra être priorisée. On voit ici que dans cette formule, nous prenons en compte à la fois la valeur métier mais aussi la contrainte de temps et la réduction du risque. Le facteur ayant le plus de poids sur la formule est donc la taille ou l’effort.
Cela met en évidence plusieurs chose. D’une part plus les Features sont petites, plus elles sont faciles à estimer et à ordonnancer les unes par rapport aux autres. On parle en général de MMF (Minimum Marketable Feature). D’autre part, ce n’est pas parce qu’une fonctionnalité semble importante qu’elle doit être priorisée. Il faudra prendre en compte l’impact si celle-ci n’est pas développée à court terme. Dernier point, ce calcul n’est pas figé dans le temps. L’ensemble des facteurs pourra être revu au fil des sessions de Product Backlog Refinement.

En conclusion, le WSJF est un outil relativement puissant permettant une bonne priorisation du Product Backlog en entrée de chaque Sprint. Il fera aussi gagner beaucoup de temps à la Scrum Team dans les sessions de Product Backlog Refinement où l’équipe pourra se focaliser sur les fonctionnalités les plus cruciales.

Pour aller plus loin:

http://www.scaledagileframework.com/wsjf/