Contrat Agile à forfait: une navigation parfois délicate mais toujours possible

L’Agilité, tout le monde connaît maintenant. Les cadres de développement informatique, tels que Scrum, qui ont émergé il y a 10 ans, sont maintenant la norme. Effectivement, la plupart des projets informatiques se prêtent très bien à ce mode étant donné leur complexité et l’incertitude qu’ils comportent.

Dans une entreprise de service faisant du développement pour des clients sous forme de contrat à forfait, est-ce possible d’utiliser ce mode de développement sans le dénaturer? Comment travailler avec nos clients en mode MVP (Minimum Viable Product) et répondre à un appel d’offres sans détailler toutes les fonctionnalités à réaliser?

C’est à cette question épineuse à laquelle nous tentons de répondre au quotidien chez Uzinakod. Il est évident que le développement informatique dans un domaine complexe avec des besoins d’affaires changeants est impossible à planifier avec exactitude à l’avance.

Alors pourquoi s’entêter à rédiger des contrats avec un budget, une durée et une portée fixe?

Le promoteur, capitaine du bateau

Un projet en mode Agile doit avoir un capitaine de bateau impliqué au quotidien pour guider l’équipe et s’assurer qu’elle travaille sur la bonne chose au bon moment.

Le contrat doit plutôt parler de risques et gains partagés entre les deux parties. De modules à développer plutôt que de fonctionnalités. De collaboration plutôt que de responsabilités. D’hypothèses plutôt que de certitudes. À l’étape de l’appel d’offres, il est possible d’établir une vision pour le produit et de définir les modules qui seront abordés, mais il est impossible de déterminer exactement la portée complète de tout le contrat.

C’est tout au long du projet que le carnet de produit se définira clairement et c’est le promoteur qui prendra les décisions sur le travail à accomplir.

Un capitaine de bateau ne regarde pas ailleurs tout au long du trajet pour dire à la fin que nous ne sommes pas arrivés à la bonne destination.

Le client, promoteur, Product Owner (PO), proxy PO, ou Power user, bref celui qui détermine les fonctionnalités, l’ordre d’exécution, la valeur ajoutée et qui donne la rétroaction si précieuse à l’équipe: cet acteur important doit être impliqué et intéressé tout au long du projet pour maximiser ses gains et minimiser les risques en s’assurant que le temps est investi au bon endroit sans gaspillage.

De plus, pour l’équipe de développement, il n’y a rien de plus démotivant que de travailler d’arrache-pied sur une fonctionnalité non désirée ne répondant pas au besoin ou même de n’obtenir que des rétroactions superficielles du promoteur démontrant un manque d’implication et de compréhension de sa part.

Des signes que l’implication du promoteur est insuffisante pour garantir le succès du projet?

1. Le promoteur s’en remet à l’équipe de développement pour détailler le travail à faire et ne participe pas ou très peu à l’élaboration du backlog.
2. On fait référence aux éléments mentionnés dans le contrat plutôt que mettre des efforts à valider et prioriser le travail.
3. Peu de tests utilisateurs sont faits tout au long du projet, les démos ne sont pas suffisantes.
4. Le discours est porté sur l’entièreté des fonctionnalités plutôt que sur la valeur ajoutée et le minimum requis pour répondre au besoin.
5. Le promoteur n’est pas assuré de la réussite du projet et ne le promeut pas auprès de son équipe. Il ne se sent pas comme faisant partie de la solution.

Si vous observez un ou plusieurs de ces signes, une mise au point est nécessaire. Effectivement, les deux parties gagnent à avoir un discours honnête et à concentrer leurs efforts sur la valeur d’affaires ajoutée, la définition et la validation au quotidien des développements effectués.

Comment redresser la barre?

Cela passe par quatre étapes:

1. Se mobiliser autour d’un objectif commun, amener le système en production le plus rapidement possible en se concentrant sur l’essentiel.
2. Trouver un ou plusieurs interlocuteurs experts du côté du client, pouvant piloter le projet et réserver une proportion importante de son temps pour le faire.
3. Impliquer le client activement au quotidien pour définir les besoins, prioriser les développements, identifier les fonctionnalités superflues dans un premier temps et valider l’exactitude des fonctionnalités réalisées.
4. Communiquer de façon transparente entre les deux parties tout au long du projet. Il est important d’avoir des conversations moins faciles et de souligner les erreurs ou imperfections et de toujours viser à s’améliorer.

Des signes que la collaboration est fructueuse:

1. Le client participe à l’élaboration du backlog. Il prend les décisions sur l’ordre d’exécution des développements et commente des stories sur leur portée avant leur réalisation. Encore mieux, il ajoute des stories au backlog.
2. Il participe aux démos de manière active en posant des questions et en prenant des notes. Par la suite, il teste l’application et fait des commentaires pertinents et constructifs à l’équipe pour maximiser la valeur ajoutée.
3. Il identifie du travail non nécessaire et non prioritaire et défend sa vision auprès de son équipe. Il approuve des alternatives moins complexes répondant au besoin.
4. Il a une vision de son produit à court, à moyen et à long terme et évangélise ce dernier auprès de son équipe.

Évidemment, travailler sur un projet Agile pour un client externe complexifie les choses. Il est toutefois possible d’y arriver en éduquant le promoteur, en identifiant les bonnes personnes et en lui faisant prendre conscience des risques, des coûts et des impacts de ses décisions ou de son manque d’implication.

Le meilleur moment pour mettre les bases et bien démarrer le processus est en début de projet. Il faut aussi s’assurer d’avoir les bons acteurs autour de la table. Un promoteur de choix est quelqu’un qui est à l’écoute, flexible et qui connaît le domaine d’affaires sur le bout de ses doigts.

De plus, tout au long du projet, il est de notre devoir d’accompagner le promoteur et de l’aider à comprendre notre réalité. Nous devons aussi être à l’écoute de ses besoins et toujours nous assurer de valider nos décisions.

Voici des exemples d’actions quotidiennes qui aident à établir une relation de confiance:

• Mentorer le promoteur pour qu’il comprenne bien les tenants et aboutissants de ce rôle crucial pour le bien du produit
• Faire des tests avec le client pour s’assurer qu’il comprend et valide les fonctionnalités
• Exposer les risques ou la complexité de choix de solution pour que le promoteur puisse prendre des décisions éclairées
• Aider notre client à rester concis dans ses besoins pour permettre un développement itératif de fonctionnalités
• Toujours prioriser les développements à haute valeur ajoutée pour l’équipe métier
• Avoir un moyen simple pour l’équipe métier d’entrer en communication avec l’équipe de développement (exemple: une boîte de support)

Il est aussi extrêmement important d’avoir un vis-à-vis du côté de l’équipe de développement, palliant le manque d’expertise technique du PO externe qui est issu du domaine d’affaires et qui ne baigne pas dans un domaine de développement informatique au quotidien. Les clients sont des mines d’or d’informations, sachons en tirer parti activement. Apprenons les règles de l’art à notre capitaine de bateau et laissons-nous guider à bon port.