L'intégration de Waterfall et Agile dans le cadre du Scaled Agile Framework (SAFe) peut sembler contradictoire à première vue, car ces approches de développement logiciel ont des méthodologies et des valeurs différentes. Cependant, dans certaines organisations, une telle combinaison peut être nécessaire pour répondre à des besoins spécifiques ou pour gérer des projets complexes.
L'exception étant, bien sûr, les nouvelles organisations ou les start-ups qui choisissent uniquement la méthode Agile. Mais la réalité est que même si ces organisations grandissent et que leur clientèle s'élargit, elles rencontreront des clients, d'excellentes ressources intégrées et d'autres vendeurs et parties prenantes qui , pour diverses raisons , exigent une livraison en cascade par opposition à un processus agile. Il peut s'agir d'une exigence gouvernementale ou simplement d'un manque de confort, d'adoption et de familiarité avec le processus agile.
Tout le monde ne peut pas ou n'accepte pas de faire le saut, quelle qu'en soit la raison, de sorte que la probabilité de maintenir les deux est élevée dans toutes les organisations et tous les secteurs.
Voici comment cela peut être réalisé :
1. Planification à long terme (Waterfall) : Les grandes lignes du projet peuvent être définies initialement en utilisant une approche Waterfall, avec des spécifications détaillées et des jalons clairement définis. Cela peut être particulièrement utile lorsque des exigences légales ou réglementaires doivent être respectées, ou lorsque le budget et les ressources doivent être fixés à l'avance. Par exemple, dans le développement de logiciels pour les industries réglementées telles que la santé ou la finance, où les exigences doivent être entièrement documentées avant le début du développement.
2. Planification itérative (Agile) : À l'intérieur de ces grandes lignes, les équipes peuvent ensuite travailler de manière Agile, en utilisant des itérations courtes pour développer, tester et livrer des fonctionnalités incrémentielles. Par exemple, une équipe de développement peut utiliser des sprints de deux semaines pour créer des fonctionnalités spécifiques, en utilisant des rétroactions régulières pour s'adapter aux changements de priorités ou aux nouveaux besoins des parties prenantes.
3. Gestion des risques (Waterfall) : Les activités de gestion des risques, telles que l'identification précoce des problèmes potentiels et la planification de la gestion des risques, peuvent être gérées de manière plus linéaire, suivant une approche Waterfall. Par exemple, une analyse des risques initiale peut être effectuée au début du projet pour identifier les principaux risques, puis des actions correctives peuvent être planifiées et suivies au fil du temps.
4. Flexibilité et adaptabilité (Agile) : Les équipes peuvent également utiliser des pratiques Agile telles que les revues de sprint et les démonstrations de produit pour s'adapter aux changements de priorités ou aux nouvelles exigences des clients. Par exemple, si une nouvelle fonctionnalité est demandée par un client, l'équipe peut rapidement l'intégrer dans la prochaine itération du produit sans perturber l'ensemble du plan de développement.
Que faut-il partager entre les deux méthodologies ?
Pour commencer, il est probablement important de discuter des aspects du programme qui doivent rester inchangés, qu'il y ait ou non une situation mixte. Tout d'abord, nous reconnaissons que le PMO existant peut assurer la gouvernance des programmes Waterfall et Agile. Le fait d'avoir une approche commune de la gouvernance permettra de prendre des décisions clés sur la base des mesures utilisées. Un aspect clé du PMO est qu'il devrait adopter une méthodologie globale qui exécute les mêmes fonctions de base d'un PMO traditionnel, comme la stratégie et le financement des investissements, la gestion des programmes et la gouvernance, mais en tenant compte de la méthode Agile.
Alors que le changement et l'adoption du programme devront se faire progressivement - cela ne se fera jamais du jour au lendemain - le meilleur plan d'ensemble est de trouver continuellement des moyens de faire évoluer le PMO vers le concept Agile et la méthodologie Agile au fur et à mesure que le temps passe.
Il existe trois scénarios possibles d'environnements mixtes qu'il convient d'aborder:
- Équipes indépendantes : Les programmes Waterfall et Agile sont totalement indépendants les uns des autres et doivent simplement être déployés dans une version commune.
Dans ce cas, les deux programmes sont principalement indépendants l'un de l'autre et peuvent être contrôlés et synchronisés. Dans ce scénario, la synchronisation tout au long du projet n'est pas nécessaire, car aucun des deux programmes ne dépend profondément de l'autre. Ces équipes peuvent même souvent livrer en production à des moments différents ou se réunir à la fin et être incluses dans la même version afin de maintenir la cohérence avec la communauté des utilisateurs. En ce sens, ces équipes sont synchronisées strictement au niveau du portefeuille du cadre SAFe, puisque la fonctionnalité fournie par chacune n'a pas besoin d'être intégrée avant la mise en production. Même si les livrables associés aux équipes sont indépendants, il est important pour le PMO de pouvoir suivre les progrès de chaque équipe de la même manière afin que les rapports et les mesures au niveau du programme soient cohérents.
- Faible dépendance : Il existe certaines dépendances, mais le succès n'exige pas une synchronisation constante.
Ce scénario est un peu plus compliqué et introduit une synchronisation temporelle des jalons de gouvernance qui sont nécessaires pour que les équipes s'assurent que leurs composants individuels s'intègrent bien. Dans la mesure du possible, les programmes s'efforcent d'aligner ces jalons sur les limites des itérations ou des PSI au niveau du programme dans le cadre de SAFe. L'équipe Agile ayant une vitesse d'horloge plus rapide, il est plus facile pour elle d'ajuster ses plans pour s'aligner sur les jalons de la cascade que l'inverse. Cela peut signifier l'introduction d'une autre itération de durcissement dans l'ISP pour permettre un point d'intégration ou la suppression d'une itération de développement si cela permet un point d'intégration plus précoce. Idéalement, l'équipe Waterfall peut également adopter une approche plus incrémentale pour développer le produit, de sorte que les longs cycles de publication ne soient pas présents et que la synchronisation et l'intégration, et donc un retour d'information rapide, interviennent beaucoup plus tôt dans le processus.
- Dépendance élevée : Des dépendances substantielles existent tout au long du développement, c'est pourquoi un niveau élevé d'interaction et de synchronisation est nécessaire pour que chaque programme soit couronné de succès.
Ce scénario est le plus compliqué et nécessite le plus haut niveau de synchronisation des équipes à forte dépendance. Dans ce scénario, la synchronisation est nécessaire au niveau de l'équipe et doit avoir lieu, au minimum, à chaque limite d'itération. Une interaction quotidienne peut être nécessaire dans certains cas pour des questions clés ou des dépendances et peut avoir lieu au niveau technique (architecte à architecte ou développeur à développeur) ou au niveau de l'entreprise (analyste à analyste). L'essentiel est que la méthode Agile ne doit pas attendre la méthode Waterfall. En d'autres termes, les équipes Agile ne doivent pas attendre que les équipes Waterfall aient achevé l'ensemble de leur cycle de développement pour commencer à s'intégrer. Les équipes agiles disposent de processus intégrés pour ces synchronisations régulières, tels que la planification de l'ISP, la planification des itérations, les réunions quotidiennes, la mêlée des mêlées et les démonstrations/rétrospectives des itérations. En outre, le volume élevé de dépendances nécessite un suivi détaillé des dépendances et des risques/problèmes associés. Il arrivera que l'équipe Agile doive faire des hypothèses afin de progresser dans ses itérations pendant que l'équipe Waterfall progresse vers un point d'intégration. Il est essentiel que ces hypothèses soient validées régulièrement et, si nécessaire, qu'elles soient utilisées pour conduire le remaniement approprié au sein de l'équipe Agile pour les hypothèses qui ne se sont pas vérifiées.
Dans le scénario indépendant, la synchronisation au niveau du portefeuille dans le cadre de SAFe est sufficient. Dans le cas d'une faible dépendance, une synchronisation plus fréquente est nécessaire, au minimum au niveau des incréments potentiellement expédiables de la solution qui sont définis au niveau du programme dans le cadre. Enfin, dans le scénario de forte dépendance, des points de contact beaucoup plus fréquents seront nécessaires, impliquant une synchronisation d'équipe à équipe.
En résumé:
Il est essentiel de commencer avec un état d'esprit agile, à la fois au sein du PMO et dans l'ensemble de l'organisation. Ensuite, avec votre PMO, continuez à évoluer vers une pensée et des comportements agiles complets au fur et à mesure que le temps passe.
En établissant une structure de gouvernance commune aux équipes Agile et Waterfall, le PMO peut superviser et piloter le portefeuille global de manière appropriée.
En exploitant la flexibilité inhérente aux processus Agile, la synchronisation entre les équipes Agile et Waterfall est possible à n'importe quelle fréquence dictée par la structure de dépendance entre les équipes.
En fin de compte, que l'environnement soit purement SAFe ou mixte, l'objectif de l'entreprise est toujours le même : à savoir la "livraison de valeur durablement la plus rapide".
En résumé, la strategie en intégrant Waterfall et Agile dans le cadre de SAFe est gagnante. Les organisations peuvent bénéficier de la planification à long terme et de la gestion des risques offertes par Waterfall, tout en exploitant la flexibilité et l'adaptabilité d'Agile pour répondre aux besoins changeants du marché et des parties prenantes.