oct
9
Agile Tour Genève – Deuxième Partie
Filed Under Conférences, Opinion | Leave a Comment
En fin de journée j’ai suivi une présentation sur les contextes favorables et défavorables à l’agilité ainsi qu’un compte rendu de la transition vers l’agilité des équipes de développement de Yahoo! International.
La présentation d’Oana Juncu parlait des contextes favorables et défavorables pour mettre en oeuvre une démarche agile. Elle a fait remarquer qu’il était difficile d’avoir un contexte projet favorable si le contexte de l’entreprise est défavorable. Pour elle, l’agilité est encore majoritairement promue dans les organisations par la direction informatique et non par les responsables métiers. Parmi les facteurs de résistance, elle mentionne la demande d’engagement de la part des utilisateurs, le scepticisme de la direction des achats et la culture « progiciel », bien que ce type de projet convienne tout à fait à une démarche agile. Elle a conclu par une mise en équivalence des objectifs du CMMI et de l’agilité pour démontrer qu’il y avait convergence et compatibilité entre ces deux approches.
La dernière présentation que j’ai suivie à l’étape de Genève de l’Agile Tour fut pour moi la plus intéressante. Alexandre Boutin nous a fait part de la mise en oeuvre des méthodes agiles chez Yahoo! International. A son arrivée en 2005, le développement informatique fonctionnait uniquement sur les efforts individuels sans aucun processus de gestion de projet défini. La première étape de la transformation en 2006 fut la mise en place d’un processus de développement classique et la création d’équipes d’assurance qualité locales. Les aspects positifs furent une amélioration de la qualité des livrables et un feedback positif des équipes basées en Asie. Par contre, les équipes anglaises étaient opposées à cette approche, car elles utilisaient déjà Scrum. En outre, certains développeurs avaient tendance à se « cacher » derrière le processus, rejetant la responsabilité de certaines activités sur les autres.
En 2007, l’agilité fut introduite dans l’organisation, mais sans être une solution obligatoire, car Alexandre Boutin pense que l’on ne peut pas forcer les gens à être agile. Le processus détaillé de 2006 fut abandonné au profit d’un framework tenant sur deux pages A4 et les gestionnaires locaux du processus furent transformés en coachs agiles. Les validations formelles furent remplacées par des check-listes pour s’assurer que tous les facteurs de risques étaient pris en considérations lors des différentes étapes du développement. Tous les employés suivirent deux jours de formations à la démarche agile. Ceci conduit à l’adoption de Scrum à 100% en Europe, mais l’Asie fut plus réticente avec seulement quelques projets pilotes. Le fait d’avoir manqué de métriques dans la situation précédente rendit aussi difficile de présenter au management des chiffres justifiant l’évolution. Enfin, la transition des équipes de contrôle qualité vers un rôle coaching ne fut pas évidente pour tous les collaborateurs.
En 2008 des mesures ont été prises pour assister les équipes produit (métier) à mieux travailler de manière agile. L’intégration continue a été mise en place ainsi que des métriques pour l’évaluation des équipes:
* La vélocité (intra équipes)
* Le nombre de builds réussis ou en échec (le build tourne toutes les deux heures durant la journée)
* Le nombre de tests (mais pas le degré de couverture de ceux-ci)
* Le nombre de bugs découverts dans les 5 premiers jours après la release
Au niveau des résultats, Alexandre Boutin a mis en évidence la bonne acceptation de l’approche framework. Scrum est aussi une réussite, mais il doit être accompagné de bonnes pratiques, notamment au niveau du test. Il a aussi recommandé de privilégier l’accompagnement local et de reformer les équipes après 4 à 5 mois de pratique. Les équipes de développement sont arrivées à des mises en productions toutes les 4 semaines et sont plus motivées. Il a également constaté une amélioration de la qualité du produit. En ce qui concerne les difficultés rencontrées, il a mentionné le fait que la culture agile soit plus difficile à transposer en Asie. Une approche plus structurée y est préférée et la notion de confrontation est peu en harmonie avec la culture du respect hiérarchique. Les tentatives de faire des daily meetings par téléphone avec des équipes multi-sites n’ont pas été non plus une réussite. Enfin, plus d’efforts doivent être faits pour coacher les utilisateurs concernés par des projets en mode agile.
Une conclusion à retenir: il est plus facile de « faire » agile que d’ »être » agile ;o)