Gestion de projet Agile
Vous êtes confrontés aujourd’hui à la complexité du monde qui nous entoure : les besoins de vos clients changent régulièrement, vous devez appréhender rapidement des nouvelles technologies… Bref vous avez besoin de vous adapter et de vous réinventer pour rester compétitif. L’agilité est indispensable. Mais comment devenir agile et le rester ? Dans quel but ? Par où commencer ? Nous vous montrons la voie.
Notre approche.
Co-construisons votre agilité pour augmenter votre capacité d’adaptation
- La « Gestion de projet agile » rassemble des consultants pragmatiques et en veille permanente. Ils vous accompagneront dans votre transformation agile :
- EAudit de votre organisation. Qu’elle soit agile ou non, nous préconisons les meilleures pratiques en fonction de votre culture d’entreprise
- EFormation et acculturation de vos collaborateurs à l’agilité
- EAccompagnement sur-mesure dans la mise en place ou l’amélioration de votre approche agile en utilisant ou combinant les frameworks agiles existant (Scrum, Kanban, SAFe …)
Actualités.
Tu es passionné ?Nous aussi !
Alors rejoins-nous.
Nos autres expertises Be & Do Agile !
Pourquoi passer par un cabinet de conseil gestion de projet Agile
Quelles sont les principaux frameworks et méthodes agiles applicables au niveau d'une équipe ?
Contrairement à ce que l’on peut lire ici ou là, la méthode agile n’existe pas. L’agilité est avant tout un état d’esprit basé sur des valeurs et des principes. Il existe différents frameworks et méthodes qui vont aider à implémenter ces valeurs et principes agiles, et non une méthode agile unique. Tel framework agile sera plus adapté à tel contexte que tel autre framework. Ces méthodologies ne sont d’ailleurs pas exclusives ; il est tout à fait possible, voir même encouragé de les combiner pour tirer le meilleur parti de chacunes en fonction des problématiques posées par le contexte.
Il existe de nombreux frameworks et méthodes qui s’intéressent à l’organisation et au fonctionnement d’une équipe agile. Toutefois, certains sont plus connus que d’autres et plus répandus.
Scrum est la méthodologie agile la plus connue et la plus répandue. C’est d’ailleurs certainement pour cela qu’il y’a souvent un amalgame entre Scrum et « la méthode agile ». Très adapté à la construction d’un produit logiciel ou non, Scrum se définit comme un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. Pour cela, Scrum définit :
• Des rôles : Scrum Master, Product Owner et Developer qui forment à eux trois une équipe Scrum
• Des rituels qui rythment le travail d’une équipe Scrum tout au long des itérations qu’on appelle des sprints : le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective
• Des artefacts : le Product Backlog qui permet de structurer, découper et ordonner selon la valeur qu’ils apportent les besoins auxquels le produit en construction doit répondre, le Sprint Backlog qui rassemble le « pourquoi » (l’Objectif de sprint), le « quoi » (les éléments du Product Backlog embarqués dans un sprint) et le « comment » (le plan de réalisation de l’incrément de produit à développer lors du sprint) de chaque sprint, l’incrément de produit qui est le résultat du travail de l’équipe Scrum lors de chaque sprint
Kanban est une approche moins normative que Scrum dans le sens où elle ne définit pas de nouveaux rôles ou des rituels comme Scrum. Kanban est basé sur le concept de flux tiré, c’est-à-dire que l’objectif est de tirer au plus vite les besoins à réaliser d’un état « A faire » vers un état « Fini » et non de pousser des éléments à faire comme dans Scrum. Contrairement à Scrum qui définit des blocs de temps rythmant l’équipe (les sprints), Kanban fonctionne sur un mode flux continu. Kanban revient à gérer le travail d’une équipe comme un flux et utilise de nombreux indicateurs et outils liés au flux pour aider l’équipe à optimiser son travail et son organisation : le débit, le temps de cycle, la limitation du travail en cours… Kanban est mieux adapté que Scrum dans certains contextes, comme les activités de support, mais pas que.
Scrumban, comme son nom l’indique, mixe Scrum et Kanban. L’idée est de profiter de l’avantage des deux méthodologies. Il existe plusieurs applications possibles de Scrumban : par exemple, utiliser Scrum pour la partie développement de produit et Kanban pour les activités de support pour une équipe réalisant ces deux activités ; ou travailler avec le cadre Scrum en introduisant des pratiques et des métriques venant de Kanban pour améliorer le flux de travail d’une équipe.
eXtreme Programming, ou plus communément appelée XP, est très complémentaire aux approches précédentes car elle met plus le focus sur les pratiques d’ingénierie logicielle qui vont améliorer la réalisation du produit logiciel. Le principe de XP est de pousser à l’extrême ce qui a été identifié comme bonne pratiques dans le développement de logiciels. Ainsi, XP implique la pratique du pair programming tout le temps ou promeut les pratiques d’intégration continue, de test first et de refactoring en continu. XP n’en oublie pas pour autant l’aspect gestion de projet. Par exemple, la pratique du poker planning très utilisé par les équipes Scrum vient à la base d’eXtreme Programming.
Quelles sont les principales méthodologies d'agilité à l'échelle ?
La réalité de moyennes ou grandes organisations implique la construction de produits, services impliquants, par leur taille, plusieurs équipes. Dans ces organisations, l’agilisation unitaire des équipes est nécessaire, mais pas suffisante pour rendre l’entreprise entière agile. Pour cela, il est nécessaire de s’intéresser à l’agilisation des autres processus qui régissent l’entreprise : la gestion des portefeuilles de projets/produits et la répartition des budgets sur ces différents portefeuilles, l’alignement entre la stratégie de l’entreprise et l’opérationnel… On entre alors dans le domaine de l’agilité à l’échelle et de la Business Agility.
Les frameworks qui répondent à ces problématiques de passage à l’échelle de l’agilité sont bien sûr différents de ceux utilisés à l’échelle d’une équipe. Comme pour le contexte d’une équipe, il n’existe pas qu’un seul framework d’agilité à l’échelle, mais plusieurs plus ou moins adaptés à chaque contexte.
Scaled Agile Framework, plus communément appelé SAFe®, est le framework le plus connu et répandu dans les grandes organisations qui souhaitent tendre vers une plus grande agilité à l’échelle. Créé et maintenu par la société américaire Scaled Agile Inc., SAFe® est en fait une base de connaissances librement disponible sur Internet, rassemblant des patterns éprouvés dans différentes organisations pour aligner plusieurs équipes dans le but de développer et livrer des produits/services complexes de manière agile : livraison continue de valeur, adaptation permanente aux changements… Ce framework s’inspire de différents courants comme le développement agile, le Lean, la pensée systémique ou le Devops.
LeSS, Large-Scale Scrum, est un autre framework d’agilité à l’échelle qui a pour principe d’appliquer Scrum sans le dénaturer dans un contexte où plusieurs équipes doivent travailler sur un même produit. Il reprend ainsi les principes de Scrum : le concept de sprint, les rôles et les rituels en adaptant certains de ces derniers pour répondre au problème des dépendances inter-équipes auquel il faut répondre dans un contexte de mise à l’échelle. Toutes les équipes sont ainsi synchronisées dans un unique sprint avec les particularités suivantes :
• Deux sprint plannings : le premier servant de synchronisation et de répartition des user stories entre les équipes, le deuxième permettant un affinage du sprint backlog dans chaque équipe
• Une participation croisée entre 2 équipes aux daily meetings quand c’est nécessaire,
• Deux rétrospectives : la première propre à chaque équipe et la deuxième traitant les problématiques inter-équipe et l’amélioration globale de l’ensemble.
Comme SAFe avec ses configurations « Essential » et « Large Solution », LeSS adresse la synchronisation de plusieurs équipes au sein d’un programme de taille moyenne (de 2 à 8 équipes), ou même dans le cadre du développement de solutions encore plus larges (au-delà de 8 équipes) avec sa version « LeSS Huge ». En revanche, il n’adresse pas la gestion de portefeuilles de projets/produits et l’alignement de ses portefeuilles avec l’opérationnel comme SAFe le fait dans ses configurations « Portfolio » et « Full ».
Scrum@Scale®, créé par l’un des fondateurs de Scrum, Jeff Sutherland, et maintenu par la société Scrum Inc., repose sur le principe d’appliquer les principes Scrum à tous les niveaux d’une organisation. Il part du principe qu’il faut dissocier le « Quoi » géré par le cycle Product Owner et le « Comment » géré par le cycle Scrum Master. Ce dernier gère l’organisation des équipes réalisant le produit. Chaque équipe travaillant sur le produit fonctionne en Scrum. La gestion des dépendances inter-équipes est faite via un Scrum de Scrums réunissant des représentants de chaque équipe. Ce Scrum de Scrums fonctionne lui-même sur le modèle Scrum avec les rôles et les rituels de ce framework. Scrum@Scale® préconise des équipes de 5 personnes. De même, un Scrum de Scrums permet de synchroniser un groupe de 5 équipes. Au-delà, il est possible de créer un Scrum de Scrums de Scrums, etc… Le modèle est ainsi scalable jusqu’à couvrir l’ensemble d’une organisation.
Le cycle Product Owner a un focus sur le produit et la priorisation des besoins. Il est construit sur le même modèle avec le concept de Méta Scrum similaire au Scrum de Scrums.
Nexus, créé par le deuxième fondateur de Scrum, Ken Schwaber, et maintenu par la société Scrum.org, repose, comme LeSS, sur le framework Scrum. Il se focalise sur les dépendances et l’interopérabilité entre les différentes équipes Scrum qui contribuent à un produit unique. Dans Nexus, ce problème des dépendances est géré via l’équipe d’intégration Nexus qui fonctionne sur le modèle Scrum, autrement dit avec le Product Owner, un Scrum Master et des membres qui peuvent faire aussi partis d’une des équipes Scrum travaillant sur le produit. Cette équipe Nexus a aussi ses propres rituels Scrum.
Cette liste de framework pour répondre aux enjeux de l’agilité à l’échelle n’est pas exhaustive. Il existe encore plein d’autres méthodologies : Enterprise Scrum, Disciplined Agile…
Quels sont les principaux nouveaux rôles introduits par les frameworks agiles ?
Les principaux nouveaux rôles qu’on a vu apparaître avec la transformation agile des organisations viennent de Scrum. En effet, ce framework a divisé le rôle de chef de projets en deux nouveaux rôles : le Product Owner qui a un focus sur le « Quoi », et le Scrum Master qui a un focus sur les processus de l’équipe et sa dynamique. Le Product Owner a une orientation clairement plus produit et son rôle est de maximiser la valeur apportée par le produit en comprenant, structurant et priorisant les besoins auxquels doit répondre le produit. Le Scrum Master, lui, est redevable de la mise en place de Scrum et de sa bonne compréhension par l’équipe Scrum, mais aussi par l’organisation. Il est aussi redevable de l’efficacité de l’équipe Scrum. Il est à son service pour améliorer ses pratiques au sein du cadre Scrum.
Si vous voulez en connaître plus sur ces deux rôles, n’hésitez à vous inscrire à nos formations certifiantes « Devenir Product Owner » et « Devenir Scrum Master ».
SAFe® apporte aussi son lot de nouveaux rôles dont les plus emblématiques sont les suivants :
• Le Product Management est le rôle qui construit le backlog au niveau du programme, donc pour chaque PI (Program Increment) pour l’ensemble de l’ART (Agile Release Train). Ce rôle est souvent assuré par plusieurs personnes au sein d’un même train. Il travaille en étroite collaboration avec les Product Owners qui s’occupent du périmètre d’une équipe au sein d’un train. Il existe un pendant au Product Management lorsque l’on est dans le cadre d’un solution train (train composé de plusieurs ART) : le Solution Management.
• Le Release Train Engineer (RTE) agit comme un Scrum Master au niveau de l’ensemble d’un ART. Dans le cadre d’un solution train, on parle de Solution Train Engineer (STE).
• Le SAFe Program Consultant (SPC) est un rôle important pour accompagner une organisation dans la mise en place de SAFe®, que ce soit via les formations tout au long de l’implémentation du framework ou via le coaching des différents acteurs de la transformation.