Veille technologique #6 : scrum et offshore

Deuxième partie de mes notes prises au ValTech Days.

Agile et offshore : retour d’expérience en milieu bancaire.

Présentée par Patrick LeGo, consultant sénior chez Valtech.

Où comment l’agilité en générale, et Scrum en particulier, apparaît comme une technique de survie en milieu bancaire.

Patrick intervient depuis deux ans en tant que chef de projet agile dans une banque d’investissement qui pratique l’offshore depuis 2001. Dans un tel établissement financier, le système d’information est LE moyen de production de l’entreprise, c’est sa valeur. Les nouveaux produits financiers sortent en flux continu, l’ouverture du SI sur l’extérieur est de plus en plus grande, avec la généralisation des marchés électroniques. La performance du système d’information dicte la capacité de survie de l’entreprise.

Cet établissement a fait le choix de l’offshore internalisée, avec deux équipes parallèles : une à Paris, et une en Inde. L’objectif de ce choix était double : augmenter sa capacité de production par l’offshoring de ressources en Inde, mais conserver la maîtrise du système d’information et la connaissance métier en conservant les équipes en interne.

A l’arrivée de Patrick, les deux équipes ont des caractéristiques bien différentes.

Une équipe parisienne, organisée en pool de ressources, qui touche à tout : des projets de grande envergure, des petits projets de 15 jours de charges, de la maintenance. Beaucoup de postes en régie de long terme, aux cultures méthodologiques disparates, mais fortement expérimentée, que ce soit techniquement ou fonctionnellement.

Une équipe indienne répartie par projets, certifiée ISO9001, sans leader technique ou fonctionnel, inexpérimentée, au turn over élevé, mais dont la méthode et les procédures permettent de s’en sortir.

L’audit des équipes dévoile encore un manque de confiance mutuelle, sans doute alimenté par la distance géographique et culturelle, mais aussi par les caractéristiques des un et des autres : désorganisation d’un côté et faible niveau technique de l’autre. De plus, l’équipe indienne est réduite à la maintenance de code dont elle n’est pas l’auteur : toute correction de bug met des jours, là ou quelques heures devraient suffire. Côté projet, les indicateurs sont flous, l’effet tunnel est permanent.

Face à ce constat, et sauver l’entreprise, une seule solution : le développement agile !

Un premier projet agile est lancé : le portage d’une application Java vers le C# et le framework .Net. Les spécifications sont embryonnaires, la conception et le code sont fait offshore. Le suivi local est insuffisant. Les performances sont mauvaises. 50% du code doivent être refactorées. Le délai et les charges doublent !

Que s’est-il passé ? Un échec de l’agilité ?

En fait, une erreur principale avait été commise : nouvelle équipe, nouvelle méthode, nouvelle technologie.

Après ce premier échec, l’agilité n’a pas été vouée aux gémonies. La phase suivante a consisté à mettre en place Scrum, avec un certain nombre d’artefacts :
– Mise en place de la collaboration : esprit d’équipe, partage de l’outil de développement et de suivi
– Renforcement et maîtrise de la gouvernance du SI : suivi du budget et des délais, suivi de la qualité, suivi quotidien, suivi sur les faits, ce qui est effectué, disparition des effets tunnel, revue de conception et de code
– Evolution de la technologie Java vers C#, partage de l’usine de développement, automatisation de tests et  build continu, condition a minima d’un développement agile
– Modification de la typologie des projets : aller de la maintenance vers l’applicatif, et du waterfall vers l’agilité.

Le processus est global :

– Itération pilotée par les risques
– Les points d’accord sont partagés par tous et écrits
– Les itérations sont de longueur fixe (ce sont les Time Boxes)

Pour se faire une idée précise de la mise en pratique de Scrum dans ce cadre de développement offshore, Patrick nous décrit le modèle d’itération :

– Le premier lundi : lancement de l’itération (1 heure). La conception et les spécifications sont effectuées par l’équipe française, le code et les tests sont faits en Inde.
– Tous les matins, le meeting classique Scrum
– Une réunion de Sanity Check à la fin de chaque semaine pour vérifier que tout le monde est bien en phase
– Les équipes sont réduites : 1 chef de projet, 1 business analyste, 1 architecte, 3 développeurs
– L’estimation des charges est effectuée par les intervenants eux-mêmes, sur la base de 6 heures de travail efficace par personne et par jour
– Le mercredi de la 3ème semaine : on gèle le code et le build, on planifie la prochaine itération, le plan doit être accepté par chacun, on effectue la revue du produit

Pour que l’ensemble fonctionne correctement, un certain nombre de moyen de communication ont été mis en place, spécifiquement à cette application de Scrum au contexte offshore :

– Des voyages fréquents France-Inde, pour les transferts de compétence, parfois plusieurs semaines de suite
– Des téléconférences pour les Scrum de Scrum, qui, de 45 minutes dans les premiers temps, sont passés à 15 minutes, comme le temps nécessaire à un Scrum classique
– Des wikis, (un par projet) qui au début n’ont pas été pris au sérieux, mais qui ont finalement été bien adoptés, pour leur supériorités sur les autres moyens d’échange que sont les forums (risque de réponses qui partent dans tous les sens) et les emails et chats (à déconseiller fortement). Seuls les wikis permettent réellement de partager les règles de bonnes pratiques.

Au départ, une dérive en charges et délai a été constatés sur les premiers projets, allant jusqu’à 250% du temps prévus. Les écarts se sont réduits ensuite. En partie par une maîtrise de la nouvelle méthode agile, mais aussi par que Scrum en particulier, et les méthodes de développements agiles en général, permettent de mieux prévoir temps et délai.
En résumé, l’adoption de Scrum a permis :

– Une meilleure visibilité
– Un contrôle amélioré
– Une plus grande qualité de développement et de conception
– Une collaboration efficace entre les différentes équipes
– La réduction du turn over
– Une efficacité renforcée
– Et même le renouvellement de la certification ISO 9001 pour l’équipe indienne : un beau challenge, sachant que les certificateurs ne sont pas forcément très connaisseurs des méthodes agiles.

Bien sûr, ces bénéfices très importants reposent au préalable sur certains facteurs clé de succès qu’il ne faut pas négliger avant de se lancer dans l’adoption du développement agile :

– L’engagement de la DSI en terme budgétaire
– Les utilisateurs en terme de patience
– Un effort dans le recrutement
– La motivation des équipes

Mais les résultats sont bien là, et les efforts consentis au départ ont largement été récompensés.

Depuis ce jour, je n'ai qu'un seul "rêve" : SCRUM !

Comments

[Rédigé par: Frédéric Doillon]

Merci Florent! Mais c'est déjà fait.
Nous utilisons (depuis peu, il est vrai), le template de Conchango disponible sur http://www.scrumforteamsystem.com/en/default.aspx.
J'ai l'intention d'écrire une note sur nos premières impressions...à suivre, donc!

[Rédigé par: Florent Santin]

Il va falloir télécharger le process template Scrum pour TFS :)