Etape Parisienne de l’Agile Tour 2009 l’après-midi (partie 2)

Retour sur les dernières sessions de la journée Parisienne de l’Agile Tour 2009.

Retours d’expériences, par Xébia, Aybea, Astria & Octo

Le but de cette session double (2 créneaux horaires) était de partager 3 retours d’expérience sur la mise en place et l’adoption de méthodes agiles.

Retour d’expérience sur la mise en place de Scrum – Nicolas Jozwiak, Xébia

Sous une forme très académique, l’intervenant (qui avait le rôle de Scrum Master) nous a narré les premiers sprints d’un projet client (application critique du fait de générer directement des revenus), illustrant en cela une mise en place progressive de briques de méthodes agiles, et notamment l’importance des différentes étapes de préparation et transition de sprint.

Lors du premier sprint (4 semaines), il a été constaté que le Product Owner (un avant vente) n’avait pas eu suffisamment de disponibilités pour mener à bien son rôle, et que ce dernier manquait de maturité dans la gestion des user stories. Ce qu’ont illustré les manques vécus lors de ce sprint a justement été le rôle du Product Owner, l’importance des user stories, ainsi que la nécessité d’une définition claire du statut DONE (critères déterminant qu’une fonctionnalité est terminée).

En conséquence, lors du second sprint (qui est passé à 3 semaines pour raccourcir le cycle et profiter d’un feedback plus rapide), le Product Owner a été coaché par le Scrum Master sur son rôle. En particulier, le Product Owner a été épaulé pour la formulation des user stories, lesquelles n’ont pas été construites/formulées de manière collégiale, ceci étant justifié par l’intervenant par la jeunesse de l’équipe dans les pratiques agiles.

Lors du sprint suivant, le Scrum Master a pu saisir l’opportunité d’introduire la notion de Story Point et le Planning Poker, et il a également insisté sur un problème rencontré en cours de sprint : le couplage de User Stories sur un même sprint. Effectivement, la réalisation perd en flexibilité dans le cas de couplages inter sprint dans la mesure où on risque un enchaînement séquentiel à la fois limité par la durée du sprint et occasionnant un besoin plus important de communication/synchronisation.

L’intervenant a également expliqué la phase de passage de relai lors de laquelle il a formé son remplaçant Scrum Master, et donc été amené à jouer le rôle de coach pour ce dernier. Les bénéfices qu’il a relevé lors de ce passage de relai ont notamment été la prise de recul et par conséquent une meilleure analyse.

Les idées que le speaker a voulu partager avec l’audience :

  • la mise en place progressive est indispensable
  • il est vital de respecter la discipline agile
  • il y a des rôles clé dont il ne faut pas sous estimer les fonctions
  • l’adoption des pratiques de développement est également un point important

Changez pour l’agile ! Alexis Monville et Martin Rigaud-Vin, Ayeba

La présentation par les intervenants Ayeba a été très ludique, sous forme de sketch / échange entre les deux speakers.

Ils ont commencé leur présentation en énonçant 3 facteurs de succès :

  • le sponsor : pour débuter, un projet éventuellement stratégique, mais le plus isolé possible
  • l’équipe : d’un côté un chef de produit impliqué et disponible, de l’autre un Scrum Master intéressé et dynamique (car, d’après les intervenants, son rôle ne l’occupera pas forcement à temps plein, ce qui implique qu’il sache se rendre utile par exemple sur des tâches de réalisation)
  • le management : son soutien est précieux, il est le garant des décisions et de la transparence des informations

Outre le côté interactif et vivant de la prestation des speakers, cette présentation était intéressante de par les anecdotes rapportées sur un projet (en cours) d’accompagnement d’un client vers un mode de réalisation agile (nouveau pour ce client). En effet, malgré qu’il se soit montré réceptif et convaincu par la méthodologie qui lui a été présentée, plusieurs situations ont montré qu’il n’avait pas forcement tout saisi et encore moins appréhendé les changements fondamentaux qu’il allait devoir apporter sur son processus.

Ce que les speakers retiennent de cette expérience, c’est l’idée de faire passer à leurs interlocuteurs une session de simulateur agile d’au minimum une demi-journée, ceci dans le but d’évaluer leur compréhension.

Osez le changement, risquez le succés, obtenez des résultats remarquables – Bénédicte Taillebois, Astria – Frédéric Friess, Octo

Dernier retour d’expérience, celui fait par la société Astria, accompagnée par la société Octo dans sa mise en place d’un processus agile (l’objectif de Bénédicte Taillebois lorsqu’elle est arrivée en poste). Le contexte initial chez Astria était le suivant : 1600 jours de spécifications sans la moindre réalisation, 1 directeur de projet et 3 chefs de projets.

L’arrêt des spécifications a été décrété, et un dossier d’architecture réalisé par Frédéric Friess, suivi d’un accompagnement au changement.

Quelques améliorations chiffrées après 18 mois :

  • une livraison après chaque itération (2 semaines), contre une livraison par semestre auparavant
  • 12 000 tests automatisés et des spécifications exécutables (FitNesse), contre 30 jours de tests de non régression auparavant

D’autres constats ont été faits, tel le regain de confiance dans l’IT et une augmentation de la valeur métier, le retardement des décisions structurantes du fait d’une approche incrémentale, mais également des frictions dues au changement (remise en question du poste de chef de projet).

Quelques pratiques relatées :

  • une immersion de 2h à 1 jour dans les équipes métier
  • tester l’innovation pour se rendre rapidement compte de ses avantages et inconvénients

Il est intéressant de noter que dans les caractéristiques du manager agile mentionnées par Bénédicte Taillebois, il y a la vulnérabilité. En effet, elle affirme que plus sa vulnérabilité est grande, plus l’équipe est forte.

Là aussi, nous avons eu droit à des recommandations, sous la forme d’un kit de survie :

  • KISS (Keep It Simple and Stupid)
  • négocier le contenu, pas la date
  • ralentir quand ca va mal

Comment concilier les pratiques Agiles et le contrat au forfait ? David Samreth, SQLI

La présentation s’est faite en 2 temps : un état des lieux / classification des caractéristiques des pratiques Agiles et du contrat au forfait, suivi d’un énoncé d’axes d’adaptation pour répondre à l’idée de conciliation entre les deux pratiques.

Les projets au forfait sont caractérisés par un triplet (budget, périmètre, planning) qui a pour conséquence d’imposer au prestataire une gestion des risques et d’introduire une conséquence importante de négociation (potentiellement conflictuelle) avec son client (ce qui est antagoniste aux valeurs énoncées par le manifeste agile).

Au sujet de sa combinaison avec des pratiques agiles, il existe un certain nombre d’idées reçues telles que :

  • le fait que les méthodes agiles pourraient permettre de proposer des forfaits moins chers
  • le fait que les méthodes agiles sont incompatibles avec les notions de maîtrise de coût et de périmètre

Dans le cadre de sa réflexion sur le sujet, l’intervenant nous a présenté 5 axes d’adaptation :

  • l’engagement budgétaire ne peut se faire qu’en redéfinissant de nouvelles unités d’oeuvres. Le story point étant un bon candidat, on peut très bien envisager un engagement contractuel sur la base d’un nombre de points
  • pour tirer profit des gains apportés par le mode itératif des pratiques agiles, il est indispensable d’introduire une flexibilité sur le périmètre plutôt que de chercher à le contractualiser au départ
  • l’engagement sur le planning peut passer par la contractualisation d’une vélocité moyenne, permettant de cadrer l’avancement en terme de richesse de fonctionnalités livrées au terme de la période définie
  • le partenariat entre « client » et « fournisseur » se doit d’être contractualisé afin de gérer l’arbitrage et la priorisation, mais aussi de maîtriser les risques en cas de faible implication du client (point de blocage pour le démarrage d’un nouveau sprint)
  • intégrer une démarche orientée ROI qui consiste à prioriser les fonctionnalités considérées comme à forte valeur ajoutée, et à savoir s’arrêter lorsqu’on atteint des fonctionnalités coûteuses à mettre en oeuvre et à faible valeur ajoutée (d’autant plus si elle ne sont pas indispensables).

En suivant ces axes d’adaptation, on peut arriver à la notion de forfaire agile, caractérisé par :

  • un budget fixe
  • un délai fixe
  • une vélocité fixe

En prenant cette approche et définissant un contrat chapeau, puis en assurant un suivi contractuel lors de chaque sprint (en définissant un mini forfait auquel est par exemple rattaché le contenu du spring backlog), il semble envisageable de mixer pratiques agiles et projet au forfait tout en apportant une flexibilité au client sur la gestion du changement. En effet, tout n’est alors plus que gestion du product backlog et de la priorisation.

Tout cela parait évidemment simple sur le papier, mais cela ne doit pas masquer les points critiques qui sont d’après moi :

  • la concrétisation de la valeur d’un point sur le plan budgétaire
  • le consensus sur l’estimation de coût en points des user stories
  • le consensus sur la qualification d’une tâche réalisée lorsque le résultat ne répond pas à ce que souhaitait le client : est-ce une anomalie à corriger à la charge du fournisseur ? Est-ce qu’une nouvelle enveloppe de points va être utilisée dans le cadre contractuel ?
  • l’évaluation par le fournisseur de la charge à reporter sur chaque sprint pour ce qui est des tâches de correction d’anomalies, et à inclure dans la détermination budgétaire (coût du point) et dans le planning (vélocité moyenne) sans que cet aspect ne soit réellement exposé à son client

Les deux derniers points montrent la limite de la combinaison agilité / forfait dans la mesure où la notion d’anomalie est un critère important dans le cadre d’un forfait en ce qui concerne la maîtrise du budget et qu’elle introduit inévitablement des conflits, lesquelles sont supposés réduit à néant avec les pratiques agiles dans un cadre classique.

Pour finir

L’Agile Tour est un évènement très précieux tant pour les initiés que pour les débutants. Son expansion dans plusieurs grandes villes de France permet de rendre l’évènement plus accessible que des messes annuelles dans une grande ville comme Paris. Ceci combiné à la gratuité (ou une faible participation) devrait vous encourager à saisir l’opportunité si elle se (re)présente.

Quelques liens pour ceux qui sont intéressés par le sujet :

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *