Plus de la moitié de toutes les équipes agiles ne sont pas ou plus colocalisées !

Understand Your Geographically Distributed Agile Team

https://blog.gurock.com/distributed-agile-team/ par Johanna Rothman

Plus de la moitié de toutes les équipes agiles ne sont pas colocalisées, chaque personne étant à moins de 30 mètres de toute autre. Si les équipes utilisent aveuglément des approches qui assument la collocation, elles pourraient échouer. Pour éviter l’échec, comprenez d’abord la sorte d’équipe que vous avez et les données que vous pourriez devoir rassembler. Ces données fourniront la base de l’approche de votre équipe aux pratiques agiles.

Nous entendons souvent les gens décrire leurs équipes comme colocalisées, distribuées, ou dispersées. Malheureusement, trop peu de personnes se mettent d’accord sur la signification de ces mots. Et, même si vous avez vraiment une équipe non-colocalisée, le type d’équipe décidera du flux de travail et de la métrique dont vous avez besoin.

Équipes colocalisées : Combien proche est-il assez proche ?

Votre équipe colocalisée pourrait être assise dans une pièce, la salle de travail de l’équipe. Une salle d’équipe encourage les gens à travailler ensemble, essaimer, travailler par paires, ou se regrouper comme nécessaire.

Trop peu d’équipes ont des salles d’équipe. Cependant, les membres d’équipe sont suffisamment près les uns des autres à une distance de 15 à 30 mètres pour pouvoir facilement se retrouver pour poser des questions, collaborer quand nécessaire et décider que faire en tant qu’équipe.

Cela demande à un adulte environ une seconde pour parcourir un mètre. Donc 15-30 mètres en environ 15-30 secondes. Si tous les membres de votre équipe sont plus distants que cela, vous avez une forme d’équipe distribuée.

Quand cela nécessite plus de 30 secondes pour poser une question, nous avons tendance à reporter la question à plus tard. Cela signifie que nous restons scotchés sur un problème, ou pire, nous passons à une autre tâche de travail. Nous augmentons notre WIP (Work In Progress), le Travail en Cours. Quand nous augmentons notre WIP, nous faisons passer moins de choses a finies (Done) par nous-mêmes et en tant qu’équipe.

Si les membres de votre équipe sont répartis sur un même étage à une distance de plus de 30 mètres, vous avez une équipe distribuée. Se déplacer à pied sur un même étage est bien meilleur que de devoir prendre l’escalier ou un ascenseur.

Si les membres de votre équipe sont sur des étages différents même dans un même bâtiment, ils font partie d’une équipe distribuée.

Dans From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, Mark Kilby et moi-même offrons des façons de penser aux équipes non-colocalisées : satellites, clusters et nébuleuse.

Équipes Satellites : La majeure partie de l’équipe ensemble, une ou deux personnes à distance

Les équipes satellites ont la plupart des membres de leur équipe à l’intérieur d’un rayon de 15-30 mètres. Une ou deux autres personnes se sentent comme si elles « tournaient » en orbite autour de la plus grande partie de l’équipe.

Nous voyons beaucoup ceci quand les développeurs et le propriétaire de produit sont dans un même bureau et que les testeurs sont à un autre étage, dans un autre bureau, ou même dans un autre pays.

Des équipes satellites semblent travailler comme « des bandes à part ». Parce que les membres d’équipe unis travaillent ensemble tous les jours, ils partagent l’information comme une équipe colocalisée le fait. Trop souvent, ils oublient de partager l’information avec les gens qui ne sont pas physiquement là.

Loin des yeux peut vraiment être loin de la pensée.

Parfois, des membres de l’équipe se regroupent dans bureaux ou emplacements. C’est l’équipe clusters.

Équipe Grappes (Clusters) : Les membres de l’équipe travaillent par deux ou trois

Parfois, nous voyons les développeurs ensemble dans un espace, les testeurs ensemble dans un espace différent à plus de 30 mètres des développeurs et le propriétaire de produit pourrait être sur un autre étage.

Dans ce cas, les développeurs sont un cluster, les testeurs sont un autre cluster et le propriétaire de produit est un satellite. Nous appelons toujours cette équipe une équipe cluster.

Votre équipe pourrait être un cluster si les gens qui sont assis près les uns des autres représentent des fonctions différentes. La clef est qu’un certain groupe des gens se rassemble en un cluster et un autre groupe en un emplacement (cluster) différent.

Les équipes clusters ont tendance à être plus conscientes de leur tendance à devenir des bandes à part. Elles trouvent souvent des façons de collaborer pour voir le travail avancer de manière plus fluide.

Il y a une troisième sorte d’équipe, la dispersée ou équipe de nébuleuse.

Équipes de type Nébuleuse : Chacun est éloigné de tous les autres

Si chacun dans votre équipe travaille de son domicile ou d’un café, votre équipe est dispersée. Peut-être chacun est-il dans un bureau séparé de tous les autres. Indépendamment de l’emplacement, chaque membre d’équipe est éloigné des autres de plus de 15-30 mètres.

Quand chacun est séparé de tous les autres, l’équipe a moins de tendance de développer des « bandes à part ». D’un autre côté, il pourrait être beaucoup plus difficile de collaborer sur le travail et de le compléter (le faire évoluer vers « Fini » / Done).

Les équipes de type nébuleuse ont un aspect positif significatif: elles savent qu’elles doivent créer un espace de travail virtuel auquel chacun ait un accès équitable.

Considérez la réalité de votre équipe distribuée

Indépendamment du type d’équipe que vous avez, considérez de traiter l’équipe comme si elle était une nébuleuse. Assurez-vous que chacun ait accès à tout le code, tests et outils dont les membres de l’équipe ont besoin.

Créez un tableau qui dresse la carte du flux de travail (workflow) à travers l’équipe.

Quand je travaille avec des équipes non-colocalisées, je leur demande de dresser la carte de leur flux de valeur.

• Qui amorce le travail ?
• Qui prend la suite du travail?
• Que font-ils avec ce travail ?
• Quand le travail se bloque-t-il, se trouve-t-il dans un état d’attente ?

Après que l’équipe ait dressé la carte du flux de son travail, je lui demande d’additionner les temps de cycle. Le temps de cycle est la durée nécessaire pour que le travail passe à travers les divers états plus les temps d’attente pour être complété.

Une fois que l’équipe voit son flux de valeur et mesure son temps de cycle, elle peut se poser ces questions

• Chacun dans l’équipe est-il dédié seulement à cette équipe, ou d’autres tâches les occupent-il brusquement ?
• Chacun dans l’équipe a-t-il accès à la zone de travail de toute l’équipe : le code, les tests, les outils collaboratifs, quoi que ce soit dont l’équipe ait besoin pour faire son travail ?
• Que devrions-nous faire pour créer plus d’occasions de collaboration ?

Votre équipe pourrait avoir d’autres questions basées sur le flux de valeur et le travail en cours visualisé dans le tableau.

Résolvez les problèmes de votre équipe

Beaucoup d’équipes distribuées ont de longs temps de cycle et trop de travaux en cours (Work In Progress – WIP). La première étape vers une solution pourrait être de devoir créer un tableau et limiter le WIP de l’équipe.

Quand les équipes limitent leur WIP, elles commencent à voir les divers problèmes dans leur équipe. Dans mon travail avec des équipes distribuées, je rencontre souvent ces problèmes :

• Les membres d’équipe ne travaillent pas que pour cette équipe. Ils travaillent pour leur manager.
• L’équipe n’a pas l’infrastructure suffisante pour collaborer.
• L’équipe n’a pas des heures de recouvrement (horaire) suffisantes pour collaborer.

Mes recommandations sont d’abord d’identifier votre type d’équipe. Avez-vous un type d’équipe qui supporte le travail que vous voulez compléter ?

Ensuite, dressez la carte du flux de valeur et mesurez le temps de cycle de votre équipe. Voyez comment le travail circule dans votre équipe et combien de temps cela prend à votre équipe pour finir le travail et délivrer de la valeur à un utilisateur.

Finalement, commencez à évaluer les possibilités de collaboration de votre équipe.

Une fois que vous savez tout cela, votre équipe peut décider comment créer un projet Agile qui réussira.