Agile

January 23rd, 2010 Leave a comment Go to comments

Quelques articles des dernières semaines sur SavoirAgile.com

AgileGardener : February 28, 2015 12:33 pm : Agile

Dans les dernières semaines, j’ai écrit quelques billets publiés sur le site de contenu d’expertise Agile savoiragile.com

Deux billets à propos de la vélocité en Scrum :

Un billet à propos d’Immunity to Change (bientôt suivi d’un second)

Leave a response »

L’entreprise polarisée – Structurée ∞ Libérée

AgileGardener : February 27, 2015 5:10 pm : Agile, Entreprise Libérée, Organisation

La notion d’entreprise libérée a le vent en poupe. Il y a 3 jours, le film « Le bonheur au travail » sur Arte en faisait la présentation et l’éloge. Plus d’engagement des salariés, plus d’innovation, plus de bonheur au travail.

Aujourd’hui, rapidement sur un coin de table, j’ai réalisé une cartographie de la polarité « Entreprise Structurée » ∞ « Entreprise Libérée ».

L'entreprise polarisée - structurée vs libérée

J’ai la chance d’évoluer depuis 6 ans dans une entreprise qui a poussé loin l’expérimentation de la liberté, au point de toucher un point de rupture. Heureusement nous avons passé le cap, survécu.

En réaction, lors du passage de ce cap, la restructuration, violente et douloureuse, nous a conduits de l’autre côté du spectre. Beaucoup de structure, de contrôle, de standardisation, etc. Et j’ai aussi participé à cette partie de l’aventure.

Aujourd’hui fort de cette expérience et d’un profond et intense travail personnel et collectif, nous naviguons avec plus de fluidité entre les 2 opposés, dans une autoorganisation structurée, dans une forme de liberté encadrée.

Mon apprentissage, dans cette aventure de libération de l’entreprise, comme lors des transitions Agile que j’accompagne dans les organisations, est qu’il est absolument primordial de développer la capacité à naviguer avec souplesse et conscience entre les 2 pôles, de danser dans la polarité.

La solution aux excès liés à un pôle n’est pas l’autre pôle.

Bien souvent, en réaction à trop de hiérarchie et de contrôle, on passe à l’opposé, une libération complète. Dans le cas de l’agilité, on passe à une agilité débridée dans laquelle, sous prétexte que l’équipe doit s’autoorganiser, on « élimine » la hiérarchie.

À tous ceux qui veulent se lancer dans l’entreprise libérée en réaction aux effets négatifs liés à trop de structure, je vous invite à explorer les racines de cette volonté, votre intention. Quelles sont vos zones d’ombre ? Quelles parties de votre personnalité n’assumez-vous pas ? Quelles sont les caractéristiques des éléments qui provoquent vos réactions épidermiques à la hiérarchie ?

Personnellement, il m’a fallu du temps pour me rendre compte des éléments qui me faisaient réagir. Ma peur d’être perçu comme un leader contrôlant ou comme une personne de pouvoir et de domination a longtemps provoqué, et elle provoque encore de nombreux comportements qui ne servent pas mon équipe ou l’organisation.

Depuis de nombreux mois, je travaille à intégrer ces parties de moi que j’ai rejetées pendant des années. Ces parties de moi qui aiment dominer, contrôler, se mettre en colère, écraser. Ce travail me permet de gagner en souplesse et de choisir consciemment, plutôt qu’en réaction. D’utiliser les forces de la structuration et du contrôle tout autant que celles de la libération et de la liberté.

Ce qui peut être vu comme paradoxal ne l’est plus tout à fait lorsque l’on développe cette conscience de soi et cette flexibilité à naviguer au sein d’une polarité.

J’ai envie d’inviter toutes les personnes qui se lancent dans des démarches de libération ou d’agilisation à prendre conscience de leur intention profonde. Au service de qui, au service de quoi agissez-vous ?

Je crois que cette réflexion nous permet de faire preuve d’une plus grande compassion pour les personnes qui vont vivre les changements profonds liés à une transformation de ce type.

Je crois aussi que cette réflexion nous aide à sortir du dogmatisme ou de la rigueur que l’on rencontre parfois dans la communauté Agile.

Je suis pour une entreprise libérée au sein de laquelle chacun est vu comme un être humain et non comme un rouage de la machine, mais cela ne veut pas dire que je suis contre la structure.

 

4 Comments »

Actu

AgileGardener : September 12, 2011 8:23 pm : Agile

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

Choisir l'agilité - le livre de Mathieu Boisvert et Sylvie Trudel


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 ;-). (Le livre est disponible sur amazon.fr et le site de l’éditeur pour l’instant) 

2 Comments »

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

AgileGardener : May 31, 2011 4:05 pm : Agile, Coaching, Rendez-vous

 

Bonjour,

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

Je participerai à la formation Coaching Agile Teams

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.

Leave a response »

Agile Coach Camp Canada – Here we go!

AgileGardener : June 10, 2010 9:14 pm : Agile, Canada, Coaching

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.

Leave a response »

Le gestionnaire agile dans les lignes de tir

AgileGardener : June 10, 2010 12:05 am : Agile

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 :

17 Comments »

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

AgileGardener : June 3, 2010 12:05 am : Agile

À 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.

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 (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 (9%, 4 Votes)

Total Voters: 47

Loading ... Loading ...

13 Comments »

ScrumMaster, chut! Écoute!

AgileGardener : May 20, 2010 12:05 am : Agile, Coaching

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!

9 Comments »

Hope to meet you at Agile Coach Camp Canada

AgileGardener : May 17, 2010 12:05 am : Agile, Canada, Coaching

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.

3 Comments »

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

AgileGardener : May 13, 2010 12:05 am : Agile, Coaching, Organisation

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.

Apprentissage de l'autonomie. Permettre à l'équipe d'organiser 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 ;-) et il est certain que rapidement l’ambiance va changer.

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

13 Comments »
« Page 1, 2, 3, 4 »