Si on demande à la plupart des managers ce qu'est la "sécurité psychologique" ou la "vision" (en savoir plus : Sécurité psychologique) de leurs équipes de développement logiciel agiles, ils sont d'accord pour dire que ces choses sont importantes, mais... Lorsque le client signale l'urgence ou que la date limite approche, toutes ces variables "plus douces" sont typiquement mises de côté. Pour les managers, il s'agit avant tout d'un flux de livraison agile qui fonctionne de manière prévisible pour leur équipe agile.
Si tu consultes notre blog Echometer (vers notre blog), tu sais que notre contenu se concentre plutôt sur l'amélioration des "soft skills" 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 les Scrum masters et les coachs Agile sous-estiment à mon avis, c'est la concentration sur l'amélioration du flux de livraison –, en fait ce que les managers veulent. Dans l'article d'aujourd'hui, je décris une technique simple pour augmenter considérablement la probabilité de livrer à temps et dans les limites 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
Beaucoup de Scrum Master ou de coachs Kanban pensent que pour une mesure valide de la vélocité, etc., il faut que les tâches ou les workitems soient correctement dimensionnés, c'est-à-dire que tous les workitems aient à peu près la même taille. Ce n'est qu'alors que les Story Points (nécessaires pour mesurer la vélocité) sont utilisables pour la mesure de la vélocité, car ils apparaissent plutôt comme 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.
Fais donc ce qui suit pour devenir prévisible : Surveille le taux de "nouvelles tâches commencées" par rapport au taux de "tâches terminées". Les deux devraient être en équilibre. En d'autres termes, le "taux d'entrée" et le "taux de sortie" des tâches devraient être aussi proches que possible, idéalement ils devraient même coïncider.
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 contraire, tu t'assures que pour chaque tâche commencée, il y a une tâche terminée, il sera plus facile de débloquer les quelques tâches focalisées au quotidien. Ta performance sera globalement plus prévisible – et l'équipe sera plus satisfaite parce que ton supérieur et tes 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, tu sais ce qu'il faut faire. Maintenant, quelle est la meilleure façon de commencer en pratique ? En créant la conscience et la "disposition au changement" dans l'équipe. Dans le meilleur des cas, en réfléchissant sur soi-même.
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 sont notre modèle de rétrospective pour la "livraison agile" (en savoir plus) : 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é
Nous faisons les choses vraiment rapidement. Pas d'attente, pas de retards.
Nous pouvons estimer avec précision ce que nous pouvons fournir dans un cycle donné.
Les résultats de nos sprints n'ont pas besoin d'être retravaillés après le sprint pour être livrés.
Nous limitons notre 'travail en cours' afin de rester concentrés à tout moment.
Questions ouvertes
Quand notre méthode de travail a-t-elle vraiment bien fonctionné ?
Quels sont les plus grands potentiels d'amélioration pour que les lots de travaux traversent nos processus plus rapidement (éliminer les temps d'attente, améliorer les processus) ?
Quels étaient les exemples récents d'un incrément qui ne fonctionnait pas/n'était pas livrable à la fin du sprint ?
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 tu peux t'en douter, le dernier point du health check (vérifier la cause) implique déjà une mesure potentielle, quelque chose que tu peux essayer pendant un ou deux sprints agiles pour voir si cela peut vous aider : La limitation du nombre de tâches ayant le statut de "travail en cours".
Poser les bases : Définir des accords pour le travail d'équipe
Tu as l'impression que ton équipe n'est pas encore prête pour ce type de réflexion ? Dans ce cas, tu devrais d'abord réfléchir au "bon travail" en général, puis établir quelques règles de base, appelées accords de travail ou working agreements. Le modèle d'atelier suivant peut t'aider dans cette démarche. Tu peux l'organiser comme une forme particulière de rétrospective au début d'un projet ou comme un atelier supplémentaire.
Tout d'abord, tu dois sentir à quel point ton équipe se sent implicitement unie – voir pour cela l'item Health Check. Ensuite, tu dois vérifier cela en pratique avec quelques questions ouvertes. Chaque membre de l'équipe doit terminer la phrase (voir les autres questions) avec le plus de réponses possibles qui lui viennent à l'esprit :
Rétrospective des engagements de l'équipe
Articles de contrôle de santé
Dans mon équipe, nous avons une compréhension commune de ce qu'est un "bon travail".
Questions ouvertes
Gérer les priorités contradictoires : 'Si je remarque des priorités contradictoires, alors ...'.
Communication des bloqueurs : 'Si je ne peux pas avancer dans une tâche, je le partage en ...'.
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 voulez travailler ensemble à l'avenir – au moins temporairement comme expérience.
Une alternative intéressante et créative
Si ces méthodes de rétrospective te semblent trop "arides", il existe une autre méthode de rétrospective qui se concentre sur la réflexion de la qualité des extrants de ton é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.
Questions à réactions ouvertes
Maison en paille : qu'avons-nous construit qui tient à peine debout, mais qui pourrait se renverser à tout moment ? 🌱
Maison en bâtons : Qu'avons-nous construit qui soit relativement stable, mais qui puisse être amélioré ? 🪵
Maison en pierre : qu'avons-nous construit qui soit solide comme un roc ? 🪨
Conclusion – Agile Delivery Flow
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, beaucoup d'idées que tu trouveras ici sont aussi 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 !
