Les 8 accélérateurs du flux de travail en mode Agile

Optimiser le flux de travail de votre équipe passe par l’identification des obstacles et l’adoption des bonnes pratiques.

Nous allons explorer ici 8 accélérateurs de flux concrets pour améliorer la fluidité et l’efficacité de votre organisation.

Pour chaque accélérateur, nous introduisons une problématique que vous avez sûrement déjà rencontrée avec votre équipe.

Ensuite, nous vous donnons des pistes de solutions pour vous aider à atténuer, voire résoudre cette problématique afin d’accélérer votre flux de travail.

Votre équipe subit au quotidien les problématiques que nous allons vous présenter.

Elle est donc la mieux placée pour en parler et les résoudre ! Par conséquent, votre rôle est de faciliter les conversations qui vont mener à des solutions.

Les 8 accélérateurs de flux d'équipe

Voici les 8 accélérateurs de flux concrets qui vous aideront à améliorer la fluidité et l’efficacité de votre organisation :

1) Visualiser et limiter le WIP

1.1) Trop de tâches en cours : risque de perte de focus

Lorsqu’une équipe a trop de travaux en cours (WIP) ou Work in progress, il devient difficile de savoir ce qui est véritablement important. 

Cette perte de focus entraîne de nombreux changements de contextes (bascules d’une tâche à une autre) et donc une perte de productivité et de qualité importante.

La charge du flux, qui mesure le nombre d’éléments actifs (commencés et non terminés) dans le kanban, permet de détecter une augmentation anormale du nombre de travaux en cours. 

Plus simplement, surveillez la quantité de User Story entre les colonnes « À faire » et « Terminé».

1.2 Pistes de solutions

Rendre le travail visible avec un kanban clair :

Faites un atelier avec votre équipe pour rendre le flux de travail visible à travers un kanban.

Gardez en tête que tout le travail réalisé par l’équipe doit être bien visible, car votre kanban doit le refléter parfaitement.

Définir des limites sur le WIP :

Ensuite, positionnez avec votre équipe une limite sur les états qui représentent du travail en cours.

Dans notre cas, les états DEV, TEST et VALIDATION représentent du travail en cours.

L’introduction de ces limites va obliger votre équipe à faire preuve d’entraide pour terminer des travaux avant d’en commencer des nouveaux.

Par exemple :

Commencer les développements de la User Story #7 ne sera pas possible tant qu’une place n’aura pas été libérée dans la colonne DEV.

Autrement dit, il faudra d’abord passer la User Story #5 ou la User Story #6 en test.

Revoyez régulièrement vos limites avec votre équipe afin de les ajuster à la charge de travail et à la capacité de l’équipe.

2) Adresser les goulots d’étranglement

2.1) Quand la demande dépasse la capacité de l’équipe

Les goulots d’étranglement représentent les limitations du système qui doivent être résolues pour accélérer le flux.

Ils surviennent lorsque la demande à une certaine étape du flux est supérieure à la capacité. 

Les causes les plus fréquemment rencontrées sont les suivantes :

• Compétence spécifique requise (une seule personne de l’équipe maîtrise le sujet)
• Accès limité à un outil (licences partagées en nombre insuffisant)
• Compétence hors de l’équipe (expert technique transverse à plusieurs équipes)

Dans l’exemple de kanban ci-dessus, la demande de tests est supérieure à la capacité de tests.

2.1 Pistes de solutions

Identifier la cause et mesurer l’impact :

Profitez des réunions quotidiennes avec votre équipe pour identifier la cause du goulot d’étranglement. 

Mesurez ensuite son impact au quotidien en comptabilisant les délais (temps passé dans la colonne TEST pour chaque User Story). 

Cette mesure vous permettra d’obtenir plus facilement de l’aide auprès du management, particulièrement sensible au temps perdu.

Explorer des solutions en rétrospective :

Menez un atelier de résolution de problèmes en rétrospective pour travailler sur des solutions possibles, et posez les questions suivantes : 

• Est-ce possible de bypasser l’étape qui pose problème ?
• Est-ce possible de bypasser l’étape pour certains types de travaux ?
• Est-ce que certains membres de l’équipe peuvent réaliser le travail à faire dans l’étape qui pose problème ?
• Est-ce possible de développer les compétences manquantes par du binômage, de la formation ou une participation à des communautés de pratiques ?
• Est-ce qu’une « Technical Story » peut être priorisée pour atténuer le goulot d’étranglement ? 
• Est-ce possible d’augmenter la capacité à l’étape qui pose problème en ajoutant des ressources ?

Développer l’autonomie et optimiser les compétences :

Pratiquons l’exercice sur notre exemple de goulot d’étranglement au niveau des tests :

• Bypasser l’étape qui pose problème revient à ne plus faire de tests, ce qui est contraire aux valeurs agiles. La qualité est non négociable et ne doit pas devenir une variable d’ajustements.
• Par contre, certains développeurs, intéressés par les pratiques de tests, pourraient participer aux tests pour aider notre testeur.
• Pour monter en compétences sur les pratiques de tests, les développeurs peuvent :
  • travailler en binôme avec le testeur,
  • participer à une formation,
  • participer à la communauté de pratiques sur les tests.

Développer l’autonomie et optimiser les compétences :

• Pour atténuer le goulot d’étranglement, il est possible de mettre en place une automatisation des tests visant à accélérer le travail de notre testeur
• Enfin, pour augmenter la capacité de tests, il est possible d’embarquer dans l’équipe des testeurs supplémentaires.

Lorsque votre équipe est d’accord pour tester une solution, continuez à surveiller le goulot d’étranglement pour savoir si la solution retenue a réglé le problème ou bien s’il faut en trouver une autre.

3) Minimiser les dépendances

3.1) Dépendances entre équipes : frein à l’efficacité

Nos systèmes d’informations sont complexes donc il est impossible de construire des équipes totalement autonomes.

Par conséquent, les dépendances sont incontournables.

Il faut donc trouver des solutions pour les minimiser afin d’optimiser le flux.

Les dépendances interviennent lorsque le travail à faire par une équipe nécessite :

• Une compétence que n’a pas l’équipe
• Un travail préalable réalisé par une autre équipe
• Une autorité tierce pour accorder des droits d’accès ou valider un livrable

Les dépendances engendrent des temps d'attente importants qui nuisent à l’efficience du flux.

3.2) Pistes de solutions

Cartographier les dépendances entre équipes :

Pour identifier les dépendances entre vos équipes, vous pouvez construire un tableau des dépendances :

Ce tableau montre les User Story prévues d’être livrées par chaque équipe dans chaque itération et les dépendances associées.

Certaines User Story sont réalisables par une seule équipe (User Story #1 et User Story #3).

D’autres au contraire nécessitent la collaboration de plusieurs équipes (la User Story #4 a besoin des équipes 1, 2 et 3). 

Un suivi des dépendances tout au long du projet est fortement conseillé pour mesurer l’impact d’un retard d’une équipe sur les travaux des autres équipes.

Réduire les dépendances grâce à l’organisation des équipes :

Vous pouvez profiter des rétrospectives pour partager ce tableau et tenter de réduire le nombre de dépendances.

Réorganiser les équipes pour les rendre plus indépendantes nécessite de transférer des personnes d’une équipe à une autre. Pour cela, vous aurez besoin d’un fort soutien de la direction.

N’oubliez pas que chaque réorganisation affecte la vélocité des équipes.

Par conséquent, mieux vaut éviter de multiplier les transferts à chaque itération.

Plus simplement, préférez le transfert temporaire d’un développeur d’une équipe à une autre, pour sa compétence spécifique, le temps d’une itération.

Encourager la montée en compétences et l’apprentissage continu :

Vous pouvez aussi favoriser une culture de l’apprentissage en continu en encourageant vos équipes à acquérir des nouvelles compétences. 

Pour cela, pensez à dédier du temps à l’apprentissage dans les itérations.

Anticiper les besoins grâce à la roadmap produit :

Vous pouvez aussi demander à vos Product Owner la roadmap des prochaines itérations afin de détecter et anticiper les besoins de montée en compétences dans chacune des équipes.

4) Obtenir des feedbacks rapides

4.1) Difficulté à obtenir des feedbacks rapides et fréquents

L’apprentissage est le moteur de l’amélioration continue.

Recevoir des feedbacks et les prendre en compte est indispensable pour vous assurer que votre équipe construit le bon produit.

Obtenir des feedbacks souvent et au plus tôt aide à se prémunir des clients mécontents, des incompréhensions et du travail à refaire.

Malheureusement, l’obtention de feedbacks rapides et fréquents est souvent difficile pour ces raisons : 

• Manque d’accès direct aux clients,
• Clients accessibles mais débordés,
• Manque d’intégrations fréquentes, pourtant nécessaires pour mettre l’application à disposition des clients

4.2) Pistes de solutions

Appliquer une démarche itérative avec la roue de Deming :

Utiliser la roue de Deming (Plan – Do – Check – Adjust) et son approche itérative permet de :

• Tester des hypothèses grâce à l’expérimentation, 
• Évaluer les résultats de ces tests,
• Apprendre et s’adapter.

Favoriser des cycles courts et impliquer les clients :

Travailler avec des petits éléments permet d’itérer plus rapidement.

Pour construire le bon produit, nous vous conseillons d’embarquer vos clients en les invitant à vos démonstrations.

Poser les bonnes questions aux bons interlocuteurs :

Pour récupérer des feedbacks, assurez-vous d’interroger les bons interlocuteurs avec les bonnes questions et le bon format.

Un simple questionnaire peut parfois aboutir à des réponses peu claires et peu précises.

Observer l’usage réel sur le terrain :

Pour mieux comprendre vos clients, allez sur le terrain et observez-les dans leur utilisation quotidienne de vos applications.

N’oubliez pas de considérer à la fois les feedbacks positifs qui éclairent ce qu’il faut garder et amplifier et les feedbacks négatifs qui permettent de savoir ce qu’il faut changer ou arrêter. 

5) Travailler avec des petits lots

5.1) Difficulté à maintenir des User Story suffisamment petites

Garantir une taille petite pour vos User Story est primordial, mais ce n’est pas suffisant pour bénéficier de feedbacks rapides.

Par exemple, si votre équipe prend l’habitude de terminer chaque User Story le dernier jour de l’itération, elle réintroduit mécaniquement un lot de grande taille composé de l’ensemble des User Story.

Pour accélérer le flux, il faut donc à la fois des User Story petites et une limite sur les travaux en cours.  

5.2) Pistes de solutions

Si vous diminuez la durée des itérations, vous diminuez également la taille des lots puisque par définition, un lot doit être faisable en une itération.

Assurez-vous que les séances de Backlog Refinement sont efficaces et permettent de détecter que certaines User Story sont trop grosses.

Formez vos Product Owner aux techniques de découpage afin qu’ils rédigent des User Story suffisamment petites.

6) Réduire les files d’attentes

6.1) Des petits lots inefficaces si livrés en fin d’itération

Si les User Story sont écrites par le Product Owner plus rapidement qu’elles ne sont implémentées par l’équipe, le Product Backlog risque de grossir au point de devenir une file d’attente.

Si une application est déployée à une faible fréquence (4 livraisons par an par exemple), les User Story développées, mais non déployées constituent là encore une file d’attente.

Au final, des files d'attente peuvent se former à différentes étapes de votre flux de travail.

Les risques liés à une file d’attente trop longue sont les suivants :

• Frustrations dues aux délais importants entre l’entrée et la sortie de la file,
• Obsolescence des éléments présents depuis trop longtemps dans la file,
• Gaspillage concernant les éléments qui ne sortiront finalement jamais de la file.

6.2) Pistes de solutions

Ajuster le rythme d’écriture des User Story :

Votre Product Owner peut s’appuyer sur la vélocité de l’équipe pour caler son rythme d’écriture des User Story sur le rythme d’implémentation.

Nettoyer régulièrement le Product Backlog :

Par ailleurs, encouragez votre Product Owner à faire un ménage régulier de son Product Backlog en supprimant les éléments qui sont présents depuis plus de 6 mois par exemple.

7) Optimiser le temps d’hyper concentration

7.1) Trop d’interruptions nuisent à l’hyper concentration

Créer des produits innovants pour satisfaire nos clients requiert de la créativité et une hyper concentration.

Les membres d’une équipe font du travail de qualité, lorsqu’ils sont focus sur leurs tâches.

Un individu atteint généralement l’état d’hyper concentration après 20 minutes passées pleinement sur une tâche.

Si une interruption survient durant cet état, il faut à nouveau 20 minutes pour redevenir hyper concentré.

Ce graphique illustre le niveau de productivité d’un développeur en fonction des différents évènements qui surviennent au cours d’une journée.

Pour ce développeur, le temps passé dans la zone d’hyper concentration (productivité > 70%) est égal à 195 minutes (zones vertes sur le graphique). Soit 32,5% du temps total de la journée (600 minutes).

Il se pourrait que vous entendez vos équipes se plaindre d’avoir trop de réunions, ou que vous constatez un nombre important de travaux en cours synonymes de changements de contextes fréquents.

Il est alors temps d’investiguer pour optimiser le temps passé par votre équipe dans la zone d’hyper concentration.

7.2) Pistes de solutions

Évaluer l’efficacité des réunions :

Faites le point sur l’ensemble des réunions et évènements récurrents de votre équipe et invitez-vous à ces réunions pour en mesurer l’efficacité.

Ajuster la durée et la fréquence des événements agiles :

Revisitez la durée et la fréquence de certains événements agiles (exemple : Backlog Refinement) afin d’optimiser le temps investi.

Réduire le nombre de tâches en parallèle :

Réduisez le nombre de travaux en cours afin de diminuer les interruptions et les changements de contextes.

Limitez à un seul objectif vos itérations dans le but d'aider votre équipe à garder le focus.

8) Revisiter vos politiques d’entreprise

8.1) Un double système de gouvernance qui freine l’agilité

Une transformation agile d’entreprise dure plusieurs années.

Pendant cette période, les leaders encouragent les nouvelles manières de travailler tout en conservant par mesure de sécurité ce qui fonctionnait avant. 

Autrement dit, deux gouvernances tentent de cohabiter pendant la transformation : 

• La comitologie, les rôles et les livrables « historiques »,
• La nouvelle comitologie (événements agiles), les nouveaux rôles (Product Owner, Scrum Master…) et les nouveaux livrables (Product Backlog, Sprint Backlog…)

Le maintien de ce double système aboutit le plus souvent à des contradictions et à des pratiques contre-productives.

Voici quelques exemples de règles qui perdurent souvent dans les organisations :

• Génération de rapports d’avancements pour le management alors que les « Sprint Review » montrent le vrai état d’avancement de l’application toutes les 2 semaines,
• Maintien des revues de jalons (fin de spécifications, fin de conception…) alors que l’atteinte des jalons ne garantit en rien la réussite du projet
• Utilisation des métriques agiles pour comparer les performances des équipes et des individus

8.2) Pistes de solutions

Identifier et challenger les règles obsolètes :

En tant qu’agent du changement, vous avez la responsabilité de challenger les règles d’entreprise qui : 

• nuisent au flux de travail de votre équipe,
• mettent en évidence des gaspillages,
• sont en contradiction avec les valeurs et les principes agiles.

Comprendre l’origine des règles existantes :

Dès que vous constatez un obstacle au flux de travail de votre équipe, entamez la démarche suivante :

1. Rencontrez les propriétaires de la règle pour bien comprendre la raison de sa mise en place dans l’organisation ainsi que les enjeux métiers et réglementaires associés.

2. Mesurez l’impact de cet obstacle sur le flux de travail de votre équipe (en temps perdu et/ou en euros) pour rester factuel et donner du poids à votre argumentaire.

3. Travaillez avec le management et les propriétaires de la règle pour trouver un compromis satisfaisant qui accélère le flux de travail de votre équipe.

Conclusion

À travers cet article, nous avons adressé les 8 problématiques les plus fréquentes rencontrées par votre équipe.

Vous avez désormais des pistes de solutions pour résoudre ces problèmes et accélérer le flux.

Chaque fois que vous détectez un endroit où le flux pourrait être amélioré, prenez le réflexe de profiter de la prochaine rétrospective pour amener le sujet.

Partagez ensuite les métriques qui mettent en exergue le problème.

Enfin posez des questions puissantes pour aider l’équipe à explorer les causes racines et trouver des solutions.

Certaines de vos tentatives pour accélérer le flux de travail vont échouer et c’est normal, car nous expérimentons.

Identifiez le problème, générez des hypothèses de solutions, testez, mesurez les résultats, gardez ce qui accélère, mettez de côté ce qui freine, et répétez !