Agilité à l’échelle : les solutions
Introduction et contexte
Scrum s’impose encore en 2018 comme le cadre méthodologique le plus utilisé dans les équipes Agiles du monde de l’Informatique (54% des projets informatique (1)). Le guide Scrum recommande d’avoir entre 3 et 9 personnes par équipe auto-organisée en Scrum. Alors comment faire si votre équipe Scrum arrive à saturation ?
Vous avez besoin d’aller plus vite? Vous devez coordonner plusieurs équipes sur un même projet? Le client ou votre entreprise vous donne les budgets pour augmenter la “vélocité” de votre équipe Scrum, il est alors nécessaire de passer sur un cadre d’Agilité à l’échelle.
Comme le montre le graphique ci-dessous (2), la productivité de l’équipe n’est pas proportionnelle au nombre de membres qui la compose. Il y a un seuil au delà duquel, on perdra en efficacité afin d’assurer une bonne coordination dans l’équipe. Il semble judicieux de ne pas attendre d’avoir 9 développeurs dans votre équipe pour se poser la question du passage à l’échelle.
Courbe de productivité d’une équipe en fonction de sa taille (2)
Ce que démontre ce graphique est la complexité des grosses équipes à s’auto-organiser efficacement (7). Il est beaucoup plus viable de séparer les équipes imposantes en 2, quitte à ne garder qu’un PO et un Scrum master pour les deux équipes ainsi créées. La séparation devra se faire au niveau fonctionnel et non au niveau technologique dans l’idéal pour garder une cohérence, une indépendance et une pluridisciplinarité entre les équipes.
Il existe plusieurs modèles qui ont bonne réputation pour le passage à l’échelle, j’ai choisi de vous présenter 3 des modèles les plus utilisés. Scrum of Scrum pour sa simplicité, Spotify pour sa vision ultra-Agile et SAFe pour son approche rassurante et son application aux grosses structures.
Scrum of scrum
Scrum of Scrum est l’un des modèles les plus simples, il permet de gérer plusieurs équipes Scrum en parallèle avec des points de synchronisation réguliers appelés Scrum of Scrum.
Ce cadre d’agilité à l’échelle a été créé par les membres fondateurs du manifeste agile et du guide Scrum Jeff Sutherland and Ken Schwaber et est déployé sur 16%(1) des projets agiles.
Chaque équipe porte un membre qui participera au Scrum of Scrum (un développeur ou le scrum master). Les équipes Scrum continuent à effectuer leurs rituels habituels sans changement.
La fréquence des Scrum of Scrum varie du rendez vous quotidien jusqu’à une fréquence hebdomadaire. Cela dépend de la maturité, de la force des dépendances ou des risques liés au déphasage entre les équipes Scrum.
Dans des équipes plus larges, il sera possible de créer des niveaux supplémentaires (Scrum of Scrum of Scrum) afin d’assurer la synchronisation à différents niveaux tels qu’à des niveaux managériaux, composants ou portefeuilles (portfolio).
https://www.mountaingoatsoftware.com/
Les sessions de Scrum of Scrum doivent être vues comme le Scrum Meeting mais elle ne sont pas time-boxées à 15 minutes. C’est avant tout un moyen de synchroniser les équipes, mettre en avant les points de blocages et peut se transformer en atelier rapide pour lever les obstacles rencontrés. Cette réunion n’est pas un point d’avancement ou un planning.
Concernant la durée des sprints, il sera conseillé de garder des durées proportionnelles entre les équipes afin d’être synchronisé à la fin des plus grands sprints. Cela permettra de réaliser une review commune à toutes les équipes et de confirmer la bonne synchronisation fonctionnelle et d’intégration entre les équipes.
Alignement possible des équipes en sos (5)
Cette méthodologie est très avantageuse car peu coûteuse. On peut y passer très naturellement en choisissant les ambassadeurs d’équipes qui participeront aux Scrum of Scrum. D’ailleurs, ce cadre ne nécessite pas d’embauches supplémentaires. C’est les personnes des équipes qui joueront les rôles d’ambassadeurs ou de Scrum of Scrum Master (SoSM).
Spotify
J’ai choisi de vous présenter Spotify car il a une approche différente. Le modèle Spotify est de plus en plus plébiscité et suivi par 5% (1) des projets de développements de produits informatiques en 2018. Je vous propose une retranscription d’une vidéo descriptive de la démarche réalisée par Henrik Kniberg (3). Le modèle Spotify est basé sur une culture d’entreprise sur laquelle s’est développée la société Spotify (streaming musical). Ce n’est pas un cadre méthodologique avec des règles strictes, des cérémonies,…. etc. C’est un retour d’expérience de la part de cette société qui a réussi à atteindre un niveau de satisfaction des utilisateurs et des employés tellement important qu’ils sont devenus une référence.
La démarche Agile a commencé vers 2008 chez Spotify avec une approche Scrum classique. Mais la société a grandi et les équipes se sont démultipliées au point d’arriver à un seuil de rupture où le cadre Scrum ne leur convenait plus.
Leur philosophie a été “les règles sont un bon début, maintenant cassons les quand cela est nécessaire”. Ils se sont réorienté vers les bases de l’agilité plus que vers un cadre scrum imposant des règles strictes.
Leurs équipes Scrum ont été renommées en “Squads”. Chaque Squad est composée de 8 membres maximum et a un rôle bien défini à long terme. La mission est la seule chose imposée. Pour le reste, c’est l’équipe qui décide quoi construire et comment le réaliser.
Autonomie vs Alignement
L’autonomie est l’une des attentions principales de Spotify. Ils savent que plus les équipes seront autonomes, plus les personnes seront motivées et plus les équipes livreront de la valeur. Ils gardent en revanche les moyens pour se synchroniser sur les objectifs, la stratégie produit et les priorités de la société.
Concernant les pratiques, il n’y a pas de norme imposée pour chaque équipe. C’est chaque équipe qui décide comment s’organiser, comment communiquer, quand se rencontrer, pour se dire quoi …etc. Certaines équipes sont en Scrum d’autres en Kanban et chacun adapte le modèle à sa manière.
C’est un principe de pollinisation qui est utilisé. La société et les équipes mettent tout en oeuvre pour permettre aux personnes de communiquer efficacement. Toutes les équipes vont régulièrement partager sur leurs pratiques lors d’ateliers proposés. Si une équipe utilise un nouvel outil et qu’elle y a trouvé des avantages conséquents, elle va le présenter aux autres équipes et si certains sont intéressés, ils pourront les aider à mettre en place cet outil dans leur équipe.
La pollinisation plus que la standardisation
Tout le code est organisé en petits ensembles fonctionnels chacun répondant à un besoin spécifique. Chaque système est développé à l’origine par une équipe mais il n’y a pas de culture de la propriété. Le partage est également un des principes fondateurs. Une équipe pourra intervenir si besoin sur un système développé par une autre équipe en cas de besoin. Il suffira juste de demander à l’équipe à l’origine de la fonctionnalité de valider les modifications réalisées.
La culture du partage passe également par l’humain. Il y a beaucoup d’entraide et un esprit d’équipe très développé. On aime se congratuler pour le travail bien fait et on communique pour remercier ses collègues, cela est très motivant.
Les squads sont regroupées en Tribues. Chaque personnes appartient également à un Chapitre. La squad est orientée sur le produit alors que le chapitre est orienté sur une compétence particulière. De plus, des guildes sont créées à cheval sur plusieurs tribues et permettent d’échanger sur des sujets transverses.
Organisation des équipes d’après Spotify
Les squads sont réparties en trois groupes:
- Features : les squads qui vont développer du fonctionnel pour les utilisateurs
- Client app : les squads qui vont faire en sorte que les développements soient compatibles avec tous les supports, navigateurs,…etc
- Infrastructure : Les squads qui vont être en support des autres squads sur les sujets techniques: déploiement continu, AB testing, monitoring,…
Ce trio créée un environnement d’entraide où chaque pôle est au service des autres.
Je trouve que la vision Spotify pousse l’Agilité encore plus loin que le manifeste Agile de 2001 et y rajoute des valeurs qui semblent très pertinentes et qui ont fait leurs preuves.
SAFe
Je suis parti sur un scénario d’agrandissement d’équipe en introduction mais l’agilité à l’échelle va également s’appliquer dans le cadre de transformation d’équipes déjà en place.
C’est en fonction de la taille de l’équipe que vous allez accompagner et des différents paramètres avec lesquels les équipes doivent composer que vous pourrez orienter votre choix.
Pour des équipes plus importantes, SAFe est très majoritairement imposé sur le marché (30 % des projets (1)).
SAFe est un modèle beaucoup plus détaillé et normalisé que scrum of scrum ou Spotify. Ce modèle ne sera pas recommandé sur les petits projets car on lui reproche souvent d’être cher à mettre en place. Il semble être le plus poussé des frameworks d’agilité à l’échelle, avec un périmètre plus complet et plus large. Certains diront plus imposant car il nécessite la connaissance et la mise en place de nombreux concepts. Ce modèle définit et standardise les rôles, les plannings et les processus de synchronisation . D’ailleurs SAFe dit qu’il faut des personnes formées pour l’implémenter dans une entreprise. Les onze formations prévues pour chaque rôle attestent de la professionnalisation de ce framework et de ses enjeux commerciaux sur le marché de l’agilité à l’échelle. Des nouvelles version du framework sortent régulièrement (la version 5.0 vient de sortir What’s new in SAFe 5.0) cela lui permet d’évoluer et de profiter des nombreux retours d’expérience dont il bénéficie.
Le modèle essential SAFe (6)
Au niveau équipes, SAFe combine le framework Scrum, les meilleures pratiques XP et intègre complètement les pratiques DevOps dans un modèle nivelé en fonction de la dimension de votre projet et de vos équipes.
Plus globalement, il reprend les principes Lean-Agile appliqués à plusieurs niveaux de l’entreprise. Plus votre produit est complexe et plus vous aurez de couches à organiser.
La couche de base est le fameux Agile Release Train (ART) qui synchronise les différentes équipes Scrum (entre 50 et 125 personnes) au niveau programme. Au dessus le modèle prévoit la possibilité d’ajouter une couche large « Solution » pour la coordination de plusieurs “trains” en charge de solutions plus complexes et nécessitant des équipes encore plus nombreuses.
Le niveau “Portfolio” permet de connecter le portefeuille et la stratégie de l’entreprise, en définissant les flux de valeurs du portefeuille qui soutiennent l’exécution du programme et le développement agile. Enfin, le niveau “Full” SAFe est le plus complet car il combine ces trois couches. Il regroupe en général plusieurs centaines de personnes.
On peut donc implémenter SAFe par paliers pour commencer, par exemple avec le niveau “Essential”, puis “Solution” ou ‘Portfolio’ ou ‘Full’…si celà est nécessaire. Tout dépend de qui est concerné et surtout de la taille de l’équipe qui peut aller de 50 à 1000 personnes, le niveau Full SAFe étant moins courant sur le marché.
Le but est de mettre à chaque niveau de l’entreprise une organisation qui permet d’encadrer de manière Agile les équipes auto-organisées et de synchroniser toutes ces équipes efficacement en intégrant le management aux pratiques Lean-Agile.
SAFe insiste largement sur le fait que c’est LE framework qui est fait pour que les entreprises tournées vers le digital deviennent Lean-Agile. Il y a une toute une philosophie autour de ces concepts qui sont représentés par de nombreuses bonnes pratiques ou outils.
C’est un modèle beaucoup plus structuré que les autres approches répandues d’agilité à l’échelle. C’est le principal reproche qui lui est fait. On s’éloigne un peu de l’auto organisation des équipes et on revient un peu à un système avec des managers qui indiquent à leurs équipes comment “il faut faire”. Il présente l’avantage de rassurer les managers lors de transformations Agile car il permet plus de contrôle sur l’organisation des équipes.
Conclusion
Le choix d’un modèle d’agilité à l’échelle n’est évidemment pas une question fermée. Scrum of Scrum est apprécié pour sa facilité de mise en place. Une équipe Scrum peut passer en SoS d’un sprint à l’autre sans grand risque et avec peu d’investissements sur le sujet. Spotify est un modèle beaucoup plus adapté pour des équipes matures qui sauront créer leurs propres environnements Agiles mais il faudra pour cela que toute l’organisation les accompagne et que tout le monde ait le bon état d’esprit. SAFe est un mastodonte qui a largement fait ses preuves dans les grandes structures qui souhaitent passer à l’Agilité sur des services ou des projets importants. Il existe d’autres alternatives tels que DAD, Nexus, Less, Scrum@Scale, Rage, APM, …
Tous ces modèles ont leurs propres avantages et beaucoup d’entreprises créent leurs modèles “maison” à l’instar de Spotify. On voit que l’important est d’orienter son choix en fonction de l’entreprise où l’on se trouve.
N’oubliez pas le maître-mot du Lean Startup: “Fail Fast!” Prenez le modèle qui vous parle le plus mais ne soyez pas dogmatique à son sujet et critiquez sa mise en place afin de trouver un modèle qui convienne à votre entreprise.
Une société ayant une expérience importante sur des projets non Agiles aura du mal à se transformer radicalement vers un modèle Spotify du jour au lendemain. En cas de doutes, n’hésitez pas à faire appel à des coachs lors du passage à l’échelle ou lors de transformations Agiles, cela évitera certainement quelques déconvenues.
Le domaine du développement Informatique est soumis à beaucoup de changements et le marché de l’Agilité fait parfois les frais de sa notoriété. Les plus gros pièges à éviter sont :
- vouloir appliquer l’Agilité de manière dogmatique, sans écouter les retours des équipes,
- vouloir mener une transformation qui n’implique pas les personnes en dehors de l’équipe du projet
Auteur : Sébastien Leclerc (sebastien.leclerc@contentside.com) avec l’aide d’Ivan Boher (ivan.boher@contentside.com), consultants Agile chez ContentSide .
Références
Ce sujet vous intéresse ?