Les meilleurs frameworks pour adapter votre processus Agile
Beaucoup d’entreprises adoptent la méthodologie de gestion de projet Agile pour optimiser l’efficacité, la productivité et la collaboration. Vous l’utilisez peut-être déjà au sein de votre équipe de gestion de projet ou de développement applicatif, et vous vous demandez si le reste de l’entreprise peut bénéficier de ses avantages.
Bonne nouvelle : vous pouvez tout à fait adapter votre processus Agile, à condition de mettre en place un framework adéquat. Dans ce guide, nous vous expliquons comment adapter la méthodologie Agile et vous présentons les principaux frameworks qui pourraient convenir à votre équipe, notamment SAFe, LeSS, DA et SoS.
Cet article aborde les points suivants :
- Rôle d’Agile at Scale
- Éléments à prendre en compte dans le cadre de l’adaptation d’Agile
- Scrum at Scale
- Large-Scale Scrum (LeSS)
- Disciplined Agile (DA)
- Scaled Agile Framework (SAFe)
- Autres frameworks notables
- Choix du framework
- Adaptation de votre équipe Agile
Rôle d’Agile at Scale
Il est probable que votre entreprise applique déjà les principes Agile pour la gestion de projet. Si c’est le cas, vous ressentez peut-être le besoin d’étendre votre processus Agile afin que le reste de l’entreprise puisse en bénéficier.
Agile at Scale est le processus qui consiste à étendre la méthodologie Agile à toutes les équipes des différents services de l’entreprise. Simplifiant les opérations au niveau des équipes tout en permettant aux grandes structures de suivre des procédures similaires, l’adaptation d’Agile permet d’adopter une approche durable et efficace pour gérer les projets dans toute l’entreprise.
Cette adaptation comporte de nombreux avantages. Tout d’abord, elle permet d’aplanir les structures de reporting et de communiquer clairement à chacun et chacune, des contributeurs et contributrices aux membres de la direction, ce qui est attendu de leur part dans le cadre d’une structure hiérarchique : définition d’objectifs, jalons, processus de validation, etc. Outre une meilleure gestion de projet, il en résulte une communication renforcée, une collaboration plus efficace et des équipes plus souples, qui s’adaptent plus facilement à l’évolution des besoins.
Dans le cadre de l’adaptation d’Agile, les gestionnaires de projet n’ont pas seulement besoin de plans et de processus. Les outils de suivi peuvent fournir à la direction des insights sur les dépendances et les risques, en identifiant les domaines dans lesquels les équipes doivent collaborer et les obstacles potentiels aux progrès. Ils apportent aussi de la transparence en matière de hiérarchisation des efforts.
Pour les équipes à distance ou hybrides, des outils de communication sont aussi nécessaires pour inciter à la collaboration. Vous devez tenir compte du fait qu’en fonction de sa culture, chaque équipe est susceptible d’employer différents moyens d’interaction par défaut. Les plateformes que vous choisirez doivent permettre de rapprocher les parties prenantes et les contributeurs et contributrices de toute l’entreprise avec une relative simplicité.
Il est important de savoir quand adapter la méthodologie Agile mais aussi pourquoi. Il faut notamment se demander si les méthodes de développement actuelles répondent à la demande. Si la réponse est non, le problème peut avoir d’autres causes que l’affectation des ressources. L’adaptation de la méthodologie Agile peut aussi améliorer la gestion des dépendances entre les équipes et réduire les délais de validation par les parties prenantes tout en fournissant à d’autres services, par exemple le marketing ou la réussite client, les informations nécessaires pour communiquer avec des groupes externes comme la clientèle.
Bien sûr, la mise en œuvre d’Agile at Scale a aussi son lot de difficultés. La maîtrise est souvent la première chose à laquelle certaines personnes doivent renoncer, car elles laissent des processus et procédures établis prendre le dessus pour la gestion de projet, la définition des besoins et les validations. La transparence étant de mise en matière d’organisation, de répartition et d’évaluation du travail, le personnel devra davantage rendre compte de ses contributions.
Au début, la collaboration renforcée peut également peser sur les services, qui n’ont pas l’habitude de se justifier auprès d’autres équipes concernant leurs livrables. La mise en œuvre de systèmes et d’applications pour faciliter le développement et l’adaptation d’Agile peut aussi ralentir les processus dans un premier temps, en raison du déploiement des solutions et de la formation des équipes à leur utilisation.
Éléments à prendre en compte dans le cadre de l’adaptation d’Agile
Il n’existe pas qu’une seule façon d’être agile. Selon leurs besoins et leur structure, les entreprises peuvent avoir recours à différents frameworks ou méthodes. Le choix de celui qui vous convient (ou l’adoption d’une nouvelle méthode) peut être source d’agacement pour les gestionnaires de projet ou les parties prenantes peu au fait de la méthodologie Agile.
Nous étudierons plus loin certains des frameworks les plus souvent utilisés pour adapter Agile, à savoir S@S, LeSS, DA et and SAFe. Chacun d’eux a été conçu pour apporter de la souplesse lors de l’application à toute l’entreprise.
Plusieurs éléments doivent être pris en compte lors du choix du framework d’adaptation d’Agile approprié pour l’entreprise. Vous devez déterminer le degré de souplesse dont vous avez besoin au sein du framework. Vous pouvez aussi étudier votre framework actuel pour savoir s’il est plus judicieux de l’adapter que de mettre en place une nouvelle structure, ce qui peut s’avérer fastidieux. Autre question importante : le périmètre de déploiement du framework, car il existe différentes approches plus efficaces pour incorporer plusieurs équipes ou services dans leurs processus.
Vous devrez aussi réfléchir aux difficultés liées à l’implémentation d’une méthodologie Agile, quelle qu’elle soit. Si nous avons déjà abordé plusieurs d’entre elles, la clé de toute modification d’un processus est l’état d’esprit de chaque contributeur ou contributrice. Les gestionnaires de projet et parties prenantes devront réussir à convaincre leur équipe pour qu’elle change ses méthodes de travail afin de renforcer la transparence et d’adopter des protocoles jusque-là inconnus. Ce changement de culture d’entreprise peut être facilité par les responsables qui font vraiment confiance à la méthodologie Agile et sont en faveur de l’autonomisation des effectifs.
Avant de poursuivre, il est important de préciser que plus de la moitié des équipes adoptent Scrum comme méthodologie Agile. Nombre de frameworks Agile adaptés s’appuient donc sur la méthode Scrum pour garantir la cohérence et une implémentation fluide. Vous trouverez ci-dessous les différentes méthodologies Agile adaptées, classées par ordre de complexité croissante.
Scrum at Scale
Scrum at Scale ou S@S est le framework le plus simple de cette liste pour adapter Agile. Il étend le processus Scrum que nombre de gestionnaires de projet connaissent déjà et l’applique dans un contexte plus large.
En résumé, Scrum incite les équipes à collaborer autour d’un but commun. Pour adapter cette approche, imaginez une pyramide avec les équipes de développement en bas et les autres empilées par-dessus, qui représentent les contributeurs, contributrices et parties prenantes nécessaires au bon déroulement des processus. Cette coordination permet aux équipes de connaître leur rôle et la hiérarchie, mais aussi d’organiser les processus, les tâches et les validations.
Le développement Scrum est une approche empirique qui privilégie la transparence et l’adaptabilité en opérant de manière itérative pour atteindre des objectifs bien définis. Avec Scrum, les équipes peuvent s’organiser via une hiérarchisation claire des tâches et des réunions régulières, tout étant conçu pour limiter les obstacles au développement. Les tâches incrémentielles sont fractionnées, puis leur difficulté est évaluée par l’équipe, ce qui permet de prévoir précisément les délais d’achèvement et de définir plus clairement les besoins et livrables en matière de fonctionnalités.
Scrum rassemble des équipes composées de responsables produit, de chefs et cheffes d’équipe Scrum et de développeurs et développeuses qui participent à divers évènements : « mêlées », séances de planification, revues de sprint, etc.
Scrum at Scale reprend ces principes fondamentaux et les transpose à de petites équipes gérables au sein d’une entreprise. La démarche peut inclure des ajouts aux processus de développement et leur empilement. Elle peut aussi impliquer le fractionnement d’autres équipes afin de garantir des livrables clairs d’une division à l’autre. Un ou une Scrum Master est désignée pour superviser la totalité du framework et identifier les domaines dans lesquels il est possible de renforcer l’efficacité ou d’éliminer les blocages au sein des équipes.
Notez que S@S est le nom exact du framework Agile adapté. Scrum of Scrums (SoS) est une méthode permettant d’organiser plusieurs équipes. On la confond souvent avec Scrum at Scale, les deux dénominations étant similaires.
Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS) permet de s’adapter à la croissance des équipes de manière un peu plus structurée qu’avec Scrum at Scale. LeSS reprend le framework Scrum et l’applique avec une équipe Scrum, dans laquelle un ou une seule Scrum Master se charge de gérer les backlogs et de définir les différentes tâches. Les personnes qui contribuent à Scrum sont ensuite réparties au sein de cette structure et se voient attribuer les différents livrables constitutifs d’une application.
Fonctionnant comme une approche d’équipe unique, LeSS simplifie les réunions et les évaluations en instaurant une mentalité collégiale, qui prime sur les cloisonnements et les séances séparées.
Comme Scrum at Scale, LeSS repose sur les principes de développement Scrum, mais aussi sur ceux du développement de produits Lean. Ce framework cherche à réduire le gaspillage des ressources et du temps consacrés aux tâches. L’approche implique des cycles de développement courts (des « sprints ») qui permettent de concevoir de manière itérative des applications pouvant être commercialisées plus efficacement. Elle élimine les obstacles à la communication soit en incorporant l’ensemble des contributeurs et des contributrices au sein d’une seule équipe, soit en rassemblant les équipes Agile dans le cadre d’évaluations et de réunions qui facilitent la compréhension.
L’une des principales différences avec LeSS vient du fait que toutes les équipes et l’ensemble des contributeurs et des contributrices suivent le même calendrier pour mettre au point une application viable. Au lieu d’intervenir à différents stades de développement et de travailler sur différents composants ou fonctionnalités, les équipes de développement s’efforcent de collaborer via la répartition des tâches pour produire des résultats au cours d’un sprint donné. Tout le monde travaille à partir du même backlog et de la même liste de tâches, en s’efforçant de proposer des solutions avec plus de régularité et d’efficacité.
Disciplined Agile (DA)
Pour mieux s’organiser, certaines équipes utilisent un framework Disciplined Agile (DA). Avec ces outils, les responsables produit et Scrum Masters peuvent personnaliser leur approche en fonction des besoins particuliers de l’entreprise. L’un des principaux objectifs de ce framework est de simplifier le processus décisionnel via l’itération des changements et des tâches de développement.
Bien que DA incorpore certains aspects de Scrum comme les sprints et les backlogs, il donne la priorité aux ressources humaines et permet à la direction de prendre les décisions nécessaires pour avancer. Il s’applique aussi plus largement à l’entreprise dans son ensemble, en traitant tous les processus et en incorporant leurs apport aux modes de fonctionnement du développement.
Cette approche offre davantage de structure. En général, Disciplined Agile couvre quatre aspects essentiels : l’état d’esprit, les personnes, le flux et les pratiques. Chacun inclut des définitions qui établissent les rôles, responsabilités, cycles de vie et workflows que doivent suivre les effectifs à tous les échelons.
DA se distingue aussi en permettant à la direction de personnaliser la structure de développement et les processus itératifs selon ses besoins précis. Par conséquent, si DA peut rigidifier les processus après leur déploiement, ceux-ci sont relativement souples lorsqu’ils sont définis initialement par les gestionnaires de projet. Cette approche peut s’avérer particulièrement utile pour les grandes entreprises en quête de structure, mais pour lesquelles l’implémentation stricte de Scrum n’est pas totalement applicable aux processus métier.
Scaled Agile Framework (SAFe)
Les entreprises qui recherchent un processus conçu pour une implémentation à grande échelle peuvent opter pour le Scaled Agile Framework (SAFe) qui met en œuvre une planification au niveau des équipes et de l’entreprise pour s’assurer que des mesures gage d’efficacité globale sont en place.
S’il est semblable à Scrum, en particulier lorsqu’il est appliqué aux équipes, le framework SAFe ajoute les perspectives de programme et de portefeuille pour aider la direction et les responsables à hiérarchiser la charge de travail jusqu’au niveau des tâches.
Au lieu que tous les membres d’une équipe travaillent sur la même initiative, SAFe applique des approches itératives simultanées à de grands groupes de développement. Appelées « Agile Release Trains » (ART), ces équipes sont constituées autour de projets ou de livrables communs et travaillent sur des initiatives fixes au sein du framework d’ensemble. Par conséquent, les développeurs et les développeuses d’un groupe d’équipes peuvent intervenir sur un sujet totalement différent de celui d’un autre groupe d’équipes. Les grandes entreprises peuvent ainsi faire progresser leur pipeline tout en simplifiant leurs opérations et leurs objectifs.
Les activités au niveau du portefeuille montrent la voie et la direction est chargée de définir une vision pour les produits et services de l’entreprise. Les gestionnaires de projet les réduisent à des livrables alignés sur les stratégies commerciales. Il en résulte une approche descendante dans laquelle la direction définit les attentes, les ART se voient attribuer des initiatives et les équipes se voient confier des tâches qui s’inscrivent dans une perspective plus large.
Le framework SAFe est celui qui oriente le plus les équipes Agile, car il définit les critères de réussite et corrèle les tâches directement aux objectifs, tout en permettant à chaque groupe de développement de travailler à son rythme. C’est toutefois l’un des frameworks Agile les plus complexes, qui peut s’avérer trop rigide pour certaines entreprises. L’orientation venant d’en haut, la direction générale a aussi un rôle pratique, qui peut parfois contraindre les équipes de développement et limiter leur capacité à être agiles.
Autres frameworks notables
Si les frameworks précédents sont parmi les plus plébiscités, en voici quelques autres qui méritent d’être étudiés.
Nexus
Prochez de Scrum at Scale (à quelques ajustements près), Nexus permet aux gestionnaires de projet et aux parties prenantes les plus haut placées d’avoir plus de poids dans la coordination des équipes Agile. Ainsi, la planification de sprint s’opère en une fois pour toutes les équipes concernées, et les groupes se rassemblent pour la revue de sprint et les réunions rétrospectives afin que tout le monde puisse prendre connaissance des expériences retirées des processus communs.
Modèle Spotify
Ce modèle offre un moyen global de structurer l’entreprise tout entière et pas seulement les équipes de développement. Il crée des sous-groupes et permet aux personnes de définir leurs propres tâches et livrables en fonction des objectifs de l’entreprise. Semblable à une structure matricielle, il peut laisser à désirer en matière de responsabilités, les contributeurs et les contributrices jouissant d'une plus grande autonomie qu’avec les frameworks Agile.
Enterprise Kanban
Cet autre modèle moins classique applique la méthode de gestion de projet Kanban à tous les aspects et services de l’entreprise. S’il établit un workflow clair que les contributeurs et les contributrices doivent suivre et qu’il est généralement associé à une application de visualisation, Enterprise Kanban n’indique pas précisément comment l’entreprise doit être structurée.
Choix du framework
Le choix du framework peut être fastidieux et intimidant. Mais vu le nombre de possibilités à disposition, toutes les entreprises doivent pouvoir trouver un framework adapté à leurs besoins. Pour rappel, la philosophie Agile consiste à mettre en place des processus et des procédures pouvant être adaptés ou assimilés en fonction de vos besoins précis.
Il convient aussi de noter que si votre entreprise a déjà mis en place un framework, comme Scrum, il peut être judicieux d’opter pour une approche similaire afin d’éviter tout problème de conduite du changement. Si votre entreprise est en forte croissance ou que vous envisagez de constituer une équipe de développement à l’échelle de l’entreprise dans un avenir proche, il peut être intéressant de mettre d’emblée en œuvre un framework plus complexe qui évoluera en même temps que vous.
En général, les frameworks reposant sur Scrum conviennent aux organisations horizontales ou aux entreprises qui n’ont pas de besoins complexes pour avancer sur les tâches. À l’inverse, un framework comme SAFe sera plus adapté à une entreprise qui souhaite édicter des actions pour ses diverses activités et s’assurer qu’elles s’inscrivent dans le cadre d’objectifs métier fixés de façon plus classique.
Voici trois facteurs essentiels souvent pris en compte dans le cadre du processus de sélection du framework Agile :
- Taille. En général, une structure plus marquée, comme celle des modèles SAFe et Spotify, est bénéfique aux grandes entreprises. Pour les petites équipes, S@S et LeSS sont plus appropriés, car ils s’appuient sur les processus Scrum déjà en place.
- Structure. Les frameworks rigides comme SAFe sont souvent privilégiés au sein des entreprises hiérarchisées, qui veulent contrôler les résultats. Les frameworks souples comme DA peuvent davantage convenir aux petites entreprises qui sont encore en phase de croissance et dont les besoins évoluent.
- Agilité. Les entreprises qui souhaitent appliquer la méthodologie Agile à leurs équipes de développement pour leur permettre de s’adapter à la demande ou à la production itérative privilégieront sans doute un framework gage de souplesse.
Adaptation de votre équipe Agile
Maintenant que vous connaissez mieux les différents frameworks Agile, vous pouvez commencer à évaluer les besoins de votre entreprise pour identifier celui qui vous conviendrait le mieux. Chaque entreprise est différente, et il est possible que vous ayez du mal à trouver un framework qui vous corresponde à 100 %. C’est tout à fait normal. Les frameworks Agile peuvent être adaptés assez facilement à des cas d’usage précis et vous pourrez heureusement choisir entre plusieurs roadmaps lorsque vous ferez évoluer votre équipe Agile.
Quand vous serez sur le point de vous lancer, notez les frameworks qui vous intéressent ou vous semblent les plus adaptés aux besoins de l’entreprise. Demandez ensuite leur avis à d’autres parties prenantes stratégiques et n’hésitez pas à partager cet article avec elles. Après avoir comparé vos notes, pesez le pour et le contre et faites appel aux autres membres de l’équipe concernés. Dans ces conditions, le choix devrait se faire tout naturellement.
Après avoir sélectionné un framework Agile adapté, vous aurez besoin d’outils de gestion de projet adéquats pour déployer votre stratégie. Adobe Workfront est une solution de gestion du travail en entreprise qui fait le lien entre le travail et la stratégie, et améliore la collaboration pour obtenir des résultats tangibles. Il intègre les collaborateurs, les données, les processus et la technologie de l’entreprise pour que vous puissiez gérer le cycle de vie complet des projets, du début à la fin.
Suivez une visite guidée ou regardez la vidéo de présentation du produit pour en savoir plus sur Workfront.