Agilité “Canada Dry”

 

L’”Agilité” est un terme très en vogue en ce moment parmi les grands comptes du secteur tertiaire. Chacun affirme la mettre en place « à l’échelle », et être mature dans ses pratiques. Mais, à y regarder de plus près, on s’aperçoit d’un puissant effet Canada Dry ! Ça ressemble à de l’Agile, mais ça n’en n’est pas ! Comment éviter les échecs de la mise en place d’une organisation de travail en méthode agile ?

Rappel : L’agilité en quelques mots

L’agilité, et plus spécifiquement Scrum, repose sur un manifeste de 4 valeurs et 12 principes :

Les valeurs à retenir sont les suivantes :

 

• Les individus et leurs interactions plus que les processus et les outils.
• Un logiciel qui fonctionne 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.

Les principes fondamentaux :

• La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
• Accueillir positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
• Livrer fréquemment un logiciel opérationnel avec des cycles courts.
• Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
• Des acteurs motivés ! Environnement et soutien nécessaire. Faire confiance pour atteindre les objectifs fixés. Dialogue en face à face privilégié.
• Un logiciel opérationnel est la principale mesure d’avancement.
• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
• Equipes auto-gérées
• Amélioration continue (vélocité de l’équipe)
• Objectifs réalistes, rythme soutenable : Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Dans ce cadre-là, une équipe Agile est constituée, d’un PO (Project Owner), d’un scrum master et de membres d’équipe.

Le PO définit les fonctionnalités du produit. Ses fonctions sont :

• Choix de la date et du contenu de la release
• Responsable du ROI
• Définition des priorités dans le backlog en fonction de la valeur métier
• Ajustements permanents des fonctionnalités et des priorités.

 

Le scrum master est un facilitateur, et le garant du suivi de la méthode. En aucun cas il n’est un chef de projet ! Ses fonctions sont :

• Responsabilité de la bonne application par l’équipe des valeurs et des pratiques Scrum
• Résolution des problèmes
• Assurance que l’équipe est complètement fonctionnelle et productive
• Facilitation de la coopération poussée entre tous les rôles et fonctions
• Protection de l’équipe des interférences extérieures

 

Une bonne équipe :

• Regroupe tous les rôles : Architecte, concepteur, développeur, spécialiste IHM (Interaction Homme-Machine), testeur, etc.
• Est, de préférence, à plein temps sur le projet.
• Est autonome dans son organisation

L’échange est un atout primordial dans l’utilisation de SCRUM, il faut donc impérativement veiller au bon dialogue au sein des équipes. Une équipe trop grande amène souvent plus de dissensions que d’approbations.

L’absence de hiérarchie (imposée par la fonction) entre les membres est primordiale pour libérer la parole.

Enfin, pour finir ce rappel, un petit mot sur Kanban. Alors que Scrum s‘attache à suivre des tâches unitaires d’élaboration d’un produit (par exemple une tâche pour la conception, une nouvelle tâche pour le dev, une autre tâche pour les tests…), Kanban s’attache à suivre l’élaboration du produit par ses changements de phases (la tâche passe en conception, puis la même tâche passe en dev avant de passer en phase de test…). Les processus d’évaluation de l’avancement du projet et de la vélocité de l’équipe sont alors complètement différents.

Il faut donc prendre garde à ne pas confondre ces deux approches agiles.

 

Mais qu’en est-il réellement au quotidien ?

 

Au cours de mes différentes missions chez de grands acteurs de la finance, j’ai pu constater des dérives par rapport à ce modèle.

Souvent, lors de l’entretien, le Directeur de Projet présente son modèle de fonctionnement Agile. Cependant à l’usage il s’avère que les bonnes pratiques ne sont pas toujours respectées.

Pour qu’un board soit utile, les tickets doivent être à jour et le périmètre le plus clair possible (définir s’il décrit une tâche, une User Story, une difficulté…) :

• Trop souvent, de nombreux tickets font doublon avec les outils internes (JIRA, Mantis, QC..)
• Le choix entre une vision Scrum ou Kanban n’est pas clair.

Les cérémonies qui font partie intégrante d’une organisation Agile méritent d’être optimisées :

• Prenons l’exemple du Stand-up Meeting : ce point doit être régulier, time-boxé et dans un temps raisonnable. Les fameuses “Rétrospectives” méritent aussi de l’attention. Elles doivent être conduites dans un cadre très formel, dans un esprit propice à la libération de la parole et à l’introspection nécessaire. Les conclusions de ce meeting, quand il y en a, doivent être suivies et publiées afin de ne pas être oubliées.
• La notion de sprint est toujours présente chez les clients. Mais des contraintes organisationnelles fortes telles que la gestion délocalisée de la production, font qu’en fait, le nombre de releases est imposé (4 ou 5 fois par an : pas plus car cela coûterait trop !) que ce soit en production ou en pré-production.  Au final on s’aperçoit donc que le sprint n’est qu’un découpage des tâches à venir, souvent sans contrainte ni attente. Et si l’on rajoute à cela que chaque livraison doit être documentée précisément plusieurs semaines à l’avance sur son contenu ou sa stratégie de test, on s’aperçoit que l’Agilité n’y est pas, puisque les processus organisationnels définis sont peu flexibles.
• Le “backlog”, ce mot est répété dans les couloirs et les réunions. Il est souvent présent…mais incomplet faute de PO ! Ce dernier doit impérativement mesurer la business-value attribuée à chaque US (user-stories), notion à ne surtout pas confondre avec le MoSCOW. Malheureusement, la méconnaissance de l’usage précis de cet artefact ramène nos clients sur les exigences traditionnelles du cycle en V (SFG, SFD, SFT…). Dans ce cas, le backlog n’est rien de plus qu’une to do list.

En ce qui concerne les Planning poker, quand ils existent, ils ne réunissent souvent qu’un seul développeur et le CP. C’est souvent un challenge que d’organiser un travail d’équipe pour chiffrer. La raison invoquée du coût met en lumière une mauvaise compréhension de cette cérémonie par les intervenants.

Et pour finir ce constat, voici selon mois la raison la plus flagrante de l’échec à la mise en place réussie de Scrum : la constitution de l’équipe :

• Qui est le PO et où est-il ? Souvent, l’équipe est en contact avec différents responsables métier qui font office de PO sur leur domaine de connaissance, mais il n’y a pas de responsable unique habilité à avoir une vision globale du produit. De plus cette personne n’est que rarement à proximité !
• Enfin, il y a un encore des chefs de projet ou des managers qui décident souvent seuls de l’organisation, du planning, du contenu… Dans ces conditions, les notions d’auto-gestion de l’équipe s’en trouvent très limitées !

Heureusement, ces dérives ne sont pas présentes chez tous les grands comptes. Certains services sont beaucoup plus matures dans leur approche de l’agilité. Cependant, même dans ces services, on retrouve certains des écueils évoqués ci-dessus, du fait de l’organisation globale de l’entreprise qui n’est pas pensée pour un fonctionnement Agile.

 

Comment en est-on arrivé là ?

 

Au-delà de ce constat, sévère, que je fais de l’Agilité dans quelques départements de grands comptes, il semble important d’en comprendre l’origine :

• Tout d’abord, et spécialement en France, il y a une très forte culture de la séparation des tâches : A chacun son métier (sa MOA, son AMOA, sa MOE, son QA…). Ce changement d’organisation du mode de travail est profond, très dur et très long à mettre en place.
• Rajoutons à cela que certains grands comptes ont débuté un processus d’offshorisation il y a 10 ans et que ce processus est en voie d’industrialisation. Mettre en place une méthode Agile basée sur la proximité dans ce contexte semble compliqué
• Comme vu ci-dessus, nos clients ont des structures organisationnelles très fortes. Pour diverses raisons historiques et de sécurité, la gestion des infrastructures de production (et parfois de préproduction) est complètement décorrélée des environnements de test. Ces contraintes nécessitent une organisation précise, documentée et stricte entre les services, difficilement compatible avec les principes et les tempos de l’Agile. Tous ces inconvénients sont de puissants freins à la mise en place du continuous delivery.
• Un autre facteur d’échec est peut-être, l’impréparation du middle-management à ce changement d’organisation. Inconsciemment un chef de projet ne peut pas réellement s’investir et s’impliquer dans une métamorphose qui fera disparaître son poste. Car, rappelons-le, dans une organisation Agile efficiente, il n’y a plus de manager. En fait, toutes les définitions de poste doivent disparaître au profit de l’équipe en général. C’est un challenge pour les salariés qui ont l’habitude d’intitulés de poste précis et de plans de carrière établis. Sur le long terme, c’est la gestion des ressources humaines qui va devoir s’adapter aux principes Agiles afin d’évaluer différemment les performances individuelles au sein de l’équipe.

Toutes les complexités mises en lumière ci-dessus sont plus spécifiques aux grands comptes car les petites organisations ont moins de process et de structure. Cela induit qu’il y est plus simple de mettre en place l’Agilité comme méthode de travail.

 

Doit-on pour autant se résigner ?

 

Non. Car l’Agilité est vraiment porteuse d’un mieux-être dans le travail et d’une meilleure efficacité.

Que pouvons-nous faire pour y parvenir ?

• Tout d’abord il est absolument nécessaire de revoir les GPEC (Gestion Prévisionnelle des Emplois et des Compétences) dans les entreprises. Cette action ne peut se faire qu’avec la participation de la Direction des Ressources Humaines de l’entreprise. Il faut donc commencer par les mettre dans la boucle de ces changements d’organisation !
• Pour se faire il faudra également convaincre les syndicats de salariés. Certains d’entre eux sont relativement réfractaires au changement. Il faut avoir les bons mots pour convaincre de l’efficience du modèle Agile et des avantages pour les salariés. Là encore, nulle possibilité de faire bouger les lignes sans avoir l’aval des syndicats de l’entreprise.
• Ensuite, il est important de repenser l’organisation de l’entreprise. Il faut rétablir la communication Business/Techno. Il serait certainement judicieux de mettre en place des équipes Agile en responsabilité totale d’un produit ou sous-produit, sans l’offshorisation d’une partie de sa conception. La délégation de gestion des architectures de production à des équipes dédiées et séparées doit être repensée afin d’offrir plus de souplesse. Pour provoquer ces changements, ce sont directement les Directions Générales qu’il faut convaincre.
• C’est d’autant plus nécessaire, que tout le monde doit passer à l’Agile en même temps. Ce changement ne peut se faire uniquement chez les IT. Le métier doit être impliqué car les processus d’expression de besoins, de validation ou de demande de changement sont complètement différents ! Le support de production, les équipes infra… Si l’un des acteurs de la chaîne n’est pas impliqué, alors la méthode ne sera pas efficiente !
• Il faut également porter une attention particulière sur les équipes. Les coachs mis en place par les DSI à cet effet doivent se concentrer sur la bonne compréhension des principes de l’Agilité, et non pas seulement sur la mise en place de cette dernière. Tous les acteurs doivent être formés ! Il ne faut pas limiter cette action aux seuls informaticiens !
• Convaincre les Directions Générales de nos clients de mettre en place ce changement d’organisation générale est une nécessité. Convaincre uniquement les directeurs de projet, ne suffit pas : l’approche top-down doit être privilégiée sur ces sujets par les forces commerciales d’accompagnement.