Archive

Posts Tagged ‘Scrum’

Agile Coach Camp Canada – Here we go!

June 10th, 2010 Comments off
Agile Coach Camp Canada - June 11, 12 2010 - IT'S FREE and it really worth time inversted.

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 ūüėČ

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 6 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

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 ūüėČ ) dans un prochain billet.

Burndown en story point - Faut-il réestimer les stories non terminées ou refusées à 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. ūüėČ

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 (61%, 27 Votes)
  • Je ne r√©estime pas les stories et je 'parie' sur l'engagement (16%, 7 Votes)
  • Je r√©estime "oralement" pour ma√ģtriser l'engagement mais je garde le pointage inchang√© au backlog (14%, 6 Votes)
  • J'utilise une autre m√©thode (9%, 4 Votes)

Total Voters: 47

Loading ... Loading ...
  1. La v√©locit√© d’une √©quipe est le nombre story points du backlog br√Ľl√©s pendant un sprint

ScrumMaster, chut! √Čcoute!

May 20th, 2010 6 comments

S’il est vrai que le ScumMaster doit savoir se faire entendre, parfois fort, pour prot√©ger son √©quipe, il doit aussi apprendre √† se taire et surtout √† √©couter.

Dans beaucoup d’√©quipes ou d’organisations, les personnes se parlent mais ne s’√©coutent pas. Chacun essayant de faire entendre sa voix, de passer son point, de montrer qu’il est l√†.

En tant que ScrumMaster, lorsque l’√©quipe d√©bute, on a tendance √† √™tre sur le devant de la sc√®ne, √† parler pour expliquer Scrum, pour animer les meetings, pour guider l’√©quipe lors des c√©r√©monies, pour suivre ce qui se passe lors des m√™l√©es quotidiennes. Bref, √† √™tre plus pr√©sent et plus directif.

Cependant, pass√© les premi√®res it√©rations, l’√©quipe doit en savoir suffisamment sur la m√©canique pour avoir adopt√© certains r√©flexes. √Ä ce moment l√†, vous devriez √™tre en mesure de vous retirer symboliquement pour laisser l’√©quipe s’organiser.

Ce retrait symbolique ¬†est pour moi le moment de passer du bruit au silence, de la parole √† l’√©coute, de pr√©f√©rer les questions aux directives.

Tout le monde vous le dira, je suis quelqu’un qui aime parler, j’aime aider l’√©quipe, expliquer, transmettre mes id√©es, mes valeurs, mes connaissances. J’ai cependant remarqu√© quelque chose de tr√®s important. Attention c’est un scoop… Le silence est d’or!

Lorsque je participe au daily de l’√©quipe, comme ScrumMaster, j’aime me mettre dans un coin, en retrait, et √©couter. En fait, je ne dors pas, je m’assure qu’on ne d√©passe pas le temps, je peux intervenir quelques fois s’il y a des questions, et, je prends des notes sur des points pour lesquels je veux questionner l’√©quipe : une t√Ęche qui semble appara√ģtre mais qui n’est pas cr√©√©e, une t√Ęche bloqu√©e, un comportement que je remarque. Mais bien entendu, je continue √† participer √† la synchronisation avec l’√©quipe et √† transmettre les informations n√©cessaire.

Parfois j’utilise ces notes √† la fin du daily, lorsque tout le monde a parl√©, pour poser des questions, faire prendre conscience de faits, de comportements. Certaines fois je retiens mes notes quelques jours pour prendre le temps de v√©rifier que mes observations se reproduisent, pour laisser l’√©quipe exp√©rimenter la difficult√© li√©e √† son comportement, etc. Bien √©videmment, tout est une question de dosage. Je ne laisse pas l’√©quipe s’emp√™trer dans des difficult√©s trop graves.

J’ai remarqu√© une chose, avec une √©quipe exp√©riment√©e, en usant de ce comportement silencieux suivi de questions pertinentes, sur une base r√©guli√®re, l’√©quipe attend la question, recherche le feed-back √† l’aide duquel elle apprend et elle adapte son comportement pour s’am√©liorer par petits pas.

Dans le cas d’une √©quipe d√©butante en Scrum il est n√©cessaire d’√™tre plus directif, mais dans le cas d’une √©quipe r√īd√©e (apr√®s quelques it√©rations), cela devient contre productif et ralenti le travail de l’√©quipe. En effet, l’√©quipe adopte une attitude dans laquelle elle attend qu’on la dirige, qu’on la corrige d√®s le moindre √©cart, elle ne prend donc pas le temps d’observer et de r√©fl√©chir √† son attitude. Elle n’a pas non plus l’opportunit√© de faire des faux pas ‘simples’ qui lui permettent d’apprendre lorsqu’ils sont remont√©s sous forme de feed-back.

En disant cela je n’invente rien, je partage simplement mon v√©cu, qui finalement illustre ce que nous transmet la litt√©rature.

Votre exp√©rience m’int√©resse. √ätes-vous un ScrumMaster loquace ou plut√īt silencieux et √† l’√©coute? Quel(s) changement(s) de comportement(s) de l’√©quipe observez-vous lorsque vous faites √©voluer votre comportement?

P.S.: Pour écouter, il faut accepter le silence. Un truc simple pour ne pas rompre le silence, compter dans votre tête ou bien encore garder un stylo dans la bouche sans le tenir avec la main, si vous ouvrez la bouche, il tombe!

Hope to meet you at Agile Coach Camp Canada

May 17th, 2010 3 comments
Agile Coach Camp Canada - June 11, 12 2010 - IT'S FREE and it really worth time inversted.

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

I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with many other great agile coaches

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!

Follow #accca on Twitter

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