Archive

Archive for the ‘Agile’ Category

Actu

September 12th, 2011 No comments

Je souhaitais vous présenter deux parutions importantes des derniers jours :

9782100558506 G 209x300 Actu


La première est le nouveau catalogue des formations de Pyxis : pyxis-formation-automne-2011. Je vous invite à le télécharger pour le consulter dès maintenant.

La seconde est la publication du livre de Mathieu Boisvert et Sylvie Trudel : Choisir l’agilité
Un très bel accomplissement de leur part. Bravo à vous deux icon wink Actu . (Le livre est disponible sur amazon.fr et le site de l’éditeur pour l’instant) 

Categories: Agile Tags:

AGILE COACH CAMP CANADA – JUNE 24TH AND 25TH, 2011

May 31st, 2011 No comments

 

Bonjour,

Je participe au Agile Coach Camp à Montréal le 24 et 25 juin prochain.

CAT33 AGILE COACH CAMP CANADA – JUNE 24TH AND 25TH, 2011

Le 23 et 24 juin, j’assisterai à la formation Coaching Agile Team donnée par Lyssa Adkins et Mikael Spayd (profitez du spécial accordé aux participants du Agile Coach Camp)

Vous pouvez suivre l’évènement sur Twitter @agilegardener avec le tag #accmtl

J’espère vous y rencontrer.

Categories: Agile, Coaching, Rendez-vous Tags:

Agile Coach Camp Canada – Here we go!

June 10th, 2010 No comments
agilecoach2010 300x88 Agile Coach Camp Canada   Here we go!

Click on the logo to register on Agile Coach Camp Canada website

Tomorrow morning will be the kind of easy wake up as I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with 3 colleagues of mine from Pyxis.

Looking forward to meet you there with all the others great agile coaches icon wink Agile Coach Camp Canada   Here we go!

Agile Coach Camp Canada
An Open Space Conference for Agile Coaches
Peer-to-peer Learning in a Collaborative Setting
June 11-12, 2010
Waterloo, Ontario, Canada
Free! And it’s SOLD OUT

Follow #accca on Twitter

To know more about registred people, have a look at postion papers.

Le gestionnaire agile dans les lignes de tir

June 10th, 2010 5 comments

Coincé entre sa direction qui ne comprend pas encore les enjeux et les répercussions de la mise en place d’une approche de gestion de projet agile  et son équipe qui maintenant prend ses responsabilités, le manager d’une équipe agile reçoit des balles de toute part.

Bien entendu, tout le monde ne souhaite qu’une chose, réussir le projet. Cependant, les 3 protagonistes n’ont pas le même point de vue sur ce projet. Ils n’ont pas les mêmes connaissances de l’ampleur, du détail et de la difficulté de l’ouvrage. Ils n’ont pas non plus les mêmes besoins aux mêmes moments pour se rassurer (ou être rassurer) sur les chances de réussite ou sur la santé du projet.

Le gestionnaire agile dans les lignes de tir 300x199 Le gestionnaire agile dans les lignes de tir

Le gestionnaire agile dans les lignes de tir (photo by http://www.flickr.com/photos/mashleymorgan)

Lorsque qu’après avoir convenu qu’une première livraison de 2 mois permettrait de lever les risques et d’obtenir une ‘tranche’ verticale de logiciel fonctionnel, afin estimer de façon plus sereine le reste du projet, la direction décide de demander à l’équipe de réestimer la totalité du backlog après seulement 1 mois de travail, la fusillade éclate et le gestionnaire ou manager agile se retrouve dans les lignes de tir.

Satisfaire la demande de la direction ou soutenir l’équipe qui est tout à fait d’accord de réestimer le backlog, mais seulement après la release, une fois qu’elle aura l’information pertinente qu’elle cherche à obtenir.

C’est à ce moment là que le manager « au service de l’équipe » devrait faire son apparition. Être au soutient de l’équipe et l’éducateur de la direction.

Il doit être en mesure de répondre clairement aux interrogations des uns et des autres et d’expliquer à chacun les besoins de l’autre comme par exemple :

  • Pourquoi la direction veut-elle une réestimation maintenant? Y a-t-il un besoin concret qui échappe à l’équipe comme par exemple une communication stratégique ou bien est-ce simplement une crainte, une insécurité générée par les nouvelles façons de faire, le nouveau reporting?
  • Peut-on patienter encore quelques semaines? Admettons que les estimés préliminaires sont faux. Normal, ce sont des estimés! Ceux d’aujourd’hui, réalisés avec des connaissances encore incomplètes sur des risques identifiés, ne seront-ils  pas aussi faux? Seront-ils plus pertinent s’ils sont établits dans 4 semaines une fois les risques levés?
  • Pourquoi l’équipe ne souhaite-t-elle pas réestimer maintenant? A-t-elle peur? Refuse-t-elle de communiquer, d’être transparent vis-à-vis de la direction? Pense-t-elle que l’investissement à ce moment donné n’est pas rentable? Manque-t-il des informations nécessaires?

Les arguments de tous seront valables. Alors que doit faire le manager? Rester au milieu et prendre les balles? Ne satisfaire personne? Ou bien se positionner et prendre le risque de décevoir sa direction ou son équipe?

Pour ma part, je pense que le calcul à faire est celui du succès de l’équipe. Est-ce qu’une journée d’estimation rapporte plus qu’une journée à coder pendant laquelle on apprend sur les risques techniques que l’on doit affronter? À certains moments peut-être, à d’autres non. Ce qui est certain c’est qu’une équipe frustrée qui ne se sent pas soutenue, est moins productive et performante.

Faire le calcul de répondre à la demande de la direction sans tenir compte de l’équipe est peut-être bon pour la carrière, mais n’est pas le meilleur moyen d’aboutir à une équipe auto-organisée, performante, motivée et responsable. Il est plus pertinent d’éduquer la direction, de la rassurer, de lui expliquer que l’équipe ne juge pas pertinent de réévaluer maintenant mais qu’elle le fera dès que possible et qu’il faut lui faire confiance. Il est aussi judicieux d’expliquer qu’en Scrum cette (ré)estimation est permanente et fait partie du cadre.

Vous serez peut-être intéressés par ce précédent billet :

Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

June 3rd, 2010 6 comments

À maintes reprises ces derniers mois, j’ai dû répondre à la question qui tracasse beaucoup d’équipes et de Product Owner (PO) lorsqu’ils viennet d’échouer une ou plusieurs stories :

Faut-il réestimer les stories refusées lorsqu’on les prend dans l’engagement du sprint suivant?

Je demande alors ce qui fait sens pour eux. Quelle information tirent-ils de l’estimation d’une storie? Qu’est-ce qui serait le plus pertinent pour réussir le prochain sprint puisque le dernier vient d’échouer?

Les réponses varient bien évidemment, mais le plus important est alors de déclencher avec l’équipe une conversation autour de la notion de vélocité1, de son utilité, de son utilisation. Cette discussion ne fait pas l’objet du billet d’aujourd’hui mais j’y reviendrai éventuellement (au sens québécois du terme icon wink Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint? ) dans un prochain billet.

burndown infrastructure 300x225 Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

L'allure générale du burndown va varier en fonction de votre façon de gérer les stories échouées à la fin d'un sprint

Aujourd’hui je souhaite principalement partager ma pratique actuelle. Je dis actuelle car ma réflexion et ma préconisation ont évolué au cours du temps.

Actuellement, au moment de la planification d’un sprint, je préconise à l’équipe de réestimer les stories et de mettre à jour le backlog pour refléter l’effort nouvellement évalué. Cette façon de faire à les effets  suivants :

  • lisser la vélocité,
  • réduire le volume global du backlog, (sur l’instant bien entendu car j’exclus ici la création de story ou la réévaluation de story précédemment estimées, etc),
  • perdre l’historique de l’effort initialement estimé pour la story.

Dans le passé, je ne réestimais pas les stories au moment du sprint, l’équipe évaluait ou plutôt devrais-je dire pariait, comme pour un premier sprint, sur le ‘volume’ des stories qu’elle pensait être capable de réaliser. Cette façon de faire avait les effets suivants :

  • générer des fluctuations parfois importantes de la vélocité, pour finalement calculer une moyenne sur le long terme,
  • rendre l’engagement très aléatoire, l’équipe n’avait pas de repère (vélocité précédente) et pariait sur un engagement, comme lors d’un tout premier sprint,
  • conserver le volume du backlog tel qu’initialement estimé (sans faire entrer ici d’autres considérations telles que la réestimation des stories déjà estimées au cours des planifications de release précédentes, la division d’une story en plusieurs, la création de stories,…),
  • maintenir l’historique de l’effort estimé pour la story.

J’ai aussi vu une troisième méthode qui consistait à réestimer ‘oralement’ le reste-à-faire (en story points), mais sans mettre à jour le backlog. Cela permettait de prendre un engagement raisonnable car il incluait le nouvel effort estimé, mais l’engagement affiché était lui très généreux, reprenant l’effort estimé au sprint passé et non mis à jour!

Comme je vous le disais plus tôt la discussion autour de la notion de vélocité était intéressante. Pourquoi réestimer sans mettre le backlog à jour? Mystère! Un bon sujet pour un prochain billet. icon wink Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

Afin de partager vos pratiques, je vous propose de répondre au sondage suivant. Et surtout n’hésitez pas à partager votre expérience en laissant un commentaire.

Comment gérez-vous les stories refusées par le PO lors de planification du sprint suivant?

  • Je réestime et réajuste le pointage au backlog et je m'engage par rapport à ma vélocité connue (57%, 27 Votes)
  • Je ne réestime pas les stories et je 'parie' sur l'engagement (15%, 7 Votes)
  • Je réestime "oralement" pour maîtriser l'engagement mais je garde le pointage inchangé au backlog (13%, 6 Votes)
  • J'utilise une autre méthode (15%, 4 Votes)

Total Voters: 47

loading Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint? Loading ...
  1. La vélocité d’une équipe est le nombre story points du backlog brûlés pendant un sprint