Et mon flux, c'est du goulet?

Initialiser à une démarche Kanban est simple. Il n'y a qu'à lire les principes du Kanban:

1. Visualiser le processus
2. Limiter le travail en cours à la capacité de l’équipe
3. Mesurer et gérer le flux de travail
4. Rendre les caractéristiques du processus explicite
5. S’améliorer de manière collaborative

C'est tellement simple qu'on le fait déjà avec les méthodes agiles:
On visualise donc notre processus avec un tableau kanban (avec un petit k) et on met des limites sur les états de notre processus: un tableau de taches et un nombre limité de points de complexité pour l'itération, défini par l'équipe. On partage la définition de prêt et de fini avec toute l'équipe. Et on s'améliore au rythme des rétrospectives.
Pas de quoi s'affoler donc! On fait déjà tout ça avec l'agilité. Y a qu'à même dire qu'on fait tous du Kanban.
D'ailleurs, au dernier sondage du French SUG, 28% des interviewés annonçait en faire.
En passant, 14% annoncent faire du Lean Software Developpement. Merci les gars pour la vanne, ça détend!

Alors que vient faire le principe "Mesurer et gérer le flux de travail" dans tout ça?
On passe à un développement en flux, au-delà du flux de valeur ou du flux de travail. Mais de manière étonnante, je n'ai pas trouvé ou retenu (mais toi lecteur, peut-être en connais-tu?) de bonne définition du développement en flux bien que différents auteurs en parlent sur les thèmes du Lean Software Developpement, du Kanban bien sur, du Scrum Ban, ... et bien sur dans le livre de Reinertsen sur le développement en flux de produit.
Cela revient à travailler sur une pièce en continue, l'unité de travail, qui va constituer le flux :

Ensemble d'éléments évoluant dans un sens commun

Et qui apporte de la valeur et faire en sorte qu'elle parcourt notre processus de réalisation le plus vite et de manière la plus fluide possible.
A l'usage, le fait qu'elle apporte de la valeur n'est pas techniquement le plus important pour mettre en place du flux, c'est plus que cet élément soit un vecteur de communication pour tous les acteurs, qu'il fasse sens pour chacun pour que cette unité soit adoptée par tous. Cal va donc dépendre de votre contexte bien sur, histoire utilisateur, cas d'utilisation, ticket d'incident, anomalie, ... et de votre granularité MMF, MVP, ...


Essayer de passer à un développement en flux change la donne et c'est difficile. Pour y arriver on va parler de choses que l'on connaît déjà : taille des batchs, limites sur le TAF, cadence, mais également de file d'attente, de buffer, de variabilité, de synchronisation...
Et effectivement, cela nécessite une mesure et un contrôle différents à la fois plus élémentaire, en suivant le temps de cycle de chaque pièce; régulier en contrôlant le débit du flux, facteur de santé du flux; et plus global avec les courbes de valeurs cumulées (suivi cumulé du nombre de pièces dans mon système par état) pour une analyse plus systémique.
Et là, les modèles de type Théorie des contraintes vont nous être bien utile pour comprendre et améliorer.

Alors, pensez-vous développer en flux?
On peut effectivement faire du Kanban sans développement en flux et rester sur un système tiré. La mécanique Kanban permet cela. Et le Lean également:

Flow is important. Leveling, flow when you can, pull when you can't. [...] But that's just technique, it's a way to reveal problems, nothing more.[The Lean Manager p 33]

Mais pour avoir pu mettre en place du flux à plusieurs reprises, c'est un outil d'apprentissage réel et un révélateur d'obstacles et d'opportunités d'amélioration bien plus important que le système tiré, et qui demande une discipline au quotidien. Et c'est bien sa finalité de contrainte le système toujours un peu plus pour apprendre et s'améliorer.