Êtes-vous prêts à devenir des citoyens de Pyxis ?

C’est la question que j’ai envie de vous poser après avoir (ré)écouter le livre audio “The Right Use of Power” de Peter Block.

Dans la première partie (premier 30 minutes), Peter Block parle de passer d’une organisation basée sur le leadership à une organisation basée sur la citoyenneté.

Cela à des implications fortes notamment la responsabilité que cela amène à porter par chacun, Raphaël en parle dans son billet “Il faut qu’on s’organise“.

Cela implique pour moi les réflexions suivantes :

Participer à un projet inspirant est difficile, mais passionnant (Photo par Pierre Fauroux)

• j’essaie de collaborer au mieux avec les différentes communautés de Pyxis,
• j’ai comme préoccupation la visibilité et le développement de l’organisation, ainsi que le partage de nos expériences,
• je prends à cœur mon rôle de caddy pour aider et soutenir la croissance personnelle de mes collègues,
• je challenge les leaders de ma communauté et accepte de me faire challenger par eux pour la progression de tous,
• je prends des risques en faisant avancer des dossiers comme l’ouverture de la rémunération ainsi que l’auto-détermination de celle-ci,
• je fais l’effort d’avoir des conversations plutôt que de ventiler dans les corridors, même lorsque celles-ci sont difficiles,
• j’agis de façon responsable vis-à-vis des ressources et des résultats de l’entreprise,
• je recherche l’équité dans la répartition des revenus dégagés collectivement,
• je m’engage en tant que bénévole dans l’administration de la CTA, partenaire actionnaire à 30%,
• etc.

Cette réflexion entamée depuis longtemps (ce billet a été en très grande partie écrit en décembre 2009) m’a conduit à tenter une définition ‘sentimentale’ du terme « Salarié », en réponse à la requête de François faisant suite à son billet Entrepreneur, dans lequel il donnait la définition suivante, plus ‘sentimentale’ du terme « Entrepreneur » :

Personne qui décide de prendre sa vie professionnelle en main en mettant de l’avant un projet créateur de valeur, qui fait cela de manière à la fois passionnée et pragmatique et qui invite d’autres personnes qui se sentent interpellés par la mission de ce projet d’entreprise à y participer avec leurs propres passions.

À comparer à la version proposée dans le dictionnaire Antidote :

« Personne qui engage des capitaux et utilise une main-d’œuvre salariée en vue d’une production déterminée; chef d’entreprise.»

Dans le même dictionnaire, le terme « salarié » est défini comme suit :

« Personne liée à un employeur par un contrat de travail, prévoyant la rétribution par salaire du travail effectué. »

Auquel je propose l’évolution suivante :

Agent de changement qui répond à l’invitation d’un entrepreneur, qui fait sien le projet commun auquel il choisit librement de participer et qui y engage et motive ses coéquipiers.  Personne qui collabore activement à définir l’orientation, et qui s’investit dans la réussite, d’un projet d’entrepreneur. Individu citoyen d’une entreprise.

Et pour vous qu’est-ce qu’un salarié? Êtes-vous tenté de devenir citoyen d’une entreprise comme Pyxis?

Vous serez peut-être intéressés par ces précédents billets :

• Qu’attend-on de moi?
• Ça veut dire quoi être actionnaire à Pyxis?
• La permission ou le pardon : faites votre choix!
• De l’usage des règles dans l’organisation
• Leader non consentant

Lors d’une rétrospective, que j’ai animé à la demande d’une équipe¹ 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

« Ne plus l’accepter! »

Cette phrase je l’entends souvent lors des retrospectives de la part d’équipes confrontées à des problèmes tels que les suivants :

• Livrer une user story ou un élément de code à une autre équipe en court d’itération.
• Prendre une user story dans l’itération qui a une dépendance à une autre équipe.
• S’engager sur une alors que le design n’est pas fini.
• …

J’ai eu moi aussi ce réflexe à de nombreuses reprises dans des situations mettaient en danger notre itération et qui impactaient directement notre réussite. Cependant, sur la durée d’un projet, cette position n’est pas tenable, c’est une solution simpliste qui conduit à termes aux conséquence suivantes :

• Sclérose de l’équipe et du projet.
• Extinction de toute forme de collaboration.
• Problèmes de fond persistants

« Ne plus l’accepter! » est une phrase qui, comme « il faut que », doit provoquer un choc à vos oreille! Que vous soyez équipier, ScrumMaster, coach ou voisin de l’équipe qui décide de prendre cette posture en réponse à un problème, s’il vous plaît réagissez!

Ne plus l'accepter! Réagissez!

Effectivement, pourquoi accepter?

Parce que refuser, c’est refuser de voir la vérité en face. C’est nier que le problème à l’origine de vos difficultés va persister, votre équipe va se protéger de plus en plus, se retrancher derrière cette « décision » et mettre progressivement fin à toute forme de collaboration.

Alors que faire?

Peut-être tout simplement accepter le changement! D’ailleurs, n’est-ce pas pour accueillir le changement dans vos projets que vous avez adopté une approche agile pour gérer vos développements logiciels?

Accepter les contraintes de votre environnement! Chercher pourquoi cette contrainte vous fais si mal. Voici quelques pistes que vous pouvez explorer aux travers des questions suivantes :

• Le processus que j’utilise correspond-il à ma réalité?
• Mes outils supportent-ils mes besoins?
• Mon architecture logicielle est-elle en harmonie avec mes capacités d’organisation et les compétences de mon équipe?
• L’organisation de mon équipes est-elle suffisamment flexible pour répondre aux besoins?
• Mes équipes collaborent-elles suffisamment? Sont-elles capables de se remettre en question?

Le changement, les contraintes, font partis de la vie et nous devons faire avec, mais cela ne devrait pas nous empêcher de  chercher à découvrir la source du problème. Cette activité, dans la majorité de cas, ne prend pas bien longtemps. Prenez ensuite une action, celle avec un porteur et une occasion identifiée dans le temps . Cette seconde activité, elle prend parfois plus de temps car elle nécessite souvent de changer des comportements ou d’acquérir de nouvelles compétences. Alors soyez patients et persévérants.

Vous venez de vous engager sur l’autoroute de l’amélioration continue!

Pour qu’une action se réalise, il faut un porteur et une occasion identifiée dans le temps.

Pour qu'une action se réalise, il faut un porteur de l'action et une occasion identifiée dans le temps.

Dans le tableau Kanban, lorsqu’une carte est bloquée, l’équipe à tendance à dire : « Cette carte est bloquée! Elle dépend de X, il faut que je le rappelle [...] mais il n’est pas très disponible. »

Lorsque j’entends ceci, je parie : « dans deux jours, la carte sera toujours bloquée au même endroit! ». D’ailleurs pourqoui changerait-elle de place? Il y a deux jours, la carte était là et j’avais déjà entendu la même excuse phrase, il n’y a donc pas de raison que cela change. Même cause, même effet!

Alors l’équipe me regarde avec de grands yeux et nous entamons un dialogue qui ressemble au suivant :

- moi : « Ok, qui va le faire et quand? ».

- équipe : « Il faut rappeler X, mais il n’est pas très disponible. ».

- moi : « Qui subit l’impact de la carte bloquée? ».

- équipe : « C’est nous! ».

- moi : « Qui a intérêt à ce que la carte soit débloquée? ».

- équipe : « C’est nous! ».

- moi : « Ok, qui va appeler et quand? ».

Certaine fois, je n’ai pas fini de poser la question qu’il y a un volontaire pour prendre la responsabilité de régler le problème dès la fin du daily. D’autre fois la réponse est : « Je n’ai pas le temps maintenant, je regarde mon horaire dès la fin de la rencontre et j’y place cette tâche ».

[Quelques semaines plus tard...]

L’équipe adresse chaque jour les points bloquants avec une action portée par une personne et identifiée dans le temps. Et les cartes bloquées se libèrent

Êtes-vous toujours attentifs aux : « Il faut que? »

Photo de mêlée attribuée à http://www.flickr.com/photos/cdm/

Il y a quelques semaines de cela, après plusieurs jours sans intervenir auprès de l’équipe, j’ai pu observer, lors de mon retour, une mêlée quotidienne¹ avec quelques dysfonctionnements.

Avertissement :

Ce que vous lirez n’est pas un jugement, ce que j’ai observé ne constitue pas à mes yeux des erreurs, mais démontre plutôt un apprentissage naissant de la mêlée quotidienne.

Contexte :

• L’équipe a terminé une première itération et s’apprêtait à commencer la deuxième.
• Finalement, elle stabilise pendant une semaine l’application pour une release annoncée très tard. Son passé l’a rattrapé et la date ne peut être manquée.
• De façon autonome, l’équipe a gardé les nouvelles pratiques mises en place dans la première itération et n’est pas retombée dans le mode “panique livraison” du passé.
• Je suis présent le jour de la mise en ligne et elle a lieu sans que l’équipe n’ai eu à faire de temps supplémentaire.

Symptômes observés :

• La ScrumMaster(SM) donne la parole à tour de rôle : “c’est à toi Louis”, Louis fait le tour de la table pour venir parler.
• Une personne fait du reporting face tableau ou tournée vers le ScrumMaster,  et des conversations parallèles ont lieu.
• Personne ne donne un statut sur le format des 3 questions²
• Le tableau de l’équipe n’est pas à jour. Le statut des toutes les tâches est mis à jour en direct, le tableau ne reflète l’état d’avancement qu’après l’intervention. Cela fait perdre du temps et provoque des cassures de rythme dans la prise de parole.
• Il y a par moment des personnes en retrait ce qui donne deux “épaisseurs” au groupe.
• La ScrumMaster demande plusieurs fois ce que l’on fait de certaines tâches au tableau avant d’obtenir une réponse.
• Un bureau gêne l’espace devant le tableau, personne ne le déplace.
• Une personne est occupée pour la mise en ligne, elle n’intervient pas du tout et ne donne pas de statut aux autres membres de l’équipe.
• Deux personnes sont assises.
• Finalement, la mêlée dépasse de 5 minutes le temps imparti.

Debrief et plan d’action :

À la suite de la mêlée quotidienne, je prends quelques minutes avec la ScrumMaster pour lui demander comment elle a perçu cette mêlée, comment elle se sent. Ce que je trouve formidable c’est qu’en quelques secondes elle m’a donnée la plupart des observations ci-dessus assorties de commentaires pertinents : “c’est comme s’ils n’avaient pas encore pris la mesure le l’utilité de mettre à jour le tableau” par exemple.

S’en est suivi un dialogue ressemblant à celui ci-dessous :

SM : “Mais comment je peux faire pour changer le comportement de l’équipe pendant la mêlée ?”

Moi : “Quel est le comportement qui te dérange le plus ?”

SM : “Je dois dire aux personnes de venir quand c’est leur tour”.

Moi : “Que pourrais-tu faire le plus simple pour changer cela”

SM : ” Tu m’as déjà dis de ne pas intervenir, de laisser l’équipe faire son daily”

Moi : “Oui effectivement, peut-être pourrais-tu rappeler à l’équipe ce que tu attends pendant le daily : qu’ils fassent un statut vers l’équipe, en répondant aux 3 questions puis les laisser continuer sans intervenir, en laissant des blancs, des silences s’il y en a. Je t’inviterai à le faire rapidement sans forcement attendre une rétrospective.”

SM : “C’est vrai, je pourrais faire ça, mais ils ne répondent pas aux 3 questions”

Moi : “Les connaissent-ils, peut-être ont-ils besoins que quelqu’un rappellele ces questions”

SM : “Pour qu’ils les voient les questions ont pourrait les afficher”

Moi : “C’est une très bonne idée ça, avoir les trois questions affichées ça permet de se les mettre en tête à chaque mêlée”

Et nous avons continué la conversation encore quelques minutes.

Finalement, le bureau qui gêne devant le tableau va être poussé un peu, les questions vont être affichées, la SM va répéter le comportement attendu lors du daily et laisser l’équipe aller. Les résultats dans un prochain billet

Dans vos organisations ou dans vos équipes, comment se passent vos mêlées quotidiennes, observez vous d’autres symptômes ?

Si vous êtes coach ou ScrumMaster, comment intervenez vous pour que l’équipe prenne conscience et règle ces symptômes ?

[Mise à jour]

Pour découvrir la suite voir le billet : « Odeurs de mêlée quotidienne – Astuces pour progresser »

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations¹.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

• Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
• Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
• Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
• Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ‘supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

• S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
• Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

Un leader désigné non consentant ne sera pas un leader ! Prendre un rôle, et la charge qui y est associée, n’est pas une chose qui se décide de façon unilatérale. Cela est un acte d’entête et de volonté réciproque qui implique de savoir dire non dans les deux camps.

Depuis mars 2009, à Pyxis, je participe à la CoMI (Communauté Marketing Internet) en tant que membre actif. Après une période de forte activité au printemps, le niveau d’énergie du groupe a baissé durant l’été .

À ce moment là j’ai proposé de changer notre mode de fonctionnement auquel je voyais les problèmes suivants : pas de cadence, pas d’engagement, pas de carnet de produit,… pour le remplacer  par une organisation du travail de type Scrum. Je pensais que livrer régulièrement des incréments dans le cadre d’un engagement mensuel limité à une part d’un carnet de produit priorisé, nous permettrait de nous concentrer  à livrer plus de valeur pour le site web de Pyxis.

Dès que nous avons parlé de cette organisation, il a été question de trouver parmi nous un ScrumMaster, la personne en charge d’animer l’équipe, et d’aider le responsable du carnet de produit, le propriétaire du produit (PO). Personne ne souhaitait prendre ce rôle (un “indice puant”, un smell). Toujours est-il qu’après avoir dit non une première fois, les membres de la communauté ont décidé, en me forçant gentillement la main , que je jouerai le rôle de ScrumMaster.

Résultat, j’en fais le constat aujourd’hui et je ne le cache pas, je n’ai pas embarqué. Certes j’ai quelques fois aidé le propriétaire du produit (PO dans la littérature anglophone) à organiser les activités et le carnet de produit (backlog), mais je n’ai jamais pris la charge qui m’incombait depuis le jour ou je n’ai pas su dire non aux autres membres.

Être sollicité et “élu” par un groupe de personnes, même si cela est très valorisant, ne signifie pas qu’on a ou qu’on aura l’énergie pour œuvrer au niveau de la responsabilité associée au rôle.

Lorsque vous travailler au sein d’une communauté, certes vous ne pouvez pas espérer coordonner cette communauté sur le long terme sans l’assentiment de ses membres, mais il est évident pour moi que le leadership de la communauté n’est pas une chose qui se décrète de façon unilatérale. Un groupe de personne, aussi bienveillant soit-il, ne peut espérer être correctement guidé par quelqu’un qui n’y est pas explicitement candidat.

J’ai appris une chose, il faut vraiment que j’apprenne à dire non, si mon oui n’est pas un oui franc et massif. Un “ouais” n’est pas un “oui” !

Depuis quelques jours maintenant, après avoir pris conscience de tout cela j’ai décidé d’agir, j’envisageais deux solutions : prendre ma place ou annoncer clairement que je ne la tenais pas.

J’ai décidé de  prendre la place et d’assumer la charge associée. Affaire à suivre …