Un avis d’expert signé par Guillaume Goguelin, de Talisker Consulting.

Backlog infini et projet sont antinomiques

Pourquoi faire des projets alors qu’on pourrait faire de l’agile ?

Opposer les deux mots vous semble absurde ? Pourtant dans certaines DSI la question est sérieuse car l’agilité tend à faire disparaitre le mode projet.

En effet, une fois lancées dans l’agilité, les DSI ont souvent tendance à ouvrir un backlog sans fin, alimenté en continu par les métiers et faisant l’objet de déploiements fréquents, voire continus. Or, par définition, un projet a une date de début et une date de fin. Peut-on encore parler de projet avec ce système de backlog infini ?

 

A mon sens non : dans ce cas, on est plutôt dans un système de maintenance applicative utilisant les principes de l’agilité. Attention, je ne dis pas qu’il n’est pas possible de combiner les deux. Le déploiement continu de petites évolutions ou de correctifs sur la base d’un backlog priorisé n’a plus à faire ses preuves en termes de satisfaction client.

La dérive que je souhaite souligner est l’utilisation de ce système de backlog infini pour faire passer des évolutions majeures répondant à des nouveaux besoins qui, d’ordinaire, devraient faire l’objet de projets. Et qui dit projet dit arbitrage, décision d’investissement et inclusion dans la stratégie d’entreprise.

Finalement, ça veut dire quoi faire du projet agile ?

 

Répondre au besoin de manière efficiente

Un projet agile part d’un besoin client identifié. J’entends souvent dire : « on fait du projet agile quand on ne sait pas ce que l’on veut ». Pour moi, quand on lance un projet agile, on sait ce qu’on veut ! En revanche, on ne sait pas forcément comment on le veut : la forme que va prendre la solution qui va répondre au besoin n’est pas définie à l’avance.

Les pratiques agiles vont permettre de répondre à ce besoin au plus proche des attentes utilisateurs et d’adapter la solution si celui-ci venait à évoluer dans le temps (grâce aux démos utilisateurs, à la priorisation par la valeur client, au mode itératif…).

Mais elles vont également permettre d’y répondre de manière efficiente en fixant le budget et le planning à l’avance.

 

Si on traduit en termes agiles, il s’agit de définir en amont du projet :

  • L’équipe projet et une estimation de sa vélocité (le nombre de points de complexité qu’elle peut développer par itération)
  • La limite de points de complexité totale du projet
  • Et par déduction des deux points précédents : le nombre d’itérations du projet

Fixer une limite de points de complexité renforce grandement la priorisation par la valeur du backlog. En effet, une fois cette limite atteinte, le client se rend compte que toutes les user-stories qu’il ajoute au backlog ne seront pas réalisées dans le projet. Il redouble alors d’attention sur la priorisation du backlog pour conserver uniquement les éléments nécessaires. On s’affranchit du superflu et on répond au mieux au besoin en respectant les contraintes budgétaires et temporelles imposées.

 

On fixe un budget, donc on l’arbitre

S’il faut fixer un budget, il faut l’arbitrer. On en revient au sujet initial du backlog infini : comment définir un budget avec ce fonctionnement d’un backlog ouvert et alimenté sans fin et sans objectifs définis à l’avance ?

La réponse est à la fois simple et dramatique : on procède comme pour une maintenance applicative, on alloue une enveloppe. La définition d’une enveloppe pour gérer les évolutions du SI c’est l’assurance de voir apparaitre 2 dérives :

  • L’utilisation de l’enveloppe par les clients plus par principe que par besoin (l’enveloppe existe, pourquoi ne pas l’utiliser ?)
  • Le risque de divergence ou du moins de non-adhérence entre les évolutions SI et la stratégie d’entreprise du fait de la suppression d’arbitrages et de décisions d’investissement partagées (le backlog est ouvert, il suffit de l’alimenter)

Une DSI doit-elle mettre en place une maintenance applicative ? Oui évidemment.

Peut-elle la gérer en mode agile ? Oui, pourquoi pas.

Peut-elle gérer l’ensemble de ses évolutions SI dans cette « maintenance applicative agile » ? Non certainement pas !

Une DSI peut allouer une enveloppe budgétaire pour sa maintenance applicative, mais elle se doit de gérer le reste de son budget dédié aux évolutions de manière structurée. La planification de projets avec des budgets définis me semble être une bonne manière de faire.

L’agilité a tendance à faire oublier ces principes en raison de la facilité de réalisation qu’elle peut apporter et de la restitution du pouvoir de priorisation entre les mains des métiers. Si vous leur ouvrez toutes les portes, les métiers auront tendance à vouloir tout passer en petites évolutions agiles : ça marche, c’est rapide et il n’y a pas besoin d’arbitrage.

Pourtant les méthodes agiles ont initialement été définies comme des méthodes projet, et c’est dans ce contexte qu’elles donnent les meilleurs résultats. Réintroduire un peu de stratégie et de vision à moyen/long termes dans vos relations avec les métiers vous permettra au final de générer plus de valeur pour l’entreprise.

Pour résumer : n’hésitez pas à abuser de l’agilité, mais ne la laissez pas enterrer la logique projet pour autant !

 

 

Envie de commenter cet article ou de nous proposer votre propre témoignage ? Inscrivez-vous sur Atout DSI !

FavoriteLoadingAjouter à mes favoris

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.