Agile Gardener

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 ;-)

Follow #accca on Twitter

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

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 (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?. N’hésitez pas à voter, votre avis m’intéresse ;-)

À 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. La vélocité d'une équipe est le nombre story points du backlog brûlés pendant un sprint], 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.

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.

 Loading ...

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!

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

Follow #accca on Twitter

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

Selon vous, qui est le mieux placé pour savoir comment l’équipe doit organiser son espace de travail?

Lorsque les membres d’une équipe prennent l’initiative de disposer et d’aménager eux-même leur espace de travail, vous courrez la chance que celui-ci soit le mieux adapté à leur besoin du moment.

Par exemple deux personnes ont besoin de travailler en paire ou bien quatre autres travaillent sur un module commun.

De même, vous passez un message fort à l’équipe qui grâce à de petits apprentissages, commence à devenir autonome, auto-organisée, car dans bien des situations, pendant longtemps les gens ont été placés par les gesionnaires qui leur attribuaient un bureau, parfois même avec quelques privilèges liés à l’ancienneté.

Bien sûr, attendez vous à ce que l’aménagement change plusieurs fois au début, le temps que chacun trouve sa place.

En tant que gestionnaire, vous pouvez aussi le voir comme un apprentissage à laisser aller votre équipe, à la laisser prendre le contrôle d’elle même, à lui faire confiance. Votre rôle de gestionnaire d’une équipe agile n’est pas de micro-gérer votre équipe, mais bien au contraire, d’être à son service pour qu’elle s’émancipe, quelle devienne pleinement responsable de son travail et de outils nécessaire à sa réalisation.

L'apprentissage de l'auto-organisation passe par la prise en charge de son espace de travail (photo par stahlmandesign's : http://www.flickr.com/photos/stahlmandesign/)

Pourquoi est-ce une bonne idée de laisser l’équipe s’organiser?

Les analogies valent ce qu’elles valent, mais j’aime bien faire le parallèle avec mes enfants. Je ne laisserai pas mon fils de 3 ans traverser seul l’avenue en face de la maison à l’heure de sortie du bureau, ni même d’ailleurs à n’importe quel autre moment. Par contre, je le laisse mettre le couvert avant le repas ou bien casser des œufs pour  faire un gâteau.

Bien évidement, il y a parfois de la casse et il nous arrive de manger des coquilles, mais ce n’est pas grave, il a appris. Je compare le fait de laisser l’équipe s’organiser au fait de mettre la table ou de casser les oeufs. Si l’équipe se trompe un peu, ce n’est tout simplement pas grave!

En tant que gestionnaire, vous devez plutôt essayer d’aider l’équipe et travailler à lui fournir un espace suffisant et le plus adapté possible. Certes, il est rare que les espaces soient adaptés dès le jour 1, mais c’est un paramètre important à prendre en compte si vous souhaitez améliorer les performances de vos équipes.

Utilisez votre temps de micro-gestion pour trouver des solutions afin de bénéficier de plus d’espace, pour trouver des espaces contigus plutôt que dispersés, pour comprendre pourquoi déplacer un prise réseau coûte 150$ et faire en sorte que cela change, pour que le matériel soit adapté et mobile. Je vous assure, l’équipe appréciera de vous voir vous démener pour elle.

Je dois bien avoué que parfois il y a des contraintes importantes. Comment faire lorsqu’il est interdit à un employé de déplacer un bureau pour des raisons de sécurité? Comment faire quand le matériel adapté, c’est-à-dire facilement mobile, ne répond pas aux contraintes ergonomiques? etc.

Je n’ai pas de réponse autre que : si l’équipe est d’accord pour rester de 5 à 6 le soir pour déplacer son mobilier, ne dites rien à personne et faites le! Les pizzas ne vous coûteront pas très cher et cela peut-être un bon moment à partager ensemble. Si l’équipe l’équipe accepte de travailler avec du mobilier ne répondant pas complètement aux normes d’ergonomie, ne dites rien à personne, commandez du mobilier adapté. Cela m’étonnerai que les membres de l’équipe viennent se plaindre par la suite. Et le coût dans tout cela? Et bien un bureau de type « table à roulette » simple coûte souvent bien moins cher que du mobilier de bureau plus traditionnel et surtout il est réutilisable pour aménager des salles de réunions par la suite.

Ce que j’ai dis jusqu’ici existe. À Pyxis par exemple, le président n’a pas de bureau fermé et luxueux. Il dispose d’un bureau à roulette et de la même chaise rouge que tout le monde et il travaille au milieu des 50 autres employés du bureau. Pour ma part, j’ai du changer de place une bonne dizaine de fois en un an et demi. Il m’arrive même d’être déménagé « à l’insu de mon plein gré » pour le bien d’un projet ou pour regrouper des personnes qui ont un intérêt à travailler ensemble pendant une période donnée. Le mobilier est adapté, les pièces sont équipées de prises réseaux et de wifi, nous disposons d’ordinateurs portables et nous avons un cassier dans l’espace commun pour déposer nos objets personnels. Tout n’est pas idéal, mais pour le travail en équipe c’est très facile et quand on est au bureau c’est quand même ça qui compte finalement.

Certes notre espace et notre mobilier sont adaptés, mais surtout il n’y a pas de notion de territoire, de représentation du statut par le mobilier, pas de « que va dire le département voisin si je vous laisse faire ce que vous voulez » et pas d’illusion de contrôle par une hiérarchie qui placerait les employés!

Permettez à vos équipe de se déplacer à leur gré, vous compenserez très rapidement les coûts grâce à une équipe plus solidaire et plus performante plus rapidement. Cela vous fera peut-être économiser quelques journées d’un accompagnateur agile ;-) et il est certain que rapidement l’ambiance va changer.

Et vous, quelles sont vos conditions de travail? Comment se comporte votre hiérarchie?

Laisser l'équipe faire des erreurs pour apprendre (photo par http://www.flickr.com/photos/sayonara/)

Je ne vous apprendrai rien en vous disant que j’accompagne des équipes lors de leur transition agile!

En tant qu’accompagnateur agile, je veille à être à l’écoute des membres du groupe pour les aider à trouver leur propre chemin vers leur succès. J’ai toujours en tête l’idée de n’être qu’une béquille temporaire, avec l’objectif, comme toute béquille, de permettre à l’équipe de progresser seule lorsque je quitte le mandat.

Cependant, lors d’une transition agile, l’équipe doit faire fasse aux difficultés du changement et comme beaucoup de personnes doit faire ses expériences pour comprendre certaines modifications de comportement que l’on essaie de mettre en oeuvre.

Ma posture est habituellement d’expliquer à l’équipe les valeurs du manifeste agile, et selon l’approche choisie, souvent Scrum, les principes et quelques règles qui guident cette approche.

Cependant, après avoir expliqué ceci à l’équipe, je l’assiste pour qu’elle trouve ses propres solutions aux problèmes auxquels elle doit faire face. Il arrive que je propose des alternatives, mais en bout de ligne, j’impose peux de choses, uniquement quelques règles de base, en expliquant aux participants qu’ils pourront les remettre en cause lorsqu’ils comprendront les implications de celles-ci.

Il arrive donc souvent que l’équipe fasse des choix qui peuvent la conduire dans une impasse, voir « dans le mur ». Lorsque je perçois cette impasse, j’en avise l’équipe, mais je la laisse suivre son chemin si elle ne souhaite pas m’écouter. Cependant, je travaille à réduire la taille du mur car je pense qu’une équipe en apprentissage, hors de sa zone de confort est plus fragile.

Finalement, en tant qu’accompagnateur agile, et comme l’équipe à besoin de faire ses propres expériences, mon but est de conduire rapidement l’équipe face au mur, tout en minimisant la taille de celui-ci et dans le même temps, de préparer le futur.

Pour illustrer la démarche, je dirai qu’après avoir prévenu l’équipe qu’il est bon de se préparer (rapidement) pour une revue d’itération ou bien qu’il est important de travailler sur les user stories dans l’ordre établi par le propriétaire de produit, je n’insiste pas et je n’oblige pas l’équipe à le faire.

Pour une équipe qui débute dans une approche agile, les exemples ci-dessus sont des pièges fréquents. Mais en laissant l’équipe expérimenter ces problèmes très tôt en ne l’en protégeant pas, je peux aborder avec elle des discussions intéressantes qui lui permettent de comprendre le nouveau comportement attendu et qui mènent souvent à des nouvelles solutions encore (et toujours) prises par l’équipe. Ces pièges restent plutôt de l’ordre de la marche que du mur.

Cependant je me demande souvent si c’est la bonne approche, si je devrais être plus directif?

Qu’en pensez-vous? Quelle est votre approche?

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

Choisir la longueur des itérations en Scrum est une décision délicate qui a son importance pour le bon fonctionnement de l’équipe et du projet. Il faut trouver le bon compromis entre un rythme soutenable pour l’équipe et la souplesse de pilotage des priorités par le propriétaire de produit.

Si la littérature originale de Scrum[1. Agile Software Development with Scrum] préconise des itérations d’une durée de un mois, la réalité est souvent différente. Depuis la publication du livre Agile Software Development with Scrum, les choses ont évolué et, dans la pratique, j’ai vu des équipes choisir des longueurs d’itérations allant de deux à six semaines, dans ce dernier cas peut-on encore parler de Scrum me direz-vous avec raison!

À chaque fois le choix est difficile, il demande un compromis entre la fréquence des points de visibilité[2. Un point de visibilité est la séquence des rencontres suivantes de Scrum : revue d'itération suivie de la planification d'itération. En effet, c'est le moment d'observer l'avancement de l'équipe et de réajuster les priorités en fonction des objectifs du projet.] offerte au propriétaire de produit (et aux parties prenantes du projet) et la capacité de l’équipe à livrer des incréments du logiciel en qualité production de façon récurrente. Ce choix peut aussi mettre en jeu bien d’autres facteurs, comme par exemple la capacité du propriétaire de produit ou des membres de l’organisation à suivre et ajuster l’horaire de plusieurs équipes.

Le choix de la longueur des itérations s’effectue souvent lors des rencontres de démarrage du projet, pendant la période de trois à cinq jours qui permet de bâtir l’équipe, de planifier et de lancer la première itération. De mon expérience, ce choix est souvent fait selon le schéma suivant :

• Le propriétaire de produit propose la date de première livraison.
• Le propriétaire de produit choisi un nombre de points de visibilité au cours de cette durée en fonction des différentes longueurs d’itérations possibles.
• L’équipe et le propriétaire de produit négocie la durée la plus adaptée.

Par exemple, pour une livraison dans trois mois nous obtenons le tableau suivant :

On se rend compte alors de l’importance de bien choisir la longueur des itérations pour un pilotage optimum du projet du point de vue du propriétaire de produit.

Cependant, la capacité de l’équipe à livrer des incréments du logiciel de qualité production doit être prise en compte. Et bien que livrer souvent puisse être difficile pour  les équipes, elles doivent aussi se rendre compte que c’est un avantage pour elles d’avoir l’occasion de s’ajuster en profitant des rétrospectives[3. voir les billets suivants au sujet des rétrospectives :

• Construire des règles d'équipe
• Ne plus l'accepter!
• Action = porteur + date
• Animer une rétrospective d'équipe est une belle opportunité d'intégration], de négocier des engagements plus clairs et plus circonscrits avec le propriétaire de produit, de permettre l’entrée ou la sortie de personnes dans l’équipe, etc.

Pour ma part, mon choix va à des itérations de 2 semaines. Elles sont parfois difficiles à accepter pour des équipes débutantes en Scrum, mais je pense que c’est une durée intéressante pour ces équipes notamment. Cela leur permet de s’ajuster fréquemment, de comprendre ce qu’elles sont capables de livrer en peu de temps, de comprendre l’importance, par exemple, d’automatiser les tests ou bien le processus de déploiement. Cela permet aussi de créer une dynamique de construction d’équipe intéressante par le biais des rétrospectives qui reviennent vites et qui permettent ainsi de ne pas laisser ‘pourrir’ des problèmes tant que l’équipe n’est pas encore assez mature pour les traiter au fil de l’eau.

Et vous, vos itérations s’étalent-elles sur 1, 2, 3, 4 semaines? Plus encore?

Je suis curieux de connaître vos choix en matière de longueur d’itération ainsi que la logique qui y conduit, alors n’hésitez pas à laisser des commentaires :-).

Lors d’une rétrospective, que j’ai animé à la demande d’une équipe[1. Il est intéressant pour une équipe que sa rétrospective soit animée, à l'occasion, par une autre personne que le ScrumMaster. Cela peut être un membre de l'équipe, le ScrumMaster d'une autre équipe ou bien une personne extérieure, un accompagnateur agile, ce qui était mon cas. Au delà de changer la dynamique, cela permet au ScrumMaster de participer pleinement à la rétrospective.] 4 mois après l’avoir aidé à faire ses premiers pas en Scrum, j’ai proposé un atelier sur la gestion des attentes au sein de l’équipe.

Au cours des 4 mois j’ai entendu plusieurs fois des phrases telles que la suivante : « Certaines personnes parlent d’une façon que je trouve parfois déplacée. Je ne sais pas quoi faire avec ça. » Je demandais alors à la personne si elle avait parlé, aux membres de l’équipe, de cette attente concernant la façon de s’exprimer dans le groupe. Bien souvent la réponse était : « non! »

Cet exemple est loin d’être le seul, je le retrouve souvent en tant que coéquipier ou en tant qu’accompagnateur. Très souvent les membres d’un groupe souhaitent un comportement des autres membres sans jamais avoir exprimé l’attente de ce comportement. Habituellement chacun adopte le comportement qu’il pense être celui que le groupe attend ou bien celui que la personne à l’habitude d’avoir. On se rend compte que la responsabilité est partagée, on pourrait renversé la discussion et chacun pourrait demandé aux autres si tel ou tel comportement à un impact ‘négatif’ sur eux.

Le but de l’atelier était donc de permettre à chacun d’exprimer ses attentes. Je visais à les rendre explicites envers les autres membres du groupe et ultimement, j’espérais voir l’équipe se construire un espace d’attentes communes et parler des comportements respectifs dans différentes situations vécues ensemble.

La session de travail s’est très bien déroulée et au final, les attentes communes ont émergé. Elles sont mêmes devenues des règles d’équipes et des objectifs à atteindre en tant qu’équipe.

Satisfait du résultat de cet atelier, j’ai eu l’envie de le partager ;-). En voici donc le déroulement tel qu’expérimenté.

L’atelier

Le matériel : des Post-it ou des cartes, des stylos, des murs ou des tables

L’agenda en trois parties tel que je l’ai proposé :

1. Mes attents (25 min)
2. Nos attentes (30 min)
3. Une équipe ! (30 min)

Remarque : Nous avons utilisé 1h30 pour effectuer cet atelier, mais il aurait mérité plus de temps, notamment les parties 2 et 3 parce que les échanges étaient riches et certaines sujets demandent du temps pour être pleinement exprimés.

Mes attentes

Résultat final de l'atelier de gestion des attentes - les régles d'équipe

J’avais réservé 25 minutes pour la première partie.

Dans cette phase chacun pose sur papier ses attentes personnelles, une par Post-it ou carte.

En tant qu’animateur lorsque j’ai présenté l’exercice, j’ai essayé de donner quelques exemples de situations, quelques exemples de comportements que moi j’attends, mais qui ne sont pas la façon de faire ou de réagir de tous.

L’exercice s’arrête à la fin de la période de 25 minutes. Si tout le monde semble avoir terminé avant, assurez vous tout de même de laisser quelques minutes pour une dernière idée.

Nos attentes

L’objectif de cette deuxième phase est d’établir les attentes communes à un sous-groupe.

Pour cela, j’ai séparé le groupe en 2. (Remarque : au delà de 5 personnes par équipe il est sans doute judicieux de faire 3 équipes pour maximiser les échanges et la participation de tous.)

Pendant la période, les membres de chaque sous-groupe, après les avoir affichées au mur, présentent leurs attentes aux autres. Ensuite le groupe essaie de créer un espace d’attentes communes. Pour matérialiser cet espace commun, j’ai demandé aux groupes de placer les Post-it en commun au centre d’une zone délimitée par les Post-it de leur attentes personnelles.

Dans ce cas, le groupe n’a pas gardé les attentes personnelles autour des attentes collectives, je suis curieux de voir ce que cela donnerait au final

Comme je l’ai mentionné plus tôt, cette période aurait mérité un peu plus de temps, mais c’est surtout la période suivante qui demande de réserver plus de temps du fait de la taille du groupe.

Une équipe!

Résultat final de l'atelier de gestion des attentes - les objectifs d'équipe

L’objectif de cette dernière partie est d’établir les attentes collectives de tout le groupe en rassemblant les attentes communes de chaque sous-groupe.

Pour cela, j’ai réuni tout le groupe et j’ai demandé aux participants de présenter les attentes de son groupe. Ensuite j’ai demandé de refaire le même exercice que précédemment, établir un espace des attentes communes tout en préservant les attentes personnelles en périphérie.

Comme lors de la précédente partie, la mise en commun a été le moment de discussion et de négociations très intéressantes et ouvertes des membres de l’équipe. Comme lors de la précédente partie, l’équipe n’a pas conservé les Post-it d’attentes personnelles autour de la zone commune.

Une fois la zone collective établie, j’ai demandé à l’équipe de regrouper ces attentes dans les 2 groupes suivants : les « règles d’équipe », les « objectifs d’équipe »

Du fait du nombre de personne et de la teneur des discussions, il faudrait prévoir plus de temps pour cette partie. Je pense que 45 minutes est un minimum.

Le résultat final est illustré par les deux photos ci-contre.

Pour conclure

L’équipe a beaucoup apprécié cet atelier. Malheureusement nous avons manqué de temps et certains ont du quitté avant la fin. Je réserverai  2h pour la prochaine fois et voici l’agenda que je compte utiliser :

1. Mes attents (25 min)
2. Nos attentes (35 min)
3. Une équipe ! (45 min)

Je suis cependant très content d’avoir expérimenté cet atelier avec l’équipe et surtout je suis très content de la participation de l’équipe et de son engagement pendant tout l’exercice.

Je serai curieux de l’impact de garder visibles, autour des règles et des objectifs communs, les attentes personnelles de chacun.

J’envisage maintenant d’utiliser cet atelier lors de la ‘construction’ d’une équipe lors du warm-up d’un projet.

Si vous avez déjà mis en œuvre un tel atelier ou que vous essayé celui-ci, n’hésitez pas à partager vos retours d’expérience, je suis avide d’idées nouvelles ;-)

En quelques semaines, j’ai eu l’opportunité d’animer à plusieurs reprises un atelier d’estimation de l’ensemble d’un carnet de produit.

Le but de cet atelier, aussi appelé Wall Planning Poker®, est d’estimer de façon relative un grand nombre de User Stories en un temps limité[1. time-box].

Cet atelier est basé sur l’estimation en Planning Poker lors des séances de planification d’itération, cependant, l’équipe n’utilise pas les cartes de planning poker, elle réalise l’estimation en plaçant les User Stories au mur (ou sur une grande table) par rapport au nombre de points évalués. On insiste évidemment beaucoup le côté relatif de l’estimation. Le but de l’exeercice, je le rappelle, est d’obtenir une idée de l’ampleur du carnet de produit.

Certes, avec une estimation rapide l’équipe va faire des erreurs, et c’est normal! D’ailleurs, n’en fait-elle pas lors de l’estimation des User Stories pour une seule itération? Pour abaisser le risque d’erreur, l’équipe choisit des User Stories étalons qu’elle révise et publie chacun dans leur “case” respective au mur. De plus, par expérience, j’estime que les cartes surévaluées compensent globalement les cartes sous-évaluées.

Un élément important à la réussite de l’atelier est de passer à l’équipe le message clair que l’estimation n’est pas définitive. Lorsque les User Stories seront inclues dans une itération, elles seront réévaluées par en fonction des éléments d’information acquis à ce moment là. (Mesdames, Messieurs les propriétaires de produit, ce message est aussi pour vous!)

Une fois les étalons établis et les messages passés sur l’estimation relative et non définitive c’est le moment de s’y mettre.

Prévoyez au moins 2 heures pour l’atelier. Si l’équipe n’a jamais estimé auparavant, prévoyez de passer du temps pour établir les premières estimations et obtenir  ainsi vos étalons. Je vous conseille d’ailleurs, dans ce cas, de séparer l’évaluation “détaillée” d’une première itération de l’atelier proprement dit, l’équipe ayant l’opportunité de construire ainsi ses étalons.

Même s’il est préférable que tout le monde participe simultanément à l’estimation de toutes les User Stories, j’ai remarqué dans la pratique que la constitution d’équipes de 4 à 5 personnes est plus efficace. Pourquoi? Pour les deux raisons suivantes principalement :

• Les discussions dans un groupe 4 ou 5 personnes sont plus riches et surtout moins longues.
• La division permet de faire une revue de l’estimation de chacun des groupes par un autre groupe.

Comment se déroule l’atelier?

1. Constituez des équipes de 4 ou 5 personnes multidisciplinaires et multicompétences. Insistez sur le fait de bien répartir les connaissances et compétences dans les équipes.
2. Distribuez à chacune des équipes des cartes sur lesquelles vous avez imprimé les User Stories du carnet de produit. Essayez dans la mesure du possible de séparer les cartes en conservant groupés les Épics ou les processus. Cela facilite souvent l’estimation du fait de bénéficier de la vue globale de la fonctionnalité. Pensez à vous assurez que si la boîte de temps achève, les User Stories les plus prioritaires auront été estimées.
3. Chaque équipe bénéficie du temps préalablement déterminé (prévoir 1h à 1,5h) pour classer les cartes au mur. Dans le cas de plusieurs équipes réalisant l’exercice simultanément, avoir trop de monde près du mur peut être gênant. Dans ce cas proposez aux équipes d’utiliser une table avant de reporter leurs cartes au mur.
4. Une variante de l’exercice consiste à ne pas affecter de points aux cartes tout de suite. Il est intéressant de classer les cartes par rapport à l’effort relatif pour réaliser la fonctionnalité, puis, une fois toutes les cartes évaluées réaliser le pointage au mur.
5. Une fois toutes les User Stories estimées au mur, demandez à chaque équipe de revoir les cartes pointées par les autres équipes (donner comme consigne, au début de l’atelier, à chaque équipe d’identifier les cartes qu’elle évalue par un signe distinctif). Chacune des équipes restant bien entendu à la disposition des autres pour expliquer un choix. S’il s’avère nécessaire, après discussion, de déplacer des User Stories, faites-le! L’avantage de cette pratique au delà de permettre un croisement des estimations, est de générer des discussions avec tous les participants et de vérifier que chaque équipe est restée proche des estimées étalons. Prévoyez 30 min à 45 min pour cette partie de l’atelier.
6. Pour conclure l’atelier, comme pour tout atelier ou pour toute réunion importante, prévoyez 15 minutes pour une petite rétrospective.

Le résultat de cet atelier est spectaculaire. Il donne à l’équipe une vue globale du carnet de produit et permet au propriétaire de produit de planifier les futures livraisons, de construire un roadmap. Il permet aussi d’évaluer la faisabilité du projet par rapport aux dates envisagées et de prendre des décisions éclairées sur la stratégie à mener pour réussir vos projets. Cela est d’autant plus vrai et plus pertinent que vous connaissez la vélocité de votre équipe.

Si vous avez des expériences à partager concernant cet ateliers ou des ateliers similaires, laissez-moi un commentaire ;-)! Si vous avez des questions écrivez-moi (tbalbous à pyxis-tech point com)

Si vous avez besoin d’aide, je serai ravi de venir animer cet atelier dans votre équipe. Contactez moi! ;-)