mercredi 20 janvier 2016

Pourquoi la taille des équipes est-elle limitée en Scrum ?


Il est préconisé qu'une équipe de développement comporte de 3 à 9 personnes, Scrum Master non compris. En dessous de 3, se parler directement est ce qui fait le plus sens (d'ailleurs on appelle ça un binôme) et si vous êtes tout seul évitez de vous parler à voix haute trop souvent, pour collaborer avec vous même, ça pourrait paraître un peu bizarre ! Au dessus de 9 on constate que cela devient difficile à gérer, car on perd en efficacité et la coordination devient très complexe.


Une raison organisationnelle


Prenons par exemple la mêlée quotidienne (Daily Scrum) qui sert notamment à faire le point sur l'avancement et à se coordonner. Celle-ci doit tenir dans un temps de 15 minutes maximum. Avec une équipe de 5/6 personnes l'exercice n'est déjà pas si évident. En effet, pour tenir dans ce laps de temps, il faut que chacun ait une idée claire de ce qu'il va dire, qu'il arrive à le dire de façon concise et claire, et enfin qu'il se cantonne aux 3 questions : Qu'ai je fais depuis la dernière réunion ? / Qu'est ce que je vais faire aujourd'hui / Quels sont les obstacles qui gênent ma progression ? (et donc implicitement, Comment peut-on m'aider ?) Tout cela nécessite une préparation personnelle. 

Si vous dépassez les 15 minutes, vous risquez de faire perdre du temps à plusieurs membres de l'équipe voire à tous. On peut limiter le temps de parole, mais que ce soit plutôt pour que chacun s'exprime en un temps imparti. La mêlée quotidienne est donc un exercice exigeant.


Prenons une réunion plus longue comme le Sprint Planning. C'est lors de cette réunion que le Product Owner expose les scénarios (User Stories) qu'il envisage pour une livraison à la fin du sprint suivant (l'itération suivante). De façon très résumée, l'équipe échange avec lui pour comprendre les scénarios, évalue la complexité de ceux-ci et s'engage sur ceux qu'elle réalisera. Hors mécaniquement, le temps nécessaire pour faire ce travail s'accroît avec le nombre de personnes présentes, la variété et le nombre de scénarios. La durée d'une telle réunion étant limitée pour des raisons d'efficacité, on ne peut avoir un nombre de participants trop grand. 


Une raison physique et humaine


Des études ont montrées que si une équipe de développement logiciel est toute réunie au même endroit (sans cloison) elle sera jusqu'à deux fois plus productive que si elle est disséminée (Teasley, Covi,Krishnan, & Olson, 2000). On considère que pour un fonctionnement optimal, tout membre de l'équipe doit être à 6 mètres maximum de tout autre membre, et j'ajouterai même, il est mieux que l'équipe soit regroupée en un îlot. 

J'ai géré récemment un projet avec deux personnes situées à une vingtaine de mètres du reste de l'équipe et je peux vous dire que c'était assez pénible à cause du temps perdu à faire les allers-retours, et à cause des problèmes que cela ajoutait en termes de communication et de collaboration du fait de leur isolement. La proximité physique favorise le dialogue en face à face, les échanges et aide à sortir de l'isolement.

Entendre ce qui se dit, voir les visages, les attitudes, facilite la convivialité, la détection des problèmes humains, techniques et permet d'avoir une meilleure perception de l'équipe et du déroulement du projet. C'est donc une aide pour le Scrum Master dans son rôle de "leader au service de l'équipe". L'organisation physique doit ainsi favoriser tout cela en permettant :
  • de voir les autres membres de l'équipe sans se lever de son siège,
  • d'avoir la possibilité d'aller les voir facilement et donc de communiquer en face à face,
  • d'entendre ce qui se dit à proximité.
Et donc forcément, cela fonctionne bien avec une équipe à taille contenue.

Conclusion


Dans une approche agile comme Scrum on recherche avant tout l'efficacité et c'est pour cela que l'on fixe des contraintes et des limites. Celles-ci n'ont pas été décrétées du jour au lendemain, mais sont le fruit de l'expérience acquise par la pratique. Au delà de la taille de l'équipe d'autres éléments sont à mettre en place comme la disposition dans les locaux. Si votre projet nécessite un nombre plus important de personnes que celui préconisé, c'est une organisation adaptée qu'il faudra mettre en place avec davantage d'équipes et une coordination adaptée. Il existe pour cela diverses approches comme SAFe pour Scaled Agile Framework, Nexus qui a été conçu par un des fondateurs de Scrum, mais c'est un autre sujet.

1 commentaire:

  1. Quelques éléments supplémentaires en cas d'équipe de taille importante:

    Les membres peuvent être submergés par la quantité d'informations échangées au Daily Scrum. Il s'en suit une difficulté pour les membres de l'équipe, de retenir qui fait quoi. De même le Scrum Master peut peiner à lever tous les obstacles rencontrés par l'équipe à cause de leur nombre.

    Le Product Owner doit produire suffisamment de scénarios pour le Sprint planning. Plus l'équipe est grande, plus il a de travail à accomplir.

    C'est pour cela, qu' en plus des raisons énoncées dans l'article, au delà de 9 personnes et compte tenu du fonctionnement de l'équipe, il est bien de se poser la question de la séparer en deux.

    RépondreSupprimer