Un nouveau modèle d'organisation pour les équipes en télétravail
Au cours de mes formations, je lance souvent le débat suivant : “Dans quelles situations les méthodes agiles vous semblent inappropriées ?”. Ce débat me sert principalement à libérer les personnes que je forme d’éventuelles croyances limitantes ou idées reçues à propos de l’agilité. Et les idées reçues à propos de l’agilité ne manquent pas 🙂 Elles font malheureusement passer trop de gens à côté des bénéfices pourtant à la clé.
L’une de celles qui revient souvent est : “Les méthodes agiles ne sont pas appropriées pour des équipes qui ne partagent pas un même espace de travail”. Cette croyance s’explique principalement par le fait que l’agilité encourage la colocalisation des membres d’une équipe car cette dernière sera plus performante que sans cette colocalisation. De même que l’agilité encourage à avoir des membres de l’équipe dédiés au projet. Mais si ces conditions ne sont pas réunies, doit-on renoncer à travailler en mode agile ? Bien sûr que non.
D’autant plus que, pour beaucoup d’équipes, le fait de partager un même espace de travail n’est pas forcément synonyme d’une bonne communication, coordination, cohésion ni d’un bon alignement vis à vis de la direction à prendre. La performance et la motivation n’ont donc pas pour prérequis la co-localisation des membres de l’équipe.
Dans cet article, je vous explique ce que les méthodes agiles peuvent apporter à une équipe dispersée. Télétravail, offshore, nearshore, multi-site, c’est une réalité pour de nombreuses entreprises.
Avertissements
Petit avertissement…
Dans cet article je vais principalement évoquer Scrum (cadre de travail agile davantage décrit dans l'article "guide de démarrage Scrum") qui s’utilise principalement en mode projet. Si vous travaillez en équipe mais pas dans un contexte projet, je vous encourage quand même à poursuivre votre lecture car la majorité (voire l’intégralité selon le contexte) des éléments abordés sont transposables dans bien des contextes.
De même que si vous travaillez dans un contexte projet non informatique (bien que les méthodes agiles soient issues du secteur du développement logiciel), aucun des éléments abordés n’est spécifique aux projets de développement logiciel. Hormis quelques rares termes que je souhaite conserver afin que personne ne se sente perdu en cas d’approfondissement du sujet via d’autres ressources.
La technologie à notre service
Pour commencer, nous disposons désormais d’outils fantastiques pour communiquer efficacement à distance. Beaucoup sont même devenus gratuits.
Webcam, micros enfin de qualité, outils de “tchat” synchrones ou asynchrones, équipements visio des salles de réunion, pieuvres USB, outils de visioconférence web (sans rien à installer et dont certains proposent même un tableau blanc virtuel partagé), etc. Autant d’outils qui permettent d’augmenter de façon significative la “bande passante” de communication directe entre les membres d’une équipe dispersée (plutôt que la communication indirecte par email par exemple dont l’efficacité est médiocre).
Sans parler du bon vieux téléphone bien sûr, qu’on a trop tendance à oublier.
La limitation des rôles
Une multiplicité de rôles dans une organisation peut sérieusement compliquer les choses. Surtout lorsque chacun (ou une bonne partie de l’équipe) ne partage pas le même espace de travail. Comment parvenir à une coordination, une prise de décision et une circulation de l’information fluide dans ces conditions ? Sans compter qu’à trop avoir de rôles, on ne sait plus qui fait quoi sans s’appuyer sur un RACI ou autre documentation (quand celle-ci existe, est maintenue à jour et rendue accessible à tous).
Intuitivement, face à des projets complexes, on a tendance à adopter une organisation complexe. Et si la simplicité était au contraire notre meilleur atout face à la complexité ?
Scrum n’a besoin que de 3 rôles pour faire “tourner la boutique” :
- Le Product Owner qui représente les utilisateurs et les sponsors/commanditaires du projet. Il décide de ce que l’on fait (le “quoi”) et l’ordre dans lequel on le fait.
- L’équipe de développement (synonyme “d’équipe de réalisation” pour utiliser un terme qui sonne moins “projet de développement logiciel”). Elle est chargée de réaliser ce qui doit l’être et responsable de la façon dont on va le réaliser techniquement (le “comment”).
- Le Scrum Master qui est le garant du respect du cadre méthodologique adopté (donc de sa bonne compréhension et bonne application par les acteurs) dans une posture de “coach”.
Et tous appartiennent à une même équipe projet (ou équipe Scrum). Donc pas de séparation du genre “maîtrise d’ouvrage” et “maîtrise d’oeuvre” qui fait souvent l’objet de tensions. Attention, je ne dis pas qu’il y a jamais de tensions en mode agile, les méthodes agiles ne sont pas des baguettes magiques. Pour autant elle permettent de réduire le risque de conflit ainsi que bien d’autres risques.
Un cadre propice à l’auto-organisation et l’engagement de l’équipe malgré le télétravail
Il est parfois difficile pour un manager d’accorder aux membres de son équipe le télé-travail. Même si ça devient difficile de faire de la résistance et c’est tant mieux pour le bien être au travail.
Comment peut-il vérifier que la personne travaille réellement, fait ses heures, s’implique vraiment, sans pouvoir la voir physiquement. Si on exclut bien sûr toutes les astuces de “flicages” (généralement faciles à détourner d’ailleurs) telles que la vérification de l’heure d’envoi des emails, le statut de la personne sur le logiciel de tchat, les logs de connexion aux outils de l’entreprise ou VPN, etc. Autrement dit, comment peut-il s’assurer que ses collaborateurs sont engagés ?
Le management agile est basé sur la confiance. Non pas une confiance aveugle mais une confiance qui s’accompagne de la mise en place d’un cadre de travail spécifique, au sein duquel l’équipe peut s’auto-organiser face à un objectif donné, s’auto-contrôler (grâce notamment à une définition explicite et partagée de “terminé”). Sans un tel cadre, on s’expose à l’anarchie (au sens péjoratif du terme). Et en termes d’objectif, une équipe véritablement agile dispose toujours d’un objectif à court terme (moins d’un mois) tout en s’inscrivant dans une vision cible de ce qui doit être réalisé à plus long terme. Disposer d’objectifs à courts et long termes est essentiel à toute équipe et c’est encore plus vrai pour des équipes dispersées encore plus exposées au risque de “perdre le fil”.
Et cerise sur le gâteau : nous mettons plus d'énergie au travail quand nous avons la liberté de nous organiser librement pour atteindre nos objectifs. Les équipes agiles vont jusqu’à estimer elle même la charge de travail associée aux tâches qui lui sont confiées.
Centralisation et visualisation du travail à faire pour un bon alignement
Moins les équipes partagent un même site géographique, plus il est essentiel de centraliser la liste des tâches qu’elle doit accomplir à court et à long terme afin d’aligner tout le monde sur une même direction à prendre.
Sans pour autant créer de goulet d’étranglement au niveau d’une personne qui serait chargée de l’estimation, priorisation, affectation de ces tâches et de la coordination ainsi que le contrôle d’avancement des acteurs comme est généralement censé le faire un-e “chef-fe”. C’est déjà un frein important lorsque tout le monde est sur le même site, alors ça l’est d’autant plus si l’équipe est dispersée. Sans parler de la pression qui pèse sur les épaules de ce manager qui peut vite se retrouver en surcharge et surchauffe.
Les équipes agiles centralisent l’ensemble des choses à faire dans un seul et même artefact appelé Product Backlog et rendent ce dernier le plus clair, accessible et transparent possible pour chacun des acteurs. Ce Product Backlog dicte aussi l’ordre dans lequel les choses doivent être faites. C’est un peu le gouvernail du navire, il donne la direction à prendre sur toute la durée du voyage et il est donc sous la responsabilité du Product Owner. Mais rappelez vous, le Product Owner n’a d’autorité que sur le “quoi” et l’ordre dans lequel faire les choses. Pas sur le comment, ni sur la quantité de travail à faire dans le délai imparti, ça c’est la responsabilité de l’équipe de développement.
A intervalles de temps réguliers et courts (maximum 4 semaines) appelés itérations ou sprints, l’équipe de développement sélectionne un sous ensemble d’éléments du Product Backlog (les plus prioritaires, ceux qui apporteront le plus de valeur au produit ou service) qu’elle - et elle seule - se sent capable de réaliser dans le temps imparti et servant un objectif précis proposé par le Product Owner. Là encore, on va chercher à rendre les tâches à réaliser au cours de l’itération/sprint les plus visible, accessibles et transparentes possible. A distance, il existe des outils très simples et gratuits de management visuel électronique pour y parvenir. Tel que Trello par exemple.
Ainsi, au quotidien, l’équipe s’auto-organise pour atteindre l'objectif fixé. Sans contention au niveau d’un éventuel chef d’orchestre isolé géographiquement. Mais comment s’auto-organiser au quotidien si l’équipe est dispersée ? C’est le moment d’aborder les événements agiles.
Événements agiles anti réunionite
Tout d’abord, il faut savoir que les événements agiles respectent les principes de base anti-réunionite. D’autant plus que ces dernières peuvent sembler nombreuses (4 événements récurrents pour être précis) et fréquentes.
Voici les fameux principes appliqués :
- A chaque événement agile est associé un objectif afin de garder le “focus”.
- Chacune est limitée dans le temps (timeboxing) afin d’éviter de tergiverser. Autrement dit, elle ne peut pas dépasser une durée déterminée et cette durée est proportionnelle à la durée des itérations (à l’exception de la réunion quotidienne abordée plus bas dont la durée maximum est de 15 minutes quelque soit la durée des itérations). Ce qui veut dire aussi que si l’objectif de la réunion est atteint avant la fin de la durée maximum (timebox), elle peut prendre fin. Et si tout n’a pas été traité comme prévu avant la fin de la durée prévue, elle prend fin à la fin du temps imparti (tant pis, on fera mieux la prochaine fois). Plutôt pratique lorsque les salles de réunions doivent être réservées à l’avance et pour rester concentré lorsqu’on est à distance les uns des autres.
- Chaque réunion est tournée vers l’action. Je ne compte plus le nombre de réunions non agiles auxquelles j’ai pu participer et au cours desquelles, aucune décision n'étaient réellement prises ou alors souvent prises sans grande conviction. L’agilité offre des processus d'adaptation tels que le droit à l’erreur est permis. Si la décision prise en réunion ne s’avère pas être la bonne, on pourra s’adapter. Ainsi on ne reste pas dans l’immobilisme et on multiplie nos chances de trouver le meilleur chemin. Ceci dit je m’écarte du thème de cet article et me rapproche trop de celui d’un prochain qui devrait être : “Comment les méthodes agiles renforcent la capacité d'adaptation d’une équipe” 😉
La synchronisation quotidienne en moins de 15 minutes
Les méthodes agiles sont souvent connues pour leur réunion quotidienne (daily meeting) également appelée mêlée quotidienne (scrum meeting) ou encore réunion debout (standup meeting). Elles sont aussi connues pour les post-it sur les murs. Bien évidemment, les méthodes agiles sont très loin de se résumer à ces deux pratiques. Concrètement, à quoi sert cette réunion ? En quoi elle peut être utile à une équipe dispersée ? Et comment la pratiquer avec une telle équipe ?
Cette réunion permet à l’équipe de développement de faire le point sur son avancement, de s'entraider si certains membres ont besoin d’aide pour avancer, de se synchroniser et de se répartir le boulot d'ici la suivante. Le tout en 15 minutes maximum en respectant des règles précises telle que renoncer à instruire les problèmes en séance, sinon on s’éternise. On instruit les problèmes après la réunion et uniquement avec les personnes concernées afin de de ne pas faire perdre du temps aux autres inutilement.
Imaginez le lien que peut créer cette simple réunion entre les membres d’une équipe dispersée. Son effet sur sa communication, sa coordination, sur sa performance. Mais aussi sur sa motivation grâce à ce lien d’appartenance et cet objectif collectif à atteindre à court terme.
Maintenant, on en arrive à la question : “Comment animer une mêlée quotidienne avec une équipe multi-site ?”.
Je vais répondre par une anecdote personnelle vécu chez Swiss Life avec “mes” (c’est un terme affectif et non pas possessif dans mon propos) propres équipes réparties sur deux sites géographiques (Levallois - Roubaix pour être précis). A la création du département dont j’ai pris la responsabilité, nous n’avions qu’une équipe et très peu de moyens de communication. Nos premières “mêlées” (réunions quotidiennes) se sont faites pendant des mois avec des ordinateurs équipés d’une webcam et téléphones en mode haut parleur (le micro des ordinateurs était d’une qualité déplorable). Chaque personne de chaque site devait se déplacer pour venir parler à tour de rôle dans le combiné. Ca vous semble pathétique et archaïque ? d’une certaine façon, vous n’auriez pas tort 🙂 D’un autre côté, ça obligeait chacun à écouter les autres et attendre son tour pour parler, donc ce n’était pas si mal au fond pour commencer. Quelques mois ou années plus tard (je ne sais plus très bien), nous sommes parvenus à obtenir un budget pour équiper une salle de réunion de chaque site géographique, d’un système dernier cri de visioconférence. Un véritable “pont” virtuel entre les deux sites.
Et si les membres de l’équipe ne partagent pas le même fuseau horaire ? Ok ça se complique un peu, dans ce cas là, on va essayer de positionner cette réunion sur un créneau horaire commun aux différents fuseaux. Quitte à ce qu’elle clôture la journée pour certains et la lance pour d’autres (ou figure en journée). Ce n’est pas idéal mais les bénéfices restent supérieurs aux inconvénients.
Les 3 autres événements Scrum
Les autres événements vont également contribuer à donner une bonne dynamique d’équipe et de travail.
La Planification de Sprint
La Planification de Sprint va servir à déterminer (entre le Product Owner et les Développeurs) le travail à réaliser sur l’intervalle de temps (itération) à venir.
La Revue de Sprint
La Revue de Sprint va permettre d’obtenir des retours (ou feedbacks) sur le travail réalisé de la part des principaux intéressés (clients/utilisateurs clés ou représentants de ces derniers, commanditaires ou sponsors, etc) afin de vérifier que l’équipe est sur la bonne voie ou doit au contraire adapter sa trajectoire. Voilà un autre élément “d’auto-contrôle” du cadre de travail (en complément de la définition de” terminé” évoquée plus haut) qui évite la nécessité d’un-e chef-fe qui contrôle l’avancement et le travail de chacun. L’équipe fait directement face aux feedbacks des principaux intéressés.
La Rétrospective de Sprint
Enfin la “rétrospective” est une réunion dont la vocation consiste à tirer les leçons de l’expérience acquise sur l’intervalle passé. D’en déduire collectivement un plan d’actions d’améliorations applicables dès l’intervalle suivant. Ces actions étant le plus souvent mise en oeuvre par les membres de l’équipe elle même. Là encore, c’est l’occasion d’entretenir un lien étroit, un bon esprit d’équipe entre ces membres malgré la distance. Au delà d’améliorer la performance en soi. La rétrospective constitue à elle seule un précieux cercle vertueux absolument indispensable pour toute équipe véritablement agile.
Et comme je l’ai déjà évoqué, la technologie nous permet d’assurer sans trop de difficultés ces réunions à distance même si les premières manquerons certainement de fluidité. Ce n’est pas grave, la perfection n’est pas exigée et les rétrospectives vous aideront à régulièrement vous améliorer.
Petit conseil au passage : une fois que vous avez fixé la durée des itérations, planifiez ces événements de façon récurrente, toujours à la même heure et même jour de la semaine. Et même lieu si certains membres partagent un même site. Cette astuce facilite à la fois la planification (y compris la réservation de salles de réunion si nécessaire) et les nouvelles habitudes à prendre. Pour la réunion quotidienne, comme son nom l’indique, elle a lieu tous les jours, donc il s’agit surtout de la planifier systématiquement à la même heure et sur le même lieu pour chaque site géographique.
Attention au full télétravail
Petit avertissement tout de même. Ne négligeons pas pour autant l’importance de prévoir des rencontres physiques des membres de l’équipe. Surtout au début si personne ne se connaît.
Prenons l’exemple d’un projet agile offshore qui démarre avec une différence de fuseau horaire et de culture (pour prendre un cas extrême). L’idéal consiste à réaliser à minima une première itération tous ensemble sur un même site avant de se séparer. Ça permettra à chacun de faire connaissance, partager des moments informels voire carrément “hors travail” (idéal pour comprendre la culture de l’autre). Evidemment, ça représente un coût (hébergement, déplacement) mais quel sera le surcoût occasionné si on ne parvient pas à faire travailler efficacement ensemble les membres de l’équipe ? Sur 10 projets offshore complexes menés de façon traditionnelle et sans un tel investissement, combien réussissent vraiment ?
Vous n'êtes pas dans ce cas extrême ? Tant mieux mais l'avertissement reste valable, c'est juste que l'investissement en rencontres physiques sera moins coûteux.
Conclusion et passage à l’action
Pour résumer
Essayons maintenant de résumer ce que les méthodes agiles peuvent apporter à une équipe dispersée. L’agilité (et Scrum en particulier) apporte à la fois un cadre, une posture managériale et donne un rythme permettant de garder une bonne dynamique d’équipe malgré la séparation géographique.
Le cadre se compose d'événements, artefacts et rôles (limités au strict minimum) spécifiques tels que la réunion quotidienne de moins de 15 minutes et le Product Backlog. Et c’est ce cadre qui favorise l’auto-organisation de l’équipe ainsi que la confiance managériale indispensable au travail à distance. Le rythme est quant à lui donné par des intervalles courts (moins d’un mois) associés à des objectifs collectifs clairs pour maintenir une bonne dynamique et un bon alignement de chacun malgré la distance.
Bien entendu, la technologie nous permet d’augmenter la bande passante de communication entre les membres de l’équipe (tchat, équipement visio, téléphone, management visuel électronique).
J’espère aussi que cet article a pu vous donner un bon aperçu de la rigueur qu’exige les méthodes agiles. Tout comme l’exige le travail en équipe à distance. La gestion du temps au cours des événements agiles en est l’une des illustrations mais ce n’est pas la seule. De quoi traiter une autre idée reçue consistant notamment à dire que l’agilité est une "méthode à l’arrache” sans soucis de la qualité, de la documentation, dans l’improvisation permanente qui pousserait à “faire et défaire” sans cesse, et j'en passe. Je peux vous assurer que rien n’est moins vrai.
Ce qu’il vous reste à faire
Vous découvrez l’agilité et Scrum ? Vous ne savez pas par où commencer pour les mettre à profit de votre équipe dispersée ? Allons-y pas à pas. Et mon conseil : commencez par mettre en place votre propre cercle vertueux d’amélioration continue grâce à la rétrospective. Profitez-en pour jeter un oeil à l’article suivant : “L’art de la rétrospective”.
Une fois la rétrospective en place, appuyez vous dessus pour mettre en place d’autres briques, techniques, outils, sans rechercher la perfection. La rétrospective sera là pour vous guider et vous évitera de rester dans l'immobilisme. Grâce à elle vous disposerez d’un processus d’amélioration continue qui vous donne le droit à l’erreur nécessaire à l’innovation dans votre façon de travailler en tant qu’équipe. De quoi se sentir plus sereins tout en obtenant des gains rapidement.
Envie d'en savoir plus sur les méthodes agiles ?
Voici le lien vers l'article d'introduction aux méthodes agiles.