Les fonctionnalités ne sont pas spécifiées, les testeurs n’ont rien à tester, les développeurs sont débordés. Problèmes courants dans la gestion Agile d’IT, qui sont des indicateurs d’un manque de fluidité dans le processus. Si en tant que manager, vous voulez améliorer vos méthodes, les principes du Lean peuvent vous guider à optimiser votre rapport valeur/coût.
En utilisant un outil de suivi de projet, comme le Kanban, vous observez pas à pas l’avancement de vos fonctionnalités. En observant les bouchonnements, vous repérez les obstacles à identifier. C’est en ce sens que des méthodes visant à mettre en place des démarches d’amélioration continue telles que Lean et Kanban permettent de parler d’innovation en management de projets IT.
Récemment, l’IT a réussi à trouver un rythme managérial adapté à l’aspect créatif du métier. C’est ce qu’on appelle aujourd’hui les méthodes “Agiles”. Les qualités de votre produit, adaptabilité, modularité et évolutivité, deviennent celles de votre gestion de projet.
C’est très beau sur le papier… mais concrètement, ça donne quoi ?
Un ensemble de bonnes pratiques [1].
Quand on veut les appliquer, on se voit modifier son cadre de travail. Une méthode de travail typiquement « Agile » est le « Scrum » [2]. Il est assez courant de s’inspirer du « Scrum » pour en déduire un cadre de travail spécifique pour votre propre projet.
Le « Lean », comme « l’Agile », est un ensemble de bonnes pratiques.
Le Kanban, comme le « Scrum », est une méthodologie d’organisation du travail.
Apparus au Japon au milieu du siècle dernier Lean et Kanban, sont des concepts qui ont été adaptés récemment aux systèmes de l’information. Ils ont inspiré les managers « agiles » qui voulaient rendre leur processus plus fluide [3].
Différencier l’Agile et le Lean n’est pas toujours chose aisée, car ces philosophies partagent des valeurs communes. Mais ce sont bien deux mouvements différents [4].
Être « Lean », c’est prendre du recul par rapport à la gestion actuelle de son projet. C’est se placer en tant qu’observateur du procédé. Le but étant de supprimer les obstacles et améliorer le rapport qualité/prix [5].
Pour parler plus concrètement, imaginez que vous êtes gestionnaire d’une source d’eau, d’un puits par exemple. En termes Lean, l’eau est votre « valeur », c’est la richesse que vous produisez. Imaginez qu’à chaque fois que vous allez chercher de l’eau au puits, votre seau d’eau est à moitié vide. Vous avez de l’eau, certes, mais un aller-retour du seau vous coûte cher en huile de coude.
En tant que manager Lean, votre but serait de réussir à remonter un seau complet. Pour une même qualité d’eau, cela serait bien moins coûteux ! Et comme vous êtes aussi un brillant manager, vous vous penchez sur votre système. Une poulie, un puits et un seau qui monte et qui descend. Les obstacles qui entravent l’efficacité de votre récupération d’eau peuvent être divers et nombreux. Des branches mortes, une manivelle irrégulière… Pour éliminer les problèmes les plus significatifs, vous devez d’abord les repérer pour les identifier.
Avant d’éliminer un obstacle, il vous faut trouver une méthode pour déterminer la localisation des obstacles. C’est pour cela que le Kanban est apparu. Le Kanban est un outil pour faciliter la gestion de projet, rien de bien méchant.
Pour les agilistes de l’IT, il ressemble le plus souvent à un tableau de post’its. Romain Couturier l’a très bien présenté au LeanKanban14 [6] si vous souhaitez en découvrir d’avantage.
Le Kanban sert à repérer les « goulots d’étranglement » de votre projet, c’est-à-dire là où il y a perte de valeur. En ce qui concerne votre puits, c’est là où se trouve cette branche qui vous accable et qui perturbe la remontée de votre seau. La méthode consiste à observer en détail le parcours de chaque unité de valeur de votre projet. Pour votre puits, une unité de valeur est un “seau d’eau”.
Le principe est d’observer l’avancement pas à pas de vos seaux.
En observant ce qu’il se passe pour chaque étape, vous saurez où se trouve cette satanée branche bloquante. « Oh saperlipopette ! » vous exclamez-vous (oui, vous êtes très poli quand vous allez au puits). « A chaque montée de seau, à 8m de longueur de corde, je sens que j’ai des difficultés à remonter mon seau ! » BINGO, bien joué !
Ainsi, on se force, grâce au Kanban, à analyser l’efficacité de son processus.
Pour aller plus loin :
_[1] Je vous conseille de lire le Manifest Agile http://fr.wikipedia.org/wiki/Manifeste_agile _
_[2] Plus de détails sur la méthodologie Scrum https://www.scrumalliance.org/why-scrum _
[3] “Kanban, Enclenchez le Moteur d’Amélioration continue de votre IT” de David J.Anderson
_[4] “Lean & Agile, lequel choisir ?” Lucille Achard http://blog.cereza.fr/si-agilite/agilite-vs-lean-lequel-choisir-870 _
_[5] “8 règes simples pour passer au Lean IT” par Joe McKendrick http://www.zdnet.com/article/8-simple-rules-for-achieving-lean-it/ _
[6] Kanban pour tous - Romain Couturier http://fr.slideshare.net/calton13/kanban-pour-tous
