Agilité d’entreprise : Voici comment nous travaillerons demain
Billet original sur LinkedIn (republié avec l’autorisation de Marc-Noël Fauvel que je remercie)
L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP .
Aujourd’hui, alors qu’elles montent en maturité, les entreprises qui développent leur SI de façon agile sont confrontées à un double plafond qui limite leur capacité à démultiplier leur performance:
1. les projets de développement deviennent de plus en plus importants ; La synchronisation de nombreuses équipes de développement devient de plus en plus complexe et les coûts de transaction rattrapent les coûts de développement. SCRUM n’a qu’une réponse partielle à cette problématique à travers son SCRUM-of-SCRUMS, mais qui reste très conceptuel.
Résultat : plus l’entreprise grossit, plus elle ralentit ;
2. les équipes agiles qui ont acquis une vélocité soutenable, sont contraintes par les prises de décision et les mécanismes de financement qui eux, ne sont pas du tout agiles. L’environnement de l’équipe agile devient alors un frein à la vitesse acquise.
Résultat : plus on cherche à aller vite, plus on est freiné.
Les entreprises ont donc aujourd’hui de réelles difficultés à percer ce plafond de performance. Il faudrait un référentiel qui démultiplie l’organisation agile existant aujourd’hui dans les équipes à travers toute l’entreprise. On parle de référentiel « scalable », car il doit permettre d’être extrapolé quel que soit la taille des projets de développement : 10, 50, 200, 1000 personnes développant les applications en mode Agile.
Ce référentiel, c’est SAFe® (www.scaledagileframework.com)
SAFe® est une réponse d’une grande élégance à la problématique de la scalabilité agile en entreprise. Ce référentiel s’articule en 3 (ou 4) couches :
1. la couche « Team »
Dans XP/SCRUM, on retrouve l’équipe de développement avec ses deux rôles pivot : le Scrum Master et le Product Owner. La « Team » implémente des incréments de fonctionnalités sur la base de User Stories.
2. la couche « Program »
Avec le SCRUM of SCRUMS, on trouve de nouveaux rôles qui ont pour objectif de coordonner n Teams contribuant à un même programme. On parle d’Agile Release Train (ART®) qui délivre des incréments de systèmes (agrégation de n incréments de fonctionnalités). Les rôles décrits ici sont le Product Manager (leader des Product Owners), le System Architect/engineer, et le responsable du Train de Release, le RTE® (Release Train Engineer) leader des Scrum Masters. La taille d’un ART® est supposée comprise entre 50 et 125 développeurs.
3. la couche « Value Stream » (optionnelle)
Elle est adossée aux principes du Lean management et a pour objectif de synchroniser les différents trains ART®, de façon à livrer des incréments de Solutions à un client final. Une Value Stream peut synchroniser de 2 à 10 ARTs® (ce qui signifie des équipes de 100 à 1250 personnes).
4. la couche « Portfolio »
Elle rend agile la prise de décisions liées aux investissements, permet la priorisation des epics (histoires de haut niveau décrivant les attendus macro) et abonde aux budgets, eux-mêmes associés aux Value Streams. Grâce à ce niveau, les décisions sont fluidifiées et associées aux flux de valeur à destination directe des clients.
Cet édifice est construit autour de principes très structurants, liés à une approche Lean-Agile permanente.
Des implémentations de SAFe® sont opérationnelles depuis plusieurs années maintenant, mais les entreprises qui utilisent SAFe® ne communiquent pas toujours sur leurs retours d’expérience : certaines considèrent en effet l’adoption de SAFe® comme étant un avantage concurrentiel tant les effets positifs sont rapides et puissants.
Il ne fait aucun doute que les entreprises vont basculer progressivement vers ce référentiel. De nombreuses très grandes entreprises l’ont déjà fait : Microsoft, Air France-KLM, Philips, Astra-Zeneca, SwissCom, HP, Cisco, Pôle emploi, Intel, Sony Interactive, etc….
à quand votre tour ?
DantotsuPM.com 