Archive

Archive for May, 2010

La permission ou le pardon : faites votre choix!

May 27th, 2010 1 comment

Ni l’un ni l’autre. Je choisis la confiance qui permet le conflit qui engendre l’engagement qui soutient l’imputabilité qui mène à se concentrer sur les résultats!

Il y a quelques semaines, j’évoquais avec Éric Laramée le fait que quelques fois, lorsqu’une chose doit être réalisée, il vaut mieux le faire sans attendre la permission puis demander pardon par la suite. J’avoue avoir succombé à cette facilité par le passé.

À la suite de cette conversation, Éric m’a dirigé vers cet article récent de Ben Snyder : “Don’t Ask For Permission When Forgiveness is Easier” dont je vous recommande la lecture.
41ym2vZ0X1L. BO2,204,203,200 PIsitb sticker arrow click,TopRight,35, 76 AA300 SH20 OU15  La permission ou le pardon : faites votre choix!
Je n’ai pas pu m’empêcher de faire le parallèle avec la (re)lecture récente du livre de Patrick Lencioni : “The Five Dysfunctions of a Team: A Leadership Fable“.

Dans un groupe, lorsqu’une personne agit à l’encontre des autres, même s’il demande pardon par la suite, cela laisse des traces. C’est d’autant plus vrai que l’action est faite avec une intention cachée, une intention de nuire ou bien à des fins personnelles sans égards au groupe.

La prochaine fois que vous entendrez l’expression bien connue “il vaut mieux demander pardon que demander la permission”, prenez quelques minutes pour comprendre le contexte, et pour déterminer à qui profite l’action qui a été entreprise.

Cette expression révèle souvent les dysfonctionnements fondamentaux évoqués dans le livre ci-contre. Une telle action ne pouvant venir d’un membre d’une équipe telle que décrite par Patrick Lencioni, une équipe dont les membres placent la réussite du groupe avant la satisfaction personnelle.

Finalement ce que ça m’inspire c’est : “Encore de belles conversations à venir”, beaucoup d’efforts à faire sur le plan personnel et de beaux jours pour continuer à faire un métier qui me passionne.

Et vous, êtes-vous inpiré?

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
agilecoach2010 300x88 Hope to meet you at Agile Coach Camp Canada

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.

Permettre à l’équipe d’organiser son espace de travail

May 13th, 2010 5 comments

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.

autonomie espace travail equipe agile 244x300 Permettre à léquipe dorganiser son espace de travail

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 icon wink Permettre à léquipe dorganiser son espace de travail et il est certain que rapidement l’ambiance va changer.

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

Un coach agile doit-il exposer ou préserver l’équipe?

May 6th, 2010 7 comments
preserve 300x247 Un coach agile doit il exposer ou préserver léquipe?

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?