La méthode Scrum repose sur la notion d’équipe pluridisciplinaire – cross-functional team en anglais – difficilement compatible avec l’organigramme traditionnel par métier et par domaine fonctionnel des entreprises.

C’est une cause reconnue d’échec de la mise en place de Scrum. On préfère adapter la méthode Scrum à l’entreprise plutôt que de changer l’organisation pour adopter Scrum. Résultat: on fait du Scrum sans en faire… et sans les résultats.

Qu’est-ce qu’une équipe pluridisciplinaire ? Pourquoi cela est-il nécessaire ? Quels en sont les avantages ? Quels sont les impacts sur l’organisation ?

Une équipe pluridisciplinaire Scrum n’est pas seulement une équipe autonome avec toutes les compétences requises pour faire le projet: développement logiciel, conception matérielle, assurance qualité, design, spécification, administration de base de données, expertise métier… Ce critère de compétences multiples est parfaitement rempli par plusieurs personnes spécialisées dans un rôle: Développeur, Testeur, Designer, DBA… Pourtant une équipe de spécialistes n’est pas une bonne équipe Scrum.

L’équipe idéale Scrum est une équipe où chaque individu est lui-même pluridisciplinaire, c.-à-d. polyvalent. Cela ne veut pas dire que chaque personne doit savoir tout faire; mais simplement que chaque membre de l’équipe a plusieurs domaines de compétences, en général 2 ou 3. Ainsi il est possible d’avoir des: UI Designer-Développeur, Business Analyst-DBA-Testeur…

Il y a une volonté avec Scrum de ne pas limiter les personnes à un rôle spécifique. Dans Scrum, tous ceux qui réalisent s’appellent simplement « Membre de l’équipe ». Un corollaire est que si on trouve dans une équipe Scrum des architectes, des développeurs, des testeurs, voire un chef de projet technique (si,si déjà vu!)… ce n’est pas une équipe Scrum.

Mais n’y a-t-il pas un risque de perte d’efficacité ou de qualité avec ce type d’équipe ? En effet, dans son domaine, un expert sera plus efficace qu’une personne moins spécialisée… C’est vrai mais étudions ensemble les avantages d’une équipe pluridisciplinaire.

Un premier bénéfice indiscutable d’avoir des personnes compétentes dans plusieurs disciplines est d’améliorer la communication et la collaboration entre les disciplines. Cela ouvre les esprits et permet de prévenir des conflits entre des spécialistes qui auraient un point de vue unique sur le projet: Développement vs Q.A., équipe logiciel vs équipe matériel, Développement vs DBA…

Mais ce bénéfice en cache un autre beaucoup plus important.

Le principal bénéfice de la mise en place d’équipe pluridisciplinaire est de résoudre 95% du problème chronique de la gestion des ressources… et tous les problèmes induits.

Une organisation a toujours trop de projets et jamais assez de ressources. Il y a donc une nécessité d’optimiser leur utilisation, ce qui peut devenir un vrai casse-tête avec des personnes très spécialisées dans un seul domaine. Et l’optimisation des ressources engendre elle-même de nouveaux problèmes:

  • Création d’interdépendances artificielles entre des projets du fait la concurrence sur des ressources partagées
  • Besoin de planification détaillée pour prévoir les affectations des personnes, lourdeur et manque d’agilité face aux changements
  • Nécessité d’adapter le planning et les priorités du projet en fonction des ressources disponibles
  • Inconfort et inefficacité des personnes travaillant simultanément sur de multiples projets

Dans le cas d’une équipe pluridisciplinaire Scrum, les personnes peuvent réaliser une grande variété de tâches. Elles sont donc systématiquement « utilisées » à 100%, tout en étant affectées à un seul projet. Ceci simplifie grandement la gestion et l’optimisation des ressources.

On retrouve ici un autre principe fort de Scrum: les personnes sont affectées à 100% au projet. Du coup, cela supprime les problèmes d’interdépendances entre les projets dus aux problèmes de disponibilité des personnes, rend inutile les planifications détaillées de type diagramme de Gantt, et n’impose plus de contrainte particulière sur le planning du projet. Enfin, les personnes sont impliquées à fond dans le projet, au lieu de devoir papillonner de projets en projets.

Sans pluridisciplinarité des individus, il est difficile, voire impossible, de les affecter à 100% au projet, donc de faire du Scrum.

OK, mais si on demande à un expert DBA d’écrire des tests unitaires en Java, on sous-utilise une compétence précieuse et rare pour faire des tâches que peuvent réaliser des personnes moins expertes. En plus, pas sûr que cela lui plaise.

Répondons immédiatement au fait que cela lui plaise ou non. Un principe dans Scrum, c’est qu’il n’y a pas de leader, on ne donne pas des tâches aux personnes, c’est elles qui les prennent. De plus, chaque personne choisit ses domaines de compétences.

Quant au fait que les personnes ne fassent pas uniquement les choses pour lesquelles elles sont les plus efficaces, cette sous-optimisation n’est qu’apparente. En effet, à force de vouloir optimiser l’utilisation des capacités individuelles, on en vient à sous-optimiser le fonctionnement de l’organisation dans son ensemble (cf. la liste des problèmes induits par l’optimisation des ressources ci-dessus).Rappelons que l’optimum de l’ensemble est rarement la somme des optimums individuels.

OK, mais c’est bien joli, mais dans mon entreprise on est organisé en pôles de compétences et directions fonctionnelles. Comment faire si on n’a que des « spécialistes » ?

Aïe. L’organisation en silos fonctionnels est difficilement compatible avec des personnes pluridisciplinaires qui ne rentrent plus dans une « case » unique. Cependant il reste une chance de faire vraiment du Scrum si les personnes restent affectées à 100% sur le projet.

L’autre solution, plus radicale, est de revoir intégralement l’organisation actuelle. C’est ce que préconise Craig Larman, personnalité célèbre de la communauté Agile et auteur du framework LeSS – LeSS pour Large-Scale Scrum. Craig a accompagné de nombreuses très grosses entreprises, notamment dans les télécoms, dans leur migration vers l’agilité et Scrum.

La raison d’un changement aussi radical est que les processus ne font que refléter l’organisation. Si on veut changer les processus, il faut d’abord changer l’organisation. Si on conserve l’organisation actuelle, toute velléité de changement conduira immanquablement à un retour au statu quo.

Alors selon Craig, la réussite de la mise en place de Scrum est conditionnée par la remise à plat de l’organisation et la suppression de la hiérarchie actuelle (sic!) pour faire émerger spontanément des équipes pluridisciplinaires autour de projets ou de produits.

Tout cela peut sembler fantaisiste, mais certaines entreprises ont déjà adopté ce type d’organisation fondée sur des équipes pluridisciplinaires. L’entreprise Spotify est un excellent exemple. Leur document intitulé scaling agile @ spotify décrit en détail leur organisation, dans laquelle les managers fonctionnels traditionnels se sont transformés en animateurs de communauté.

En conclusion, l’équipe pluridisciplinaire Scrum, c’est l’équipe idéale: compétente, totalement autonome et impliquée à 100% sur le projet. D’où une meilleure performance…

Merci à Craig Larman et Christophe Addinquy, notre libre penseur logiciel français, qui ont inspiré les idées développées dans cet article.

Tagged with →  
Share →

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>