Les estimations sont une bonne pratique

Tableau RelatifJ’avoue ne pas totalement accrocher avec le mouvement #noestimate.

Je comprends bien la volonté de gagner du temps (ou plutôt d’éviter d’en gaspiller) et je sais que l’on peut planifier des releases sans avoir besoin d’estimer chacune des User Story (@claudeaubry détaille cela précisément dans la version 4 de son livre sur Scrum – Ce qui lui  a d’ailleurs valu plusieurs remarques de ma part lorsque j’en ai fait la relecture).

D’autres personnes considèrent que dès lors qu’une estimation est donnée, elle est considérée comme un engagement et que tout engagement amène du mauvais stress sur l’équipe (la pression) et un biais potentiel sur la qualité de ce qui sera produit (afin de tenir l’engagement). Et donc qu’il est préférable de ne pas donner d’estimation pour éviter ces désagréments.

De la même façon, j’ai lu et entendu que puisque les managers ne comprennent pas l’utilisation des indicateurs agiles et qu’il est trop difficile de leur en expliquer le fonctionnement (ou peut être simplement qu’ils ne veulent pas entendre) alors le plus simple est d’arrêter de les produire. Donc plutôt que de s’occuper du problème réel, on fait disparaitre la conséquence en espérant que cela ira mieux … un doux rêve 🙂

De mon coté, je trouve que passer du temps à faire des estimations a de la valeur pour peu que l’on tienne compte des éléments suivants :

Continuer la lecture de « Les estimations sont une bonne pratique »

Petites et grandes victoires

Victoire SamothraceLors du lancement d’un nouveau sprint d’une équipe que j’accompagne depuis plusieurs mois, j’ai eu cet échange intéressant :

  • Moi : Ce qui serait bien, c’est que l’équipe tienne son engagement sur ce sprint
  • Moi : Ce n’est pas encore arrivé, et ce serait une belle victoire que nous pourrions exploiter
  • Equipier : C’est cela que tu appelles une victoire !
  • Moi : Oui, et toi, comment définis-tu la victoire ?
  • Equipier : C’est lorsque l’utilisateur peut utiliser un module complet sur son poste
  • Moi : Bonne remarque, alors considérons que tenir l’engagement du sprint sera une petite victoire 🙂

Il est tout à fait vrai que la réussite d’un projet se mesure en terme de valeur et de satisfaction des utilisateurs, et que donc, tant qu’ils n’ont pas quelque chose d’opérationnel qui peut leur amener des bénéfices concrets, il est difficile de parler de succès sur le projet.

Néanmoins, j’utilise souvent le terme de « petite victoire » lors de la mise en œuvre de l’agilité au sein d’une équipe, car je trouve qu’il est important que l’équipe ait un objectif raisonnable qu’elle puisse atteindre à court terme afin de garder sa dynamique et son envie de donner le meilleur d’elle même.

Voici quelques petites victoires (en vrac) que je souligne systématiquement :

  • Déplacer un postIT de tâche dans la colonne « Terminé »
  • Finir la première « grosse » User Story
  • Tenir l’engagement de l’itération pour la première fois
  • Prendre une Story en plus au cours de l’itération
  • Voir que le Scrum Board est vide de PostIT en fin d’itération
  • Voir que le « Hall of Fame » des Story terminé est trop petit
  • Faire tenir un Stand Up en moins de 10 minutes
  • Avoir réalisé toutes les actions de la rétrospective à mi itération
  • Recevoir un mail de félicitation d’un utilisateur
  • Se faire applaudir par les utilisateurs lors de la revue d’itération
  • Voir que le Product Backlog de la Release est presque vide

Et vous, quelles petites victoires avez-vous partagé sur vos projets ?

 

Ne pas oublier le chemin parcouru …

cycle de RogersIl semble que l’agilité devienne de plus en plus « main stream » (en référence à la courbe de Moore) avec une majorité de personnes qui souhaite l’adopter.

Je fais ce constat non pas vraiment en constatant de plus en plus d’initiatives Agile (bien que j’ai du refuser plusieurs missions très intéressantes dernièrement ce qui indique une demande de plus en plus forte) mais plutôt en constatant le nombre d’attaques de l’agilité via des blogs ou site web (je ne ferais aucune publicité pour ces espaces qui, au delà d’amener une contradiction bénéfique, sont bien souvent rédigés comme des savates).

Du coup je me demande si nous, les early adopters, nous comportons comme il le faut actuellement et si nous n’avons pas un peu « oublié le chemin que nous avons parcouru ces dernières années » ?

Continuer la lecture de « Ne pas oublier le chemin parcouru … »

Réponse à Appel d’Offre Agile

appel d'offresDernièrement j’ai été sollicité par une société de service en informatique pour les aider à répondre à un appel d’offre important (plusieurs M €) dans lequel l’Agilité était obligatoire.

Commençons par la fin en disant que l’histoire s’est bien terminée puis cette société a gagné les lots les plus importants de cet appel d’offre, puis revenons au début de l’histoire.

Histoire

Cela faisait de nombreuses années que je ne m’étais pas confronté à l’écriture d’une RAO (Réponse à Appel d’Offres), exercice que j’ai pratiqué quotidiennement, ou presque, de 1998 à 2002, et j’étais très intéressé à l’idée de replonger dans cet exercice difficile que néanmoins j’aime bien.

Le contexte était également particulier puisque le client était un fin connaisseur de l’agilité, il n’allait donc pas suffire de lui écrire des banalités sur l’agilité pour le convaincre de la compétence du fournisseur (J’ai déjà vu un simple copier/coller de Wikipédia ou du contrat type mis à disposition par Xebia … bonjour la compétence du fournisseur !!).

Pour la méthode Scrum, il n’était pas question de remplir la RAO de pages et de pages de description de la méthode, avec des schémas récupérés sur le net. Il ne fallait surtout pas confondre quantité et qualité, tout en sachant que dire « nous sommes agiles » ou « regardez toutes nos expériences agiles » n’allait pas suffire à convaincre.

Il y a avait également une demande de PQS dans l’appel d’offre, ou Plan Qualité de Service, avec certains indicateurs demandés … qui n’étaient pas forcément compatibles avec une démarche agile.

Alors comment se sortir de cette situation ?

Continuer la lecture de « Réponse à Appel d’Offre Agile »

Agile : J’aime / J’aime pas

Pour animer la dernière rétrospective d’une équipe qui pratique l’agilité depuis 2,5 mois sur un projet de monétique, j’ai demandé à chaque participant de me donner un éléments de l’agilité qu’il aime et un élément qu’il n’aime pas.

Je souhaite partager avec vous ces réponses, qui n’engagent bien entendu que cette équipe spécifique dans son contexte spécifique 🙂

Tout d’abord quelques éléments de contexte :

  • Une équipe de 3 Product Owner + 1 représentant métier
  • Un Scrum Master
  • Une équipe de 4 développeurs
  • Les POs et les équipiers sont sur des sites distants de quelques centaines de kilomètres.
  • Les sprints font 2 semaines et de vrais utilisateurs sont présents (par connexion car ils sont à l’étranger) à la démo de sprint

Et voici les réponses au J’aime / J’aime pas, assaisonné d’une petite explication dite oralement durant la rétrospective

Continuer la lecture de « Agile : J’aime / J’aime pas »

Piloter l’agilité avec la vélocité

Je rencontre pas mal d’équipes Scrum qui se posent la question de l’utilité de l’estimation des stories en points !

Ok, me disent-ils, nous savons que les points permettent de calculer la vélocité (i.e.: la vitesse de l’équipe), c’est à dire le nombre de points par durée fixe de temps ou itération (comme des km/h pour une voiture), mais chez nous, personne n’utilise la vélocité pour prendre des décisions, du coup, à quoi ça sert d’estimer en points ?

Effectivement, vu sous cet angle, l’équipe aurait raison d’arrêter une pratique qui prend du temps et qui ne leur sert à rien, et pourtant, un Product Owner bien informé dispose avec la vélocité d’un outil réel de pilotage Agile.

Ce que je recommande de mettre en place sur tous les projets que j’accompagne est … Continuer la lecture de « Piloter l’agilité avec la vélocité »

Evaluation Agile … Bonne ou Mauvaise nouvelle ?

Depuis quelques mois je suis sollicité pour faire des évaluations de situation « Agile » afin de diagnostiquer les causes des problèmes rencontrés.

Mon activité principale est plutôt de former et d’accompagner de nouvelles équipes dans la mise en place de l’agilité, et ces nouvelles demandes me font penser que nous sommes peut-être en train de franchir une nouvelle étape dans la prise en compte des méthodes agiles … ou alors très proches de tomber dans le gouffre de Moore (Cf. « The Chasm » de la Courbe de Rogers ci-dessus).

Dans la grande majorité des cas, il s’agit d’équipes qui pratiquent l’agilité, principalement Scrum, depuis plus de 18 mois, et bien souvent la demande d’évaluation émane de managers, plus rarement des équipes elles-même, qui n’obtenant pas les bénéfices attendus, me demandent de chercher les raisons de cette situation.

Dans le cadre des ces évaluations, ma démarche est toujours la même : Continuer la lecture de « Evaluation Agile … Bonne ou Mauvaise nouvelle ? »

Rétrospective Dixit

Lors du dernier Agile Games France, Alexis (@alexismonville) a proposé un jeu pour faire travailler une équipe sur la définition de quelque chose, par exemple, la perception de l’agilité. Pour cela il utilisait un ensemble d’images que les participants devaient choisir en fonction de ce qu’ils imaginaient de leur représentation.

Cela m’a donné l’idée d’utiliser les cartes DIXIT (que j’avais également apporté à Agile Games France) pour animer une rétrospective. Les cartes Dixit ont la particularité de contenir plusieurs dessins très différents sur chaque carte, ce qui fait qu’elles sont un support intéressant pour aider les membres d’une équipe à dire des choses qu’il pourrait être plus difficile d’exprimer oralement.

Voici la façon dont Eric, Scrum Master d’une équipe que j’accompagne, a utilisé cette méthode dernièrement :

Continuer la lecture de « Rétrospective Dixit »

Product Owner … qui es-tu ?

Je partage avec vous ma vision du rôle du Product Owner, tous vos feedbacks sont les bienvenus 🙂

Rôle du Product Owner

Le Product Owner (ou PO) est avant tout un rôle initialement définie dans la méthodologie Scrum et maintenant généralisé à l’ensemble des méthodes dites « Agile ». Ce rôle est généralement tenu par un individu unique, mais il est courant de voir également une équipe de PO assurer cette mission avec succès, sous réserve que cette équipe de PO tienne un discours commun et cohérent auprès de l’équipe de réalisation.

Le PO est un membre à part entière de l’équipe Scrum dont la responsabilité principale est de définir un produit qui apportera le maximum de valeur métier aux utilisateurs dans le temps et le budget impartis au projet.

Le Product Backlog

L’outil principal utilisé par le PO est le Product Backlog (ou PB) qui est la liste ordonnée des éléments constitutifs du produit. La priorité des éléments est définie suivant 4 caractéristiques : leur valeur métier, leur effort de réalisation, leur risque et la connaissance technique ou métier apportée par leur mise en œuvre. Chaque PO définit des règles de priorisation, basées sur 1 à 4 de ces caractéristiques, généralement valables pour la durée de réalisation d’une version (un produit se décompose en plusieurs versions).

Continuer la lecture de « Product Owner … qui es-tu ? »

Pair Training et Sérendipité

A la Fédération Agile, nous avons institué le Pair Training (2 formateurs en séance) avec beaucoup de succès dans nos approches pédagogiques.

Pour les participants, cette co-animation leur permet de bénéficier de

  • regards croisés,
  • retours d’expériences variés,
  • un rythme plus dynamique,
  • une plus grande proximité avec les formateurs lors des ateliers.

A ce propos je vous rappelle mes prochaines formations :

  • Innovation Games® : 14 mars sur Grenoble et 10 avril sur Paris
  • Kanban pour l’IT : 13 mars sur Grenoble et 20 novembre sur Grenoble

Généralement nous co-animons des sessions que nous avons préparé ensemble (comme les formations « Innovation Games® » que j’ai eu l’occasion de donner en 2011 et 12012 avec Claude Aubry @claudeaubry, Romain Couturier @romaincouturier et Fabrice Aimetti @Agilarium) ou nous collaborons avec un expert d’un domaine précis qui a préparé une formation spécifique (comme les formations « Kanban pour l’IT » que je vais donner avec Laurent Morisseau @lmorisseau).

Cette semaine la situation était différente car Claude Aubry m’avait sollicité pour co-animer une formation Scrum pour 16 personnes sur 2 jours – avec ce nombre de participants il est préférable d’être 2 – et des formations Scrum j’en donne également beaucoup de mon coté. Claude était à l’origine du contact alors nous avons naturellement choisi son support de cours pour la formation et c’est donc lui qui a donné le rythme du cours et décidé des ateliers à faire. J’intervenais ponctuellement pour donner mes retours d’expérience et surtout pour animer un groupe lors des différents ateliers.

Ces 2 jours ont vraiment été très spéciaux pour moi !!!

Continuer la lecture de « Pair Training et Sérendipité »