Trop souvent l’organisation d’un projet s’apparente à un acte inconscient, choix instinctif découlant de l’habitude des parties prenantes. Dans ce schéma, aucun temps de réflexion n’est accordé à l’étude des avantages d’un modèle par rapport à un autre dans le contexte précis du projet, et les équipes s’engagent dans le traditionnel cycle en V.

Rien pourtant de prédestine toutes les équipes à suivre une même méthode, qui leur serait « traditionnelle ». Aujourd’hui, de plus en plus de projets regardent vers des méthodes alternatives qui, si elles existent déjà depuis des décennies dans certains secteurs, sortent de leur périmètre initial et influencent de nouveaux domaines.

Sortons un instant du mauvais réflexe « on a toujours fait comme cela » pour voir pourquoi et comment les adapter aux problématiques des Ressources humaines.

Dans ce premier document nous abordons les principes généraux des méthodes agiles et scrum, dans un second temps nous traiterons de l’utilisation des méthodes agiles en RH et enfin dans un contexte concret à mi-chemin entre les origines de la méthode et les problématique de ressources humaines : la construction d’un SIRH.

Pour naviguer dans le document :

1. Introduction à la notion d’agilité
2. Quels principes gouvernent la méthode ?
3. Des principes aux processus
4. Rôles et responsabilités de chacun
5. Les objectifs
6. Les risques

Ce document reprend les bases de la méthode. Pour les plus aguerris, n’hésitez pas à vous rendre directement à la partie qui vous intéresse.

I. Introduction à la notion d’agilité

La méthode agile est un terme sous lequel se regroupe un ensemble de pratiques de pilotage et de réalisation d’un projet, qui tire son origine d’un manifeste rédigé en 2001 par un collectif de 17 experts (1)

Le constat initial vis-à-vis des méthodes traditionnelles, soulève deux difficultés récurrentes : les délais avant la livraison d’un produit fini et les écarts entre la demande initiale et le rendu final.

Souhaitant mettre en avant un comportement pragmatique face aux inéluctables évolutions que subit un projet entre ses points de départ et d’arrivée, la méthode propose d’intégrer les demandes du client dans le quotidien du projet. Le principe est ainsi de faire de la souplesse un axe d’organisation que la réactivité devienne un atout systémique.

Source : Toucan Toco (toucantoco.com)

A partir de cette réflexion, la méthode agile s’appuie sur des cycles courts, des itérations précises et le retour d’expérience dans un objectif d’adaptation constante face aux évolutions des besoins clients.

Dans la galaxie des projets, la méthode agile se décline en plusieurs systèmes parmi lesquels l’entreprise doit choisir. On appelle ceux-là, des méthodologies. Leurs modèles poursuivent les objectifs de la méthode agile selon une mise en pratique particulière. Le plus utilisé pour des projets SIRH – et plus largement de la production logiciel – se nomme « SCRUM » (2)

Si, dans un premier temps la méthode ciblait les projets de développement informatique simples, les bénéfices observés ont poussés les directions à essayer cette méthodologie dans des domaines de plus en plus diversifiés. Aujourd’hui, les concepts se démocratisent et les expériences se multiplient dans de nouveaux contextes, et notamment par le biais des SIRH aux ressources humaines.

Agile et Scrum, synonymes ?

La méthode agile peut s’apparenter à une philosophie de projet, dont les valeurs sont :

• 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

Scrum est une forme particulière de mise en pratique de l’agilité. Elle cherche à améliorer la productivité de l’équipe en fractionnant le projet en étapes dont chacune est l’occasion d’une livraison et d’une redéfinition des priorités selon les retours clients. Si l’Agilité est la philosophie d’un projet, Scrum en est la boite à outil.

Quels sont les objectifs poursuivis ?

• Peu de hors sujet
• Une documentation réduite
• Une proximité avec les besoins du client
• Des versions opérationnelles livrées régulièrement
• Une meilleure sécurité, par la continuité des tests
• Une communication constante sur les améliorations apportées au produit
• Des délais raccourcis et des mises à jour réactives

Dans quel contexte ?

Si la méthode est apparue dans un milieu d’équipes d’ingénieurs et de développeurs, elle s’est d’abord répandue dans tous les projets visant à la réalisation concrète d’un produit. Et comme le produit en question n’a pas d’impératif physique, de nouveaux métiers adoptent ces principes pour, par exemple, la rédaction de cahier des charges, la rénovation des plans de formation ou la construction d’un SIRH.

En définitive, si votre projet est :

• Innovant : Une conception laissant place à la créativité
• Porteur de paramètres inconnus : Besoins, technologie ou délais
• Complexe : Articulation de plusieurs équipes, métiers, domaines

Alors la méthode agile peut être la bonne solution pour éviter les risques de retard et de surcoût

II. Quels principes gouvernent la méthode Scrum ?

Le principe de rythme :

• Une unité de temps : Une cadence cyclique définit dès le départ du projet pour positionner chaque étape par rapport à un délai de livraison.
• Une récurrence des moments par unité : Chaque étape revient avec un nouveau cycle. Un suivi : La satisfaction des étapes est contrôlée.

Le principe du livrable :

•  L’unité d’action : Toutes les avancées sont découpées en unité, ou livrable, dont le périmètre est une action logique simple. Chaque unité se veut fonctionnelle et exploitable.
• La livraison au client : Une livraison dans l’environnement de recette disponible pour le client est effectuée à chaque cycle
• La prise en compte des retours: Pour chaque livraison, les retours effectués par le client sont pris en compte en amont, et vérifiés.

Le principe de hiérarchie des actions :

Les étapes de spécifications :

• L’épopée : Il s’agit dans le vocabulaire Scrum de la spécification générale du domaine auquel se rapporte un certain nombre de besoins et d’actions (ex : Module Formation)
• La culture : Spécification détaillée d’une fonction logique (ex : Catalogue de Formation / Acquisition des heures de Formation / Demandes de Formation …)
• Le récit : Développement de l’action fonctionnelle, fractionné en plusieurs récits pour une culture si la complexité technique du développement le requiert.

Les étapes de développement :

• L’estimation de la complexité technique d’une action fonctionnelle. C’est à ce moment qu’une culture peut être sous-découpée en plusieurs récit. Selon la complexité, une pondération est donnée au récit, dont se déduit le délai.
• La réalisation du développement, avec le soutien des équipes fonctionnelles lorsque cela s’avère utile.
• Les tests d’intégration et unitaire sur le récit

Les étapes de consolidation :

• La recette des développements, par le client et par les équipes fonctionnelles, afin de valider un développement.
• La correction des bugs remontés lors de la recette
• La rédaction de la documentation qui sera reprise pour les supports de formation et les modes opératoires.

Un aperçu ?

III. Des principes aux processus :

Le backlog

La méthode Scrum repose sur le principe de “transparence”. Une large part des informations se veulent ainsi accessibles par tous les membres du projet. On retrouve dans ces éléments partagés la tâche en cours de chacun, son état d’avancement, et l’objectif actuel de l’équipe. Ce choix favorise la compréhension de l’état d’avancement et de l’interlocuteur pertinent.

Un tableau joue ce rôle. Il porte le nom de « Backlog » et récapitule les tâches du cycle en cours, leur état d’avancement, ainsi qu’un réservoir des tâches non abordées.

Ce réservoir liste les exigences du client. Chaque exigence porte une pondération selon la complexité qu’elle représente, et une priorité selon son importance. Elle peut aussi être soumise à la réalisation d’une autre exigence. L’apparition des exigences dans la liste des développements à entreprendre dans un cycle dépend donc de son niveau de priorité et du poids des exigences déjà ajoutées – le poids maximum d’un cycle étant fonction de la capacité de maitrise d’œuvre présente sur le projet..

Lors de la constitution des listes, il est préférable de respecter l’objectif de la méthode Scrum, qui cherche à produire le plus tôt possible la plus grande valeur possible

Le point quotidien

Appelé Scrum meeting – qui donne son nom à la méthode, « stand-up meetings », ces réunions ont lieu quotidiennement, en début de journée. Tous les membres du projet y prennent la parole, pour évoquer l’état de leurs travaux. Du point de vue du projet, cela consolide l’idée de transparence des actions et permet d’anticiper les difficultés. Chacun y évoque :

• L’état d’avancement de mes sujets Les difficultés rencontrées la veille Mon planning et mes objectifs du jour
• Les obstacles que j’identifie pour y parvenir

On retrouve l’idée d’une réunion « debout », quel que soit le nom qui lui est accordé, car cette position favorise l’attention et encourage la concision. Les échanges restent limités à l’organisation de la journée. Si des problèmes sont soulevés, l’équipe identifie les pistes et les personnes pouvant les résoudre mais n’y pallie pas en séance.

A l’issue de ce point, le graphique d’avancement mis à jour affiche la diminution en poids des actions restantes pour le cycle. On peut donc suivre quotidiennement la progression des développements et agir sur les éventuels retards. Ce rapport immédiat entre actions et délais sert lors de l’estimation de charge des futures actions similaires, notamment lorsqu’il met en lumière un niveau de complexité différent de la première estimation sur le sujet.

L’enchaînement des Sprints

Le sprint est le nom donné aux cycles. Un sprint est donc une durée, des étapes et des actions. La durée est fixée d’un commun accord avec le client, puisque ce dernier recevra sur ce rythme les livraisons qu’il se charge d’évaluer, les étapes sont des évènements, réguliers (ex : réunion de démarrage du sprint, comités…) ou singuliers (ex : Démonstration à un nouveau client), et les actions les tâches de chacun. Comme vu plus haut, dans les délais et selon les étapes, ont alimente chaque sprint avec un certain nombre d’actions à partir du « backlog »

Un sprint débute par un « sprint planning meeting » qui est une réunion de prévision pour le cycle ouvert. Est déversé depuis le « backlog », l’ensemble des actions à réaliser. Dès lors que l’équipe valide les actions d’un sprint, il n’est plus possible d’en ajouter. Le périmètre ne se voit modifié qu’en cas d’avance ou de retard sur les prévisions, évaluation à la main du responsable des développements.

C’est également à ce moment que les retours clients sont exprimés, les besoins priorisés, pour permettre à l’équipe de développement d’estimer plus précisément la charge de travail.

Au terme du sprint, l’équipe se réunit pour une Revue où sont présentés les retours des clients et utilisateurs finaux. Prenant en compte ces détails, le périmètre des prochains sprints est défini et/ou ajusté.

Chaque sprint se termine par une rétrospective, qui a pour vocation de faire remonter les ressentis de l’équipe sur le sprint passé. Ce moment est voulu comme un espace d’expression de propositions pour s’améliorer (efficacité, conditions de travail, mise en place de bonnes pratiques, …)

La Revue et la Rétrospective précèdent généralement le « sprint planning » au cours de la première matinée du nouveau cycle. Tous les sprints s’enchainent jusqu’au dernier sprint de déploiement.

La mesure de l’avancement

Le volume des développements nécessaire avant le déploiement final peut être compliqué à suivre dans un projet en mode agile car de nouvelles exigences peuvent apparaître en cours de route.

Il s’avère indispensable de maintenir un suivi général de l’avancement sur l’ensemble du projet et non seulement sur les réalisations d’un « sprint ». Les tâches du projet sont répertoriées et ordonnées de sorte que les étapes préliminaires soient terminées avant d’entamer celles qui en dépendent, puis clôturées cycle après cycle. Les retours formulés peuvent donner lieu à l’addition de nouvelles tâches. Ces dernières sont traitées selon les mêmes règles que les tâches déjà présentes, bien qu’elles augmentent le volume global. Dans ce contexte, l’efficacité de l’équipe, l’avancement du projet, ne se résume pas à la seule diminution des actions restantes mais au rapport global entre le « backlog » et le réalisé, à la lumière de la pondération effectuée.

Averti de la possibilité d’ajout, la date de déploiement final doit prévoir la marge de manœuvre qui sera utilisée pour satisfaire les besoins encore inconnus lors du démarrage. Néanmoins, l’espace conservé pour ces ajouts doit être limité, et la limite respectée, au risque d’atteindre la date de déploiement sans porter la totalité du périmètre. Au-delà de la marge allouée, il n’est plus question d’ajout mais de remplacement en fonction des niveaux de priorité relevées.

IV. Rôles et responsabilités de chacun :

La notion de rôle

Les arcanes de la méthode Scrum repartissent les membres de l’équipe dans des rôles précis. Chaque rôle porte des prérogatives et des responsabilités particulière qui se connectent mais ne s’échange pas. Cette organisation se veut bénéfique pour la conservation des objectifs du projet face aux impératifs su projet, qu’ils soient techniques, fonctionnelles ou clients. Les membres de l’équipe, jouant leur rôle, maintiennent un équilibre des forces.

On trouve :

Le « Product Owner »

Il porte la vision du produit à réaliser. En ce sens il est aussi le représentant du client et défend les intérêts du produit pour le marché.

Le « Scrum Master »

Il garantit l’application de la méthodologie Scrum, facilite la communication, centralise les développements et en assure le suivi. On le considère généralement comme le chef de projet.

Les responsables fonctionnels

Ils travaillent en lien avec le « Product Owner » pour retranscrire les besoins exprimés par les clients en règles exploitables par l’équipe technique. Par leur expertise ils peuvent circonscrire les demandes clients. Dans certains cas une même personne assure ce rôle et celui de « Product Owner »

• les référents fonctionnels (Maitrise d’ouvrage) qui assurent la pertinence des règles métiers.
• les responsables de la recette qui vérifient les travaux effectués

L’équipe de développement :

Elle se constitue de plusieurs groupes dont les travaux cumulés mène à la réalisation du produit. On trouve dans ce groupe la maitrise d’œuvre, développeurs dans le cadre d’un projet Si ou experts plus largement (pouvant eux-mêmes être répartis selon leur domaine d’expertise) qui élaborent le produit.

V. Quels objectifs servent une telle méthodologie ?

Là où les méthodologies classiques de projets s’attachent à planifier tous les aspects d’un projet sur de longues périodes – ce qui les rend résistantes aux changements – la méthode Scrum s’adapte à l’évolution rapide du marché. Les projets gagnent en souplesse et en adéquation avec les besoins du client. C’est une vision centrée sur le produit plutôt que sur le projet.

Cependant, on peut s’interroger sur la manière d’évoluer vers une nouvelle méthode lorsque l’organisation générale suit une approche en cascades ? Comment être sûr que la nouvelle méthode, agile et donc innovante par rapport aux pratiques, fera ses preuves rapidement face à un référentiel en place ?

Une période d’essai, appuyant sur la transition, peut s’avérer si ce n’est rassurante, à minima nécessaire pour convaincre l’entreprise en prouvant l’efficacité de l’agilité. Une option commode et réaliste vis-à-vis de la structure d’une entreprise, consiste à faire vivre certains projets en mode agile – les plus pertinents – au sein d’une organisation traditionnelle, mais cela exige une clarification de l’autonomie accordée auxdits projets.

Qu’y a-t-il à gagner avec la méthode Scrum ?

L’une des valeurs au cœur de la méthodologie Scrum de gestion de projet est l’idée d’amélioration, et celle-ci est possible par le principe d’itération. Cela s’applique non seulement au produit en développement, mais aussi à l’efficience de l’équipe.

Comme nous l’avons vu, au terme d’un sprint, le livrable doit être exploitable par le client. Bien sûr, le projet n’est ni abouti ni finalisé, mais suffisamment avancé pour montrer quelque chose au client, ce qu’on nomme le Produit Minimum Viable (MVP). Si l’équipe bâtissait un parc d’attractions, un sprint s’apparenterait à un manège : le parc n’est pas encore prêt mais la grande roue est déjà utilisable.

Pourquoi est-ce intéressant ?

Parce que cela permet de collecter les retours d’expérience des utilisateurs finaux alors que le projet est encore en cours, qui participeront aux décisions. Ainsi dans le parc d’attraction, la grande roue peut être ralentie, le train fantôme bénéficier dans sa conception du retour d’expérience sur le confort des nacelles ou la création du stand de barbe à papa repoussée car encombrant et peu utilisé.

C’est autant d’efforts épargnés en communication, autant de temps, d’argent, gagné sur des corrections qui seraient demandées a posteriori.

Qui plus est, la recherche des améliorations envisageable dans l’organisation du projet – que ce soit des difficultés techniques, un déséquilibre des priorités, le dialogue entre personnes, etc – font que l’obstacle se résout en collaboration. Les solutions alors identifiées sont immédiatement connues et adoptées par les personnes concernées.

Pour résumer, il existe 3 différences majeures entre la méthode agile/Scrum et la méthode traditionnelle :

• Sur l’organisation des équipes : Equipes collaboratives et autonomes vs Management hiérarchisé
• Evolution et adaptation vs séquencement des étapes du début à la fin
• Réalisation continue cadencée par des livraisons itératives vs définition d’une date de livraison en fin de projet.

Sous condition d’un respect de certains principes :

Former une dynamique de groupe, pour l’implication de tous les membres de l’ équipe. On trouve comme pratique la mise en place d’un plateau commun réunissant tous les acteurs pour faciliter les échanges, des moments de communication sur l’avancée du projet (clients gagnés, retours utilisateurs, …).

• Donner au Product Owner (PO) un pouvoir de décision adéquat vis-à-vis du chef de projet informatique. C’est à dire un fort pouvoir de décision de ce qui doit être conçu et un devoir de validation de ce qui a été réalisé.

• Conserver une relation privilégiée entre le Chef de Projet informatique et le Scrum Master, afin que tous deux disposent constamment d’une connaissance complète des besoins, risques et réalisation de chaque équipe (on peut voir ces postes cumulés en une personne)

• Conserver une ligne directrice : la flexibilité des travaux ne signifie pas de revenir sans cesse sur ce qui a été fait au prétexte d’un besoin d’évolution.

• Adapter les tests aux développements agiles. Si une recette régulière est effectuée à chaque cycle, une recette globale ne doit pas être écartée. Il en va de même pour les tests techniques et fonctionnels.

• Insister sur le besoin de coopération, que ce soit entre membres de l’équipe agile, ou avec d’autres parties prenantes, extérieures au projet. Un projet agile n’est pas un projet isolé dans l’organisation.

VI. Rester attentif

La méthode agile ne revient pas à appliquer quelques règles innovantes pour obtenir des résultats magiques. Certains écueils existent, et peuvent lorsque l’équipe s’y heurte trop durement, abîmer le projet entier, corps et biens.

Cet échec provient soit du projet lui-même soit de son environnement. Dans la liste des risques pouvant y mener, on trouve :

La vision « tunnel »

La méthode Scrum encadre les seules phases de développement et de recette.

En creux, cette constatation souligne le l’important de conserver un pilotage globale (sur la dimension totale du projet et non d’un cycle). Autrement, les instances de management externes perdent la main sur le projet faute de visibilité. Il est donc indispensable de maintenir des comités de pilotage et des reportings réguliers, qui offrent en sus une objectivité sur le projet.

Le second effet pervers de la vision tunnel tient à l’encadrement du travail du métier. Un regard itératif peut être adapté pour la réalisation de développements et de tests, mais il risque facilement d’être trop resserré pour la conception d’un produit. En effet, le produit doit avoir une cohérence générale, tant en termes de logique, que de philosophie, que d’ergonomie, et s’égarera s’il en reste à constamment définir de nouvelles fonctionnalités pour alimenter les itérations à venir. Il est primordial de maintenir des phases de conception précoce, afin de pérenniser une compréhension du besoin dans son ensemble, évitant ainsi des spécifications appuyés uniquement sur les réactions à chaud face à ce qui a été développé. Les retours utilisateurs pourront ainsi être réfléchi et non traités mécaniquement.

Des délais rallongés

Trop de flexibilité dans la prise en compte de nouveaux besoins peut provoquer une moindre rigueur dans la conception initiale du produit. Cela risque aussi de générer de nouvelles demandes au fil du projet, qui s’avère finalement inutiles. Sur ce point également, un pilotage appliqué du projet à un niveau plus large que le suivi des itérations permet de limiter ce risque.

D’autre part, les méthodes agiles incitent à favoriser la qualité : l’utilisateur recevant régulièrement des itérations du produit fera plus facilement, plus rapidement, des critiques sur le moindre accros. Or, une trop grande recherche de perfection entraîne une stagnation – les développeurs ne passant au sujet suivant que lorsque l’actuel est irréprochable. Dans l’idée de fournir au marché un produit viable le plus rapidement possible, il est conseillé de limiter la reprise de travaux terminés. On accepte l’amélioration d’un élément mais on n’en modifie pas un de correct. Si nous reprenons l’exemple de la grande roue du parc d’attraction, il est parfaitement envisageable de ralentir la grande roue, en revanche l’armature ne sera pas repeinte de bleu foncé à bleu clair.

L’engagement des membres de l’équipe

Tout d’abord, comme pour toute innovation, il faut garder à l’esprit que certaines personnes sont plus réticentes au changement que d’autre. La méthode scrum tranche avec les méthodes traditionnelles, communes à la plupart des entreprises. Les réunions quotidiennes et les méthodes collaboratives notamment peuvent apparaître comme un excès de contrôle.

De plus, ces méthodes favorisent la conversation par rapport à la formalisation d’un besoin au travers d’un cahier des charges exhaustif. En cela, chacun doit faire l’effort de comprendre les sujets plutôt que de suivre une consigne.

Enfin, la recherche d’amélioration des processus implique la capacité à remettre en question ses méthodes, ses manières de faire. Il faut donc être capable d’une part d’entendre la critique, et de changer ses habitudes en cours de projet. Une attention particulière doit être accordée à la manière de formuler ces commentaires, pour les exprimer comme propositions d’action et non comme stigmatisation.

Une dérive des objectifs

La dérive des objectifs découle souvent d’une vision « tunnel », et parfois de la multiplication des sources d’information.

Certains projets traitent effectivement avec plusieurs clients pour l’élaboration de leur produit, et chacun de ces clients, livrés au terme d’un « sprint » exprimera ses retours selon l’utilisation qu’il a de l’outil, ses habitudes de gestion, le parcours personnel de ses utilisateurs.

Or, tous ces commentaires peuvent d’une part former une masse immense d’information et d’autre part se contredire. Le « Product owner » a donc la charge de trier parmi cette multitude les éléments critiques généraux, de réaliser des compromis et de fixer les priorités, sans quoi l’équipe se retrouve sous une masse trop importante à gérer et risque de piocher aléatoirement dans le réservoir indifférencié de demandes hétérogènes.

L’ « endettement technique »

L’endettement technique représente l’ensemble des défauts connus et dont la correction est mise en suspens.

Le « Product Owner », dans un souhait de préservation de la confiance auprès des utilisateurs de faire preuve d’honnêteté quant aux erreurs et lacunes de la version livrée. Idéalement, cette communication s’accompagne d’un engagement de délais de correction. Toutefois, si la purge des erreurs nécessite un trop grand nombre d’itérations, voir si des régressions sont observées, c’est signe que certaines pratiques, telles que les tests techniques ou fonctionnels, ont été négligées.

Une accumulation d’anomalies recensées, et pire d’erreurs non relevées, faire courir un risque d’échec important lors de la livraison finale car le produit, inexploitable, sera refusé par le client