Les échanges autour du Nouveau Forfait Agile ont été l’occasion de répondre à de nombreuses questions, dont une partie revient régulièrement. Cette F.A.Q permet de rassembler et de partager les réponses apportées sur ces différents sujets de questionnement récurrents.

• Un backlog détaillé, en réalité, c’est un cahier des charges… alors quelle est la différence avec du cycle en V ?
• Comment puis-je demander un engagement forfaitaire alors que je n’ai pas encore la vision sur la totalité de mon projet ?
• Faire un pilotage item par item, est-ce que ça n’est pas trop contraignant ?
• Et les sprints dans tout ça ? Ils sont où ?
• Le Fair Play, c’est bien beau, mais comment on peut le garantir ?
• La contractualisation plutôt que la collaboration : pas vraiment Agile, non ?
• Est-ce que les prestataires ont vraiment intérêt à aller vers ce type d’approche ?
• Est-ce que le Nouveau Forfait Agile me dispense de la logique d’avenants en cas d’extension de périmètre ?
• Est-ce que le Nouveau Forfait Agile me permet de mieux terminer un projet Agile ?
• Le Forfait Agile, ça veut dire que je dois faire une consultation (avec les délais associés) avant de démarrer un projet ?
• Est-ce que contracter un volume de points peut vraiment être considéré comme un contrat au forfait?

 

Un backlog détaillé, en réalité, c’est un cahier des charges… alors quelle est la différence avec du cycle en V ?

Pour servir de base à un engagement forfaitaire, le backlog doit atteindre un niveau de granularité et de précision relativement fin. Cependant, seuls les éléments de description et/ou les hypothèses structurantes en termes de complexité de réalisation sont nécessaires. En cela, on est très loin d’une spécification fonctionnelle détaillée.

Pour atteindre le bon niveau de détail et de découpage dans le backlog, il est clairement préférable qu’il soit constitué par quelqu’un disposant d’une expérience significative des projets de réalisation. Et, bien entendu, les prestataires peuvent / doivent demander les informations / les hypothèses manquantes pour réaliser leur estimation de complexité dans les phases d’avant-vente ou de consultation. Lorsque la mise en œuvre démarre, les items sont spécifiés en détails au fil de l’avancement de la réalisation, avec le niveau de détail nécessaire à la réalisation.

La différence avec le cycle en V, au-delà de la fourniture d’un entrant « light » et donc plus rapide à produire qu’une expression de besoin plus détaillée, se trouve également dans le fait de mettre en œuvre le projet de manière incrémentale, avec des livraisons en continu, et de permettre une modification permanente du périmètre tout au long du projet.

Pour finir, le fait de réfléchir a minima au besoin avant de démarrer un projet (en se laissant la possibilité de le faire évoluer ensuite, bien sûr) me semble une bonne pratique de projet dans l’absolu, quelle que soit la méthode de mise en œuvre employée. Vouloir démarrer trop vite est souvent contre-productif, notamment en termes de surconsommation de ressources.

 

Comment puis-je demander un engagement forfaitaire alors que je n’ai pas encore la vision sur la totalité de mon projet ?

Démarrer rapidement implique parfois, surtout sur les projets importants, de lancer la réalisation avant d’avoir défini la totalité du périmètre. C’est encore plus vrai avec une approche Lean StartUp. Heureusement, il n’est pas nécessaire de disposer d’un  backlog complet pour démarrer la réalisation en Forfait Agile, loin de là !

Le contenu du backlog utilisé comme base de l’engagement forfaitaire du prestataire a essentiellement vocation à servir de référence à l’évaluation des points de complexité associés aux livrables demandés au prestataire. C’est une sorte de « mètre étalon » qui permet de challenger l’évaluation de nouveaux items au backlog, en les comparants aux items déjà évalués par le prestataire.

Plus le backlog de départ est complet, et plus la comparaison avec de nouveaux items est simple et objectivable. Dans tous les cas, il permet de disposer d’une base d’engagement traduisant du livrable concret (des fonctionnalités ou des briques techniques concrètes) en coût de réalisation pour challenger le prestataire.

A l’extrême, on peut très bien disposer d’un backlog de départ générique, uniquement adapté au contexte technique et macro-fonctionnel du produit (outil de gestion, BI, etc.), et constituer le backlog réel au fil de l’eau en s’appuyant uniquement sur cette base de référence pour l’évaluation des points de complexité des items ajoutés au fur et à mesure (On se rapproche alors de la logique « catalogue d’unités d’œuvre » qui se pratique par ailleurs).

L’engagement contractuel avec le prestataire est, dans tous les cas, la réalisation d’une enveloppe de points (qu’on sait associer à du livrable) dans un délai donné.

Quoi qu’il en soit, un cadrage du projet a minima est nécessaire pour donner une vision suffisante de l’ensemble du produit et estimer un périmètre budgétaire cohérent avec les ambitions du projet. Cela permet de se donner une capacité à faire contractuelle avec le prestataire qui permet, en restant dans une logique de « design to cost », d’atteindre les objectifs visés de manière macro.

 

Faire un pilotage item par item, est-ce que ça n’est pas trop contraignant ?

Le pilotage se fait au niveau de l’item pour ce qui est du suivi de la mise en œuvre (démarré, terminé, …), avec un suivi d’avancement global avec une vue « burn up chart ». C’est donc tout naturel de suivre de la même manière l’ajout ou le retrait d’items de backlog.

Concrètement le volume d’items concernés à chaque instance de pilotage opérationnel (hebdomadaire) dépasse rarement la dizaine : rien d’insurmontable donc ! Et cela permet de gérer le projet à la même granularité, qu’on parle du suivi de réalisation ou du suivi contractuel.

 

Et les sprints dans tout ça ? Ils sont où ?

La notion de sprint est essentiellement associée à la méthode SCRUM, dans laquelle elle permet de cadencer la réalisation, la définition du périmètre à produire, l’engagement de l’équipe et les cérémonies.

Avec l’approche Nouveau Forfait Agile, l’engagement du prestataire en termes de vélocité (c’est-à-dire la production d’une quantité de livrables dans un temps donné) est acquis dès le démarrage du projet, et la gestion de l’organisation et du dimensionnement de l’équipe pour atteindre la vélocité prévue est entièrement du ressort et de la responsabilité du prestataire (ce qui est beaucoup mieux pour le client !). Les notions de sprint planning, de poker planning, etc. sont donc totalement caduques.

En revanche, on peut très bien découper la réalisation du produit en sprint, lots ou itérations, pour cadencer davantage les livraisons et le regroupement des items cohérents, mais sans se contraindre, comme c’est le cas en SCRUM, à fixer le périmètre d’un sprint pendant sa durée.

 

Le fair-play, c’est bien beau, mais comment on peut le garantir ?

Clairement, le fair-play n’est jamais acquis. Il se cultive et il s’entretient avec un mode de fonctionnement transparent et équitable, et avec la conviction que les relations client – fournisseurs les plus profitables pour les deux parties se construisent dans la durée dans un climat de confiance et de partenariat. Aucune méthode de gestion de projet ne fonctionne correctement lorsqu’une des deux parties cherche à duper ou à profiter outrageusement de l’autre.

Avec le Nouveau Forfait Agile, le fair-play est objectivé au maximum par une formalisation de la logique de fonctionnement et des engagements du prestataire relatif à un besoin clair du client. Mais, comme dans le domaine sportif, le recours à un tiers neutre, capable de réaliser les arbitrages lorsque c’est nécessaire dans un souci de maintien de l’équité, est fortement conseillé. Avec l’augmentation du niveau de maturité du couple client-fournisseur, le recours aux arbitrages est de moins en moins nécessaire dans le temps.

A noter : l’arbitre est nécessairement apporté par l’une des deux parties (et donc au final financé par le client sur le budget du projet) mais doit s’engager à conserver sa neutralité.

 

La contractualisation plutôt que la collaboration : pas vraiment Agile, non ?

La contractualisation est au cœur du dispositif Nouveau Forfait Agile. Elle permet de clarifier et de formaliser le mode de fonctionnement Trade In / Trade Out et les engagements du prestataire en termes de volume de livrables et de délais.

Cependant, la contractualisation n’interdit pas la collaboration, bien au contraire. Concrètement, c’est le prestataire qui, dès le départ, assume et porte l’engagement de vélocité et de délais, mais l’objectif commun reste la mise en œuvre d’un produit répondant au mieux aux besoins du client, dans le cadre budgétaire défini au départ.

Le client, à travers un porteur de projet, s’engage à être présent auprès de l’équipe et disponible pour fournir avec réactivité les informations nécessaires à la réalisation du produit au fil de l’eau et à recetter les items livrés par l’équipe.

Le prestataire, à travers l’équipe engagée auprès du client, doit rester force de proposition sur le contenu et les arbitrages à réaliser. Cependant, il assume son rôle d’expert de la mise en œuvre et gère de manière unilatérale le dimensionnement et l’organisation de l’équipe qui réalise le produit, afin de respecter son engagement de résultat.

Dans ce sens, on s’éloigne de la logique de « best effort » d’une équipe impliquée et engagée auprès du client vers la réalisation du meilleur produit possible dans le temps donné et avec les ressources imparties, dans une logique d’engagement de moyens.

Mais, dès lors qu’il peut démarrer rapidement la réalisation et faire évoluer le périmètre tout au long du projet, le client a bien plus intérêt à laisser le prestataire porter la productivité de l’équipe et gérer les aléas de la production de l’équipe à travers un engagement de résultat.

 

Est-ce que les prestataires ont vraiment intérêt à aller vers ce type d’approche ?

L’engagement de moyens et l’approche « régie » restent bien entendu les modes de fonctionnement les plus confortables pour les prestataires, dans la mesure où ils reportent le maximum de risques sur le client, qui demeure porteur du projet de réalisation.

Cependant, le risque juridique associé à la mise à disposition de ressources (délit de marchandage) amène les clients, et certaines SSII, à privilégier de plus en plus un mode de fonctionnement forfaitaire avec engagement de résultat.

L’approche Forfait Agile reste, in fine, au plus grand bénéfice des clients, qui peuvent se délester de la responsabilité de la mise en œuvre sans en perdre la maîtrise, et surtout sans remettre en cause l’agilité des projets.

Pour les prestataires, lorsque le cadre forfaitaire est imposé (et c’est de plus en plus le cas) c’est l’occasion de proposer une valeur ajoutée supplémentaire au client (gestion du changement) et donc de se démarquer d’offres concurrentes, mais également de sécuriser l’équilibre économique de la prestation en limitant le risque de dérive.

 

Est-ce que le Nouveau Forfait Agile me dispense de la logique d’avenants en cas d’extension de périmètre ?

L’engagement du prestataire est, au final, un volume de livrables (traduit par une enveloppe de points) dans un délai donné. Dès lors que l’enveloppe de points est suffisante pour atteindre le résultat attendu par le client (avec une logique de design to cost), il n’est pas nécessaire de modifier le cadre contractuel.

La variation de périmètre est inclue dans le cadre contractuel et ne fait absolument pas l’objet d’avenants.

En revanche, si l’enveloppe de points (et donc la capacité à faire) n’est pas suffisante pour atteindre le périmètre souhaité par le client, il est nécessaire d’étendre le volume de la prestation avec un avenant. Dans ce cas, il suffit d’étendre l’engagement à un volume de points supplémentaires. Le calcul du budget et du délais supplémentaires associés est tout simplement réalisé au prorata du nombre de pointa ajoutés par rapport à l’engagement de départ : X% de points en plus = X% de budget et X% de délais en plus.

Et à contrario, si le besoin du client n’implique pas de consommer la totalité de la capacité prévue, il est tout à fait possible de restreindre la facturation au périmètre concrètement réalisé.

Dans cette mesure, il est préférable de prévoir une enveloppe de points complémentaires dès le début du projet, qu’on pourra consommer ou non en fonction de l’évolution du besoin et des arbitrages réalisés au cours du projet.

 

Est-ce que le Nouveau Forfait Agile me permet de mieux terminer un projet Agile ?

La seule manière de terminer raisonnablement un projet agile est de couper le gaz à un moment donné, décidé par le client (lorsque la valeur métier apportée par les moyens engagés baisse significativement, par exemple…), ou prévu dès le départ par une capacité à faire capée.

Dans le cadre du Nouveau Forfait Agile, on se positionne dès le départ dans cette approche « design to cost », avec la possibilité de faire varier la capacité à faire (en plus ou en moins) au cours du projet si cela est souhaitable, mais de manière maîtrisée, avec en outre un engagement du prestataire sur le délai de réalisation. Le projet est terminé lorsque la totalité de la capacité à faire (en termes de livrables, pas de moyens !) est consommée, quels que soient les arbitrages réalisés au cours du projet sur le périmètre.

Un projet mené avec cette approche méthodologique reste donc nécessairement dans les clous en termes de budget, et dans les délais (dès lors que le prestataire tient son engagement).

 

Le Forfait Agile, ça veut dire que je dois faire une consultation (avec les délais associés) avant de démarrer un projet ?

Un des grands avantages de l’approche Nouveau Forfait Agile est de permettre, avant le lancement du projet, de comparer les offres de plusieurs prestataires sur un même périmètre (formalisé dans le backlog).

La comparaison des prestataires s’effectue à la fois sur le montant de la réalisation du backlog présenté, mais également sur les délais proposés. Bien entendu, d’autres critères de comparaison sont indispensables (capacité à produire des livrables de qualité, à accompagner le client sur l’ensemble des phases de réalisation (conception, tests, etc.),  à piloter le projet, à sécuriser ses engagements, etc.

La mise en concurrence de plusieurs prestataires avant le démarrage du projet représente cependant un délai supplémentaire au démarrage du projet. Pour contourner cette contrainte, sans remettre en cause la logique de mise en concurrence, plusieurs solutions sont possibles :

1/ Anticiper la consultation avec une logique de backlog de référence (cf. ref.) pendant la phase de cadrage

2/ Mettre en place un contrat cadre plus global avec un prestataire unique, capable de couvrir la réalisation d’un ensemble de projets, et portant globalement un engagement points / k€ / délai et un ensemble d’items de référence.

Indépendamment de ces deux manières de traiter la question des délais, gardons en tête que la mise en concurrence des prestataires reste une pratique saine pour maintenir l’équilibre de la relation client-fournisseur, et qu’avec la pratique des prestataires, les délais de réponse peuvent être significativement réduits (en dehors de cadres Achats stricts et contraints, type marchés publics)

 

Est-ce que contracter un volume de points peut vraiment être considéré comme un contrat au forfait ?

Oui, dès lors qu’on est capable d’objectiver le lien entre un coût forfaitaire (k€) et un livrable. C’est notamment l’intérêt du backlog de départ, dont chaque item, correspondant à un livrable, est évalué par le prestataire en coût de réalisation forfaitaire (à travers une évaluation en points, ou non)

A défaut on est sur un engagement de moyen « déguisé ».

 

 

Crédits :

Illustrations : Julie Boiveau / https://julieboiveau.wordpress.com