Agilité: régie ou forfait?

Lors de mes pérégrinations au sein de mes différents projets et surtout, lors de discussions à bâton rompu avec les membres des associations que j'ai pu rencontrer, le thème régie et forfait fait débat.

En effet, tout dépend de ce que vous vendez :

·        

     Une société de service voudra vendre des ressources dans un projet agile :

o   Dans ce cas, elle vend des CV

o   Et le pilotage du projet est fait par le client, même en ajoutant des closes hybrides avec un Scrum Master ou un coach.

o   Cela ne me satisfait pas vraiment, c’est de l’interim….

·        

     Une société de service voudra vendre un projet agile :

o   Dans ce cas, elle fournit toutes les ressources pour aboutir à la réussite de ce projet et principalement un Product Owner et un Scrum Master.

o   Elle peut composer avec des développeurs internes à la condition que ceux-ci soient dédiés à 100% au projet.

o   A mes yeux, c’est déjà mieux.

 

Mais que dit l’ Agile Manifesto ?

J’ai relu les 12 principes sous-jacents au manifeste et voici mes conclusions :

1.   satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

a.    Régie : Pas concerné. La régie, c’est une obligation de moyens et pas de résultat. Est-ce que la fourniture de moyens répond à cette attente ?

b.    Forfait : Obligation de résultat: livrer = satisfaire

2.   Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

a.    Régie : Une ressource peut détecter une solution de changement, mais celle-ci reste dans son silo fonctionnel.

b.    Forfait : Le changement initie une modification du périmètre du projet, une action, un ou plusieurs livrables.

3.   Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

a.    Régie : Une ressource exécute une décision liée à la gestion des livrables. Elle aide, interagit, mais n'a pas de lead.

b.    Forfait : Il s'agit d'un processus, d'une cadence ainsi qu'une validation de la qualité des livrables.

4.   Les utilisateurs ou leurs représentants et les développeurs doivent travailler  ensemble quotidiennement tout au long du projet.

a.    Régie : En tant que ressource, je contribue à l'effort de façon Co-productive.

b.    Forfait : Le processus est le "comment" pour valider le ou les livrables du projet.

5.   Réalisez les projets avec des personnes motivées.

a.    Régie : Par principe, cette règle n'est pas liée au contrat en "régie". Mais, elle est une règle de vie.

b.    Forfait : Peut éventuellement apparentée au processus du projet. Le mode "forfait" donne la possibilité au client (sponsor) de revenir sur cette partie.

6.   La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

a.    Régie : Règle de vie. Mais que ce passe-t-il lorsque vous avez plusieurs prestataires dans la même équipe ?

b.    Forfait : C’est la partie communication du Process Projet.

7.   Un logiciel opérationnel est la principale mesure d’avancement.

a.    Régie : L'obligation de moyen n'oblige pas le développeur à fournir cela. C'est, dans ce cas, plutôt une mesure déontologique.

b.    Forfait : Il s'agit de la validation des livrables.

8.   Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

a.    Régie : Mais en fait, Oui/Non serait approprié. Oui pour l’équipe de développement. Non pour les autres acteurs du projet : MOA, Tests externes, BI, etc…

b.    Forfait : Tous les développements disposent d'une date de fin et une unité de mesure, même dans la recherche. Le forfait permet de conserver la main sur la gestion du temps.

9.   Une attention continue à l'excellence technique et à une bonne conception renforcent l’Agilité.

a.    Régie : Règle déontologique.

b.    Forfait : Règle déontologique.

10.                La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentiel.

a.    Régie : Ce n'est pas lié au mode régie en particulier.

b.    Forfait : Il s'agit avant tout de la réduction du risque d'échec et la sécurisation des livrables. Cependant trop de simplicité nuit à la créativité et réduit l’interactivité entre les membres des équipes autogérées dans un système complexe auto-adaptatif (cf. Cynefin).

11.                Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées.

a.    Régie : La régie lie un profil, un individu et pas une équipe.

b.    Forfait ; Le mode au forfait favorise la vente d'un projet. L'interaction du client sur l'organisation du projet est nulle. De ce fait, l'autogestion peut être sécurisée.

12.                À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

a.    Régie : Travail d'équipe

b.    Forfait : Amélioration continue = réduction des risques.

Conclusion :

·         L’Agilité en mode régie est un non sens. Quelle différence y-a-t-il entre un développeur agile et un développeur catholique ?  En régie, si vous envoyez un développeur agile chez un client « traditionnel » pensez-vous vraiment que celui-ci évangélisera tout le monde ? est-ce que c’est ce que l’on demande ?

·         Cette démonstration n’est pas parfaite car il y a toujours des cas particuliers.

·         Il y a des versions alternatives qui vont bien à l’agilité, tels que les contrats de support (tickets).

·         Dans mon cas, en tant que coach et Agile PMO, je ne fais que des contrats de support ou des contrats au forfait.

·         Très souvent, les contrats au forfait s’enchaînent les uns aux autres chez un client. A chaque fois, nous définissons un objectif (Plan de Release, Project Backlog) et celui-ci est géré en parallèle de façon collégiale avec le client.

Tu fais de l’agilité en régie? Nnoooonnn...

Le principe de la régie est de fournir des profils pouvant intégrer un projet ou, plus souvent, une équipe existante. Dans un autre contexte, on appelle cela de l’interim.

Mais, bon... c’est le marché qui décide.