Les réunions hebdomadaires de la Team

A l’heure où cet article est publié, je ne suis pas disponible. Ni par mail, ni par téléphone, ni par aucune autre interface. Non je ne suis pas en congés, pas plus que je ne suis malade ou en train de promener mon chien.

Le mardi dans la Team, c’est réunion hebdomadaire, à 14h. Le monde du web s’arrêterait presque de tourner (bien que nous recevons des demandes à ce moment). La réunion dure une heure environ, mais il arrive qu’elle soit écourtée selon les sujets à aborder, ou à l’inverse allongée. 

Cette réunion est presque capitale pour nous. Elle nous permet d’améliorer ce que nous faisons et qui nous sommes. Tout est basé sur des principes scrum et agiles, et a pour but d’améliorer la qualité de notre travail ainsi que notre vie professionnelle. Et croyez-moi, il y en a des choses à dire !

 

Scrum et Agile c’est quoi ?

Bon, c’est un peu complexe comme principe, bien que répandu, j’opterai donc pour le choix vulgarisant mais facile de la vidéo qui saura expliquer en gros les avantages (et vous devinerez peut-être les inconvénients) de ce que que sont Scrum et Agile.

Le débat pourrait aller bien plus loin, et si vous souhaitez faire parler un CEO ou un développeur, demandez-lui ce qu’il considère comme inconvénients chez Agile, vous aurez votre soirée bien occupée !  😆 

L’idée est cependant là : une organisation hiérarchisée et une écoute du client, le tout couplé à des réunions brèves mais efficaces, apporte un résultat de meilleure qualité pour des rapports humains améliorés.

 

L’importance de faire un bilan sur les projets

Un projet, ça évolue, ça grandit, ça change. A force d’avoir la « tête dans le guidon » on peut rapidement passer à côté de choses essentielles, ou d’une solution pourtant évidente. Même au bout d’une semaine, les projets ont tellement progressé qu’il devient important de faire un point dessus. Même le client, à exprimer ses besoins, en oublie ce que ses propres clients désirent réellement ce qui demeure pourtant un des piliers du référencement naturel. Il faut donc qu’une personne ou plusieurs se mettent à sa place et occupent en même temps le fauteuil de ses prospects ou clients. Un projet web, ce sont des personnes physiques, que l’on côtoie, et que l’on ne verra jamais. Tout cela est à prendre en compte.

Tout autant que le projet, c’est donc la personne qui travaille dessus qui doit également être en confiance et à l’aise. Celle-ci peut demander à être formé sur une technologie, ce qui lui permettrait de gagner en efficacité, en compétences, et de pouvoir plus facilement gérer des contraintes dans le temps. Ceci rejoint totalement mon article sur la formation (et puis finalement, un client ça se forme, tout comme l’on doit se former en interne).

Cette réunion a donc un double objectif, qui se tient en (très grosso modo) deux questions :

• Comment ça va ?
• Les projets en cours, ça roule comment ?

 

Sujets abordés : difficultés, contraintes, solutions

Ainsi que le précise la vidéo, un projet est divisé en itérations. Ou tickets, cartes, appelez cela comme vous le désirez du moment que vous saisissez bien l’importance de subdiviser les demandes selon d’une part le besoin, et d’autre part les compétences dont vous disposez. On ne met pas un graphiste à développer un plugin ou gérer une base de données, laissons l’expertise aux experts.

Chaque itération abordée par un des membres de la Team est sujette à une difficulté ou une contrainte (sinon, ça ne serait pas marrant  🙄 ). On pourrait définir plusieurs niveaux de difficultés, le niveau le plus bas étant celui le plus maîtrisé, l’inverse étant directement bloquant. 

• Difficulté « verte » : n’a pas donné lieu à un souci particulier. 
• Difficulté « jaune » : j’ai un peu perdu de temps sur la demande mais j’ai su la résoudre malgré tout rapidement
• Difficulté « orange » : j’ai pas mal bloqué sur la demande, la deadline était trop courte ou quelque chose m’a coincé, il est nécessaire d’en parler
• Difficulté « rouge » : je suis bloqué ! Soit par manque d’informations (et il faut donc revoir la user story), soit parce que la demande n’est pas claire, soit alors parce que cette demande est très complexe et nécessite que quelqu’un de la Team vienne m’aider

Ceux qui utilisent les niveaux d’incidence verront tout de suite la hiérarchisation de ces difficultés rencontrées, ce qui permet de prioriser les choses à faire suite à une réunion où – justement – c’est le moment d’en parler.

Les contraintes les plus fréquentes que nous rencontrons sont de plus en plus le nombre d’intermédiaires entre le « product owner » (le client final donc) et nous-même. Au moins il y a d’intermédiaires, au plus la compréhension du besoin est élaborée, structurée, notée dans la user story, et au mieux le résultat est rapide, efficace, et de qualité. Le but demeure – bien évidemment – que le product owner soit le plus satisfait possible, et que la création que nous avons réalisé corresponde à son besoin exprimé. Tout cela demeure – vous vous en doutez – sujet à des contrats, de la paperasse, des cahiers des charges et autres documents qui sécurisent le travail tout en le ralentissant (ce qui fera l’objet d’un autre article, soyez-en certain !)

Imaginez un peu un projet qui ne corresponde pas à vos besoins à cause d’une incompréhension ou d’une mauvaise écoute… Vous seriez – et c’est Umberto Eco qui définit cela dans l’excellent roman « Le Pendule de Foucault » – un imbécile, car comme il le définit si bien :

« L’imbécile ne dit pas que le chat aboie, il parle du chat quand les autres parlent du chien »

Par-dessus le marché, si la user story n’est pas bien retranscrite ni même bien analysée, les personnes en charge des itérations feront des « chats » au lieu de « chiens » tant attendus  🙄 

 

L’art et la manière d’aborder les projets

Tout d’abord, une règle : pas de mauvaise foi. Il n’est nullement question de trouver un coupable, de parler d’incompétence ou tout autre terme négatif. La réunion est là pour qu’on s’améliore les uns les autres, en mettant en place des procédures pour que si un éventuel souci s’est produit, celui-ci ne revienne plus. Si une personne est de mauvaise humeur, mauvaise foi, ou que sais-je encore, celle-ci doit immédiatement quitter cette réunion. Les mots d’ordre sont « partage« , « entraide« , « bonne humeur » et « humanité« . Le dialogue doit être constructif.

Dans le débat que nous avons ces fameux mardis, il est très intéressant de voir l’humour qui en ressort (Nico me cite parfois le « scrumgneugneu » 😆 ), et que chacun partage un peu de sa vie personnelle. Nous passons plus d’un tiers de notre vie à travailler, il est capital que cela se passe bien. La réunion n’est donc nullement stressante, bien au contraire.

Nous commençons par discuter entre nous, afin de savoir comment nous allons, et si tout va bien (ou pas). Nul n’est obligé de répondre, mais tout le monde le fait naturellement. De savoir comment va notre collègue de travail, nous nous réorganisons afin que celui-ci (au cas où quelque chose n’irait pas) puisse voir sa qualité de vie professionnelle améliorée. Si lui va bien, le travail qui en découlera ira bien aussi.

Une entreprise dont le nom depuis m’a échappé avait essayé d’analyser la productivité de ses salariés selon deux critères radicalement opposés. Voici ce qu’ils ont fait.

• Le premier jour, ils ont servi des repas à la qualité plus que douteuse, en diffusant dans le réfectoire les informations à la radio. Rien de bien valorisant. Le travail a été cette journée long, pas très bien réalisé, et les salariés étaient plutôt de mauvaise humeur.
• Le second jour, les repas servis étaient d’une toute autre qualité, et une petite musique douce a accompagné les salariés durant leur repas. Le résultat a été sans équivoque.

Etre à l’aise professionnellement rend le travail plus agréable à réaliser, et la personne sera beaucoup plus enclin à s’attacher à la qualité de son oeuvre. 

Faire une réunion au sein de Team Ever sans porter une attention à nous-mêmes ne servirait donc pas à grand-chose. Nous sommes une Team, nous nous comportons comme tel  😎 

Les projets sont donc abordés un par un, avec des sous-parties correspondants aux différentes itérations : développement d’un module spécifique, webdesign SAV,, etc. Chacun intervient et répond à la fois sur sa partie, les autres posant des questions afin de bien comprendre la problématique, ou de suggérer des solutions, lesquelles viennent très rapidement.

De ces projets découpés en itérations, nous en déduisons non seulement des tâches à réaliser, mais aussi les personnes en charge de ces résolutions. Bien noté sur des tableaux de bord, ce sont nos fameuses « to do lists« , que le responsable de la réunion prend soin de préciser à chacun, avec explications.

 

L’objectif à court terme VS l’objectif hebdomadaire

Certains objectifs sont à réaliser rapidement, pour aussi bien des raisons de deadline, de régularité professionnelle (comme la rédaction d’un article de blog) ou parce que la personne en charge de l’itération est tout simplement bloquée. D’autres projets peuvent avoir pris du retard parce qu’un intervenant était indisponible (congés, maladie, tout peut y passer, soyons humains). Hiérarchisons cela. 

Lors de cette réunion, un responsable rédige chaque projet avec chaque itération, et y associe les personnes qui vont être en charge de la résolution. Ce responsable agence le document selon la priorité des projets, permettant ainsi de régler rapidement pas mal de contraintes. Il s’agit donc d’objectifs à court terme, qui sont suffisamment difficiles pour faire partie des sujets de la réunion hebdomadaire de Team Ever. A la fin de la réunion hebdomadaire, chacun connaît très précisément les objectifs client à réaliser, tout comme l’ordre précis via lequel il est préférable d’opérer.

Les objectifs hebdomadaires sont tout autres. Régler des contraintes inhérentes aux projets est normal, mais cela ne suffit pas. Nous abordons donc un point différent, qui est l’amélioration de tout ce que nous réalisons et de comment nous le réalisons.

Par exemple, nous avons il y a pas mal de temps rencontré la difficulté de partager notre code et notre développement. Dans l’après-midi, nous avions tous un compte sur Bitbucket, un outil collaboratif très proche de GitHub. Depuis, nous nous entraidons même sur nos projets personnels via cette interface.

Je n’ai jamais été quelqu’un aimant les procédures, j’ai toujours trouvé que cela bridait les initiatives. Cependant, en échangeant dessus avec toute la Team Ever, ce ne sont plus réellement des procédures, mais des techniques de travail collaboratives qui nous ont fait gagner un temps extraordinaire, jusqu’à des journées entières ! Nous avons à présent tous à cœur d’améliorer cela, car chaque semaine nous nous posons la question suivante : « si cela m’a pris deux heures à faire, comment faire pour que cela ne me prenne plus qu’une, et que tous mes collègues profitent de l’astuce ? »

 

Un développeur, c’est quelqu’un de fainéant, mais intelligent !

 

L’objectif client VS l’objectif interne

L’objectif client est plus rapide à analyser que l’objectif interne, car il a fait l’objet d’une user story et d’une analyse de ses besoins. Il a cependant une deadline et un but à atteindre dans le temps. 

L’objectif interne dépend totalement de votre structure. Dans notre cas, cela se passe sur de très nombreux points, en voici quelques-uns récurrents :

• Amélioration des process de mise à jour de Prestashop
• Optimisation des modules développés en interne (comme le module de référencement Ever SEO ou le module gratuit de connexion au compte d’un client en tant qu’administrateur)
• Modification des procédures de travail, comme la création de cahiers des charges et de devis
• Optimisation des niveaux d’incidence liés à notre SAV
• Réduction du temps téléphonique (qui, comme le citait si bien Olivier Clémence dans sa vidéo à ce sujet, peut rapidement être un frein à la productivité, je vous invite vivement à visualiser cette vidéo).

Vous vous doutez bien qu’il y en a bien d’autres, et celles-ci évoluent énormément avec le temps. C’est au CEO de gérer cela, selon le retour qu’il a de son équipe. Il faut échanger, en discuter, conseiller et féliciter systématiquement lorsque tout va bien, et donner de nouveaux objectifs lorsque ce n’est pas le cas.

Vous pouvez bien évidemment pousser les objectifs sur du plus long terme, cela me semble finalement important dans la vie d’une entreprise, mais diffère d’une gestion de flux tendus (et bon, ça n’est pas le débat ici).

 

L’analyse des résultats la semaine suivante

Une semaine s’est écoulée. Nous avions tous des choses à faire, à n’importe quel niveau. Analysons donc la semaine suivante lors de la réunion les résultats obtenus.

Des objectifs ont été donnés durant cette réunion, à chacun. Il y a eu un partage des tâches, avec du travail collaboratif dans les cas les plus complexes ou requérant une intervention rapide. Ces objectifs ayant été notés, il suffit de s’y référer pour rapidement faire un tour de table et savoir si tout est résolu, ou le cas échéant qu’est-ce qui a coincé (auquel cas il faut remettre le sujet « sur le tapis » en ajoutant les nouvelles contraintes). Dans la grande majorité des cas, rien que le fait d’en avoir discuté permet de résoudre cela.

Si l’objectif n’a pas été atteint, réfléchissons au pourquoi. A-t-il été surévalué, ou une contrainte supplémentaire est-elle venue entre-temps remettre en question cet objectif ? En discuter à nouveau permet à d’améliorer cela, et de se réorganiser en conséquent.

Si l’objectif a été atteint, quel en a été le gain personnel et professionnel ? Si une personne était coincée sur un code précis par exemple, le fait de la mettre en binôme aura peut-être débloqué la situation, mais quelle expérience humaine en est ressortie ? Cela pourra peut-être faire l’objet d’une solution à un autre problème, ou à un agencement différent des itérations, non ?

 

Cherchons systématiquement le bien dans les réussites comme dans les échecs !

 

Une review tous les jours

Chaque jour, nous effectuons un point rapide sur ce qui va être abordé dans la journée (tel client, tel projet…) Il est possible de mettre cela en place sur un tableau, via des post-its, ou carrément en utilisant des interfaces collaboratives comme la suite Jira, ou plus modestement Trello.

Lorsqu’un membre de la Team arrive, il commence par dire bonjour (« la politesse ! ») puis se rend directement sur son planning afin de voir quelles sont les itérations en cours, et préciser celles sur lesquelles il va se concentrer dans la journée. S’il a rencontré un souci ou un blocage, il peut en parler directement à ce moment, les autres sauront le conseiller ou l’aider selon leurs propres plannings. Nous appelons cela entre nous le « daily« , le quotidien en somme.

De cette manière, ces dix petites minutes passées chaque jour à faire le point nous font gagner du temps à la fois sur l’avancement des projets, et tout autant sur la réunion hebdomadaire. Le scrum master en profite pour prendre des notes selon ce qui pourrait être un sujet à aborder lors de la prochaine réunion hebdomadaire. Croyez-moi, ça peut vite se remplir !

 

Le bilan ?

Le bilan est simple : en quelques heures des problématiques pouvant durer des semaines sont résolues, ce grâce à un échange et des décisions communes. Outre une réduction de la charge ou de la difficulté du travail grâce à un dialogue fréquent, c’est un excellent moyen pour que des personnes soient épanouies dans leur métier, et qu’elles réalisent un travail de qualité. Une heure par semaine, c’est peu ou beaucoup, mais c’est important.

Par-dessus le marché, l’analyse des contraintes rencontrées permet également à une structure de savoir se positionner là où elle a des compétences, et de ne pas avoir à se retrouver en porte-à-faux à la fois avec des clients ou des propositions sans rapport avec le cœur d’activité. « Connais-toi toi-même » fonctionne aussi pour les entreprises.

Ces réunions, c’est bien nous connaître entre nous, indépendamment et ensemble. Ça aussi, ça fait une Team !

 

 

(Faudrait que j’arrête de parler de chien moi. Ça se voit que j’en ai un depuis peu, non ?)

 Imprimer