Programme Agile Tour 2008

Eh bien non désolé, vous ne trouverez pas le programme de l’étape Grenobloise sur ce Blog aujourd’hui. Pourtant je peux vous garantir que nous y travaillons assidument et nous espérons être en mesure de le publier dans les prochains jours.

En fait c’est un exercice plutôt difficile car nous avions trop de sujets et nous avons du faire une sélection en éliminant des sujets potentiellement intéressants. Mais le méthode Agile nous a aidé, plusieurs itérations sur un grand mur blanc sur lequel les sujets étaient positionnées nous a permis de converger assez vite, enfin quand même 3 heures d’efforts. Nous sommes maintenant en cours de validation de la disponibilité des orateurs et de la durée proposée avant de communiquer officiellement.

Quelques indiscrétions, mais chut, ne dites pas que c’est moi qui vous l’ai dit :

• Un « keynote speaker » Grenoblois
• Une 12aine de sessions planifiées

Bref, une belle conférence en perspective

Priorités !

Lors d’une de mes premières expériences professionnelles la Direction Qualité de la société diffusait des posters pour illustrer des bonnes pratiques logicielles. L’un de ces posters représentait un croisement à 4 routes avec une ambulance, un camion de pompier, une estafette de gendarmerie et une voiture de police qui arrivaient en même temps au carrefour, gyrophare et sirène à fond. La légende de ce poster était « Lorsque tout est prioritaire, il n’y a plus de priorité »

Cette entreprise n’était certainement pas Agile, mais voulait diffuser une bonne pratique qui consiste à définir ses priorités à l’avance et pas lorsque la question se pose.

Les méthodes Agile intègre cette pratique, souvent structurellement. Par l’intermédiaire du « Product Backlog », Scrum oblige à prendre des décisions sur ce qu’il faudra réaliser en premier et les visualiser dans un document unique. Ces décisions sont parfois difficiles à prendre mais sont nécessaires pour gagner en productivité ensuite.

J’entends parfois « C’était pourtant évident que c’était très important » pour fustiger une équipe technique qui a manqué un échéance. Mais que veut dire « très important » relativement aux autres tâches qui étaient également importantes … nul ne le sait. Nous étions dans le cas d’un véhicule prioritaire qui arrive au carrefour où 3 autres véhicules prioritaires sont déjà présents et dans ce cas, pensez-vous que la meilleure méthode est de faire descendre chaque chauffeur sur la route pour discuter avec les 3 autres et négocier de passer en premier car son action à lui est « très importante » ?

Pour que l’équipe soit efficace, les priorités du produit doivent se décider en amont de l’équipe de réalisation, pensez-y !

Scrum – Premier echec

Cela devait bien arriver et c’est malheureusement arrivé !

Il y a 4 mois, J’ai coaché un projet en interne (durant 3 sprints de 2 semaines) pour aider les équipes à gagner en maturité sur la méthode Scrum que l’équipe utilisait depuis 3 mois. Je considère que ce coaching a porté ses fruits puisque l’équipe a pris conscience de certains de ses dysfonctionnements et a cherché à y remédier par elle même avec mon support. Le motivation de l’équipe était alors très bonne et la productivité supérieure à ce qu’elle avait été (bien que nous ne disposions pas de métriques fiables – comme une mesure régulière de la vélocité)

Aujourd’hui, force est de constater que ce projet s’éloigne de la méthode Scrum. Ce n’est pas encore visible sur la forme car l’équipe parle encore de Sprint, de « Scrum of Scrum » et fait des rétrospectives, mais sur le fond tout est changé et je vais me permettre de donner ma vision personnelle des raisons qui ont conduit à cela.

1. Le management n’a pas eu suffisamment confiance dans la réussite de l’équipe auto-pilotée et a (re)commencé à faire du micro management pour se rassurer car lui aussi subit une très forte pression de la part de son management pour délivrer à temps
2. Le conflit de priorité entre Produit (nouvelles fonctionnalités) et Engineering (Stabilité) n’a pas été résolu. La méthode Scrum oblige à prendre une décision, à la rendre visible dans le backlog et permet de focaliser les énergies sur 1 objectif commun. Plutôt que de prendre des décisions difficiles et lourdes de conséquences, les 2 entités ont préféré masquer le problème en changeant leur façon d’utiliser le Product Backlog et disant « on va faire un peu des 2″. Le problème est toujours présent … mais comme on le voit moins, certaines personnes pensent qu’il est résolu (qui a dit que les managers croyaient en la Magie ?).
3. Le micro management s’est traduit par un contrôle journalier de l’équipe sur la réalisation de tâches unitaires suivant un processus par étapes remis à l’ordre du jour (abandon du concept de sprint et surtout de ‘done’ en fin de sprint).
4. Contrairement à la volonté de l’équipe, les ressources sont affectés à des tâches précises et chacun est responsable de sa partie. Fini l’engagement de l’équipe à délivrer itérativement quelque chose qui marche, voilà le retour de la justification individuelle !
5. La plus grande partie du reporting actuel consiste à expliquer pourquoi l’avancement du projet n’est pas conforme à la roadmap définie initialement par … quelqu’un … sans implication de l’équipe. La seule question posée actuellement est « pour quand ce sera prêt ? » plutôt que « comment je peux t’aider à résoudre tes problèmes ? ».

Attention, mon propos n’est pas de dire que la méthode utilisée (Waterfall couplée à du micro-management) est mauvaise car je suis convaincu que l’équipe va délivrer les fonctionnalités demandées (j’ai moi-même utilisée cette méthode avec succès dans le passé). Mais comme pour la plupart des projets dans ce mode, ce sera avec du retard et avec un niveau de qualité non optimal (et cela devient déjà visible sur ce projet).

Mais je suis également convaincu qu’une approche Agile avec Scrum aurait permis de délivrer plus vite un produit de meilleure qualité. Car une équipe motivée, travaillant par petits incréments avec des objectifs clairs et partagés, est la plus grande chance de réussite d’un projet. Donc plutôt que de se concentrer sur le ‘pourquoi ca n’a pas marché’ il est plus important de se focaliser sur le ‘que reste-t-il à faire pour finir’.

Comme axe d’amélioration personnel, j’en retire qu’un coaching au niveau de hiérarchie supérieure aurait peut-être permis d’utiliser Scrum suffisamment longtemps pour prouver son efficacité et convaincre cette hiérarchie.

On apprend beaucoup de ses erreurs et puis il n’est pas dit que ce projet ne puisse pas revenir à l’agilité d’ici quelques mois, restons optimistes !

Scrum et Process – Mariage réussi

A toronto j’ai présenté une session avec Karl Scotland (qui a malheureusement quitté la société) sur l’historique de l’intégration de Scrum dans le « process framework » en vigueur chez Yahoo. Ce retour d’expérience décrit plus particulièrement la contribution des équipes Européenne à « l’agilisation » du framework entre 2006 et 2007.

L’article donne quelques informations sur les étapes de cette transformation, les difficultés rencontrées, les méthodes utilisées (mise en place de groupes locaux – le concept DICE) et les challenges toujours actifs.

En conclusion de cette article, nous considérons que le mariage est réussi entre la méthode Scrum et le Process Framework, à partir du moment ou les équipes en charge de la définition du process pratiquent le « inspect and adapt », ont l’ouverture d’esprit suffisante pour accepter les feedbacks et cherchent à faire adhérer (coaching) plutôt qu’à imposer (contrôle).

L’article est malheureusement en anglais, langue officielle actuelle de la communauté Agile, et je n’ai pas prévu de le traduire.

Accès à l’article en pdf : boutin-yahooeuropeagileexperiencereport

Agile Tour 2008

Comme plusieurs d’entre vous le savent déjà, je contribue à l’organisation de l’étape Grenobloise de l’Agile Tour 2008 qui se déroulera le 9 octobre à partir de 14h dans les locaux de Physique de Grenoble Université.

Après la recherche des sponsors (merci à tous) qui s’est faite assez rapidement – preuve de l’intérêt de la communauté Grenobloise pour l’Agilité – nous allons passer à la phase de choix des sujets de présentation (il y en a beaucoup et tous très intéressants, le choix va être difficile) et à l’organisation de la logistique (3 sessions en parallèle dans 2 amphis et une salle de cours).

Pour cette première édition, c’est déjà un petit succès car nous avons à ce jour 139 inscrits sur Grenoble pour un nombre maximal de 150 personnes (capacité des locaux) donc j’invite les retardataires à passer rapidement le message auprès de leur réseau et vite aller s’inscrire sur le site pour être certains d’avoir une place.