mardi 2 juillet 2013

Estimer : oui, mais pas tout de suite !


 Apprentissage incrémental


Quand on apprend une méthode, un sport, le solfège, une langue..., on commence par les bases, et on augmente progressivement le niveau de difficulté des apprentissages, au fur et à mesure qu'on a sécurisé les acquis précédents.

Quand une équipe apprend l'agilité, il me semble pertinent d'appliquer ce principe d'apprentissage progressif. D'ailleurs, c'est incrémental, c'est dans le thème !

Du coup, je me suis demandé quels sont les premiers apprentissages pour une équipe agile, et ceux qui peuvent attendre d'avoir sécurisé les bases.

De mon point de vue, les premières pratiques à mettre en œuvre sont celles qui ancrent les valeurs et principe de l'agilité (cf. le Manifeste Agile). Je choisirais donc :
  • les itérations courtes et les rétrospectives, qui permettent l'amélioration continue et l'adaptation
  • la présence du product owner dans l'équipe, les stand up meetings et le tableau partagé d'avancement des tâches (scrumboard, kanban,...), pour asseoir la collaboration et le feedback
  • les user stories et la priorisation du backlog produit, pour mettre la valeur du produit pour le client au centre des préoccupations de l'équipe
Et donc,  par soustraction, vous aurez compris que l'estimation ne fait pas partie des premiers apprentissages pour une équipe agile, de mon point de vue. J'entends hurler autour de moi, donc je vais m'expliquer.

A quoi sert l'estimation ?


L'estimation en planning game aide l'équipe à définir le périmètre sur lequel elle peut s'engager pour l'itération, pour peu qu'elle soit capable de calculer sa vélocité de façon fiable (par exemple, la moyenne de la vélocité des 3 dernières itérations).

L'estimation du backlog produit permet au product owner de piloter le projet : date de fin pour réaliser l'ensemble du backlog, ou quantité de périmètre à décaler à la release suivante pour tenir la date de livraison, ou... Et pour faire cela, il s'appuie là encore sur la vélocité de l'équipe, et il faut que son backlog produit soit suffisamment complet pour que ces prévisions aient du sens.

Donc on voit que l'estimation n'est efficace qu'une fois qu'on a une bonne idée de la vélocité de l'équipe, c'est-à-dire pas avant la fin de la deuxième itération.

Estimer à partir de la 3ème itération


Ah ben oui, je risque pas d'avoir la vélocité si l'équipe n'estime pas !!! Ne vous inquiétez pas, on va estimer, chaque chose en son temps ;-)

Mon idée est d'introduire les notions de complexité et de vélocité à la fin de l'itération 2. J'explique les avantages de ces mesures.

En général, au début d'un projet agile, il y a ce moment délicat où le coach (ou tout autre sachant) explique à l'équipe les principes de l'estimation relative des user stories. Il faut notamment expliquer que l'équipe doit choisir une user story de référence "pas trop petite ni trop grosse" et lui attribuer une estimation "moyenne", pour pouvoir ensuite comparer la complexité des autres US à celle de cette US de référence.
Si vous avez déjà essayé d'expliquer cela, vous avez déjà probablement l'habitude de voir le regard au mieux interrogatif, au pire vide et blanc des membres de l'équipe devant votre explication...

Le choix des user stories de référence est très simple : il s'agit des user stories des 2 premières itérations, qu'on estime a posteriori ! L'équipe peut appréhender la notion de complexité relative sur des user stories qu'elle maîtrise bien, puisqu'elles ont déjà été réalisées.

L'équipe estime alors les premières user stories restantes dans le backlog produit, et c'est plus facile parce que :
- on a une notion concrète de ce que représentent les points de complexité
- on connaît mieux le fonctionnel et l'environnement technique du produit, donc on comprend mieux la complexité de chaque user story

On calcule ensuite la vélocité moyenne sur les 2 premières itérations, et l'équipe peut s'engager plus facilement sur le périmètre de l'itération 3. L'équipe prendra un temps pour estimer l'ensemble du backlog (comme dans tout projet agile) et le product owner pourra construire le burndown chart de release et s'en servir pour piloter le projet.

En résumé :


Méthode :
- n'introduire l'estimation qu'au planning game de l'itération 3, avec les notions de complexité, de vélocité et d'indicateurs agiles
- utiliser les user stories des deux premières itérations comme user stories de référence, et les estimer a posteriori

Bénéfices :
- faciliter l'apprentissage de l'estimation et des indicateurs agiles
- faciliter le démarrage d'un projet agile en échelonnant dans le temps les apprentissages





mardi 28 mai 2013

Agile France 2013 : deux jours très intenses !

La semaine dernière, j'étais à Agile France 2013 et je me suis régalée.
D'abord, parce que ces conférences sont l'occasion de discuter avec mes pairs, et que ça fait du bien !
Mais aussi parce que j'ai assisté à des sessions de qualité, qui m'ont permis de remplir mes trois objectifs : apprendre des choses, prendre du plaisir et réfléchir. Et je suis ressortie de là avec beaucoup de sujets de réflexion !

Je vous livre (presque) à chaud ce qui m'a le plus marqué.

Le silence est d'or


Dans son excellente session "Pourquoi y m'écoute pas ?", Florence Chabanois  nous expliquait comment bien écouter les autres.
Elle m'a permis d'identifier un comportement que je reproduis souvent, et que je n'avais pas identifié comme néfaste.

Quand j'écoute quelqu'un, j'ai tendance à lui envoyer des ACK, des petites phrases qui, pour moi, veulent dire : "je t'écoute, je t'ai entendu, je t'ai compris".  Probablement parce que moi-même, j'ai besoin de ces marques d'écoute quand je discute avec quelqu'un...

Il s'avère que certains de ces ACK peuvent être perçus comme des interruptions qui font perdre à l'autre le fil de sa pensée. Par exemple, finir les phrases de l'autre...

Maintenant que je le sais, je vais essayer de me surveiller un peu mieux et d'améliorer encore ma qualité d'écoute.


Et toi, c'est quoi tes drivers ?



David Alia nous a servi une session riche en enseignements : "Un produit qui déchire, une équipe qui déchire... un leader qui déchire".

J'ai particulièrement aimé la partie sur les 5 drivers qui nous animent :
    Sois parfait !
    Sois fort !
    Fais des efforts !
    Fais plaisir !
    Dépêche-toi !
Je connaissais les miens (ceux qui me connaissent ont deviné qu'il s'agit de "Sois parfait !" et "Fais plaisir !"), mais je ne connaissais pas vraiment les autres... Du coup, j'ai fait un petit exercice : j'ai cherché pour chaque driver une personne de mes connaissances qui me semblait y obéir. Bizarrement, je connais beaucoup de gens qui suivent mêmes drivers que moi  : qui se ressemble s'assemble ?


La puissance du corps


Marielle Bezy nous a fait danser le tango dans sa session "Le tango : un outil ludique et profond pour revisiter le travail d'équipe, son leadership et son followership". Plus précisément, elle nous a fait ressentir les notions de leadership et de followership dans des exercices s'apparentant à la danse.

Cette session était non seulement originale, agréable et intéressante, elle m'a donné plusieurs épiphanies.

D'abord, les apprentissages passant par le corps sont souvent bien plus puissants que ceux passant par l'esprit. Ils s'ancrent en nous et restent plus longtemps, je pense. Alors je me suis demandé comment je pouvais utiliser ce type d'exercices dans mon métier de coach. Je pense que les jeux agiles tirent parti de ce principe. Je repars aussi avec un exercice simple à proposer à deux personnes qui n'arrivent pas à communiquer.

Mais surtout la révélation que j'ai eue pendant cette session est venue confirmer ce que j'avais déjà commencé à identifier en parlant avec d'autres coachs durant la conférence. J'arrive maintenant à mettre des mots dessus. Et cela m'apporte beaucoup d'un point de vue personnel.

Chacun d'entre nous est une trinité que j'appellerai les 3 C : Corps, Coeur, Cerveau.
En ce qui me concerne, ces dernières années, j'ai donné une place croissante à mon cerveau, au détriment de mon coeur (les sentiments) et de mon corps (les sensations). Cela s'est fait inconsciemment, pour des raisons assez variées que j'identifie maintenant : les études d'ingénieur qui ne reconnaissent que l'intelligence du cerveau, le fait que mes parents m'étiquetaient comme "la plus intelligente" de la fratrie et que c'était ma façon d'exister pour eux, le fait que je tire beaucoup de plaisir à comprendre les choses et les gens (à commencer par moi-même) d'un point de vue très rationnel, à tel point que ça devient additif, le fait que ce soit rassurant et que cela donne une impression de maîtrise...
C'est comme ça qu'on fait un burn out...

J'ai donc décidé de redonner plus de place à mon corps et à mon coeur pour atteindre un meilleur équilibre, une forme d'harmonie finalement :-)

C'est en polissant qu'on devient polisson...


Dans sa session "Coacher des managers", Antoine Contal nous livre ses recettes pour bien coacher un manager.

J'en ai retenu une en particulier, que je veux m'appliquer à mon auto-coaching : la pratique de petits exercices répétitifs pour s'approprier une nouvelle habitude.

Je vais commencer par appliquer cette technique aux deux sujets dont je vous ai parlé plus haut : développer une meilleure écoute et trouver l'équilibre entre coeur, corps et cerveau.


Pour le plaisir !


Pierrick Thibault nous a présenté les résultats de son enquête sur le plaisir au travail dans sa session "Travailler ? Oui, avec plaisir !".

Cette session m'a rappelé à quel point il est important de prendre du plaisir à ce qu'on fait, de façon à pouvoir donner du plaisir aux personnes autour de nous.

C'est un peu le principe de ce blog pour moi : je prends du plaisir en l'écrivant, et du coup, j'espère que vous prenez du plaisir en le lisant ;-)

jeudi 4 avril 2013

What... is your quest? To seek the Holy Continuous Improvement !

Aujourd'hui, j'ai déjeuné au Frog. J'ai déjeuné tard, bien après l'heure de pointe. Cela m'a permis d'assister à une scène qui a ravi l'agiliste en moi :-) (a ravi quoi ? l'agiliste en moi, placé après, donc c'est bien ça, ravi : i)

Je n'ai pas tout le contexte, je vous livre ma compréhension de ce que j'ai observé.

Une serveuse senior (manager ?) et une nouvelle serveuse se posent devant un jus de tomate, après le coup de feu. La manager demande à la nouvelle serveuse comment se passe son intégration. Est-ce qu'elle rencontre des difficultés ? La nouvelle serveuse a l'air en confiance, la conversation est détendue. Elle partage avec sa manager ses questionnements. La manager lui donne des conseils. Jusque là, rien d'exceptionnel, me direz-vous...

La manager demande ensuite à la nouvelle si avec son regard neuf, elle voit des choses qui pourraient être améliorées dans l'organisation du pub. Elle a l'air de vraiment écouter les suggestions de la nouvelle.

La nouvelle demande à sa manager si de son côté il y a des choses qu'elle peut améliorer dans sa façon de faire. La manager répond avec bienveillance.

A la fin de cet entretien (si on peut appeler ça comme ça), la manager dit à la nouvelle : Bon, on y retourne. Aujourd'hui je vais te montrer comment on ...

En 5 minutes, on a un bon exemple d'amélioration continue, dans un domaine totalement différent de l'informatique (même s'ils ont de la bière, c'est un pub quoi !). On voit aussi une bonne pratique d'apprentissage : l'apprentissage incrémental, avec des objectifs clairs.

Et j'ai eu droit à la cerise sur le mc do : en partant, j'ai vu 3 serveurs jouer à la courte paille. J'imagine que c'était pour se répartir une tâche désagréable. Ils ont gamifié le rangement du pub !!!

Holy crap ! Je crois que je vais retourner là-bas plus souvent ! J'aurais une bonne excuse pour déguster leur bière : j'observe des pratiques managériales innovantes :D


P'ho !!! Dojo


Le 20 mars s'est tenu à Smartpoint le premier PODOJO.

Un PODOJO, c'est quoi ?

Lors d'Agile Games France 2013, on était plusieurs à avoir constaté que nos Product Owners ont du mal à écrire des tests d'acceptance. Et on avait eu une idée pour y remédier. Les développeurs ont leurs coding dojos pour s'améliorer par la pratique, faisons la même chose pour les PO ! Le PODOJO était né.

Nous avons accouché le 20 mars, mais petit bébé doit encore grandir. La première séance a été riche, mais le format reste encore à ajuster.

La prochaine séance sera le 10 avril, encore une fois en mode expérimentation. Si vous voulez vous tenir informés, inscrivez-vous sur le google group PODOJO !

Mon petit oiseau s'est pris à voler

On m'a dit et répété qu'on n'existe pas si on ne twitte pas...
Alors je m'y suis mise.
Vous pouvez me suivre : @EmilieEsposito
Soyez indulgents, je débute...

mardi 12 mars 2013

PO stratégique / PO opérationnel

Je rebondis sur le très bon article d'Alexandre Boutin sur le rôle du Product Owner .

Pour qu'un projet agile réussisse, il faut que le Product Owner tienne son rôle.
Et pour que le Product Owner tienne son rôle il faut :
- qu'il soit suffisamment disponible pour l'équipe
- qu'il ait le mandat pour prioriser le backlog produit

C'est malheureusement une situation idéale que j'ai rarement trouvée sur les projets.

Le problème vient en général du fait que les personnes de l’organisation qui ont vraiment le mandat suffisant pour décider seul des priorités (sans demander à sa ligne hiérarchique) n’ont souvent pas le temps de s’impliquer plus que quelques heures par semaine. C’est vraiment insuffisant pour bien tenir son rôle de PO…

Dans ces cas-là, je conseille la mise en place d’un PO « stratégique » et d’un ou plusieurs PO « opérationnels ».
Les PO opérationnels sont dans l’équipe et sont en relation fréquente avec le PO stratégique. Le PO stratégique partage la vision produit avec les PO opérationnels, valide les propositions de macro user stories (epics) et de priorisation macro des PO opérationnels. Les PO opérationnels ont en charge le grooming du backlog, la rédaction des tests d’acceptance, la recette du produit, bref, les tâches quotidiennes dont le PO est responsable.

Certains parlent de proxy PO, mais je n’aime pas ce terme. Un proxy protège l'intérieur de l'extérieur, il agit comme une frontière, une barrière. Et l'équipe ne doit pas être protégée du PO stratégique, car, tout simplement, il fait partie de l'équipe !  Le PO stratégique et l’équipe doivent garder des occasions de se rencontrer et d’échanger, par exemple les démos.

 Qu’en pensez vous ?

mercredi 6 mars 2013

Entretenez la flemme !

En ce moment, je coache un PO dont c'est le premier projet agile, et même le premier projet informatique. On peut dire que c'est un dépucelage pour lui, et pour l'instant, il est ravi ;-) J'adore ça, parce qu'il amène beaucoup de fraîcheur dans mes réflexions sur l'agilité.
Il m'a récemment montré un avantage de la spécification par les tests que je n'avais pas encore perçu.

J'étais en train de relire une user story qu'il avait écrite. Il s'agissait de gérer un élément d'information simple, en texte libre. Je lui fais remarquer qu'il n'a prévu que les fonctions d'ajout et de suppression, mais pas de modification. Sa réponse m'a amusée et m'a fait réfléchir : "Ah oui, c'est vrai, tiens... Mais ça veut dire qu'il faut que j'écrive la règle de gestion et les tests qui vont avec ??? Franchement, on peut s'en passer, de la modification. Si on veut modifier, on supprimera puis on ajoutera !".
Il faut dire que mon PO sera un utilisateur de l'application que nous développons, donc il connaît parfaitement le fonctionnel et il est bien conscient que les autres utilisateurs se tourneront vers lui s'ils estiment que le logiciel n'est pas assez pratique. J'en déduis donc que cette fonctionnalité n'est réellement pas prioritaire. Hop, affaire réglée :-)

Conclusion : en faisant écrire les tests d'acceptance au PO, on lui donne un moyen très concret d'appréhender la complexité d'une user story, et du coup, il est bien plus aisé pour lui d'évaluer le ROI d'une user story. Il y a du lean là-dedans, il me semble...