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 ?

Nouveau cours: L’Agilité à grande échelle

Offrez à votre gouvernance une capacité décisionnelle souple et rapide, sans limiter les effets bénéfiques attendus des méthodes Agiles.

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.

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.

Billet précédent

Agile Tour Gatineau Ottawa, Pyxis y sera

Billet suivant

Une approche Agile pour concevoir et déployer des programmes de développement du leadership

pawel mysliwiec

Diplômé en 2004 et certifié Professional Scrum Master, Pawel a joué divers rôles depuis le début de sa carrière – programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et, plus récemment, 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 aussi dans celles responsables des activités commerciales.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s'est joint à Pyxis en 2015 pour continuer à aider les personnes 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.

Pas de commentaire

Laissez un commentaire

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