Cas Pratique : Construire un SIRH avec la méthode agile

Nous nous proposons d’observer un exemple concret d’utilisation de la méthode agile dans un contexte particulier car si l’aspect produit logiciel est conservé, la dimension du projet et sa proximité avec le domaine des ressources humaines en font un exemple rare à ce jour.

Construire une SIRH, qu’est ce que cela signifie ?

Clarifions les termes du sujet, il s’agit ici d’élaborer un nouvel SIRH à partir d’une étude de marché et non de reprendre un outil existant pour l’améliorer. Le produit porte l’ambition de couvrir à terme tous les domaines RH, ajoutant pierres après pierres à l’édifice reposant sur des fondations Gestion Administrative et Paie. La situation est donc semblable à un projet de création logiciel, tout en portant la singularité de couvrir un spectre de fonctionnalités plus large que la moyenne, une responsabilité réglementaire majeure et une utilisation critique en situation d’exploitation.

Avec quels objectifs ?

Lorsqu’un acteur se propose de créer un nouvel SIRH, c’est qu’il constate une opportunité sur le marché qui résulte au choix, d’une absence de solution à une problématique ou d’une solution devenue inadaptée. Dans ce contexte, où il est souvent présent à un niveau ou un autre – d’où l’identification de l’opportunité – il se veut alors force d’une proposition innovante. Cette proposition doit toutefois correspondre à des besoins précis, au risque de ne pas rencontrer sa cible.

De là, son implication sera proportionnelle aux retours, garanties et réactions qu’il obtient du marché car se faisant éditeur il se rémunèrera des ventes de ce nouveau produit. Son investissement de ressources dans le développement répond ainsi aux attentes qu’il recueille, or les clients potentiels ont des besoins à plus ou moins court terme et ses concurrents les moyens d’y répondre aussi. Par conséquent, un impératif de délai s’instaure pour ne pas lancer son produit trop tard.

Le cumul de ces objectifs d’adéquation et de rapidité, nécessaire à la réussite du produit, font les intérêts de l’emploi de la méthode agile.

Les étapes à respecter

La construction d’un SIRH comporte de nombreuses étapes, chez différents interlocuteurs. Nous nous limitons à celles propres à l’éditeur et interne au projet. D’un bout à l’autre du projet nous pouvons lister les étapes suivantes :

1. Analyse des besoins
2. Spécification / Définition des modules et des lots
3. Conception (MOA)
4. Réalisation (MOE)
5. Recette
6. Livraisons partielles des pilotes
7. Déploiement en situation réelle

Certaines de ses étapes se superposeraient traditionnellement sur une même période, et nous allons voir que ce comportement s’amplifie avec la méthode agile.

Adéquation des étapes de la construction au prisme de la méthode agile

Effectivement, la méthode agile prescrivant une régularité des livraisons selon le principe des

« sprints » – terme que l’on peut traduire par cycle ou itération – entraîne une répétition de ces étapes à petite échelle.

Cela signifie entre autre, que les responsables d’un domaine interviennent tout au long du projet, et non plus en début, milieu ou fin selon que leurs sujets entrent sur scène. Dans les faits, cela signifie que le « Product Owner » identifie les besoins clients, les transcris avec l’aide des experts métiers (MOA) en spécification, qui sont fournis pour développement aux experts techniques (MOE) en début de sprint et testés dans la foulée.

En schéma, avec les actions :

• Identification des besoins des clients,
• Rédaction des spécifications et validation avec le client,
• Développement et Recette fonctionnelle,
• Livraison aux clients.

De plus, il va sans dire que, aux vues de l’étendue des vocations d’un SIRH, les fonctionnalités étudiées comportent plusieurs développements dont la complexité est parfois très importantes, ce qui induit une superposition des spécifications et développements par sprint.

Dans ce contexte, la planification joue un rôle crucial afin d’anticiper sur les ressources nécessaires au bon déroulement de chaque sprint.

Quel rôle des membres de l’équipe selon la méthode agile

Au sein d’un projet ayant choisi la méthode Scrum, chacun dispose d’un rôle particulier, ouvrant ses responsabilités sur un périmètre donné.

Pour un produit simple, chaque rôle est occupé par une personne seule, et toutes partagent une compréhension des actions des autres.

Lorsqu’un projet s’attaque à un produit complexe, il est courant de voir émerger des positions d’experts, dont la fonction consiste à assurer la bonne réalisation d’une partie du produit, inconnue des autres. Ces experts s’imposent en raison de la spécialisation du produit, à laquelle ils répondent par des compétences précises.

On peut alors se demander comment articuler ce besoin avec les principes de la méthode. Tout d’abord, les rôles ne vont pas être affectés dans la même mesure par cette complexification.

• Le « Product owner » : Idéalement le rôle est toujours occupé par une seule personne, afin de centraliser les requêtes des clients. Ses interventions se feront plus tôt, de sorte que les besoins soient clarifiés sur chaque domaine. Il est souhaitable que le Product Owner possède une connaissance – au moins générale, si possible précise – des domaines abordés

• Le « ScrumMaster » : Une seule personne rempli ce rôle aussi. Ses reseponsabilités se concentrent davantage sur le respect des règles de la méthode et l’harmonisation des actions avec l’accroissement de la taille de l’équipe, se délaissant des tâches connexes.

• La Maitrise d’ouvrage : Aux vues de l’étendue des sujets, ce rôle ne peut être cumulé que de manière marginale avec celui de « Product owner », qui se fait accompagner par une équipe dont les compétences couvrent tous les domaines du SIRH. (Juridique, Paie, et tous les domaines RH embarqués). Cette équipe fonctionne comme relais des utilisateurs, assurant la formalisation d’exigences métiers approfondies sur la base de l’expression des utilisateurs finaux.
  • Et son responsable : Ce sous-rôle se révèle nécessaire à partir d’une certaine taille d’équipe, afin d’assurer la répartition des actions et l’harmonisation des travaux. Le « Product Owner » occupe idéalement ce rôle de supervision et de validation.

• La Maitrise d’œuvre : Bien que ce ne soit pas systématique, le choix de la spécialisation des développeurs peut être pris, que ce soit sur le niveau d’intervention (front/back/reprise de données…), les technologies ou les domaines (reproduction de la répartition des domaines fonctionnels)
  • Et son responsable : Comme pour la MOA, il intervient lorsque la synchronisation des travaux le requiert. Par facilité, le « Scrum Master » prend cette charge, car la préparation des livraisons lui incombe déjà, mais ce choix n’est pas systématique : il ne doit pas porter préjudice aux tâches du « Scrum Master ».

Comment articuler les relations de l’équipe avec son environnement ?

L’équipe projet chargé du développement d’un nouveau SIRH évolue au sein d’une entité macroscopique, dont le métier et les objectifs dépassent, comme nous l’avons vu, la seule réalisation du produit en question.

Elle doit donc naviguer selon ses principes sur une mer aux puissants courants.

La situation de l’équipe dans son entreprise

La situation de l’équipe doit être clarifiée vis-à-vis de l’organisation générale. En effet, les méthodes agiles suggèrent une autonomie des acteurs par rapport au schéma classique de hiérarchie puisque le déroulement des tâches se subordonne en partie aux requêtes des clients. Toutes les strates d’encadrement sont affectés dans leur fonctionnement, à commencer parce qu’elles acceptent de dédier des ressources, de revoir les critères d’évaluation, d’adapter leur fonctionnement.

Ce sont donc deux méthodes à faire cohabiter. Pour autant, l’équipe ne doit pas être déconnectée de son environnement, premièrement et évidemment pour assurer le lien entre l’avant, le pendant et l’après pour les salariés impliqués, mais aussi car le projet s’inscrit dans une dynamique globale. Les exigences d’une entreprise dépassent les résultats d’un projet, mais sa réussite sur un investissement de cette ampleur en dépend.

Un moyen efficace de conserver un contact entre les activités projets et les problématiques d’entreprise, consiste à établir des comités communs. A l’occasion de ceux-ci, les grandes lignes de l’activité du projet sont remontées à une direction de projet relais, hors de l’équipe qui sert de garde-fou, avec un regard sur la planification, le respect des objectifs, le budget. Ce relais donne les moyens d’action au projet et contrôle les progrès.

On retrouve dans ces comités, une notion d’organisation traditionnelle, dont l’influence doit donc se restreindre à des moments délimités. Afin de conserver les avantages de l’agilité, la direction n’exerce pas une pression directe sur la structure de l’activité mais agit plutôt comme gouvernance avec un pouvoir de validation. Les échanges sont canalisés par le

« ProductOwner » et le « Scrum Master ».

De par leur rôle, ces deux personnes possèdent les outils pour anticiper et organiser l’écosystème projet selon les exigences de la direction de projet. Centralisant les activités, ils disposent par ailleurs de la meilleur vision sur les actions en cours et à mener, ce qui les autorise à exprimer les demandes de ressources de l’équipe. De plus, leurs voix relaient celles des clients. Or, la satisfaction des clients est un objectif pour le projet comme pour l’entreprise dans sa globalité. Le principe de transparence, qui conforte cette satisfaction, s’applique au niveau de gouvernance

Cohabitation des exigences de l’équipe projet et de l’entreprise

Dans leur autonomie, l’équipe projet cherche à satisfaire les intérêts de l’entreprise. Ainsi, les exigences de qualité et de planning existent en parallèle dans l’équipe et dans l’entreprise. Une convergence des objectifs au niveau des rôles exercés par les salariés et des résultats, établis dès le départ du projet, permettra d’assurer la canalisation des efforts. Cependant, la mise en pratique des procédures pour atteindre lesdits résultats autorise dans cette configuration une liberté qu’il faut préserver même si elle n’existe pas ailleurs dans l’organisation. Concrètement, cela se traduit par un suivi des critères de satisfaction intermédiaires.

Vis-à-vis des clients

Les utilisateurs finaux impliqués dans l’équipe agile sont aussi des clients potentiels du produit, qui ont été convaincus de participer. En raison de leur connaissance du métier, ils font bénéficier l’équipe d’un retour d’expérience concret – conformément aux principes de la méthode. De leur côté, ces volontaires seront intéressés par les opportunités, fonctionnelles et commerciales, du nouveau produit. La présentation des avancées à chaque itération porte donc un double enjeu de progrès dans la construction et de communication. Il faut concevoir chaque itération comme un ajout à la vitrine d’un magasin avant sa première ouverture.

Une principale difficulté de la situation des clients réside dans l’allocation des disponibilités requises pour leur participation au projet, puisque les utilisateurs désignés pour travailler avec l’éditeur ne sont pas systématiquement, ni totalement, déchargés de leurs fonctions premières.

Une seconde difficulté apparaît lorsque les utilisateurs impliqués dans l’équipe agile viennent de différentes organisations. Dans cette situation, le recoupement des expressions doit trouver des compromis convenant à toutes les parties prenantes tout en restant cohérentes avec les valeurs du produit, au risque de créer des dissensions.

Des adaptations nécessaires :

Devant les contraintes générées par la complexité et l’ampleur des sujets que nous avons évoqués ci-dessus, il est utile de se poser les bonnes questions :

1. Quels délais se donner pour la sortie du SIRH ? Atteindre le stade de maturité dans lequel tous les domaines RH sont couverts est une projection sur plusieurs années
   1. Risques : Ne pouvoir rentabiliser son investissement
   2. Suggestion : Lotir les domaines. L’étude de marché de laquelle découle la validation du lancement du projet doit définir la priorité des lots. L’objectif est de mettre en production une version 1.0 du SIRH comportant les lots minimaux au regard des utilisateurs.

2. Comment gérer la durée du projet ? Un SIRH est réellement exploitable seulement lorsque un ensemble de fonctionnalité – correspondant à un domaine

– est livré (Gestion Administrative / Paie / Formation …), ce qui impose d’anticiper une date de déploiement.

1. Risques : Mal définir la date de déploiement, ou la repousser en raison des tâches ajoutées itérations après itérations
2. Suggestion : Lister les lots de livraison puis évaluer la complexité générale de chaque domaine d’un lot. Il faut pour cela que les utilisateurs sachent exprimer une vision générale de leurs attentes, de sorte que les experts techniques puissent en déduire la difficulté des développements. A cette estimation, on ajoute une marge pour anticiper les demandes ultérieures. On planifie la date de déploiement des lots en accord avec ce travail.

3. Quelles marges octroyer aux retours utilisateurs, et aux adaptations demandées ?
   1. Risques : Accroître les délais
   2. Suggestion : Mettre en place un espace de retours libres lors des spécifications et limiter les retours de recette aux spécifications validées.

4. Comment éviter de revenir trop loin en arrière dans les développements lors des retours d’expérience des utilisateurs finaux ?

1. Risques : Perdre une partie du travail de développement (ce qui est précisément ce que cherche à éviter la méthode Scrum) et ainsi engendrer une dérive des délais.
2. Suggestion : Se mettre d’accord – dans l’équipe et avec les utilisateurs finaux – sur une politique produit et des valeurs qui serviront de référence, de ligne directrice tout au long du projet. Canaliser les retours d’expérience qui dévient de ces objectifs. Etre clair avec les utilisateurs sur les conséquences d’une demande de révision.

5. Comment gérer la dimension des tâches pour conserver un rythme régulier de livraison ?
   1. Risques : Perte de visibilité et de réactivité vis-à-vis des utilisateurs finaux
   2. Suggestion : Imposer une dimension maximale aux tâches de développement. Le poids de certaine sera largement supérieur à d’autres, notamment lorsqu’elles impliquent des sujets réglementaires. Elles devront être maitrisées et ne pas dépasser un sprint, pour cela un sous- découpage est acceptable.

6. Comment garantir le principe de livraisons exploitables ? et ne pas entraver les actions de recette utilisateur
   1. Risques : Avancer simultanément sur plusieurs fonctionnalités et n’en terminer aucune.
   2. Suggestion : Dans le découpage des tâches, prévoir un plan de cadencement fonctionnalité par fonctionnalité.

7. Quelle priorité donner au traitement des anomalies ?
   1. Risques : Donner une image de manque de réactivité, paralyser des fonctionnalités sur la durée et à terme accumuler une dette technique
   2. Suggestion : Consacrer une ressource au traitement régulier des anomalies

8. Comment préparer le déploiement final ?
   1. Risques : Se trouver à l’approche du déploiement sans avoir évaluer précisément le poids des actions de recette, de paramétrage, de conduite du changement, …
   2. Suggestion : Utiliser le même système de tâche pour ces actions que pour les développements. Ainsi, ayant conservé l’unité de mesure, les délais sont calculables en parallèle des dernières livraisons.

1. Que faire si les prérogatives d’un rôle deviennent trop importantes pour une seule personne ? Et notamment lorsque le projet grandit entre son début et sa fin ?

1. Risques : Ne plus assurer la totalité des actions du rôle.
2. Suggestion : Recentrer l’activité aux responsabilités essentielles du rôle. Si cela ne suffit pas, déléguer une partie des actions à mener, il faudra alors développer des méthodes de communication efficace entre ces personnes. Utilisation d’intermédiaires (ex : experts MOA si les utilisateurs finaux ne sont pas assez disponibles) ou des relais entre les utilisateurs ou les développeurs et le Product Owner (responsable MOA/MOE)

10. Comment favoriser l’appréhension par tous les services impactés des besoins du projet les concernant, qu’ils soient immédiats ou à venir.
    1. Risques : Se trouver avec un SIRH finalisé mais mal maitrisé par les équipes de l’entreprise en orbite autour (Commerce / support / formateurs).
    2. Suggestion : Conserver une certaine perméabilité avec les autres équipes, maintenir une communication sur les développements, intégrer si possible des relais dans les phases de recette, donner les moyens de le prendre en main.

Conclusion

Les dimensions d’un projet tel que la création d’un SIRH – sur le plan des délais, des enjeux financiers et des services impliqués – rentrent en friction avec la souplesse voulue pour un projet agile suivant la méthode Scrum. Si le fonctionnement par itération permet d’accroître l’efficience des développements réalisés et ainsi d’améliorer les délais, des compromis sont nécessaires pour s’adapter aux procédures communes à l’entreprise. Ces compromis respectent les principes de l’agilité tout en assurant le contrôle des livraisons. On chercher avant tout à maintenir de bonnes relations avec le marché – notamment au travers des utilisateurs embarqués – avec pour finalité la réussite de la commercialisation du SIRH.

Il ne doit pas être exclu de faire cohabiter cette méthode avec d’autres. Cette cohabitation est envisageable tant que les frontières sont claires et comprises, avec par exemple un recours aux méthodes traditionnelles pour les premières étapes (analyses et spécifications générales) puis une bascule vers l’agilité (conception détaillées, réalisation et recette).

Il est également possible de faire évoluer l’équipe d’une phase à l’autre, ajustant en parallèle les modalités de l’agilité.

S’il existe de bons espoirs d’un développement plus rapide par l’utilisation de cette méthode, la réussite est soumise à une attention particulière aux risques, à leur anticipation et leur maitrise sous peine d’une incontrôlable dérive.