Voici un article publié dans l’ouvrage collectif Rupture Douce #2 en 2013 et qui reste d’actualité pour découvrir de façon ludique la différence entre Kanban, Scrum et le Waterfall.


Le lièvre, la tortue et l’escargot

Commençons par revisiter la fable du lièvre et la tortue, en y ajoutant un troisième personnage qui vient redéfinir les règles du jeu : l’escargot. L’idée est d’illustrer les différents modes de gestion du temps dans l’organisation des projets informatiques.

Le lièvre Waterfall : prise de risque maximale

Le lièvre de la fable est à l’image d’une organisation classique des projets informatiques dite « Waterfall ». Il commence normalement sa course, ensuite il se repose sur ses lauriers et fini en en retard et en panique, par manque de temps pour finir tout ce qu’il a commencé !

Cette organisation de projets se déroule en un long enchaînement de phases. Préparation de l’ensemble des plans dans une première phase, puis engagement dans l’ensemble des développements, et enfin, tests et livraison (mise en production). Comme l’illustre aussi l’histoire « Larguez les amarres » cette méthode d’organisation des projets est semble-t-il logique. Tout l’enjeu est de ne pas se tromper dans ses plans, ni dans l’estimation du temps de réalisation.

Chaque jour de retard pris à la conception est un jour de retard pour l’ensemble du projet, et de même pour chaque phase. Ainsi comme dans le bâtiment on finit bien souvent par avoir des projets d’un an qui sont livrés avec un an de retard.

Depuis bien des années ce type de fonctionnement est connu pour faire prendre à l’ensemble de l’entreprise un risque maximum d’échec, tant que le projet n’est pas terminé, l’entreprise n’a rien acquis. Et en attendant, tout repose sur la confiance que l’on a sur les capacités à accélérer à la fin si besoin. Malgré tout, ce mode d’organisation reste le mode d’organisation standard, car faire un cahier des charges, répondre à un appel d’offres, sélectionner un prestataire sur le coût global d’un projet est tout à fait naturel.

Synthèse : Le Waterfall avec sa date de livraison unique et son déroulement en phases séquentielles expose le projet à un risque énorme d’échec. C’est malgré tout encore le mode d’organisation standard voir culturel de nombreux projets. La date de fin est l’élément qui porte le risque majeur, au bénéfice du coût global.

La tortue Scrum : agile mais stressée

La tortue serait Scrum qui fonctionne a son rythme et qui « patte » après « patte » se dirige vers la ligne d’arrivée. La stratégie pas à pas est de rythmer le travail de l’équipe en itérations successives de quelques semaines qui permettent à l’équipe de réaliser un élément fini. A la fin de chaque livraison, l’avancement est démontré. Le projet avance en prenant le temps de redéfinir sa direction à chaque itération.

Scrum, dans la lignée des méthodes agiles est née il y a plus d’une dizaine d’années de la réflexion d’acteurs du domaine informatique. Leur but avoué était de retrouver du plaisir à travailler en reprenant le contrôle de l’organisation de leur travail, tout en s’attachant à satisfaire au mieux leurs clients.

Mais deux éléments vont stresser notre tortue :

  • Les dates de livraison. En y regardant de plus près on se rend compte que la tortue a principalement découpé les grands projets en plein de petits projets (ou lots), définis au fil de l’eau. Ces lots restent dans la même pratique de planification à date (tous les mois), et d’optimisation de l’utilisation des ressources. La date de fin d’itération reste un événement à ne pas rater.
  • L’enchaînement livraison/démarrage. Et plus encore l’enchaînement rapproché livraison/démarrage pour le projet ressemble à une course à étapes qui, si vous ratez une arrivée, va perturber le démarrage de l’étape suivante.

Pourquoi du stress ? Tout simplement parce qu’elle reste dans le triangle des Bermudes de la planification de projet :

  • Délai fixé : date de livraison.
  • Ressources fixées : les équipes ne varient pas en taille.
  • Contenu fixé : chaque itération est un lot défini.

Ces trois paramètres ne peuvent pas être fixés tous les trois en même temps. Il y en a obligatoirement un qui va varier. Ce qui dans notre cas est principalement la date au sein d’une itération. Soit l’équipe fini plus tôt car elle a fini plus vite que prévu, soit elle fini en retard et se retrouve régulièrement à la peine.

Les symptômes de ce stress sont une agitation plus forte que d’habitude au moment de l’enchaînement des itérations. Finir un chantier, livrer le produit, le montrer au client, recueillir des retours, prendre commande des tâches suivantes. Voilà qui fait beaucoup d’activités différentes à gérer en très peu de jours.

A bien regarder notre chère tortue Scrum avancer, on sent que le passage d’une patte à l’autre n’est pas une mince affaire ! Mais tout comme dans la fable elle arrivera bien avant le lièvre.

Synthèse : Cette approche dite Agile apporte énormément de flexibilité aux projets qui viennent d’un mode de gestion dite Waterfall, et un cadre de fonctionnement sain pour les projets sans pratique initiale. Elle évite le risque d’échec complet, en fonctionnant par de courts cycles qui sur la durée restent difficiles à enchaîner.

Kanban l’escargot : il est déjà arrivé !

Notre troisième personnage est un escargot qu’on appellera Kanban. Il est bien sûr bien plus lent que la tortue, et ne risque pas de la doubler. Mais il gagne quand même. Alors comment fait-il ?

Il triche bien sûr ! Il se poste dès le début sur la ligne d’arrivée, et exécute de petits cercles continus en passant mille fois la ligne d’arrivée le temps que le lièvre et la tortue arrivent. Ce qui dans notre analogie avec les développements informatiques revient à livrer ses tâches une par une dès qu’elles sont prêtes. On est bien d’accord qu’il ne suit pas les règles du jeu, mais il faut bien qu’il se serve de ses propres qualités, et la sienne c’est : passer son temps à finir.

En prenant un peu de recul, on peut observer que nombre de développements informatiques modernes  opèrent sur des systèmes déjà en production. Chaque nouvelle tâche pourrait généralement être livrée indépendamment des autres, alors à quoi bon regrouper les développements en lots et se stresser à les livrer tous en même temps pour une date définie plusieurs semaines à l’avance ?

Ainsi pour les système qui peuvent être mis en production de manière continue il est possible de dire à son client : le « dès que j’ai fini une de vos commandes je vous la livre ». Il n’y a plus de date de livraison car c’est en permanence, la mise en production devient un non-événement. 200 fois par jours chez GitHub, 20 fois par jour pour Etsy me dit-on à l’oreillette !

L’escargot fonctionne en continu, pas de changement d’une patte à l’autre, pas de surcapacité à gérer. Il s’occupe simplement de faire des petits tours et ajouter pas à pas des éléments au système. Il profite de la modernisation des développements informatiques et des logiciels, ainsi que des techniques de mise en production qui permettent une organisation en flux continu. Ce serait vraiment dommage de s’en passer.

La morale officielle de l’histoire :

« Un bon usage de la lenteur peut rendre votre vie plus riche et plus productive ». (Carl Honoré)

La morale officieuse de l’histoire :

« L’escargot est un tricheur », oui, pourquoi ne pas tirer partie des outils et des pratiques modernes et rester avec des outils voire des règles d’organisation d’un autre âge ? Pourquoi ?

Partant de ce constat il me reste à vous faire découvrir ce nouvel univers de la lenteur productive où livrer est plus important que commencer, et se promettre de finir à l’heure n’est même pas une question.

Rendre le temps au temps

Optimiser ses ressources et mourir  !

L’optimisation du système de production est le cœur de notre sujet, l’optimisation des coûts nous pousse à essayer d’occuper les gens le plus possible, et de s’assurer qu’ils ont un planning complet pour les semaines à venir. Mais paradoxalement vouloir occuper tout le monde génère un embouteillage monstre, justement au moment où on a besoin de ressources. Pourquoi ?

Une illustration classique de ce phénomène est la circulation autoroutière. Plus on charge une autoroute de voitures roulant à 130 km/h, plus elles se rapprochent les unes des autres. Le débit augmente, et tout se passe bien, mais à partir d’une certaine charge une simple perturbation (freinage, changement de file) peut engendrer un ralentissement brutal de l’ensemble du système. Il faudra des heures pour le relancer.  Ce phénomène arrive aussi pour l’organisation du planning des équipes de développement. A vouloir optimiser l’occupation des ressources on ne laisse plus de place au système pour respirer, et à la moindre anomalie il se bloque. Plus encore il mettra beaucoup de temps à retrouver un rythme normal.

Pire encore, les développements informatiques sont un ensemble de constructions uniques, donc d’une charge très difficile à estimer. La variabilité dans le temps de réalisation d’une tâche est importante par nature. C’est un aspect fondamental dans la gestion du temps des projets informatiques. Et cette variabilité naturelle devient un poison pour le remplissage des plannings. C’est fort bien démontré dans ce contexte par Don Reinertsen dans son livre « Product Development Flow ». Il démontre même que les principes industriels de « zéro stock » ne sont pas forcément une bonne idée du fait de cette forte variabilité. Il nous enseigne qu’il faut créer et entretenir des files d’attentes pour alimenter de façon stable des postes de travail (conception, développement, tests).

En résumé :

Laissez le système respirer, et préparez-vous à l’alimenter en fonction de son appétit !

La conservation du mouvement

Observez le rythme de travail de votre équipe sur plusieurs semaines. Ce rythme est régulier ? La plus grande valeur est délivrée au plus tôt ? Les décisions sont prises en regard du fonctionnement réel de ce qui a déjà été produit ?

Démarrer et arrêter des chaînes de production est extrêmement perturbant, et source d’incertitudes en nombre. Chaque livraison est un mur potentiel, si elle est unique (mode Waterfall), une marche (mode agile itératif) qui génère un stress non négligeable à l’équipe, et surtout un énorme changement de rythme. Il faut tout finir en même temps, puis totalement se remobiliser pour entamer le prochain cycle.

L’approche Kanban en multipliant les livraisons (en faire un non événement) est là pour mettre en place un rythme de travail qui correspond à un optimum de productivité de l’équipe sur un très long terme. De plus la limitation de l’encours aura une tendance forte à stabiliser le système en cas de perturbation.

La dynamique du mouvement devient un facteur de qualité de l’équipe, elle doit bien faire attention à cet élément trop souvent bâclé. On parle de rythme soutenable, de flux continu, de régularité.

La lenteur productive est bien là, chercher un optimum ne veut pas dire chercher un maximum. Connaître et observer son rythme idéal, savoir stabiliser ce rythme devient une compétence fondamentale d’une équipe pour qu’elle puisse durer. Et évidemment ce n’est pas lent en soi, c’est juste plus lent que le maximum pour garder ce rythme sur la durée.

Kanban ré-inventé

Kanban est une pratique ancienne héritée du monde industriel que des personnes comme Don Reinertsen ou David Anderson ont expérimenté jusqu’à découvrir et décrire très précisément une utilisation adaptée à l’univers informatique. Cette pratique de Kanban se trouve être assez différente du monde industriel, tout en conservant l’approche et certains outil.

Leurs trouvailles en terme de gestion du temps :

1 – Mesurer le temps de cycle (définition à venir) permet de se focaliser sur la production de valeur de l’ensemble de la chaîne (client, équipe, produit).

2 – Une fois que le rythme de la chaîne est mesurable on peut travailler à sa stabilisation avec différentes techniques (limitation de l’encours, files d’attentes, … )

3 – La mise en place d’un flux tiré se révèle être formidablement efficace pour stabiliser cette organisation, et se résume en une phrase emblématique :  » Commencez par finir, finissez par commencer « .

Ils nous ont appris à prendre le temps de finir, et regarder le temps qui s’écoule plutôt que le temps prévu.

Mesurez le temps de cycle

Mesurer le temps de cycle revient à déclencher un petit chronomètre dès qu’une nouvelle fonctionnalité d’un produit démarre et l’arrêter quand elle est en production. Et cette mesure ne tient pas compte du nombre d’intervenants, des activités annexes, elle mesure juste le temps qui passe.

Regardez les toutes petites tâches d’un projet, qui prennent une heure ou deux à un développeur pour être réalisées. Combien de temps mettent-elles à passer de l’état de demande à l’état « en production » ? Souvent plusieurs semaines ! Alors qu’elles pourraient avoir une grande valeur ajoutée pour le produit fini. Si le système ne s’organise pas pour les réaliser très simplement et rapidement, ces tâches auront un coût de gestion très supérieur à leur coût de réalisation : coût d’encombrement dans le planning, coût de stress quand elles sont nombreuses, coût pour délivrer en urgence.

Une fois cette mesure du temps de cycle en place, il devient possible de matérialiser les principaux défauts (tâches courtes ayant mis un temps anormalement long, ou tâches similaires mettant des temps très différents pour être réalisés).

Si l’on sait que dans 90% des cas les tâches sortent en moins de 2 semaines, il n’est plus nécessaire de se battre sur un planning, on peut se concentrer à bien ordonner la demande, et aider à valider les livraisons.

Le pilotage et la gestion du temps s’en trouvent radicalement modifiés, il faut un temps d’adaptation mais vous verrez que ça devient très naturel.

Limitez l’encours

Comment fluidifier les développements ?

En limitant le nombre de tâches dans un même état (à faire, en cours, en test, …), vous forcez l’équipe à d’abord faire avancer ces tâches avant de pouvoir en commencer de nouvelles.

C’est simple à comprendre, mais plus difficile à réaliser. L’éloge de la lenteur productive se cache exactement ici. En réduisant le nombre de tâches en cours, vous en favorisez l’aboutissement, et par la suite la réalisation des suivantes.

La limitation de l’encours a une tendance vertueuse à la résolution de problèmes. Un petit exemple : Quand un trop grand nombre de développements sont terminés sans être testés, la limitation de l’encours va empêcher le démarrage de nouvelles tâches et rendre disponible les développeurs pour aider à la validation des tâches.

Derrière ce mécanisme assez anodin, voire dérangeant au premier abord, se cache toute une théorie de la gestion des flux. Savoir entretenir la capacité d’un système est un art bien difficile.

Maintenant vous êtes sensibilisé à Kanban, n’oubliez pas son leitmotiv :

Commencez par finir, finissez par commencer !

Mes 3 clés

  • Aidez le système à trouver son rythme
  • Limitez l’encours, vous finirez plus tôt
  • Faites de la mise en production un non-événement

Références