1) Sortir la tête de l'eau avec Kanban

Dans l'exemple précédent (Faires des économies en investissant) nous avions une équipe de développement qui était littéralement la tête sous l'eau et qui courait après le planning.

Comment est-il possible de sortir d'une telle situation? Pour retrouver une certaine maîtrise du planning on va chercher à connaître :

• Le fonctionnement et les limites de l'équipe: le(s) processus suivi(s), les compétences, la disponibilité de ses membres sur le projet,
• Les limites du produit en terme d'architecture et de bugs au regard des demandes faites,
• Les dysfonctionnements s'il y en a,
• Les interlocuteurs avec lesquels l'équipe interagit: leur rôle, leur compétence.

Il y aura probablement des actions à réaliser au sein de l'équipe, mais aussi vis à vis de l'extérieur. En effet on peut distinguer différents flux dans cette équipe : des flux entrants – les demandes et les retours sur le produit [suite aux livraisons], et des flux sortants – ce que l'équipe produit.

Ici tout se passe comme si l'équipe était un barrage avec un lac de rétention. S'il pleut (donc s'il y a des sollicitations), le niveau du lac de rétention a tendance à monter. Hors plus il pleut plus le niveau monte vite et plus il y a de débris, de troncs d'arbres qui vont boucher les entrées du barrage et l'empêcher de délivrer la même quantité d'eau. Autrement dit plus les flux entrants sont nombreux et impactants et plus la performance de l'équipe va en pâtir.

S'il est possible d'améliorer le fonctionnement en interne, cela demandera un investissement pour un résultat à moyen terme, donc une baisse de performance dans un premier temps. L'équipe fonctionnant dans un écosystème, il faudra le faire accepter. En outre cet investissement ne suffira pas la plupart du temps.

L'enjeu pour l'équipe est donc aussi de réguler les flux entrants – les sollicitations, afin d'être en mesure d'atteindre une performance optimale. Pour cela elle doit aussi être capable de dire à quelle cadence elle peut travailler, et donc à quelle cadence elle peut livrer. Mais livrer quoi ? Les livrables n'auront pas tous la même taille, le nombre de fonctions, de bugs corrigés varie.

Nous allons utiliser une démarche Kanban afin de mieux définir ces notions. Cela va nous aider aussi à opérer un renversement de la perspective : plutôt que de ne travailler qu'en fonction des sollicitations – « en flux poussé », on va fonctionner en fonction de ce que l'on peut livrer – « en flux tiré ».

Suite au prochain article.

Faire des économies en investissant

Vous avez peut être déjà rencontré ce genre de situation :

• D'un côté le commercial est insatisfait de l'équipe de développement, car ils ne livrent pas dans les délais et de façon satisfaisante. Il est tenté de les croire inefficaces voire incompétents. Pour rattraper les affaires non rentables, il facture au prix fort certaines prestations.
  

• D'un autre côté, l'équipe de développement (R&D) râle après le commercial, car il vend des affaires qui ne leur conviennent pas en terme de contenu technologique (car ils en maîtrisent mal certaines), de charges, de délais.

On voit bien que cette situation a des effets pervers, notamment:

• L'image de l'entreprise vis à vis des clients est dégradée, car elle ne tient pas souvent ses engagements, et certains services sont surfacturés.
• Les relations sont tendues, et un climat de défiance et de frustration règne, ce qui favorise le turn over et la baisse d'efficacité des personnes.
• L'équipe de développement sont mis dans une logique d'échec.
• Le commercial de son côté n'est pas forcément plus à l'aise car sa confiance dans les équipes de développement est faible. Lui aussi est entraîné dans cette logique d'échec. Il doit faire face au mécontentement des clients et a l'impression de se débattre relativement seul

Quelles actions pourraient permettre de sortir de cette spirale ? Est-il possible d'obtenir une amélioration substantielle sans investissement important ou sans générer une dérive des coûts et du retard sur les projets ?

Comme il y a plusieurs problèmes à régler, il va falloir procéder par étapes. Voilà pourquoi une réponse possible passe par l'utilisation d'outils issus du Lean. On va donc:

1. Faire un bilan des projets sur une durée significative.
2. Se donner des objectifs
3. Dégager les améliorations les plus prioritaires.

Faire un bilan des projets sur une durée significative

Le bilan des n derniers projets permet de voir ceux qui ont été rentables, ceux qui ne l'ont pas été et de combien. Difficile de rentrer dans les détails à posteriori; cela dit on peut déjà avoir une idée du sérieux de la situation notamment en terme de coût et d'image auprès des clients. Un bilan de chaque projet fait au fur et à mesure apporterait certainement bien plus d'informations. Ceci va permettre de justifier l'investissement fait en améliorations, car il est illusoire d'espérer une amélioration si on ne fait rien.

Se donner des objectifs

Il s'agit de savoir où l'on veut être dans 6 mois, 1 an et ce qu'on est prêt à investir. La question se pose en priorité à la hiérarchie, car de son implication et de son approbation dépend le succès. 

Revenir à une rentabilité correcte demande du temps, surtout si les équipes sont noyées sous les tâches à réaliser. On peut fixer des règles d'emblée (respecter l'évaluation des équipes de développement, valider le contenu technologique d'une offre), mais il faudra assumer les conséquences immédiates. Hors on n'est peut être pas prêt à de tels changements.

Dégager les améliorations les plus prioritaires

On constitue avec toutes les parties prenantes une liste des objectifs principaux à atteindre. On en déduit des points d'améliorations, qui permettrons d'atteindre progressivement ces objectifs. Un médiateur (le consultant?!) aidera à faire ces listes de façon non personnelles afin de sortir du conflit, mais aussi de sorte à ce que les points d'améliorations soient suffisamment réalistes, précis et simples. On affinera par la suite au fur et à mesure les points retenus et au besoin on les découpera en plusieurs points d'améliorations.

Une fois les objectifs principaux fixé, on ordonne les points d'améliorations par priorité. On doit s'accorder sur la mesure et le critère de réussite de chaque point d'amélioration, et ce au fur et à mesure qu'ils seront retenus.

En fait on procède par itération:

• Avant chaque itération, on nettoie la liste des points d'amélioration, on la met à jour par priorité et on affine les points susceptibles d'être pris lors de la prochaine itération.
• Lors de la réunion de fin d'itération on fait le bilan du ou des points d'améliorations. On peut en dégager d'autres points d'amélioration, ou décider d'en découper un qui s'avère trop gros.
• Lors de la réunion de début d'itération on choisit les prochains à mettre en œuvre pour l'itération suivante et on fixe la date du prochain point.

Attention à ne pas vouloir trop en faire: il vaut mieux se limiter par exemple à un ou deux points d'amélioration par équipe par itération. Sinon on risque de se disperser, de trop impacter les projets en cours, et de ne pas améliorer grand chose dans les temps fixés.

Conclusion

Cette démarche présente plusieurs intérêts :

• Elle implique toutes les parties prenantes,
• Elle leur ouvre les yeux sur les besoins et la complexité du métier des autres parties,
• Elle va permettre d'avoir des signes encourageants assez rapidement, ce qui aura un effet positif sur le moral et la motivation.
• Elle permet de mesurer le progrès réalisé notamment sur un plan financier,
• Elle contribue à rétablir la confiance et de s'inscrire dans une logique de réussite! 

Elle est conforme au Kaizen, un outil du lean qui signifie « amélioration continue » en Japonais. On la retrouve dans certaines méthodes comme Scrum (méthode agile de gestion de projet). D'ailleurs ce projet d'amélioration est pleinement compatible avec cette méthode.