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.