Méthode Agile [3/3] – La méthode agile SCRUM, c’est tout une organisation !

 

Première étape de la méthode Agile : Le Poker Planning

 

Le Poker Planning est la première réunion Agile du cycle de réalisation. Elle se déroule au début de l’itération pour définir quelles sont les User Stories qui vont être intégrées dans le cycle de développement. Cette réunion repose sur un prérequis essentiel et suit deux étapes clés pour son bon déroulement. 

 

• Prérequis essentiel : avant toute chose, le Product Owner doit avoir déterminé et complété l’intégralité de son Product Backlog et chaque User Story doit au moins avoir un résumé détaillé de son objectif et être priorisée par rapport aux autres. Sur les différents projets Agiles auxquels nous avons participé, nous avons constaté que ce prérequis conditionne la bonne réussite des projets et permet de tenir les engagements. Malgré son nom, cette itération n’est pas un jeu de hasard et doit faire l’objet d’une préparation rigoureuse !

 

• Première étape : un échange entre le Product Owner et l’équipe. Valider les objectifs du projet avec l’équipe de réalisation est d’une importance majeure. L’utilisation de « user’s case » permet en outre de clarifier les objectifs business entre les acteurs.

 

• Deuxième étape : une fois le Product Backlog partagé, l’équipe de réalisation chiffre User Story à l’aide d’un jeu de poker, où les valeurs vont de 0 à 100. Cette phase de chiffrage est particulièrement importante : les cartes servent d’abaques du projet, les histoires conditionnent la granularité des sprints, et donc une bonne adéquation entre le planning de réalisation et la charge de travail. Effectuer cet exercice sur l’intégralité du Backlog permet d’obtenir un chiffrage précis du projet, validant ainsi le budget et les délais de réalisation. À la fin du chiffrage, l’équipe s’engage sur les délais de réalisation qu’elle vient de définir. Cette étape est primordiale pour garantir le succès de la réalisation et assurer la fiabilité du chiffrage. Mais c’est aussi l’avantage de la méthode : les itérations entre le Product Owner et les développeurs permettent de partager en amont, et faciliter le respect des jalons.

 

 

Deuxième étape de la méthode Agile : Le Daily Scrum

 

Le Daily Scrum est la réunion la plus opérationnelle du cycle Agile. C’est une réunion qui dure 15 minutes, qui est quotidienne et qui réunit l’équipe autour du Scrum Master (maître de cérémonie), Cette réunion est un temps fort où chaque membre de l’équipe prendra la parole pendant 2 minutes pendant lesquels il fera un point sur :

• Sa réalisation de la veille
• Les items sur lesquels il compte travailler aujourd’hui
• Les obstacles/barrières/difficultés rencontrés (de quelque nature que ce soit)

 

Si cette réunion a une finalité technique, la présence du Product Owner reste importante pour répondre aux différentes questions sur les aspects métier.

 

 

Troisième étape de la méthode Agile : le Sprint review

 

Le Sprint Review est la réunion qui marque la fin de l’itération de développement. Lors de cette réunion, l’équipe de réalisation présente son travail au Product Owner pour valider, avec lui, que toutes les fonctionnalités développées fonctionnent conformément aux spécifications. Chaque User Story est examinée minutieusement et la démonstration est faite devant un écran d’ordinateur selon de scénario de « How To Demo » (comment le démontrer) défini par le Product Owner dans son Product Backlog.

 

 

 

Quatrième étape de la méthode Agile : le Retrospective Meeting

 

À la suite de cette démonstration et après validation de la livraison par le Product Owner, l’équipe procède au Retrospective Meeting. L’objectif de cette réunion est de faire un bilan du sprint, de capitaliser sur les bonnes pratiques et de relever les erreurs ou lourdeurs rencontrées au cours de l’itération. Ce rendez-vous est un temps fort pour toute l’équipe et offre à chacun l’occasion de proposer un bilan de sa vision du fonctionnement de l’équipe que ce soit d’un point de vue technique ou organisationnel.

Bien que la mise en place des réunions propres à la méthode Agile puisse sembler être une contrainte dans le processus de projet, ces rencontres garantissent la cohésion de l'équipe, la communication et facilitent les réalisations dans un esprit d'amélioration continue et de satisfaction client. Toutefois, s’il faut tout mettre en œuvre pour faciliter l’autogestion de l’équipe, attention à ne pas tomber dans un système anarchique !

 

 

 

La communication et la visibilité au niveau de la direction de l’entreprise

 

Si le cycle des instances Agiles est un principe bien rodé où chaque réunion a un fonctionnement bien précis, il est important d’inscrire ce dispositif dans un cadre global. Les projets Agiles doivent être gérés dans le cadre d’une direction de projet au niveau de l’entreprise avec la production d’un reporting régulier. Bien qu’un projet Agile puisse sembler autosuffisant et capable de fonctionner en autarcie, il est essentiel de remonter les informations à la direction concernant :

 

• Le bon respect des engagements en termes de périmètre,
• La bonne tenue des jalons et des délais,
• Le respect du budget global alloué au projet,

 

Cela afin de maitriser la trajectoire du projet et sa bonne adéquation avec la stratégie globale de l’entreprise. Les projets Agiles font partie intégrante du portefeuille de projets et ne sont pas simplement des entités indépendantes au sein de la stratégie de l’entreprise.

 

 

 

La méthode Agile, une méthode qui ne l’est pas forcément pour tous les types de projets !

 

La méthode Agile, bien qu’adaptable à la majorité des projets peut, dans certains cas, se révéler inadaptée telle quelle, soit en raison de la structure organisationnelle ou si la technologie finale n’est pas adaptée, ... 

Dans de tels cas, des modifications et ajustements dans la méthode interviennent donc pour donner une méthode hybride que nous baptisons semi-Agile. 
Ces méthodes semi-Agiles gardent un des éléments fondateurs de la méthode initiale intact. Bien souvent, c’est l’expression des besoins du projet qui est tronquée pour conserver le mode classique de rédaction de spécifications au détriment d’une rédaction de cas d’utilisation plus simple et plus rapide. Ce constat nous amène à 2 conclusions :
 

• Tous les projets ne peuvent pas être réalisés en méthode Agile. La réunion de facteurs organisationnels ou encore techniques favorisant, aide à la mise en place de la méthode. Il est très difficile de mettre en place une méthode Agile avec des équipes de réalisation à distance, tout comme il est difficile de mettre en place une méthode Agile si l’architecture technique finale n’a pas été mise en place ou n’est pas maîtrisée.

 

• Tous les acteurs projets ne font pas encore confiance à cette méthode et l’acceptation du changement est parfois difficile. C’est ce qui provoque bien souvent la conservation de la rédaction de spécifications et implique donc la perte d’une partie des bénéfices de la méthode. Préparer les ressources au déroulement du projet selon une nouvelle méthode est primordial pour la réussite de celui-ci afin de bénéficier de tous les aspects positifs de la méthode.

 

👉 Retrouvez la suite de notre série sur la méthode Agile : 

 

Méthode Agile [1/3] – La méthode agile SCRUM, une nouvelle ancienne méthode

 

Méthode Agile [2/3] – La méthode agile SCRUM, des hommes et des rôles