Quelles bonnes pratiques du SCRUM sont applicables au Cycle en V ?

Outre la théorie, la méthodologie SCRUM et celle en V dite « classique » ne sont pas si éloignées dans leur application opérationnelle, malgré le fait qu’elles soient trop souvent présentées comme rivales. Pour le démontrer, cet article s’intéresse aux pratiques SCRUM applicables au cycle en V, leur mise en place et les conditions qui optimiseront leurs résultats.

« Agilité », « méthode agile », « approche agile », les appellations de cette méthode de management de projet sont aussi nombreuses que les avis sur celle-ci. Une énième méthodologie à la mode qui ne s’avère adaptée qu’à des contextes très particuliers pour certains, un réel « game-changer » pour d’autres… Une chose est sûre : cette méthode connaît un succès et un intérêt sans précédent, aussi bien au niveau managérial qu’opérationnel.

« Consistency reduces complexity »

Toute personne ayant été exposée de près ou de loin à une méthodologie agile connait ce fameux adage. Littéralement traduit par « la consistance réduit la complexité » et bien qu’évident, il n’est pas toujours facile à appliquer concrètement aux projets. Ladite consistance, en méthodologie SCRUM, s’illustre par des cérémonies régulières (Planning, Démonstration, Rétrospective, etc.), d’une durée maximum et d’une fréquence définie à l’avance, qui plus est en consensus.

Pour s’adapter au cycle en V, il est possible de garder l’intitulé des instances (ce qui réduira le changement et donc la résistance à celui-ci) tout en conservant la même rigueur que SCRUM : un comité de projet hebdomadaire pour le suivi, un comité de pilotage mensuel pour le bilan et l’ajustement, etc. Ici, la clé n’est pas le nombre d’instances, qui lui peut varier et évoluer en fonction de la situation dans laquelle le projet se trouve, mais bien la fréquence de celles-ci.

Pour mettre en place cette bonne pratique, il faut d’abord communiquer dessus en expliquant le pourquoi, le comment et les bénéfices attendus à chacun, et ce afin que ces instances ne soient pas perçues comme des “réunions de plus”. Ensuite, il est possible de bloquer les agendas des mêmes personnes, sur le même créneau horaire, pour la même durée, à échéance régulière, en communiquant dessus au préalable. Les nombreuses minutes régulièrement consacrées à la “logistique” pure des cérémonies projet pourront alors être consacrées aux tâches à forte valeur ajoutée (plan d’action, support, CR), et ce pour toutes les parties prenantes.

Une équipe de développement transverse et autonome

De par sa dénomination, l’équipe de développement est un élément commun à la méthode classique et au SCRUM : elle est en charge de la production d’un livrable « fini » et utilisable. Cependant, il existe une différence majeure entre une équipe de développement “classique” et une dite “agile” : leur composition. En méthode classique, l’équipe est souvent composée majoritairement de développeurs, avec un niveau d’expertise souvent fractionné. Simplement dit : chacun a un domaine d’expertise précis mais sait peu de celui de son collègue. En méthode agile, l’équipe est auto-organisée dans son travail et l’accomplissement de ses tâches, pluridisciplinaires et sans cloisonnements. En plus des développeurs, il n’est pas rare d’y trouver des architectes, des testeurs, tous réunis sous la même enseigne.
De retour à la méthode classique, s’efforcer de constituer une équipe de développement aux caractéristiques « agile » présente plusieurs avantages. Premièrement, sa pluridisciplinarité palliera au problème des back-up absents ou incompétents, évitant ainsi les fameuses interruptions dans les projets aux périodes « creuses ». Deuxièmement, son auto-organisation améliore la productivité et responsabilisent les membres sur le travail qui doit être effectué.
Pour la mettre en place, il est possible de demander explicitement aux parties prenantes d’inclure différents profils complémentaires dans leur équipe lors de la commission de cadrage projet. Si cela n’est pas possible, il faudra alors s’assurer d’inclure les différents profils lors des échanges au cours du projet, et idéalement de les inclure activement dans les cérémonies que vous mettrez en place. Enfin, il est également envisageable d’organiser des formations au sein de l’équipe pour une montée en compétence accélérée. La formation pourra en effet être animée par les personnes au sein même de l’équipe, à tour de rôle, sous forme de module.

Ecouter pour mieux s’adapter

Un des problèmes les plus fréquemment rencontrés sur un projet informatique est de développer une application avec des fonctionnalités qui ne sont plus en phase avec les attentes métier ou, plus simplement dit, des fonctionnalités “inutilement coûteuses”. A l’inverse, il est tout aussi fréquent de développer une application avec une fonctionnalité manquante, malheureusement structurante aux yeux du client. D’où viennent ces développements inutiles ? Comment peut-on passer à côté d’une fonctionnalité majeure ? La raison est simple : le manque de communication.
L’environnement juridique, réglementaire, technologique et concurrentiel et, par ricochet, les attentes métier qui en découlent, évoluent à un rythme que même un chef de projet chevronné ne peut suivre. Aux spécifications fonctionnelles, tout est en règle. Arrivé à la recette, il est déjà trop tard : ce qui est marqué dans les spécifications ne reflètent plus les attentes du client. Ce casse-tête devenu fatalité pour beaucoup peut pourtant être résolue simplement : en écoutant. Ecouter, c’est recueillir à un instant t les attentes et besoins des utilisateurs finaux. Mais écouter ne suffit pas : il faut écouter régulièrement et activement, c’est-à-dire à une fréquence définie et de manière structurée. 

Tout comme le Sprint Review de la méthode Agile se tenant à chaque fin de sprint, soit environ toutes les 3 semaines, il est également envisageable d’organiser en cycle en V un atelier avec les acteurs principaux du projet pour faire un point sur ce qui a été fait aujourd’hui et ce qui sera fait demain, et ce à fréquence régulière. Pour les projets de petite et moyenne taille, un atelier « feedback » par mois peut suffire. Contrairement à ce que certains pensent, c’est bien le client qui sera le mieux placé pour dire si la direction prise est la bonne, et non l’équipe projet. En vous appliquant à écouter, vous augmenterez significativement vos chances de ne rien produire en trop, et sans rien oublier.

Des bonnes pratiques

Aucun secteur, aucune entreprise, aucun projet n’est immun face aux traverses classiques des projets : baisse de productivité, évolution des besoins, inconsistance des cérémonies, pour ne citer que les plus répandues. Ayant conscience de ces problématiques inhérentes aux projets SI, des experts ont, au fil des années, développé différentes méthodologies, différentes solutions pour aider les entreprises à minimiser leurs impacts budgétaires et temporels. Aujourd’hui, bon nombre d’articles et de discussions gravitent autour de la rivalité de ces solutions (“Cycle en V vs Agile”), délaissant le fort potentiel de leur miscibilité (“Cycle en V + Agile”). Suivant la réflexion de cet article, l’actuelle diversité des nouvelles méthodologies projet et leur expansion croissante (e.g., SAFe) constitue une formidable base pour dénicher soi-même des bonnes pratiques à appliquer à ses projets.