Avez-vous déjà participé à un Scrum de Scrums ?

Si vous avez déjà travaillé sur un projet Scrum multi-équipes, il y a de bonnes chances que la réponse soit oui. Dans mon cas, Scrum de Scrums a été une mêlée quotidienne bizarre entre Scrum Masters où tout le monde s’est présenté avec une liste de choses à discuter (essentiellement définies durant les mêlées quotidiennes au niveau des équipes), a discuté des problèmes rencontrés et est retourné à son équipe de développement avec des réponses.

Scrum existe depuis plus de 20 ans et livre des résultats convaincants au sein de plusieurs entreprises privées ainsi que dans le secteur public. Mais quand est venu le temps de l’appliquer à l’échelle de plusieurs équipes, les résultats étaient souvent moins impressionnants. Avec tous les défis qui peuvent survenir en présence d’équipes multiples travaillant sur un même produit, système ou processus, de nombreuses équipes Scrum ont essayé diverses façons de coordonner le travail pour assurer la livraison réussie d’un produit fonctionnel.

Tandis que les équipes expérimentaient et apprenaient, des pratiques ont fait surface pour gérer la mise à l’échelle. Scrum de Scrums était parmi les premières, tentant d’appliquer Scrum à grande échelle avec les mêmes règles que le guide Scrum. Cependant, en raison d’un vaste éventail d’interprétations, Scrum de Scrums a évolué de façon chaotique, produisant des résultats inconstants. Dans le but d’aider les équipes et les organisations éprouvant des difficultés, des auteurs de premier plan ont promulgué des cadres de mise à l’échelle comme Large Scale Scrum de Craig Larman, Scaled Agile Framework de Dean Leffingwell ou Nexus de Ken Schwaeber.

Avant de plonger dans l’un de ceux-ci, retournons aux fondements. La raison pour laquelle on souhaite appliquer Scrum à plus d’une équipe Scrum est souvent liée à un manque de capacité ou de productivité pour répondre au moment opportun à un besoin d’affaires. Mais peu importe le processus, qu’il soit empirique (Scrum) ou prédictif (en paliers ou cascades), l’expérience soutenue par les données démontre une baisse immédiate de productivité lorsque l’on ajoute des individus ou des équipes. Au fil du temps, la capacité accrue produit rarement une augmentation proportionnelle de productivité et requiert un surplus de coordination au-dessus des équipes individuelles.

Il y a des alternatives à la mise à l’échelle qui sont souvent ignorées malgré les preuves empiriques de leur valeur :

  • Boucle d’apprentissage validée à l’échelle de petits lots – Est-ce que votre équipe Scrum livre un incrément de produit « terminé » (potentiellement livrable) à chaque sprint ? Est-ce que cet incrément est livré de façon régulière aux utilisateurs (externes ou internes) pour vérifier l’hypothèse de valeur, sans développer l’ensemble de la portée définie en amont ?
  • Équipe autonome et polyvalente – Est-ce qu’on encourage les membres de l’équipe à travailler de manière transversale sur l’élément le plus important du moment ? Est ce que cette polyvalence inclut des domaines d’affaires en plus des rôles de TI évidents ? Est-ce que l’équipe est capable de créer le produit complet par elle-même et de valider la valeur livrée grâce à des mesures de valeur exploitables ? Est-ce que les gens sont encouragés à grandir en tant que professionnels dans le cadre de leur expertise ainsi que de façon transversale ?
  • Automatisation et outillage – Est-ce que votre équipe a commencé à automatiser autant que possible les tâches redondantes (test, intégration, déploiement) ? Est-ce que votre équipe utilise des outils efficaces pour soutenir les pratiques d’ingénierie, l’apprentissage et la communication, et ce, même en mode distribué ? Est-ce que vous utilisez des pratiques visuelles pour que l’information émane de façon claire et transparente pour les gens l’utilisant pour travailler ?

Le meilleur conseil à propos de la mise à l’échelle, c’est de la faire quand votre équipe Scrum livre un incrément de produit de valeur et potentiellement livrable à chaque sprint. La croissance organique (une équipe à la fois) est fortement recommandée par opposition à une croissance de type « Big Bang » (plusieurs équipes en même temps), principalement pour aider la mise à l’échelle de chacune des facettes de manière douce, pour que l’efficacité d’origine et les dynamiques d’équipe ne soient pas écrasées par cet énorme changement.

En ce qui concerne le modèle à suivre, les opinions divergent largement. Ce qui fonctionne dans une situation peut échouer dans une autre. Néanmoins, tout en s’appuyant étroitement sur les valeurs Agiles et sur ce qui a fait de Scrum un succès — c’est-à-dire le fait qu’il s’agisse d’une approche empirique pour la livraison incrémentale de produits, qui favorise des boucles d’apprentissage rapides provenant du client final — il est important de demeurer prudent et de ne pas se coller aveuglément au modèle que nous décidons d’utiliser, quel qu’il soit.

Personnellement, j’ai tendance à favoriser Nexus, un cadre minimal construit au-dessus du guide Scrum et qui se concentre fortement sur les problèmes d’intégration, puisque ceux-ci engendrent souvent d’énormes frais dans le cadre d’initiatives de mise à l’échelle. Comme Scrum, Nexus bénéficie de nombreuses pratiques complémentaires qui ont prouvé leur efficacité dans divers contextes. Cela étant dit, l’Agilité requiert de la souplesse, et le fait de recommander une approche plutôt qu’une autre serait nocif pour toute organisation

Découvrez comment surmonter les défis des initiatives de développement à grande échelle et comment garder le cap. Découvrez notre cours Scaled Professional Scrum avec Nexus

Dans le cadre d’une approche de mise à l’échelle, un vrai professionnel gardera l’esprit ouvert et utilisera des outils et des pratiques qui proviennent de n’importe quelle autre méthode ou n’importe quel cadre de mise à l’échelle (ou même d’ailleurs), refusant de suivre aveuglément une meilleure pratique prescrite. Peu importe le nombre d’équipes, l’intention ultime demeure la même : des équipes engagées et polyvalentes qui ravissent les clients et les utilisateurs avec des livraisons fréquentes de produits de qualité et de grande valeur.

pawel mysliwiec

Détenteur d’un Master en Informatique depuis 2003, Pawel a joué divers rôles depuis le début de sa carrière: programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et architecte d’affaires; dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et d’affaires.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s’est joint à Pyxis en 2015 pour continuer à aider les individus et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client. Il a joué le rôle de coach Agile et Lean dans des organisations de diverses tailles et à divers niveaux. Il est également formateur certifié par Scrum.org et offre les formations de Professional Scrum Master et Professional Product Owner publiques et privées au niveau international.

Billet précédent

Rééquilibrage de la société et organisations Agiles

Billet suivant

Cinq façons faciles de collaborer avec votre équipe

Pas de commentaire

Laissez un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.