Agile Delivery Flow : toujours livrer à temps en 3 étapes

Si vous demandez à la plupart des managers ce qu’ils pensent de la “sécurité psychologique” ou de la “vision” (plus d’informations à ce sujet : Sécurité psychologique ) de leurs équipes de développement logiciel agile, ils reconnaissent que ces choses sont importantes, mais… Lorsque le client signale une urgence ou que la date limite approche, toutes ces variables “plus douces” sont généralement mises de côté. Les managers se soucient avant tout d’un flux de livraison agile fonctionnant de manière prévisible pour leur équipe agile.

Si tu consultes notre blog Echometer ( vers notre blog ) vous savez que notre contenu se concentre plutôt sur l’amélioration des “compétences non techniques” des équipes et des organisations. Celles-ci sont souvent sous-estimées par les décideurs. Mais pas par les Scrum Masters et les coachs Agile.

Ce que, selon moi, les Scrum Masters et les coachs Agile sous-estiment, c’est l’importance de se concentrer sur l’amélioration du flux de livraison - en gros, ce que veulent les managers. Dans l’article d’aujourd’hui, je décris une technique simple pour augmenter considérablement la probabilité de livrer dans les délais et dans le respect du budget, encore et encore.

1ère étape par rapport à ton flux de livraison Agile

Je parle de la surveillance du flux de livraison Agile de tes tâches ou tâches. Si tu fais quelques choses correctement, tu seras en mesure de fournir des résultats beaucoup plus prévisibles. Même tes Cycle Time Scatter Plots ou ta simulation Monte Carlo pour calculer les estimations de projet pourraient enfin indexer des prédictions valides au lieu d’être complètement à côté de la plaque (plus d’infos à ce sujet : 9 Métriques agiles pour les décideurs ).

Premier symptôme à combattre : il y a des tâches qui ne prennent que quelques jours pour passer de “planifié” à “terminé”, et il y a des tâches qui prennent plus d’un mois. Pour éviter cela, tu dois t’assurer qu’une tâche contient toujours la plus petite version disponible de la fonctionnalité souhaitée. Sans fioritures, qui ne sont pas nécessaires pour le souhait principal du client. En fait, c’est une MVT, Minimum Viable Task. Cela ne signifie pas que chaque tâche est petite. Mais cela devrait t’aider à atteindre un stade où les tâches ne durent pas plus de quelques semaines et pas des mois.

2ème étape par rapport à ton flux de livraison Agile : WIP au lieu de Velocity

De nombreux Scrum Masters ou coachs Kanban pensent que, pour une mesure valide de la vélocité, etc., il est important de “dimensionner correctement” les tâches ou les éléments de travail, de sorte que tous les éléments de travail aient à peu près la même taille. Ce n’est qu’alors que les story points (nécessaires pour mesurer la vélocité) peuvent être utilisés pour mesurer la vélocité, car ils ressemblent davantage à une unité de temps comparable. 

Mais c’est faux : les tâches n’ont même pas besoin d’une taille similaire. Tu ne devrais pas partir de ce principe, car il est tout simplement trop difficile de contrôler les estimations de Story Point. La seule chose que tu peux contrôler, c’est le nombre de nouvelles tâches que tu commences.

Alors, faites ce qui suit pour devenir prévisible : surveillez le taux de “tâches nouvellement commencées” par rapport au taux de “tâches terminées”. Ces deux taux devraient être équilibrés. En d’autres termes, les taux d’entrée et de sortie des tâches devraient être aussi proches que possible, idéalement même correspondre.

Un exemple : le comportement typique dans les équipes de développement de logiciels est que dès qu’une tâche est bloquée, on commence un nouveau work item. Il en résulte que de nombreuses tâches sont ouvertes mais non terminées, ce qui rend leur déblocage beaucoup plus compliqué. 

Si, au lieu de cela, vous veillez à ce que chaque tâche commencée soit également une tâche terminée, il sera plus facile, lors du Daily, de débloquer les quelques tâches sur lesquelles vous vous concentrez. Votre performance globale deviendra plus prévisible - et l’équipe sera plus satisfaite parce que votre supérieur et vos clients seront plus satisfaits.

Quelques “symptômes positifs” d’un flux de livraison agile sain

Dans la pratique, cela se traduirait par les comportements suivants :

• • Nous ne commençons pas de nouvelles tâches alors qu’il y a encore beaucoup de choses en cours. 

• • Nous nous concentrons sur la fin de ce que nous avons commencé avant de commencer de nouvelles choses.

• • L’âge des tâches ne dépasse jamais quelques semaines.

• • S’il n’y a pas de bonne raison, nous travaillons toujours sur la tâche la plus ancienne.

Les limites WIP (Work-in-Progress) aident également, même si elles ne sont souvent pas suffisantes. Une fois que l’équipe aura appris à se concentrer sur l’achèvement des tâches au lieu d’en commencer de nouvelles, vous serez meilleurs que la plupart des équipes.

Si tu utilises correctement le flux de livraison Agile

Pour créer des attentes claires : De cette façon, tu ne peux toujours pas contrôler si une tâche prend deux ou trois jours. Mais au moins, tu t’assures que ton équipe ne travaille pas sur tant de tâches que des tâches de 2-3 jours finissent par prendre un mois.

Ton équipe se sentirait beaucoup mieux si tu savais que toutes les obligations de livraison sont en principe remplies en quelques semaines ? Cela suppose bien sûr que tu mettes en œuvre toutes les choses mentionnées ci-dessus : La définition de MVT, une limite stricte de WIP et l’obligation de ne pas recommencer les tâches tant qu’une autre tâche n’est pas terminée.

Étape 3 : Commencer à améliorer le flux de livraison Agile

En théorie, vous savez ce qu’il faut faire. Comment démarrer au mieux en pratique ? En créant une prise de conscience et une “volonté de changement” au sein de l’équipe. Dans le meilleur des cas, par l’autoréflexion.

Tu dois être transparent sur ces chiffres et les vérifier régulièrement pour voir si le rapport entre les tâches commencées et les tâches terminées est en équilibre. Une partie de ta rétrospective pourrait être d’aller un peu plus loin et de réfléchir à la raison pour laquelle les chiffres n’étaient pas équilibrés lors du dernier cycle. 

Je peux te recommander de discuter des comportements que j’ai mentionnés avec notre outil de rétrospective agile Echometer dans ta rétrospective (plus d’informations à ce sujet : 7 Outils de rétrospective en comparaison ). Tu pourrais même en faire une partie de tes accords de travail (ou working agreements) ou de tes bilans de santé réguliers pour sensibiliser en posant les questions régulièrement.

Les questions suivantes font partie de notre modèle de rétrospective pour la “livraison agile” (plus d’informations à ce sujet : 22 modèles amusants pour des rétrospectives agiles ). Nous commençons par quelques déclarations de bilan de santé et demandons à l’équipe si elle est plutôt d’accord ou pas. Ensuite, il y a quelques questions ouvertes :

Rétrospective de la livraison agile

Articles de contrôle de santé

Quand notre méthode de travail a-t-elle entraîné un flux de travail sous-optimal ? (par exemple, des directives peu claires, inadaptées ou non suivies)

Comme vous pouvez l’imaginer, le dernier point du bilan de santé (vérification de la cause) implique déjà une mesure potentielle, quelque chose que vous pouvez essayer pendant un ou deux sprints agiles pour voir si cela peut vous aider : la limitation du nombre de tâches ayant le statut “Travail en cours”.

Poser les bases : Définir des accords pour le travail d’équipe

Vous avez l’impression que votre équipe n’est pas encore prête pour ce type de réflexion ? Dans ce cas, vous devriez d’abord réfléchir à ce qu’est un “bon travail” en général, puis établir quelques règles de base, ce que l’on appelle des accords de travail. Le modèle d’atelier suivant peut vous y aider. Vous pouvez le réaliser sous la forme d’une rétrospective spéciale au début d’un projet ou sous la forme d’un atelier supplémentaire.

Vous devriez d’abord avoir une idée du degré de consensus implicite de votre équipe - voir l’élément du bilan de santé à cet effet. Ensuite, vous devriez vérifier cela en pratique avec quelques questions ouvertes. Chaque membre de l’équipe doit terminer la phrase (voir autres questions) avec autant de réponses que possible qui lui viennent à l’esprit :

Rétrospective des engagements de l’équipe

Articles de contrôle de santé

Gérer les conflits : ‘Si je remarque qu’un conflit se développe dans notre équipe, alors …’.

Après avoir recueilli les réponses, vous devriez bien sûr essayer de trouver des modèles et de vous mettre d’accord sur des accords concrets sur la façon dont vous souhaitez travailler ensemble à l’avenir - au moins temporairement à titre d’expérience.

Une alternative intéressante et créative

Si ces méthodes de rétrospective vous semblent trop “sèches”, il existe une autre méthode de rétrospective qui se concentre sur la qualité de l’output de votre équipe ( Tu trouveras ici 54 méthodes rétrospectives amusantes ) : La rétrospective des “trois petits cochons”. C’est une alternative simple pour commencer à réfléchir et à améliorer tes performances, basée sur l’histoire des trois petits cochons qui construisaient des maisons avec différents matériaux.

Conclusion - Flux de livraison Agile

Peu importe comment tu commences : le plus important est de commencer tout court. Les équipes qui gardent un œil actif sur leur Agile Delivery Flow sont les meilleures équipes.

D’ailleurs, bon nombre des idées que vous trouverez ici sont également bien résumées dans le podcast “Agile Bites”, que je recommande vivement (Vers le podcast : Bouchées agiles). 

Amuse-toi à faire progresser ton équipe !