La transformation agile n’est pas un long fleuve tranquille !
Pour réussir une transformation agile, il faut l’anticiper et travailler sur plusieurs points. Ces points sont :
- La formation des futures équipes aux méthodes et à la philosophie agile
La première chose à faire est de s’assurer que les membres des futures équipes agiles soient formés à la méthode qui sera utilisée mais surtout à la philosophie agile.
Comme expliqué dans le chapitre sur le rôle du testeur agile, un membre d’une équipe agile, et même toute personne travaillant avec cette équipe, doit être capable de penser en produit. Le mode de pensée en projet avec des engagements précis à long terme sont contreproductifs en agile. Ils sont même une raison fréquente de l’échec de ces changements.
La formation ne se fait malheureusement pas uniquement avec des certifications. Faire des ateliers agiles avec les membres de la future équipe est complémentaire et au moins aussi efficace. L’atelier « le jardinier agile », par exemple, est un atelier très efficace pour comprendre la vision produit.
Enfin, la formation à elle seule ne suffit pas : il faut non seulement comprendre « l’état d’esprit » nécessaire à la réussite des projets en mode agile, mais aussi adhérer à cette philosophie, ce qui inclut une préparation.
- La préparation des futurs membres des équipes agiles à travailler dans des équipes pluridisciplinaires
Savoir comment fonctionne l’agilité, avoir intégré ses principes et sa philosophie n’est malheureusement pas suffisant (même si cela reste un point très important). Les futurs membres de l’équipe (ce qui inclut les testeurs) vont devoir se préparer à travailler dans une équipe pluridisciplinaire… ce qui revient à dire qu’ils vont devoir se préparer à ne pas travailler uniquement sur leur spécialité mais également sur ce pour quoi ils sont le plus utiles à l’équipe.
Les développeurs vont sûrement faire du test, les testeurs des spécifications et/ou du développement…
De même, les membres de l’équipe vont devoir s’habituer à converser directement avec des personnes qui ne font pas le même métier qu’eux (les silos entre ces les différentes équipes ne seront plus présents).
Pour assurer une bonne cohésion dans cette équipe, il faudra développer des compétences en « T », c’est-à-dire que chaque membre devra être capable de faire des tâches basiques normalement dévolues à d’autres métier (un développeur : exécuter des tests, un testeur : écrire une spécification ou développer des fonctionnalités basiques, etc.). Cette montée en compétence permettra de mieux comprendre les contraintes et besoins des autres métiers mais facilitera également la communication, chaque membre ayant une idée plus précise des problématiques techniques liées au métier de chacun.
Enfin, cette préparation théorique est rarement suffisante pour créer un esprit d’équipe. La mise en place d’ateliers ou de moments d’échanges permettant aux futurs membres de l’équipe de se connaître, de se comprendre et de se faire confiance, est toujours un plus non négligeable.
- La formation des managers à ces méthodes et à l’évolution de leur rôle
Cette partie est trop souvent oubliée. Elle reste cependant essentielle. Le manque de préparation/formation des managers est une raison courante de l’échec de la mise en place des projets agiles.
Voici des questions courantes que les managers peuvent se poser :
- Comment puis-je gérer une équipe pluridisciplinaire ?
- Comment m’engager sur des résultats quand c’est l’équipe qui doit décider elle-même ?
- Comment rendre des comptes sur l’avancée du projet ?
- Quelle est ma place dans cette organisation ?
- Qu’attend-on de moi ? Suis-je encore utile ?
Toutes ces questions sont légitimes et traduisent une non-adaptation du manager à l’environnement agile. Le manager non accompagné dans la transformation agile va continuer à penser et travailler comme il le faisait avec les méthodes traditionnelles. Il va donc vouloir avoir une activité de suivi engageante, vouloir montrer des résultats… Bref, il continuera de penser en projet. Or, l’agilité c’est la fin de la pensée « projet » et l’avènement de la pensée « produit ».
Un manager / un chef d’équipe voit son rôle évoluer. Il doit donc lui aussi évoluer dans sa manière d’agir mais surtout dans sa manière de penser. Le chef d’équipe doit se muer en facilitateur, permettre aux équipes de travailler dans les meilleures conditions en apportant à l’équipe écoute, aide et conseils. On parle généralement de « servant leader », c’est-à-dire quelqu’un qui est là pour aider, appuyer, encourager son/ses équipes… Ce rôle peut être comparé à celui d’une enzyme dans une réaction chimique. L’état initial et l’état final sont (quasiment) les mêmes, l’enzyme a en revanche permis à la réaction d’aller beaucoup plus vite.
De plus, chaque « chef d’équipe » va se retrouver avec « ses » ressources dispersées dans diverses équipes agiles. Les chefs d’équipe devront donc se préparer à voir leur travail au jour le jour évoluer fortement.
Prenons l’exemple d’un chef de projet test (test manager). Ce dernier ne s’occupe plus (ou très peu) de diverses activités comme :
- Estimer le coût d’un projet : c’est le testeur agile qui estime le coût des User Story
- Travailler sur la « stratégie de test » (niveau projet) : c’est le testeur agile qui prend cette responsabilité avec l’équipe agile. Il est même possible de faire le rapprochement entre Definition of Done et stratégie de test.
- La coordination des activités de test : là encore, c’est le testeur agile qui a ce rôle dans une équipe agile.
- Contribuer à améliorer les processus de test : dans une équipe agile c’est l’équipe, à travers les rétrospectives, qui effectue ce travail. Néanmoins, le chef de projet test peut proposer des processus communs, voire « clé en main ». Ces processus peuvent en revanche être adaptés par chaque équipe en fonction des besoins spécifiques, l’important étant de garder une base commune.
- Evaluer la qualité du produit : c’est là aussi l’équipe agile qui est responsable de la qualité. Elle s’appuie sur le testeur agile pour déterminer et communiquer cette qualité.
Le chef de projet test ne se retrouve pas au chômage, loin de là ! Il a des responsabilités qu’il avait déjà et d’autres qui apparaissent avec cette nouvelle méthode de travail. On peut citer par exemple :
- Travailler à garder le sentiment d’appartenance des testeurs agiles à l’équipe test (par exemple en proposant des projets transverses)
- Travailler à avoir une « base commune » aux testeurs dans les différentes équipes agiles (outils, documents types, élaboration de la stratégie, processus, etc.)
- Gérer les ressources : il est plus compliqué de gérer 15 fois 1 testeur plutôt qu’une équipe de 15 testeurs.
- Assurer la montée en compétences et le partage de connaissances/retours d’expérience des différents membres de l’équipe.
En agilité j’aime parler de « rôle » du chef de projet test. Avec les équipes agiles, le chef de projet test se retrouve dans un environnement différent. Dans cet environnement, il est entouré de « mini chefs de projets test » (les testeurs agiles). Son rôle s’oriente alors légèrement vers plus de coordinations et d’aide au partage de connaissances, des bonnes pratiques et des retours d’expérience.
Le métier de chef d’équipe a donc toujours de beaux jours devant lui (même en agile !), et, même si les membres de l’équipe agile prennent une partie du rôle qui leur était attribué dans les méthodologies classiques, les chef d’équipes / les managers restent très importants.
- Implémenter l’agilité au fur et à mesure en proposant un projet pilote
Cette partie est constamment rappelée lorsque l’on parle de transformation agile. Une transformation « Big Bang » est rarement une réussite. Si l’on veut réussir une transformation il faut savoir avancer étape par étape. Il faut d’abord former. Il faut ensuite s’attacher à convaincre. Pour comprendre cela, rien ne vaut un exemple.
Il est préférable, pour démarrer dans une méthode agile, de prendre un projet « moyen ». Ici, « moyen » signifie que le projet garde un degré d’importance non négligeable mais qu’il n’est pas trop important en terme d’investissement.
Le « projet » se transforme alors en POC (Proof Of Concept), en prototype de l’agilité pour l’entreprise et permet d’acquérir de l’expérience, d’essuyer les plâtres et de permettre une transformation plus aisée des autres équipes.
Il faut également se rappeler que la synchronisation entre une équipe agile et des équipes fonctionnant encore en cycle en V se révèle souvent compliquée. Je pense notamment à des problèmes comme :
- L’équipe du cycle en V qui n’arrive pas avoir la modification immédiate demandée car on est en cours de sprint (pour la méthode Scrum).
- L’équipe agile qui se plaint de ne pas pouvoir faire de démo car elle est en attente de la livraison d’une fonctionnalité qui a pris du retard dans un projet en V
- L’équipe agile qui ne peut pas livrer rapidement car elle doit attendre des « slots » trimestriels de livraison…
Afin de limiter ces effets, il est préférable d’avoir un projet qui est le plus indépendant possible.
Un autre axe essentiel dans la sélection du projet/produit pilote est la sélection des membres de l’équipe associée à ce produit. Cet axe, qui est trop souvent ignoré, est peut-être le plus important. C’est l’axe humain, choisir les bonnes personnes, au bon moment.
Le manifeste agile ci-dessous a été créé par des développeurs expérimentés :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
Comme l’écrit le manifeste : les individus, les logiciels opérationnels, la collaboration et l’adaptation sont mis en avant.
Néanmoins, les processus et outils, la documentation, les contrats et les plans ne sont pas non plus oubliés et restent important.
Afin de réussir à suivre efficacement ce manifeste il faut des personnes ayant assez d’expérience pour connaitre l’intérêt de chacun de ces points afin de savoir jusqu’à quel niveau il faut user des processus, outils, documentation…
Une équipe agile pour un projet pilote se doit donc d’être une équipe composée de personnes expérimentées et matures. L’idée de mettre uniquement des ingénieurs fraîchement sortis de l’école pour commencer dans l’agilité s’avère (quasiment) toujours être une erreur fatale au produit/projet.
Le projet pilote ne peut fonctionner qu’en choisissant un projet et une équipe appropriée.
- L’industrialisation de l’agilité
Après avoir franchi toutes les étapes précédentes (formation de l’équipe et du manager, préparation des équipes (état d’esprit) et la réalisation d’un projet pilote), il est alors temps d’industrialiser !
L’industrialisation ne peut se décréter et se faire comme en mode Big Bang et ce, même après avoir bien suivi le « mode d’emploi » donné dans le reste de ce chapitre. Les 4 premières étapes, bien que nécessaires, ne sont que le début d’un long processus de transformation qui peut prendre des mois voire des années, en fonction de la taille des équipes.
Le projet pilote et, plus particulièrement, les membres de l’équipe pilote, ont un rôle primordial. Ils doivent notamment permettre de repérer certaines difficultés et résoudre les causes racines de ces problèmes. L’équipe pilote doit ensuite proposer un retour d’expérience continu.
Son rôle ne s’arrête pas à proposer ce retour d’expérience et à « essuyer les plâtres ». En effet, l’équipe pilote a au moins une autre responsabilité tout aussi importante ; celle de répandre la « bonne parole », d’accompagner les nouvelles équipes dans la transformation, de leur faire partager leur expérience, tout en laissant les nouvelles équipes apprendre par elles-mêmes. Cette responsabilité de l’équipe montre encore l’importance de bien sélectionner les personnes qui intègreront cette équipe.
Attention, l’équipe pilote seule ne peut rien. Afin de réussir une transformation agile, il faut aussi avoir un vrai soutien de la hiérarchie, des managers. Hiérarchie qui doit donc être prête à s’adapter à ses nouveaux rôles.
Une méthode efficace pour généraliser l’agilité est d’intégrer des personnes dans l’équipe pilote et d’en faire des membres de l’équipe pendant quelques mois. Ces membres intégrés (ou simplement membre originels de l’équipe pilote) pourront ensuite être des référents dans de nouvelles équipes agiles et faire comprendre l’état d’esprit attendu par l’agilité.
Conclusion :
Être agile ne se décrète pas. Une transformation agile réussie n’est pas simple et il existe de très nombreuses équipes nommées « agiles » qui, dans les faits, ne le sont pas du tout.
Afin d’être agile il faut avoir le bon état d’esprit, changer de manière de penser. Pour cela, la formation, la preuve par l’exemple mais aussi un vrai travail de fond est nécessaire. Ce travail est un travail qui se fait à moyen, voire à long terme. Il reste néanmoins primordial afin de ne pas se retrouver dans une méthodologie de travail reprenant les défauts des méthodes classiques et agiles sans pour autant avoir une seule de leurs qualités.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
