Méthode Agile – La méthode Agile Scrum, c’est toute une organisation !

Voyons plus en détails, en quoi consistent ces différentes réunions et leur fonctionnement.

 

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

 

Le Poker planning est la première réunion Agile qui intervient dans le cycle de réalisation. Elle opère au démarrage de l’itération pour définir quelles sont les histoires utilisateurs qui vont être intégrées dans le cycle de développement. Cette réunion est soumise à un pré-requis fort et deux étapes sont nécessaires à son bon déroulement.

 

• En pré-requis et avant toute chose, le Product Owner doit avoir déterminé l’intégralité de son Backlog produit et toutes les histoires utilisateurs doivent avoir à minima un résumé détaillé de son objectif et être priorisées les unes par rapport aux autres. Sur les différents projets Agile auxquels nous avons participé, nous nous sommes rendu compte 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 particulièrement soignée !
• La première étape est un échange entre le Product Owner et l’équipe. Nous avons pu constater que valider avec l’équipe de réalisation les objectifs du projet avait une importance majeure. L’utilisation de «user’s case » permet en outre de clarifier entre les acteurs les objectifs business poursuivis.
• Une fois le Backlog produit partagé, l’équipe de réalisation va chiffrer chaque histoire à l’aide d’un jeu de poker où les valeurs sont comprises entre 0 et 100. Cette phase de chiffrage est particulièrement importante : les cartes sont les 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. Effectuer cet exercice sur l’intégralité du Backlog permet d’obtenir un chiffrage fin du projet et de ce fait permet de valider le budget et les délais de réalisation A 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 assurer le succès de la réalisation et est une garantie du sérieux du chiffrage. Mais c’est aussi l’avantage de la méthode : les itérations Product Owner et Développeurs permettent de partager en amont, et faciliter la tenue 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 freins/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 va présenter son travail au Product Owner pour lui démontrer que toutes les fonctionnalités qui ont été développées fonctionnent conformément aux spécifications. Chaque histoire utilisateur est passée au crible et la démonstration est faite devant l’écran d’ordinateur selon le scénario de « How To demo » (Comment le démontrer) définit par le Product Owner dans son Backlog produit.

 

 

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

 

Suite à 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 pointer du doigt les erreurs ou lourdeurs relevées dans l’itération. Ce rendez-vous est un temps fort pour toute l’équipe et est l’occasion pour chacun de proposer un bilan de sa vision du fonctionnement de l’équipe que ce soit d’un point de vue technique ou organisationnel.

 

Si l’instauration des réunions propres à Agile peuvent paraitre être une lourdeur dans le processus projet, elles garantissent toutefois la cohésion de l’équipe, la communication et facilite les réalisations dans une logique 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 Agile est un principe bien rodé où chaque réunion a un fonctionnement bien précis, il est important d’inscrire ce dispositif dans un fonctionnement 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. Si on peut penser de prime abord qu’un projet Agile est autosuffisant et qu’il vit en autarcie, il ne peut se passer de remonter les informations à sa 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,

 

pour maitriser la trajectoire du projet et sa bonne adéquation avec la stratégie globale de l’entreprise. Les projets Agiles composent également le portefeuille de projets et ne sont pas simplement des électrons libres parmi l’ensemble des projets composant 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, même si elle se veut adaptable à la majorité des projets peut dans certains cas être inadaptée telle quelle, soit parce que l’organisation ne s’y prête pas ou encore la technologie finale n’est pas adaptée, ... Des modifications 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 fondateur 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 à la méthode et l’acceptation du changement de méthode est parfois difficile. C’est ce qui provoque bien souvent la conservation de la rédaction de spécifications et implique donc une 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 primordiale pour la réussite de celui-ci afin de bénéficier de tous les aspects positifs de la méthode.

 

 

Maintenant que nous vous avons exposé notre vision des aspects méthodologiques et organisationnels de la méthode Agile ont été abordés, nous vous proposerons lors de la prochaine publication un « reportage » au cœur d’un projet Agile où des collaborateurs Exeis ont pu participer à la mise en place de la méthode Agile Scrum en Multi Scrum et œuvrer dans ce projet en tant qu’assistant au pilote du projet et Product Owner sur un projet de refonte d’un site web bancaire.