Avoir le réflexe Agile

Lors de la préparation de l’AT2008 (le 9 octobre à Grenoble), nous avons identifié une liste de tâches à faire avant le début de la manifestation (mise en place de tables pour l’accueil et le buffet, organisation des salles, affichage des posters …). Pour nous organiser au mieux, nous avons donc lister les tâches sur notre Wiki et de demander à des volontaires du CARA d’inscrire leur nom en face de chacune des tâches. Comme disent les anglais : « Cela fait du sens ».

Lors de notre dernière réunion de préparation, j’ai challengé cette approche car je ne la trouvais pas vraiment Agile. En effet, elle nécessite la présence d’un coordinateur (qui a dit un chef de projet ?) pour gérer les dépendances entre tâches et les impacts liés aux éventuels retards.

Nous avons donc décidé de nous organiser de la façon suivante :

• L’équipe organisatrice identifiera l’ensemble des tâches, le nombre de personnes nécessaires pour la mener à bien et les classera par priorité (Product Owner)
• Chacune des tâches sera écrite sur un Post-It qui sera affiché sur le mur de la salle de conférence (Scrum Master)
• Les volontaires se retrouveront devant le mur de Post-It, prendront le premier Post-It disponible, réaliseront l’action et reviendront chercher une nouvelle tâche etc … (Team)

De cette façon nous pouvons démarrer dès que suffisamment de volontaires sont disponibles pour réaliser la première tâche, pas besoin d’attendre que tout le monde soit là, si un volontaire arrive en retard il ne pénalise pas le projet, nul besoin de coordination (pas de ‘muda’) car l’équipe s’auto-organise, et si une tâche prend plus de temps que prévu ce n’est pas un problème en soi.

Il n’y a pas que les projets informatique qui se prêtent à l’Agilité et avoir le réflexe Agile permet souvent de trouver des solutions plus efficaces que celles auxquelles nous pensons en premier lieu.

2 for Scrum and Scrum for 2 …

Régulièrement, des personnes viennent me voir pour me dire que compte tenu de la taille réduite de l’équipe (2 personnes), elles n’ont pas l’intention de mettre en place l’ensemble des cérémonies Scrum (les réunions comme les « Daily stand up » ou « Demo »)

Même si cela ne me plait pas vraiment,  en général je laisse filer car je n’ai pas vraiment d’arguments à leur opposer et je ne connais pas vraiment les risques qu’ils encourent à se comporter comme cela. Bien entendu, si la taille de l’équipe est de 3 ou plus, j’évoque les besoins de synchronisation, de prioritisation et de communication pour inciter ces personnes à mettre en place toutes les cérémonies Scrum. Mais s’ils ne sont que 2, je suis généralement moins convaincant car moins convaincu.

J’ai donc décidé d’expérimenter par moi même « Scrum for 2″ puisque je suis en charge d’un nouveau projet  où nous sommes 2 dans l’équipe (je rassure ceux qui me connaissent, il n’a rien de technique).

Je suis le Product Owner, Laurent est le Scrum Master et l’équipe de réalisation est constituée de Laurent et Moi

Nous allons appliquer la méthode « in the book » ce qui me permettra de mieux appréhender la plus value apportée par chaque cérémonie et avoir plus d’arguments à opposer à ceux qui veulent faire sans.

Bref, c’est une action à suivre …

Bravo ManU !

Je me joins à Claude (qui doit travailler la nuit à Toulouse car son post est daté de 00:06) pour féliciter ManU pour son excellent article sur les pratiques agiles de son équipe et surtout par ses illustrations grâce à de nombreuses photos réelles de leur espace de travail (je le sais, j’y étais il y a 2 jours).

Je recommande TRES FORTEMENT de prendre le temps de lire attentivement le document décrivant le retour d’expérience de ManU

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