Les méthodes agiles gagnent en popularité ces dernières années. Elles ont su séduire les entreprises par leur capacité à s'adapter à un marché mouvant, leur force reposant sur l'acceptation des changements. Elles ont aussi su séduire les équipes de développement qui y voient une valorisation de leurs compétences et une mise en avant des bonnes pratiques d'ingénierie.
Cependant adopter ses méthodes est bien souvent un exercice périlleux. Une transition mal abordé peut entrainer un rejet pur et simple des valeurs agiles.
Je vous propose un petit tour d'horizon des différentes façons d'aborder les transitions agiles avec l'aide de retours d'expériences glané à droite à gauche et j'aborderais mes propres retours d'expérience au dernier chapitre.
La première chose dont il faut se rendre compte avant de commencer, c'est que les méthodes agiles entrainent bien souvent une mutation profonde de l'organisation. Le mot "transition" ici est important, on passe d'un état à l'autre et il est courant que cette phase soit sous-estimé.
Pour Pyxis sous-estimer les impacts de cette transition fait d'ailleurs partie des 8 façons de rater la mise en place des méthodes agiles :
Pyxis range ces raisons dans deux catégories, les impacts organisationnels :
et les impacts humains :
Avant de démarrer une transition, il est important d'évaluer le contexte actuel pour pouvoir choisir la bonne façon de faire.
Claude Aubry propose une méthode visuelle très simple. L'idée étant d'évaluer le contexte selon certains critères :
et de les noter pour créer un kiviat de transition :
Certaines contraintes imposeront d'aborder la transition de façon différentes par la suite. Par exemple une équipe ayant une faible capacité en ingénierie de développement devra peut être d'abord se focaliser sur les pratiques d'ingénierie.
Un petit point de vocabulaire tout d'abord. Lorsque la volonté de transition vient de la hiérarchie, on parle d'approche top-down.
A l'inverse si l'initiative vient d'une ou plusieurs équipes, on parle d'approche bottom-up.
Bien évidemment les approches pour aborder une transition agile dépendent dans un premier temps du contexte (bottom-up ou top-down).
Par exemple une approche Big-bang sera plus facile à envisager si la démarche est initiée par la hiérarchie.
Pour aborder le virage aux méthodes agiles, on entend souvent parler des deux approches différentes :
(Vu par exemple au Sigma Tour : http://www.sigmat.fr/public/SigmAgileTour/AgiliteEnSituation.pdf)
L'approche Big Bang comme son nom l'indique consiste à faire évoluer radicalement l'organisation dans un laps de temps très court.
Cette approche repose sur un un engagement fort de la hiérarchie. Elle part du principe qu'en allant plus vite on fait émerger plus rapidement les bénéfices et que l'on évite de prendre de mauvaises habitudes de transition.
On évite de plus une cohabitation des processus trop longue.
Par contre une approche de ce type peut être risqué car la conduite du changement est concentré sur un petit laps de temps. Cette approche est couteuse (utilisation de coach externe, formations, disfonctionnements du à la transition amplifié par le timing etc...). Le stress induit par le changement sur les individus peut aussi être rédhibitoire et provoquer un rejet.
Exemples d'entreprises ayant choisi cette approche :
Le principal argument en faveur de cette approche repose sur le fait qu'une transition longue a plus de chance de s'essoufler en route et d'entrainer de mauvaises adaptations. Voir à ce sujet l'article de Claude Aubry : Transition rapide et radicale
La méthode du projet pilote consiste à choisir un projet pour l'expérimentation et d'appliquer la méthodologie sur ce projet pour l'adapter au contexte avant la diffusion au reste de l'entreprise.
La transition est moins risqué, les erreurs portent uniquement sur le projet en question. Les membres du premier projet seront par la suite des ambassadeurs de la méthode.
Cependant, un projet pilote peut ne pas être représentatif (on pourra toujours argumenter qu'il s'agissait d'un projet facile s'il réussit).
Une transition de ce type est plus longue et demande plus d'adaptations et de compromis sur le processus au risque de la dénaturer et de diffuser par la suite de mauvaises pratiques.
L'article suivant met le doigt sur le principal défaut de cette méthode.
En utilisant un projet pilote au sein d'une organisation non agile, on accepte des compromis car la structure autour du projet est resté inchangé :
etc...
Le principal risque étant que ces compromis restent par la suite et seront catalogués "méthode agile" même s'ils en contredisent l'esprit.
Au dela de ces deux approches, Mike Cohn va plus loin dans l'article suivant : "Patterns of Agile Adoption" :
Il parle de trois dimensions qui se recoupent :
On peut en effet se focaliser des pratiques d'ingénierie logicielle à travers des concepts XP (TDD, tests unitaires) par exemple ou bien se concentrer uniquement sur l'aspect méthodologie (équipes projets, collocalisation etc...).
Il est intéressant de noter la troisième dimension. Dans une entreprise dont la culture d'entreprise est frileuse à accueillir le changement, une approche plus discrète sera en effet plus simple. A l'inverse, dans une entreprise où la communication est importante, une approche trop discrète pourrait passer comme un manque d'engagement et de clarté.
Dans tout les cas, un accompagnement externe est bien souvent nécessaire (formations externes, accompagnement sur place pour la mise en place des pratiques etc...).
L'accompagnement que peut proposer une société externe peut prendre différentes formes :
Dans un accompagnement externe cependant, il est important de bien cibler l'objectif attendu et de valider fréquemment la direction choisie (par des rétrospectives régulières par exemple).
Un mauvais accompagnement ou un accompagnement mal ciblé peut entrainer un rejet de la méthode par les équipes.
Pour ma part, j'ai pu connaitre deux transitions dans des contextes très différents.
Pour le rendre visuel, j'ai utilisé les kiviats présenté par Claude Aubry en rajoutant un critère très important, notamment sur la seconde transition : la résistance au changement.
Cet élément n'apparait pas dans les critères proposés par Claude. Sans doute parce que ce n'est pas très politiquement correct de présenter ce type d'informations à sa hiérarchie lorsque l'on fait son évaluation. Difficile d'indiquer dans son graphique que certains éléments vous ont fait penser aux irréductibles gaulois dans Astérix et Obélix. Cependant il est inévitable d'en tenir compte, même s'il faut l'enrober différement quand on le présente.
La première transition s'est effectué chez un éditeur de logiciel. Ici j'ai été impliqué en tant que membre de l'équipe et le changement a été initié par un responsable d'équipe (bottom-up).
Les projets impliqués dans la transition reposaient sur des nouvelles technologies. Il s'agissait de projet interne avec une forte criticité. Le nombre de personne impliqués était faible (10 personnes) avec un peu d'offshore. La gouvernance était complexe.
On peut le symboliser sur le kiviat suivant :
La bonne capacité de l'équipe, la qualité de l'architecture et la faible taille de l'équipe a permis de rapidement mettre en place des pratiques d'ingénierie forte :
De plus, les projets étaient menés par des équipes pluridisciplinaire avec une vision claire des objectifs.
Cependant plusieurs éléments négatifs sont venus géner la mécanique :
La transition s'est donc cantonné à l'équipe en elle-même ce qui a tout de même permis de conserver des bonnes pratiques de développement et a eu de très bons impacts sur la qualité.
La seconde transition qui est toujours en cours a été initié par la hiérarchie. Cette fois-ci j'officie en tant que coach agile.
Les projets sont assez critique et le nombre de personnes impliqués dans la transition est assez important (> 25 personnes). La méthode de gouvernance utilisé auparavant était très directive, laissant peu de place à l'autonomie. La capacité des équipes sur les pratiques d'ingénierie est relativement basse (pas de tests unitaires, manque de séparation des couches par endroits etc...). Le système est de plus assez complexe avec une partie de nouvelles technologies, du mainframe, de l'éditique, du datawarehouse etc...
L'approche retenue a consisté à utiliser des projets pilotes qui ont servi de modèle par la suite pour démarrer sur des projets plus critiques. Les pratiques d'ingénierie n'ont pas été poussés dans un premier temps.
Avec le recul, il aurait sans doute été préférable d'avancer par petits pas pour améliorer le process progressivement. Le trop grand décalage entre la cible et la situation actuelle implique trop de stress pour les équipes. Même si, pris un par un, l'ensemble des participants sont unanimes pour décrire tout les disfonctionnements de la situation actuelle, accepter tout les changements d'un coup est trop douloureux.
A mon humble avis, plus la transition est lente, plus le risque de faire des compromis augmente et plus l'amalgame risque de durer dans l'esprit des gens entre ces fausses bonnes pratiques et la cible. Dans ce cas là, autant adopter une approche discrète, centré sur l'amélioration progressive du processus actuel et ne parler de méthode agile qu'une fois que les équipes ont suffisament avancé pour l'accepter volontairement. C'est d'ailleurs ce que propose Mark Levinson ici .
Cette approche plus pragmatique permet aussi d'éviter d'opposer sans arrêt un côté très puriste de la méthode (qui effraie par son côté secte parfois, il faut bien l'avouer) aux opérationnels qui ne jurent que par l'expérience du terrain.
Cf. la démonstration de cet article, à jongler entre le refus du compromis et le trop de compromis on s'épuise vite ^^