L’agile à l’échelle est un terme très à la mode et j’en ai moi même fait de nombreux articles. Mais qu’est-ce l’agilité à l’échelle en fait ? Cet article va permettre d’éclairer sur ce terme ceux qui ne le comprennent pas bien.
Le premier but de l’agile à l’échelle
L’agile à l’échelle taggué « Agile@Scale » est tout simplement la mise en place d’un cadre pour faire travailler plusieurs équipes agiles ensemble.
Pour rentrer doucement dans le détail cela implique de créer une organisation qui permettra de faire travailler toutes ces équipes ensemble autour d’un même produit ou de plusieurs produits.
L’agile à l’échelle inclue également la transformation globale de l’entreprise ce qui inclue ressource humaines, métiers, commerce… et la formation qui va permettre aux collaborateurs de s’intégrer dans cette transformation.
Difficile de transformer réellement l’entreprise si l’ensemble de l’entreprise ne rentre pas dans cette transformation.
Pour cela, il existe plusieurs framework (cadre de travail) différents qui permettent de faire de l’agilité à l’échelle. Ceux-ci sont en général assez différents et répondent à des problématiques distinctes.
Certains framework d’agile à l’échelle sont aussi liés à des philosophies qui diffèrent entre coachs mais si vous débutez dans le domaine, ne vous prenez pas la tête avec cela, c’est du détail.
Un framework agile à l’échelle rassurant
Aujourd’hui beaucoup d’entreprises optent pour un framework nommé SAFe ; de nombreuses sociétés françaises sont en train de l’installer ou l’ont déjà fait (Pôle Emploi, Société Générale, Axa…).
SAFe est très contesté dans le monde de l’agilité car un grand nombre de coach agile ne le considère pas comme agile. Cependant les sociétés le trouvent rassurant car il est de loin le framework d’agile à l’échelle qui offre le cadre le plus complet… Il est contesté du fait de ce cadre « TROP » complet (selon de nombreux agilistes).
Cependant, les entreprises l’apprécient car il est plus facile à vendre aux directions qui ont une réelle visibilité en s’engageant avec ce framework malgré le fait d’embarquer des centaines de personnes dans celui-ci.
Voici un lien qui en parle si vous êtes intéressé : Qu’est-ce que le framework SAFe 4.5 ?
Faire travailler plusieurs équipes sur un même produit
Le deuxième framework qui se démarque est le LeSS qui propose un cadre très proche du Scrum. Il propose quelques ajouts au Scrum sans perturber son fonctionnement avec la couche supplémentaire de synchronisation des équipes.
Il se met rapidement en place et les équipes y adhèrent très facilement ; pour l’avoir mis en place, je suis assez surpris de la facilité de mise en place de ce framework. Il a la particularité d’avoir un seul Product Owner partagé par les équipes.
Son cadre est intéressant mais moins rassurant pour les grandes entreprises qui voient mal comment faire travailler des centaines de personnes autour de celui-ci. De plus, ce framework ne parle pas du tout de la partie portefeuille projet.
Article : Qu’est ce que le framework agile LeSS ?
Un autre framework d’agile à l’échelle (plus précisément de scrum à l’échelle) permettant de travailler sur un même produit (1 seul backlog et 1 seul Product Owner) est né d’un des créateurs de Scrum ; celui-ci est très peu utilisé mais propose des idées intéressantes à connaitre.
Comme pour le Scrum, ce framework se veut volontairement proposer un cadre léger.
Article : Le Nexus pour organiser plusieurs équipes Scrum
Agile à l’échelle sur plusieurs produits
Le LeSS Huge qui est une version plus grande encore du LeSS, propose de travailler sur plusieurs produits avec plusieurs Product Owner. Cependant ce framework reste évasif sur les notions de porte-feuilles contrairement au Safe.
Article : L’agilité à l’échelle avec LeSS Huge
Un modèle de plus en plus populaire sur l’aspect organisation
Contrairement aux précédents framework, le modèle Spotify n’impose pas de Scrum (voire de Scrumban) aux équipes. Ce modèle va plutôt proposer une enveloppe qui saura faire travailler des équipes ensemble.
Article : L’agilité à grande échelle avec le modèle Spotify
Depuis quelques temps d’ailleurs, des entreprises aventurières imaginent un mélange entre Spotify et SAFe pour créer leur propre modèle. Il est intéressant de voir ces entreprises créer leur propre modèle en prenant le meilleur selon leur propre contexte.
Article : Agilité chez Axa France : mélange entre le modèle Spotify et Safe
Le petit dernier framework
Jeff Sutherland, co-créateur de Scrum vient de proposer il y a peu de temps, un framework d’agile à l’échelle Scrum@Scale qui est un Scrum of Scrum (autre framework d’agile à l’échelle) évolué.
Le but étant de proposer des framework au cadre léger mais qui pourraient s’avérer plus complexe à mettre en place qu’il n’y parait au premier regard. Cependant, par rapport à un SAFe, le cadre est réellement plus léger et pourra paraître moins rassurant pour les managers qui voudraient décider de la stratégie à mettre en place pour « FAIRE » de l’agile.
Un ancien petit framework appelé SSwS est lui aussi assez proche dans la démarche que le Scrum of Scrum ou Scrum@Scale.
Articles :
Scrum of Scrum : Coordonner plusieurs équipes
L’agilité à l’échelle avec Scrum@Scale !
Le Scrum à grande échelle avec SSwS
Et si le meilleur framework était celui créé par les équipes ?
Une démarche très agile qui apparait de plus en plus dans les structures est le concept de laisser ces équipes créer leur propre fonctionnement. En général, ceux qui deviennent leader de ces démarches se renseignent de l’existant et vont guider ceux qui sont moins renseignés sur le sujet.
Cependant la démarche si elle peut faire très peur aux managers, semble fonctionner dans certaines grosses structures ; il faut juste attendre quelques temps pour s’assurer de la pérennité de ce type de démarches où ce sont les employés qui vont créer leur propre modèle d’organisation.
Article : Et si l’agilité à l’échelle venait des équipes ?
Conclusion agile à l’échelle
Cela faisait bien longtemps que j’essayais de comprendre car beaucoup de mes clients sont directement concernés, et selon les personnes à qui on demande on peut avoir tous types de réponses…
Cette fois-ci c’est limpide, merci beaucoup !!!
Bonjour,
Je me pose un question depuis longtemps au niveau de Scrum.
Comment différencier un « produit », d’une « feature » ?
A partir du moment où les choses sont vendus ensemble, est-ce que cela en fait des features qui cohabitent dans le même produit ?
Ou le fait qu’il y ai une expérience suffisamment différente entre chaque élément en fait des produits à part entière ?
Quel autre critère doit-être pris en compte ?
Les concepts de « Product Team » et de « Feature Team » semblent quand même différents, mais personne ne semble fournir une définition claire pour les séparer dans des entreprises qui possèdent une offre assez riche.
Est-ce que tout cela a une importance dans les choix d’organisations et d’autonomie des équipes ?
Merci pour cette lumière
Le produit est le résultat de plusieurs fonctionnalités (features) rassemblées [il est rare qu’un produit n’ait qu’une seule feature]. Oui on peut avoir des features qui cohabitent ensemble et c’est même probablement le cas dans plus de 99% des cas.
Il peut s’avérer qu’une feature devienne un produit si on en voit un potentiel très fort mais c’est un cas particulier.
Il n’y a pas de règles précises car l’appréciation peut différencier d’une personne à une autre mais voici un exemple :
1/ j’ai un site ecommerce (produit) -> j’aurais plusieurs features : fiche produit, panier, navigation par catégories…. [certains iraient plus en détail dans leur vision de feature : code promotion, bon d’achat…].
La « product team » et la « feature team » sont dans la même idée de fonctionnement. Ce sont des équipes autonomes pour la réalisation du produit qui fonctionnent en mode agile.
Quand il y a plusieurs équipes qui travaillent autour d’un même produit, on va alors parler de « feature team » -> elles vont travailler autour de fonctionnalités de façon autonome (au tout cas en essayant au maximum de l’avoir). Chaque équipe travaillera sur sa fonctionnalité.
Une product team est sur un produit (probablement beaucoup moins gros) ; mais je n’ai jamais rencontré ce terme dans le monde francophone [cela ne veut pas dire qu’il n’est pas utilisé].
Mais les deux sont sensiblement la même chose même si feature team fait plus penser à de l’agilité à l’échelle (plusieurs équipes travaillant sur un même produit) et product team à un produit ayant qu’une équipe de réalisation. Ces noms se mettent surtout en opposition avec ce qu’on appelait le component team.
De parler de « product team » ou de « feature team » ne sera pas la question à se poser. Les deux veulent l’autonomie des équipes. Pour l’organisation, si le produit imposera d’avoir plusieurs équipes, alors nous parlerons de « feature team » et d’une organisation (agile à l’échelle) faisant travailler tout ce monde ensemble ; et si le produit imposera d’avoir qu’une seule équipe, ça sera une product team.
N’hésite pas si tu as besoin plus d’explication.