Nous avions également la possibilité de passer 20 minutes avec 1 des 16 coaches présents pour une session de coaching personnel sur un sujet qui nous tenait à cœur, et vu l’évolution de la situation actuelle chez Yahoo, j’en avais un de tout prêt. Je dois dire que j’ai été bluffé par le bénéfice personnel que j’ai tiré de ces 20 minutes de coaching. Si les 10 premières minutes ont été plutôt neutre car mon coach s’est limiter à des questions standards (il m’a semblé qu’il déroulait la méthodologie) alors que moi je jouais le jeu à fond, en toute honnêteté et transparence, les 10 dernières minutes ont vraiment été passionnantes avec des échanges très productifs et très enrichissants de mon point de vue. Et comme mon coach était curieux, je lui ai même parlé d’agilité.

Lors du débriefing de la session avec une autre coach à qui je mentionnais ma surprise d’avoir eu un enrichissement aussi important sur un temps aussi court avec quelqu’un que je ne connaissais pas la minute d’avant, elle m’a fait remarqué que pour elle j’avais reçu à la hauteur de ce que j’avais donné. C’est à dire que mon honnêteté et la richesse des informations fournies durant la première partie avaient donné suffisamment de matière pour permettre au savoir faire du coach de s’exprimer pour que je puisse en bénéficier.

J’avais déjà un avis très positif sur le coaching, qui n’est pas du conseil ni de la formation, maintenant je suis convaincu des bénéfices que l’on peut tirer d’un coaching personnel … à condition de jouer le jeu de la transparence et de l’honneteté.

PS : Bruno Orsier propose un feedback plus complet sur le contenu de cette journée.

Il y a 5 semaines, j’avais évoqué mes incertitudes sur l’application de Scrum pour une équipe de 2 personnes et je suis maintenant en mesure de faire un premier retour.

Scrum est parfaitement adapté à une équipe de 2 personnes et voici comment nous avons pratiqué:

• Le Product Backlog est consitué uniquement de Post-IT sur un mur proche de mon bureau (de temps en temps je remets à jour le Wiki avec les éléments identifiés sur les Post-IT)
• L’itération dure 1 semaine. Démarrage et Fin tous les Vendredis après-midi.
• Le Daily Stand-Up est formel et nous nous réunissons tous les matins vers 9h pendant 10 mn environ devant le mur de Post-IT
• Les critères d’acceptation de chaque item sont clairement définis et affiché sur le mur.
• Les tâches ne sont pas pré-affectées et il nous est arrivé plusieurs fois de prendre une tâche qui semblait « mieux » adaptée à l’autre
• Les cérémonies (Review, Rétro, Product Backlog Review et Sprint Planning meeting) se déroulent sur 1 heure maximum le vendredi de 14h à 15h.
  • La Review consiste à imprimer ce que nous avons produit (des standards de bonnes pratiques) et les mettre sur le mur afin de visualiser l’avancement du projet. Un mail est également envoyé à tous les stakeholders et reviewers (nous l’appelons le Friday Mail) et contient l’ensemble de la production de l’itération.
  • La Rétro est formelle et enregistrée sur le Wiki
  • La Vélocité de l’itération est calculée et enregistrée sur le Wiki
  • Le Product Backlog Review consiste à discuter des actions nouvelles identifiées durant l’itération (cela arrive fréquemment car le projet est dans sa phase créative – on ne sait pas encore vraiment où on va arriver, mais nous avons défini le comment nous allons y arriver) et de choisir les priorités des items.
  • Le Sprint Planning Meeting consiste à écrire les Post-IT de l’itération et les coller sur le mur
• Nous n’utilisons pas de BurnDown de sprint ou de Backlog (et pour l’instant cela ne nous manque pas vraiment)

Ce que nous a apporté la méthode Scrum sur ce projet de 2 personnes (à temps partiel) après 5 itérations

• Nous produisons des éléments chaque semaine car nous nous focalisons sur une liste de tâche réduite
• Notre engagement à produire quelque chose toute les semaines me semble plus fort car il est rendu visible sur le mur de Post-IT
• La vision des Post-IT nous focalise sur nos priorités de la semaine et cela nous permet de ne pas nous perdre dans des discussions intéressantes mais longues et stériles à ce moment du projet sur « vers quoi nous allons » (nous sommes en train de le découvrir itération par itération)
• L’affichage permet un gain de temps substantiel car il est très rapide de réécrire un Post-IT mal formulé puis de jeter l’ancien en le remplacant par le nouveau voir de jeter une Post-IT qui n’a plus de sens du fait de l’avancement du projet (cela nous est arrivé)
• La discipline avec laquelle nous réalisons les cérémonies Scrum nous donne la garantie de ne rien oublier (en particulier vrai pour la rétrospective car nous trouvons une idée d’amélioration à chaque fois)

Je suis maintenant convaincu que si nous n’avions pas été formel dans notre application de Scrum, nous n’aurions pas eu la même productivité sur ces 5 dernières semaines car j’ai clairement en mémoire une itération qui a été « sauvée » par l’application stricte de la méthode car sans elle nous aurions repoussée l’échéance à la semaine d’après et créé un précédent de mauvaise pratique.

Ce petit article ne se veut pas être une liste de vérités absolues mais simplement ma perception de la situation dans les différents pays régulièrement visités. De plus, il est important de limiter mes propos au périmètre de mon entreprise (les personnes avec qui je travaille) et ne pas généraliser à l’ensemble du pays.

FR : Une bonne implication des équipes techniques, mais une forte résistance du management dû à la crainte d’une perte de pouvoir, une volonté de micro management et globalement la satisfaction des méthodes traditionnelles (on échoue mais on sait pourquoi, donc tout va bien et on ne change rien).

UK : Une démarche purement individuelle basée sur l’atteinte des objectifs définis par le top management qui empêche la mise en place d’un vrai sentiment d’équipe. Un certain manque de maturité sur l’importance de la qualité logiciel (et les bonnes pratiques associées) et la satisfaction réelle à être le héros que tout le monde admire.

TW : Une curiosité naturelle pour tout ce qui est nouveau, mais freinée pas une hiérarchie omni-présente et omni-potente (tant technique que produit). Les équipes vivent l’agilité comme une pression supplémentaire car il est interdit de descoper pour ne pas « perdre la face ».

KR : La phrase qui résume le mieux ma perception m’a été dite il y a 18 mois « Alex, it’s incorrect to challenge ! » ce qui veut dire qu’il n’y a jamais de remise en cause de ce qui a été dit ou écrit. Le Scrum Master agit comme un chef de projet et la discipline est assurée, mais contrairement à ce que l’on pourrait croire, plusieurs bénéfices liés à Scrum dans ce contexte commencent à être visibles.

HK : Bonne implication des équipes techniques mais sous tutelle stricte de la direction produit (une relation client-fournisseur exacerbée du fait d’une relation excessive vis à vis de l’argent). Une fois la direction produit rassurée sur la possibilité de garantir des dates de livraison (4h de négociation au lieu de 1h initialement prévu), Scrum est en cours d’implémentation avec succès.

IN : Manque total de confiance du management envers les équipes techniques, ce qui se traduit par des responsables techniques qui veulent être maître de la situation en permanence. Ils ne doivent pas échouer sous peine de lourdes sanctions et donc ne laissent aucune liberté aux équipes (CMMi est par ailleurs un grand succès en Inde).

CA : Les Mr Jourdain de l’agilité, ils sont agiles (et pas font) sans le savoir ou presque, j’adore les canadiens Un esprit d’équipe ultra poussé (soutenu par le management qui s’implique) allié à une proximité avec la direction produit leur permet de délivrer des produits superbes qui sont de vrais succès commerciaux.  La taille réduite de l’équipe est surement le critère principal de succès, alors attention à ne pas perdre cet esprit lorsque l’équipe grandira.

Comme indiqué ci-dessus, ce n’est que ma perception actuelle retranscrite en quelques mots et je suis conscient que la situation est surement différente dans une autre société.

Nous avons été accueilli au Genève Business Center par Jacques et François qui avaient organisé des sessions de présentations dans 2 salles en parallèle. Une 50aine de personnes étaient présentes, majoritairement novices à l’Agile que expérimentées à ce qu’il m’a semblé, et les échanges ont été nombreux et fructueux, que ce soit durant ou entre les sessions. Un grand merci aux organisateurs pour cette réussite, le prochain évènement d’importance sera les XPDays Suisse le 30 mars 2009 … restez à l’écoute.

J’ai eu l’occasion de présenter la démarche « Process » de Yahoo International de 2005 à 2008 et le basculement vers l’agilité à partir de 2006 avec des réussites diverses du fait de la différence de culture de certains pays.

Jeudi 9 Octobre, c’est le grand jour pour Grenoble, nous attendons plus de 200 personnes à partir de 13h30 pour un démarrage à 14h00 précise.

Quelques pointeurs:

• Methods & Tools blog

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 …

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

Par contre, j’ai trouvé une forme de réponse coté Lean. En effet, si le prend le point de vue de l’utilisateur final, la documentation qui n’est pas lue par l’utilisateur final peut souvent être considérée comme du « gâchis » et je considère qu’il y a donc une opportunité de réduction des coûts de production.

Depuis quelques temps, chaque fois que quelqu’un veut écrire un document, je lui pose la question suivante:

• QUI VA LA LIRE ?

Les réponses sont le plus souvent l’une des suivantes:

1. Untel la lit et l’utilise
2. Je n’en sais rien mais quelqu’un devrait le faire
3. Ce document est contractuel
4. Notre processus dit qu’il faut la produire

Sur la réponse 1, je réponds : « C’est Ok, ce document est utile ».

Sur la réponse 2, je réponds simplement : « Mais pourquoi l’écris-tu ? », et bien souvent ce document est abandonné

Sur la réponse 3, je dis : « Ok, mais as-tu essayé de la réduire au strict minimum ? », car il y a souvent une volonté de bien faire alors que le juste nécessaire suffit souvent.

Sur la réponse 4, je dis : « Viens avec moi on va voir le responsable de ce processus pour voir si on peut le modifier ».