C’est une sacrée promesse ça, d’arriver à développer un logiciel juste avec des posts-it. On va parler de gestion de projet, de la méthode Kanban mais aussi de Scrum.

Et oui, il faut bien ça pour mon premier article invité. 😉

Ceux qui baignent dans le monde de l’agilité me voient venir avec mes gros sabots (on a vu mieux niveau discrétion). Je vais bien sûr parler de la méthode Kanban. Et plus particulièrement de la méthode Kanban appliquée aux projets IT, comme un développement de logiciel.

Si je suis souple … Je suis agile ?

Petit rappel rapide pour ceux qui découvrent l’agilité (bandes de petits veinards) :

L’agilité, c’est un concept à la base de plusieurs méthodologies de gestion de projet qui a été créé en 2001, en partant du constat que le cycle de développement traditionnel des logiciels ne correspondait plus aux contraintes et aux exigences du marché.

Si je devais résumer l’agilité, je dirais que c’est l’envie de faire autrement, d’apporter de la flexibilité dans sa manière de travailler afin de s’adapter aux défis du quotidien.

Cette philosophie Agile se développe de plus en plus dans le monde du développement et de l’IT car cela permet :

• De gagner en réactivité face à des besoins qui changent et évoluent constamment.
• De faciliter au quotidien le dialogue et la collaboration entre les équipes, et entre les développeurs et les utilisateurs. Le logiciel final sera ainsi de bien meilleure qualité qu’avec les méthodes de gestion de projet traditionnelles.
• De se concentrer sur la qualité du développement du produit.

Si vous souhaitez aller plus loin, j’aborde en détail dans cet article les 12 principes de l’agilité, qui sont à la base de toute méthodologie de projet Agile, y compris la méthode Kanban, que l’on va disséquer ensemble.

A vos scalpels ? prêt ? Partez !

Kanban : c’est quoi cette bête-là ?

Cette étrange bête est née au Japon chez Toyota, dans les années 1950, avec pour objectif d’améliorer la gestion de la production en flux tendu.

Kanban est un terme japonais qui veut dire « étiquette ».

Alors pourquoi ce nom ?

Revenons sur notre ligne de production chez Toyota.

D’un côté nous avons une ligne d’assemblage, de l’autre la zone de stockage. Et Toyota faisait face à un problème vieux comme tout le monde (et qui existe toujours aujourd’hui) : La gestion de l’offre et de la demande.

Autrement dit : comment faire pour produire assez afin de ne pas être en rupture de stock et de pouvoir répondre à la demande, mais sans produire trop pour éviter d’avoir des coûts de stockage trop importants et des invendus ?

La réponse de Toyota a été de mettre en place des Kanban, des étiquettes, qui voyageaient entre les postes de production aval (à la fin de la chaîne) et amont (au début de la chaîne) pour indiquer quand fabriquer une nouvelle série de pièces.

Cela a permis :

1 ) De limiter l’en-cours du stock, et donc de limiter les coûts de stockage.

Imaginons que mon stock ne peut stocker que 10 voitures. Lorsque toutes les places sont prises, je n’envoie aucune « fiche » (ou étiquette) à la ligne d’assemblage. Donc logiquement, elle arrête de produire puisqu’il n’y a plus d’ordre de production.

Dès qu’un véhicule est vendu à un client, une place se libère. Le gestionnaire du stock envoie donc un nouveau Kanban (une nouvelle fiche) à la ligne d’assemblage, qui démarre la production d’une nouvelle série de pièces.

2 ) D’éviter le gaspillage de matière première si un défaut est constaté en aval sur une série de pièces.

Il arrive parfois qu’un défaut se glisse dans un lot de pièces. Exactement comme un bug logiciel.

Lorsqu’une pièce est terminée, elle passe dans les mains du « contrôle qualité » avant d’aller séjourner au stock.

Imaginons qu’on a 100 pièces à produire :

• Avec la méthodologie de projet traditionnelle, on produirait les 100 pièces, on fournirait le lot entier au contrôle qualité, qui noterait le défaut. Résultat : les 100 pièces partent à la poubelle, et il faut tout recommencer. Perte de temps et d’argent pour l’entreprise.

• Avec la méthodologie Kanban, lorsque la première pièce atteint le contrôle qualité, l’équipe d’assemblage travaille sur la seconde pièce. Quand le défaut est remarqué, les 2 pièces partent à la benne. Et c’est tout.

On gagne ainsi en réactivité, on économise de la matière première, on évite de faire 2 fois le même travail.

Bref, que des avantages.

3 ) De fonctionner en flux tendu et de faire en sorte que tout le monde ait quelque chose à faire sur la ligne d’assemblage.

Le pire sur une chaîne d’assemblage serait que des personnes se tournent les pouces en attendant qu’un nouveau lot arrive. Ou que d’autres subissent une surcharge de travail d’un coup. C’est un manque d’efficacité flagrant, et c’est totalement aberrant pour une chaîne de production.

En fonctionnant en flux tendu, chacun travaille sur une pièce à un moment donné.

Lorsque C a fini sa pièce il l’envoie au contrôle qualité, B transmet sa pièce à C, A transmet sa pièce à B et en commence une nouvelle.

4 ) De visualiser les points de blocage sur la ligne.

Pour que les choses fonctionnent bien en flux tendu, il faut éviter les points de blocage, donc éviter les surcharges de travail.

L’avantage de Kanban est qu’il permet visuellement de voir rapidement le point de blocage sur la chaîne de travail, pour y apporter des corrections.

Comment ?

Il se suffit de regarder le nombre de fiches empilées. Si le tas augmente ou dépasse un nombre fixé en avance c’est « alerte rouge » !

Kanban est une méthode de management visuel des tâches qui a fait ces preuves.

5 ) D’être hyper-réactif et d’adapter l’offre à la demande.

Ainsi même en cas de confinement prolongé, et de chute drastique et immédiate de la demande de nouvelle voiture, Toyota peut être réactif et diminuer ou stopper sans attendre la chaîne de production.

Le projet sauce Kanban

Alors là vous allez me dire : « C’est bien beau tout ça Thibault, mais tu nous parles voiture, assemblage, chaînes de production et compagnie, mais nous on est développeurs, alors bon comment ça marche pour nous » ?

Et bien plutôt que de gérer les flux de production, on va gérer les flux d’un projet, à savoir les tâches à traiter et développements à réaliser. Tout ça pour réaliser une livraison rapide et continue. La méthode s’adapte sans problème aux évolutions du besoin, aux changements, aux imprévus. Et en plus elle permet de visualiser d’un coup d’œil des tâches à réaliser, en cours, terminées, et des éventuels points de blocage.

Bref, ça correspond totalement à l’agilité, et c’est parfait pour développer un logiciel.

Alors, comment ça marche ?

1 ) Par où commencer ?

Le mieux pour commencer c’est de réunir l’équipe, et de se mettre devant un tableau blanc.

L’objectif est de représenter votre flux de travail via un tableau, chaque colonne correspondant à une étape du projet.

Un tableau Kanban est composé au minimum de 3 colonnes : « A faire », « En cours », et « Terminé ».

Dans la plupart des cas de développement d’un logiciel, un tableau Kanban aurait 5 colonnes et ressemblerait à celui-ci :

• « Tâches » : Liste de toutes les tâches à réaliser sur le projet
• « A faire » : Liste des tâches à réaliser sur le court terme (dans la semaine par exemple)
• « En cours » : Tâches commencées par l’équipe
• « A tester » : Développement terminé, en attente de test utilisateur 
• « Terminées » : faut-il vraiment que j’explique le principe de cette colonne ?

2 ) Comment gérer les tâches ?

Chaque tâche est représentée par un post-it, qui navigue de la colonne la plus à gauche vers la colonne la plus à droite. Avec une limite importante : une tâche ne peut jamais revenir vers la gauche !

Là vous allez me demander « quoi mettre sur les posts-it ». Et bien, ma réponse est la suivante : toutes les informations nécessaires à la réalisation de la tâche. C’est à décider en équipe.

Personnellement, j’aime bien avoir sous les yeux les infos suivantes :

• « Titre de la tâche » : qu’est-ce qu’il faut faire ?
• « Date d’arrivée sur le tableau » : cela me permet de voir combien de temps nous avons mis pour traiter la tâche, pratique pour faire des stats.
• « Catégorie » : j’aime bien utiliser les couleurs de post-it pour catégoriser mes tâches. Ça peut aussi bien être « 1 couleur = 1 personne » que « 1 couleur = 1 type de tâches ».
• « Affectation » : qui doit traiter la tâche

3 ) La limitation de la quantité de travail

Là où Kanban devient intéressant, c’est qu’on doit poser une limite de quantité de travail afin de ne pas surcharger les équipes.

En pratique, on va poser un « en-cours » sur chaque colonne. Imaginons qu’on a 3 testeurs : L’en-cours sera généralement de 4 (3 +1 étiquettes).

Concrètement cela voudra dire qu’il ne peut pas y avoir + de 4 tâches dans la colonne « A tester », et il faudra attendre qu’une place se libère pour y faire glisser une nouvelle carte.

Si on a un point de blocage sur les tests, on aura donc :

• 4 tâches dans la colonne « A tester »
• Les tâches dont le développement est terminé et qui sont « à tester » s’accumuleront dans la colonne « En cours » jusqu’à atteindre la limite d’en-cours.
• Ce qui fait que l’équipe de développement ne pourra plus prendre de nouvelle tâche à développer, qui s’accumuleront alors dans la colonne « A faire ».

On voit bien que l’en-cours aura un impact sur l’efficacité et la performance de l’équipe de développement : un en-cours trop faible créera un point de blocage qui n’a pas lieu d’être. Un en-cours trop élevé surchargera de travail une équipe.

Partez pour commencer sur un en-cours de x personnes +1, et voyez ce que cela donne dans l’équipe.

Après tout, l’avantage de Kanban c’est que rien n’est figé dans le marbre, et qu’on peut tout faire évoluer.

4 ) Et l’amélioration continue dans tout ça ?

Comme je viens de le dire, avec Kanban rien n’est figé dans le marbre, tout est sujet à amélioration.

Le gros avantage de Kanban par rapport aux autres méthodes c’est que c’est visuel : ça permet de voir rapidement ce qui fonctionne de ce qui ne fonctionne pas. Et donc ça permet de s’améliorer.

Kanban s’articule en 2 phases :

• La première : la visualisation des méthodes de travail actuelle.
• La deuxième : l’amélioration continue, grâce aux boucles de feedback.

« Attends, attends tu me parles de quoi là, c’est quoi ce terme » ?

Chaque fin de semaine, on se réunit en équipe, on observe le tableau, on observe ce qui s’est passé dans la semaine, et on en débat pour trouver des axes d’amélioration à mettre en place sur la semaine suivante :

• Y a-t-il eu un point de blocage cette semaine ?
• Les en-cours ont-ils été atteints ?
• Y a-t-il eu des tâches bloquées ? Pour quelles raisons ?
• Comment fonctionne le travail en équipe ?
• Pourquoi telle tâche stagne-t-elle dans cette colonne ?
• Pourquoi cette tâche qui a X semaines n’est pas terminée ?

Ainsi on s’améliore chaque semaine, on devient de plus en plus efficace tout en gardant une visualisation sur la charge de travail en cours et à venir.

Quels outils utiliser ?

Depuis tout à l’heure je vous parle de tableau blanc et vous vous demandez pourquoi je n’ai pas encore abordé les logiciels permettant de travailler en mode Kanban ?

Pour la simple et bonne raison que le tableau blanc est la meilleure manière de démarrer. Une collection de posts-it colorés c’est plus visuel que des cartes virtuelles sur un logiciel.

Et aussi parce que votre tableau Kanban ne sera jamais optimal du premier coup. Il va évoluer, en fonction de vos axes d’amélioration, de vos feedback hebdomadaires.

Côté logiciel je vous recommande chaudement Trello, qui s’adapte parfaitement à la méthode Kanban. Vous pouvez consulter cet article sur leur blog qui indique étape par étape comment mettre en place un tableau Kanban dans Trello.

Scrum versus Kanban : quelles différences ?

Malgré que ces deux méthodes soient agiles, elles sont fondamentalement différentes dans leur conception.

Scrum est une méthode rythmée par des sprints, qui se déroulent généralement entre 2 et 4 semaines. Lorsqu’un sprint est commencé en Scrum, il n’y a aucune possibilité de l’ajuster ou de le faire évoluer, il faut aller au bout. En démarrant le sprint, l’équipe de développement prend un engagement de livraison du nombre de fonctionnalités qui sont dans ce fameux sprint dans le délai du sprint.

Du côté de Kanban, on gagne en souplesse : il n’y a aucune notion de sprint. Tout est axé sur un flux continu de tâches et sur l’amélioration continue. On peut donc prioriser de nouvelles demandes sans aucun souci. Il n’y a pas de contraintes de temps avec la méthode Kanban : on tire les tâches une à une, comme on l’a vu ensemble plus haut.

Quand utiliser Kanban ? et quand utiliser Scrum ?

Alors au final vous allez me demander quand choisir l’une ou l’autre de ces méthodes. N’est-ce pas ?

Généralement, on choisit la méthode Kanban pour des projets qui impliquent de nombreux changements, et on choisit Scrum pour des projets plutôt stable.

Par exemple, Kanban est tout adapté lorsque l’on a des difficultés à estimer des délais, lorsqu’on a un périmètre qui évolue fortement du jour au lendemain, et aussi lorsqu’on veut favoriser la collaboration dans l’équipe.

Pour un projet de développement bien cadré, avec peu d’évolutions, Scrum est tout adaptée.

Enfin, notez bien que Scrum impose un cadre supplémentaire par rapport à Kanban : si l’équipe n’est pas familière avec les méthodologies Agile, Scrum sera plus simple à mettre en place que Kanban.

Et n’oublions pas que les deux méthodes peuvent aussi se compléter !

Au final, le choix de la méthode se fera en fonction de l’équipe et devra s’adapter à celle-ci. Le mieux que je puisse vous recommander est de tester les deux, et de voir laquelle vous convient le mieux.

Conclusion

Kanban est une méthodologie de gestion de projet Agile que je vous recommande d’essayer soi en alternative à Scrum, soit en complément : on parlera alors à ce moment-là de Scrumban.

C’est une méthode simple à mettre en place et qui apportera des résultats rapides, mais j’insiste sur un point : il faut l’adapter aux besoins de l’équipe et à la réalité du terrain. Et l’améliorer, toujours, tout le temps. Ce qui veut dire prendre le temps d’analyser régulièrement son tableau Kanban avec l’équipe, et prendre le temps de mettre en place des axes d’amélioration.

C’est à ce prix que l’on peut travailler en agilité.

Chef de projet et manager depuis + de 10 ans & Trello addict, Thibault a géré des projets IT complexes à plusieurs millions d’euros. Il a décidé de dépoussiérer la gestion de projet sur son blog www.reussirsesprojets.com.

Son objectif ? Donner les clés pour piloter des projets avec efficacité, et atteindre les résultats souhaités. Tout en travaillant intelligemment et en cherchant toujours à s’améliorer.