Interviews

Vous pouvez retrouver deux interviews sur le blogue de RH-Solutions.:

• 4 Conseils qui expliquent ma démarche en tant que consultant.
• Un plaidoyer pour l'agilité.

Bonne lecture!

Utilité et futilité du ROI

Le ROI où RSI quézaco ?

R.O.I signifie Return Of Investment (où Retour Sur Investissement = RSI). Ce terme est employé en premier lieu dans la finance et correspond au montant d'argent gagné ou perdu par rapport au montant d'un investissement. On parle peut être plus couramment d'un taux de rendement et donc d'un pourcentage de l'investissement sur une période donnée.

Dans l'industrie, on parle aussi de ROI pour qualifier le bénéfice attendu ou mesuré d'un investissement, qui est la majeure partie du temps un gain direct en argent ou convertible en argent comme un nombre de jours-hommes. Mais pourquoi le gain ne pourrait-il pas être aussi, l'amélioration d'un indice de confiance, de l'image de marque, de la qualité,...? Tout cela a aussi des répercussions financières dans le temps même si la finalité peut être autre ou plus large comme d'améliorer le climat social, de réduire le turnover, d'augmenter des parts de marché, de fidéliser un client, ...

Il est donc question à la fois de ce que l'on attend d'un investissement, de la finalité et de ce qui nous permettra de dire si cela a apporté le gain attendu.

Pour vendre une action d'amélioration, il est souvent nécessaire de démontrer à l'avance que l'investissement à faire en vaut la peine, qu'il rapportera suffisamment et qu'il sera relativement rapide. Combien de bonnes idées sont rejetées parce que les personnes qui les mettent en avant n'arrivent pas à convaincre, à argumenter et en particulier à donner un ROI réaliste ?

Mesurer le gain

Afin d'évaluer un ROI, il est nécessaire de définir ce que l'on va mesurer, comment, à quel endroit et avec quelle unité de mesure.

Si on a un groupe identifié qui rencontre le même problème de façon régulière et fréquente, la mesure sera assez aisée à faire. C'est comme cela que l'on peut vendre des logiciels pour améliorer la productivité: si on estime que le gain en temps par jour par personne est de X minutes, compte tenu du coût de la main d'oeuvre, on en déduit le gain pour l'entreprise. A contrario, si la perte de temps est faible, si le nombre de fois que l'opération coûteuse réalisée est aléatoire, il sera plus compliqué de justifier l'investissement.

La mesure est d'autant plus complexe si elle nécessite la participation d'autres personnes. Par exemple si on demande à plusieurs personnes de mesurer elles-même le temps que prend une opération, et que l'opération est manuelle, combien le feront de façon précise et systématique ? Dans ce cas l'automatisation de la mesure par le biais d'un outil adapté peut être une bonne approche. Mais ça n'est pas toujours faisable.

On peut être confronté à un manque d'implication de la population concernée ou à une impossibilité de l'impliquer. Si c'est le cas, quelles en sont les raisons ? L'organisation de l'entreprise favorise t-elle cela ? A t-on une culture d'amélioration continue ? S'il s'agit des clients de l'entreprise, comment peut-on avoir un retour précis ?

Une mesure statistique sur plusieurs semaines peut être nécessaire. Par exemple, supposons que la documentation d'un produit soit éparpillée sur plusieurs sites internet ou serveurs. Si on supprime les documents obsolètes, et que l'on centralise et rationalise les autres via un portail, la recherche sera accélérée et fiabilisée. Mais comment mesurer de façon fiable la déperdition avant l'amélioration?

Doit-on renoncer à mettre en place une amélioration dont le gain est difficilement mesurable, mais dont on devine qu'il est réel ?

Calculer le ROI

Il existe des cas où le ROI est assez facilement évaluable, par exemple si on simplifie le travail et que l'on supprime des tâches ou des attentes inutiles. Mais souvent le calcul est complexe parce que la mesure est complexe ou que l'on manque de données propres à l'entreprise.

L'unité de mesure du gain peut être une charge économisée, un temps d'exécution réduit, un taux de disponibilité d'une plate-forme, un nombre de problèmes résolus, une baisse du turnover dans les équipes (de la rotation de l'emploi pour parler français), etc. L'idéal est souvent de traduire en euros le gain par le biais d'une conversion, par exemple avec le salaire moyen d'un employé s'il s'agit d'un gain de temps.

Il peut être difficile d'avoir accès aux informations permettant de convertir la mesure en un coût. Qui a idée du taux d'absentéisme dans une société, de ses motifs ? Qui connaît le coût moyen d'une heure de travail avec les charges ? Qui connaît le coût de l'indisponibilité d'un service en fonction du temps ? Qui connaît les conséquences d'un défaut sur un produit sur les affaires ? Qui connaît le coût de résolution d'un défaut détecté chez le client ? Selon la personne qui initie la démarche, il se peut que ces données lui soient cachées, ou même que l'entreprise ne les ait pas.

Nous voyons bien ici, que la recherche d'une amélioration ne peut être l'affaire d'une seule personne, et ce, que ce soit pour la collecte des informations, des statistiques nécessaires au calcul du ROI, ou même de la capacité de l'organisation à adhérer à l'amélioration proposée, et à accepter ce genre de démarche.

Est-ce la bonne façon de faire?

Le bénéfice attendu va t-il être compris? Est-on en mesure d'exprimer clairement et simplement l'action envisagée et le bénéfice attendu ? Celui-ci sera t-il [suffisamment] important aux yeux du/des décideur(s)? Peut-on impliquer les parties prenantes pour avoir un retour précis de celles-ci ?

Avant de se lancer dans un calcul de ROI, il vaut mieux discuter avec les parties prenantes et en particulier les décideurs, pour identifier les attentes, les priorités de chacun. Celles-ci ne sont pas forcément partagées par tous. Qui pourra financer l'amélioration? Qui pourra en décider ? A t-on une chance de remporter suffisamment d'adhésion ? Il faut au moins pouvoir répondre à ces questions.

La recherche de l'amélioration doit elle passer par la constitution d'un dossier détaillé et complet ? Si la mesure est complexe faut-il renoncer pour autant ? Peut-on vendre uniquement des améliorations dont le bénéfice est facilement quantifiable ? Qu'en est-il avec une approche agile ou lean ? L'effort déployé ne risque t-il pas d'être trop important pour évaluer un ROI ? N'est-on pas dans un processus trop administratif ? Que faire s'il y a des freins organisationnels?

Nous verrons tout cela dans le prochain article!

Ils ont abandonné leur démarche agile!

Cela fait plusieurs fois que je rencontre une entreprise ou que j'entends autour de moi que telle ou telle entreprise, a abandonné une démarche ou une méthode agile. Certains perçoivent d'ailleurs l'adoption des méthodes agiles comme une mode passagère.

Même s'il est assez facile de comprendre une démarche, ce n'est pas pour autant qu'il est facile de la mettre en œuvre. En effet, lorsque l'on regarde de plus près ce qui se passe, on se rend compte qu'il y a plusieurs raisons à ces abandons : problèmes humains, culturels, organisationnels, compréhension imparfaite de la méthode et de ses enjeux. Ce qui se traduit par exemple, par :

• Un Scrum Master qui peine à laisser son rôle de chef de projet, pour devenir non pas d'abord celui qui décide pour les autres, mais un facilitateur.
• Des rétrospectives sans bénéfice probant que l'on finit par abandonner.

Il s'en suit une perte de motivation, et comme il est plus facile de revenir à sa zone de confort et de procéder comme avant, avec le « bon vieux cycle en V », on abandonne ces pratiques. Mais cela ne revient-il pas à faire la politique de l'autruche ?

Abandonner l'agilité c'est très souvent se priver d'outils qui justement permettent de s'améliorer progressivement.
Si on ne fait plus de rétrospective (ce qui correspond au travail d'un cercle de qualité), on se prive la plupart du temps de retours réguliers sur le fonctionnement de l'équipe, les obstacles rencontrés, ce qui fait avancer plus rapidement et plus efficacement. On perd de la visibilité, de la réactivité, et l'appréciation du fonctionnement actuel devient plus flou.

Certaines situations de crise rappellent qu'il y a des problèmes non adressés. On va les traiter de façon plus séquentielle, on ne les traitera pas forcément tous. Il sera souvent plus difficile de justifier des mesures préventives. Et surtout tout cela prendra plus de temps.

L'organisation humaine de l'entreprise, ses processus, peuvent donc être un frein à cette transition vers l'agilité. 

Conduire un changement demande de la patience, de la persévérance et du courage. Avoir conscience des raisons pour lesquelles on le fait, de leurs bien-fondés est nécessaire. Car il ne s'agit pas de suivre une mode, ou de faire comme les concurrents parce qu'ils le font. De plus si des équipes fonctionnent déjà en mode agile, nous avons vu qu'il peut y avoir des retours en arrière.
Il s'agit donc, non seulement d'accompagner le changement, mais aussi de tenir dans la durée.

Outre une formation des équipes et du management, voici quelques pistes pour perdurer dans une démarche d'amélioration continue:

• Avant de commencer une démarche, identifier collectivement les raisons pour lesquelles on s'y engage,
• Travailler sur les valeurs partagées, au besoin revenir dessus régulièrement.
• Créer une équipe qui accompagnera la transition de l'organisation, de façon légère en mode Scrum.
• Utiliser les jeux agiles afin de maintenir la dynamique et d'avancer dans le  changement.
• Continuer à apprendre de ses échecs de façon constructive.
• S'il le faut, remettre en question l'organisation, les critères d'évaluation des personnes.

Mais surtout, il faut un management impliqué qui croit en cette aventure et qui n'hésite pas à se faire accompagner.

Lean start-up réservé aux start-ups ?

Qu'est ce que le Lean start-up ?

Le Lean start-up est une méthode exploratoire de conception de produits. Elle repose sur l'idée que l'on doit se confronter au marché le plus tôt possible, pour valider les concepts, les fonctions d'un produit et ainsi progressivement construire un produit viable pour une activité durable et donc rentable.

On va ainsi concevoir un produit minimum viable, c'est à dire offrant un minimum de fonctions susceptibles de déclencher l'intérêt du client au point qu'il ne se contente pas que d'essayer le produit, mais qu'il l'achète. Ensuite, on mesure l'utilisation que les clients font du produit, et on va chercher à identifier ce qui va déclenche l'achat et maintient l'intérêt du client dans le temps.

On s'inscrit ainsi dans un processus d'apprentissage qui permet de valider ou non ce qui apporte une réelle valeur au client et donc ce qui contribue à la croissance de la rentabilité du projet. Tout ce qui n'apporte pas ou pas assez de valeur doit être supprimé. Les livraisons sont faites de façon régulière et le fonctionnement se fait en mode agile. La méthode est Lean en ce sens qu'elle utilise des outils propres au Lean comme par exemple l'analyse de la valeur, des méthodes de résolution de problèmes spécifiques.

Il se peut que l'on soit obligé de faire des changements stratégiques parce que l'on arrive dans une impasse, un marché qui n'offre pas ou plus assez d'opportunité. Dans le Lean start-up, on dit que l'important est de faire des erreurs fréquemment car on apprend plus des erreurs que des réussites.

Utilisée d'abord par les start-ups, cette méthode l'est aussi par des groupes comme Google et ce depuis plusieurs années.

Quelles applications pour qui ?

Le Lean start-up peut s'appliquer à d'autres domaines qu'à l'informatique, même si souvent  l'informatique est utilisée comme outil.

On peut par exemple fournir des services à des clients tel que du support, du SAV avec un minimum de moyens au début tout en visant le maximum d'efficacité. On va ainsi commencer avec peu de services offerts, et tester à chaque fois la valeur de tout service introduit auprès des clients. On ne gardera que ce qui apporte le plus valeur.

En s'inscrivant dans un processus où l'on commence avec peu (produit minimum viable), qui accueille le changement, qui permet d'apprendre vite, de réagir rapidement en cas d'erreur, on réduit considérablement les coûts d'investissements, et on fiabilise la recherche d'un produit et d'un marché porteur.

Toutefois il n'est pas toujours aisé de commencer avec peu. Selon le secteur d'activité, et le niveau de maturité du marché, le niveau d'exigence des clients peut être [très] élevé. Offrir un service limité avec une fiabilité modérée, peut être rédhibitoire pour les clients potentiels.

Le Lean Startup convient bien pour des innovations de rupture, celles où l'incertitude est très élevée, et où on trouvera plus facilement des primo adoptants.

L'organisation

Si l'on n'est pas une start-up, il est très probable que l'on ne puisse pas démarrer un projet selon le Lean startup avec les structures existantes. En effet au fur et à mesure de leur développement, la plupart du temps les entreprises créent des départements par spécialité: marketing, finance, commerce, R&D, support, ... Même si ceux-ci fonctionnent avec un certain niveau de collaboration, les missions et les intérêts sont différents. Les processus de décision se complexifient avec l'âge et la taille de l'entreprise, et la prise de décision en est ralentie d'autant. On en vient ainsi à des organisations qui si elles ont leur sens, sont peu agiles et peu réactives.

Vendre son produit, c'est l'exposer au marché et donc potentiellement à la concurrence qui peut avoir de plus grandes capacités techniques, financières, humaines, voire qui a déjà commencé à développer un produit concurrent. Il ne s'agit pas que d'avoir des idées de produits: la différence se fait surtout dans l'exécution des projets tant en termes de méthode que de vitesse.

Tester ses choix auprès du marché, prendre des décisions rapidement avec de petits investissements, apprendre souvent de ses erreurs est un atout pour aller plus vite que la concurrence.

Pour y arriver, on constitue une petite équipe pluridisciplinaire qui fonctionnera de façon autonome pour le projet. Les prises de décisions, le dialogue en seront facilités et accélérés. Bref cela revient à créer une start-up au sein de l'entreprise.

On considère qu'il faut en moyenne au moins un an pour définir un produit avec un marché suffisant pour générer une activité pérenne et rentable. Aussi utiliser le Lean startup n'est pas anodin. Cela demande de la persévérance, de la patience, et de la conviction et beaucoup de pragmatisme.

Dans la pratique

En tout état de cause, il est important d'avoir une vision du produit dès le début. Le Lean startup part de la vision initiale du produit. Hors cette méthode itérative peut perturber la compréhension et la clarté de cette vision. Aussi il est important de travailler dessus pour l'affiner et continuer à la partager, à fortiori si on change de cible marketing en cours de projet.

Changer de cible, faire de l'analyse de la valeur et donc mettre à la poubelle une partie du travail accompli, peut conduire à une certaine démotivation (Pourquoi fait-on cela? Finalement quel est le but?). Le marché est dur et tout le monde n'est pas prêt à s'y confronter surtout dans une phase de création de projet.

Afin d'éviter ce genre d'écueils, il me semble indispensable, qu'un travail préalable soit fait sur les valeurs partagées au sein de l'entreprise voire de l'équipe. Ensuite on peut régulièrement se réinterroger sur ces valeurs.

Une des difficultés de tout projet innovant est de trouver la cible marketing et en particulier, les primo adoptants. On peut être amené en cours de projet, à négliger des clients primo adoptants car le marché ne s'avère pas assez porteur. La relation client étant un point particulièrement sensible, il est intéressant de bien définir ce qu'est un produit minimum viable compte tenu de la cible marketing.

La culture de l'entreprise est un élément déterminant. Utiliser le Lean startup nécessite d'avoir déjà bien intégré les méthodes agiles. Hors les méthodes agiles peuvent entrer en conflit avec la culture de l'entreprise.

Enfin utiliser le Lean startup ce n'est pas utiliser une méthode que l'on déroule un peu comme une recette miracle. On apprend en pratiquant et en faisant des erreurs.

Conclusion

Se lancer dans la création d'un nouveau produit reste une activité risquée. Mais est-il possible de définir un produit qui sera suffisamment rémunérateur sans prendre de risque ? Les erreurs sont inévitables, mais que fait-on pour qu'elles aient le moins de conséquences négatives possibles et le plus de conséquences positives ?

Puisqu'on apprend plus de ses erreurs que de ses réussites, autant se donner les moyens d'identifier au plus tôt ses erreurs, et d'en tirer des leçons. C'est avec ce pragmatisme que le Lean startup propose de définir pas à pas un produit qui générera des revenus durables et suffisants pour l'entreprise.

Le Lean startup n'est pas adapté à tout type projet dans tout type de contexte et à toute entreprise. On privilégiera les innovations de rupture, les marchés peu ou pas matures et les entreprises qui ont bien intégré l'agilité.

Comme dans tout projet innovant il peut y avoir des échecs. Si le Lean start-up n'offre pas une garantie de réussite à 100%, force est de constater que cette méthode est une source d'apprentissage sans comparaison, et qu'elle peut augmenter significativement les chances de réussite.

Je vous souhaite une bonne vision!

Lorsque l'on mène un projet ambitieux, les obstacles ne manquent pas, et le tracé s'avère rarement aussi droit que prévu. Si les résultats n'arrivent pas aussi vite qu'espéré, certains se découragent et abandonnent.

Dans le milieu professionnel, l'obligation de résultat avec les enjeux financiers qui vont avec, poussent à continuer malgré tout, ce qui n'empêche pas parfois l'abandon pur et simple du projet.

Aussi, comment atteindre un objectif ambitieux, si cela implique de multiples obstacles à franchir?

Interrogeons nous sur la façon dont les sportifs de haut niveau procèdent. Ils mettent en place, souvent avec une équipe, les conditions d'une progression, avec des objectifs intermédiaires, et des décisions (hygiène de vie, alimentation, entraînement, ...). Tout cela n'a qu'un but ultime, la victoire. A chaque objectif ambitieux de la carrière du sportif, correspondra une vision qui si elle est claire et si elle lui correspond, lui permettra d'accepter de multiples contraintes, et de surmonter de multiples difficultés.

On peut adapter cela à notre propre monde professionnel, par exemple pour la gestion d'un projet en tant qu'objectif ambitieux. Tout projet repose (ou devrait reposer!) sur une vision exprimant ce que le produit ou le service va apporter, pourquoi, à qui et comment. Difficulté supplémentaire, la victoire, la réussite du projet là aussi, n'est atteignable qu'ensemble, avec tous les membres de l'équipe.

Il faut donc pour cela que la vision soit claire et partagée:

• Claire, parce que sinon, comment atteindre un objectif flou, mal défini? 
• Partagée, pour permettre un engagement et une contribution plus efficace.

Le partage d'une vision ne peut se faire uniquement par une simple communication, verbale ou écrite, car il est peu probable que l'équipe se l'approprie. C'est ainsi qu'il est fortement recommandé au début d'un projet agile de travailler avec toute l'équipe (Product Owner compris) sur la définition de la vision, avec un ou des ateliers spécifiques (L'affiche, Product Box, Product Vision Box,...). Ceci permettra à chacun d'exprimer ce qu'il comprend, d'apporter le fruit de sa réflexion, de confronter sa compréhension à celle des autres, et de se mettre d'accord sur la vision.

Acquérir une bonne vision et la partager ne s'improvise donc pas, et l'appui d'un coach en agilité peut vous y aider.

"Storytelling" ou facilitation graphique?

Vous avez peut être déjà constaté qu'il est parfois plus facile de discuter autour d'un dessin, d'un diagramme. Napoléon Bonaparte, ne disait il pas :"Un bon croquis vaut mieux qu'un long discours"?

Ce que certains appellent le "Storytelling" (encore un terme anglais!), est l'illustration par le dessin des propos d'un conférencier. Je vous donne ici un bel exemple, que vous connaissez peut être déjà. Ça va vite (peut être un peu trop!), cela parle de l'éducation, de la pédagogie. C'est intéressant dans la forme et le fond: https://www.youtube.com/watch?v=zDZFcDGpL4U

Si ce format aide à la compréhension et à fixer les idées, cet exercice n'est évidemment pas à la portée de tout un chacun. Vous avez aussi remarqué que la vitesse du dessin était bien supérieure à ce qu'il est possible de faire en temps réel.

Heureusement il est possible d'utiliser un outil plus simple, plus accessible, que l'on appelle la facilitation graphique. Le principe est de dessiner au fur et à mesure, lors d'une réunion, en fonction de ce qui se dit, afin de donner une représentation graphique des propos, des idées. Celui qui dessine, le facilitateur, le fait évidemment sur un tableau visible de tous.

Le niveau de dessin requis n'est pas important, ce qui est rassurant, car la plupart d'entre nous ont arrêté de dessiner vers 10 ans. Il ne s'agit pas de dessiner bien, mais de dessiner de façon sommaire afin d'illustrer ce qui se dit. D'abord parce que la parole va très vite, mais aussi parce qu'un dessin schématique suffit pour donner suffisamment d'informations.

Cela demande au facilitateur une bonne capacité d'écoute, et un peu d’entraînement. Celui-ci peut aussi écrire si c'est plus simple, plus compréhensible, mais il vaut mieux qu'il se limite à quelques mots.

Il est très probable que ceux qui n'ont pas été présents à la réunion, trouverons difficile de savoir tout ce qui s'est dit en regardant simplement le dessin. Mais là n'est pas l'objectif. La facilitation graphique est intéressante pour la réunion, et ne dispense pas d'écrire un compte rendu. Elle permet d'aider à clarifier un propos, mais aussi de venir en aide aux personnes qui peinent à exprimer leurs idées, ou même à s'exprimer par timidité. Enfin elle peut donner une vision plus complète du sujet abordé, pour peu que la ou les pages de dessins soient toutes rendues visibles en même temps, au besoin en les fixant sur un mur côte à côte.


Un site intéressant pour en savoir plus sur les différentes formes de facilitation, mais là les dessins sont d'un autre niveau: http://www.fgcp.net/techniques-et-medias/

Quelle méthode de gestion de projet choisir ?

La situation

La méthode classique de gestion de projet utilisée en informatique est issue du bâtiment. Elle suit le cycle en V dans lequel on définit un cahier des charges, on rédige des spécifications, puis on définit l'architecture, on fait le développement, les tests, la validation, on fait la recette et le client dit ainsi  si cela lui convient ou pas. Il existe une variante, le cycle en Y qui dissocie le fonctionnel du technique, mais fondamentalement on reste sur un fonctionnement où une fois que le client et son fournisseur se sont mis d'accord sur le cahier des charges avec le coût et les délais correspondants, le projet est lancé et ces bases ne sont plus censées varier.

Le Standish group publie depuis plus de 20 ans une étude appelée « Chaos computer » qui indique le pourcentage de projets réussis, en échec ou en dérive. Un projet réussi est un projet où les fonctions et caractéristiques attendues, ainsi que les délais et le coût répondent aux attentes initiales du client et du fournisseur. On constate que la proportion de projets réussis oscille entre 25 et 33 % et que les projets stratégiques ont encore moins de chance d'être réussis car beaucoup sont interrompus avant la fin (http://rapportsalzman.blogspot.fr/2012/05/la-gestion-de-projet-peut-mieux-faire.html).

Les raisons de ces échecs sont multiples : incompréhensions, retards, besoin du client qui évolue, changements de spécifications diverses, risques techniques et humains, manque d'outils de suivi adaptés, études amont insuffisantes... Certains projets connaissent le redouté effet tunnel:  des quantités importantes de développements restent à réaliser, et les échéances ne cessent d'être repoussées, jusque parfois à ne plus donner de date de sortie du tout.

Si l'on décide longtemps à l'avance les services, les fonctions que l'on veut offrir, il se peut bien qu'à la mise sur le marché, cela ne corresponde pas ou plus aux attentes des consommateurs / utilisateurs. Il se peut aussi que l'on n'ait pas une vision totalement claire de ce qui doit être fait dès le début. Souvent certains points ne seront affinés que durant le projet. Hors avec l'accélération de l'évolution des marchés, particulièrement depuis l'arrivée d'Internet, une grande réactivité et une bonne vitesse d'exécution des projets sont encore plus nécessaires.

Lorsqu'un changement, une décision qui en remet en cause d'autres, intervient tard dans le processus de développement d'un logiciel, son coût s'accroît de façon exponentielle. En effet, non seulement une partie du cycle devra être re-parcourue (architecture, développement, tests, validation,...), mais en plus le nombre de personnes impliquées sera d'autant plus grand que ce chemin sera long. Il en va de même pour tout bug trouvé.

Hors les méthodes de gestion de projet classiques sont peu ouvertes au changement et elles n'empêchent pas l'effet tunnel. Le Processus Unifié tente de résoudre le problème avec les itérations et les incréments. L'itération est la possibilité de reparcourir une partie du processus: par exemple en mettant à jour l'architecture alors que l'on était dans le développement proprement dit. De même, le projet peut être découpé en sous-projets qui conduisent à autant d'itérations exécutées les unes après les autres, et qui cette fois-ci parcourent chacune tout le cycle. On fait donc des livraisons successives incrémentales qui correspondent à l'ajout d'un sous-projet à chaque fois. Enfin le Processus Unifié, en se centrant sur l'architecture et la réutilisabilité, entend réduire les coûts.

Ces méthodes restent toutefois assez rigides et ne permettent pas de réduire les coûts de façon significative en particulier lors d'un changement de spécification qui intervient tard, ou de bug rencontré.

Quelques méthodes agiles

Face à ce constat, Kent Beck a créé une méthode appelée eXtreme Programming (XP) qu'il a appliquée dès 1996. L'idée est d'accueillir le changement, de permettre des prises de décision tardives, mais aussi, de reprendre toutes les bonnes pratiques du métier qui ont pu être expérimentées, et de les appliquer dans un développement informatique. Cela a donné en particulier:

• le jeu du planning pour évaluer et planifier les tâches à réaliser pour une itération.
• la recherche constante de la simplicité (analyse de la valeur).
• la programmation en binômes.
• le refactoring: afin de favoriser la simplicité, la maintenabilité et la fiabilité, on n'hésite pas à refaire une partie du logiciel, à revoir l'architecture, à supprimer le code mort ou redondant.
• l'automatisation des tests pour contrôler la qualité et maîtriser toute dérive.
• l'intégration continue pour éviter les intégrations qui n'en finissent plus mais aussi pour permettre le test régulier de la livraison complète, et ainsi contrôler toute régression.
• la mise en production le plus tôt possible pour valider le logiciel et avoir des retours.
• le stand-up meeting, qui est la réunion quotidienne d'avancement de l'équipe. Celle-ci se fait le matin et dure 15' maximum!

Une des grandes forces d'XP est que l'ensemble de ces pratiques se renforcent. Par exemple, une conception simple simplifie les tests, l'intégration, les livraisons, les retours. Le logiciel est décrit en scénarios (user stories) de petite taille plutôt qu'en fonctionnalités. Ainsi le parcours du cycle de développement est rapide, et on contrôle l'évolution du logiciel. Par conséquent le coût de tout changement de spécification est réduit.

La présence du client est requise au sein de l'équipe ! Ainsi il peut répondre à toutes les questions, clarifier ses demandes. Le client pilote davantage le projet, car on lui fait clarifier au fur à mesure ce qui doit être développé, on le fait choisir ce qui est prioritaire pour lui, ce qui donne le plus de valeur au produit à ses yeux. Le client voit ce qui est réalisable et réalisé par l'équipe à chaque itération. Tout cela contribue à construire une véritable relation de confiance avec lui.

Scrum est une méthode née officiellement en 2001. Cette méthode est faite pour tout projet technologique et donc pas seulement logiciel. 3 rôles principaux sont décrits: le Product Owner qui dit ce qu'il souhaite voir implémenter, l'équipe de développement, et le ScrumMaster qui agit pour améliorer le processus, le produit, le fonctionnement et le niveau de l'équipe.

Comme dans XP, on travaille à optimiser la prise en compte de tout changement afin d'en réduire le coût et de maximiser la valeur du produit. Les livraisons se font régulièrement à l'issue de chaque itération appelée sprint, ce qui contribue à éviter l'effet tunnel. Scrum intègre des pratiques du Lean et d'XP. Par exemple:

• La mêlée quotidienne correspond au "stand-up meeting" d'XP.
• Le tableau kanban qui permet de visualiser l'étape dans laquelle se trouve un scénario utilisateur où user story (A faire/En cours/Terminé), vient du Lean. 

De plus, en informatique, il est recommandé de reprendre des pratiques d'XP comme l'automatisation des tests et l'intégration continue.

Kanban est une méthode qui date des années 50, qui fait partie des pratiques du Lean. Si elle a été utilisée en premier lieu dans l'industrie automobile, elle est aujourd'hui mise en œuvre dans l'informatique. Cette méthode se concentre sur la gestion du système de production, afin d'en optimiser la capacité et de livrer en continu des éléments de travail (fonction, bug fix,...). Cela commence par formaliser le processus de production. Kanban utilise le management visuel notamment en mettant en place dans la salle de l'équipe, le tableau kanban visible de tous, qui indique ce qui est planifié, en cours et réalisé.

Un des changements les plus radicaux est le passage au flux tiré : désormais l'équipe ne prendra une nouvelle tâche que si elle en a la capacité, le but étant de faire des livraisons régulières et d'optimiser l'efficacité de l'équipe. Il n'y a pas d'itération planifiée comme avec Scrum. Kanban s'adapte bien aux projets en maintenance ou aux longs projets de développement. On peut envisager son utilisation pour une activité de support.

Enfin Scrumban est une combinaison de Scrum et de Kanban : on utilise Kanban pour la gestion des user stories et pour fluidifier la production. On garde la gestion par itérations/sprints, mais on détaille les différentes étapes par lesquelles chaque user story passera. On dessine donc un tableau, avec une colonne par étape, par exemple avec les colonnes: A faire, Développement, Intégration, Validation, Fait. Cela permet de détailler le processus de production, parfois même de le formaliser! C'est aussi très utile pour détecter et prévenir des situations de famines ou de surcharge dans une étape.

Scrumban est recommandé par rapport à Scrum, si l'équipe contient des personnes spécialisées dans des domaines particuliers (3D, tests, par exemple). Le logiciel peut aussi imposer que certaines étapes soient gérées par un nombre très restreint de personnes à la fois, comme pour l'intégration par exemple.

Conclusion

De plus en plus d'entreprises optent pour une méthode agile pour éviter l'effet tunnel, et améliorer les chances de rentabiliser leurs projets. Cela nécessite des compétences: les équipes doivent être formées, et les rôles définis par la méthode choisie, doivent être respectés. En effet les rôles et les processus diffèrent de ceux auxquels on est habitué.

Les méthodes agiles sont adaptées dans un contexte changeant où certaines décisions peuvent être prises tardivement et peuvent éventuellement en contredire d'autres. La méthode choisie peut ne pas être adaptée, par exemple à cause de la taille de l'équipe: avec XP l'équipe de développement ne dépasse pas les 10 personnes.

Il s'agit de rester pragmatique avant tout. Certaines pratiques peuvent être mises en place très rapidement. Mais il y a un réel changement culturel à opérer, et la migration vers une méthode agile n'est pas instantanée, ni semée d'embûches, aussi il vaut mieux être accompagné dans cette démarche.