Passées les premières expérimentations des méthodes agiles au sein de l’entreprise avec un succès que l’on va qualifier de variable, d’aucuns se posent la question de comment aller plus loin, voire comment envisager une entreprise agile. Tous les architectes techniques vous le diront, il existe deux types de scalabilité quand on parle de serveur : la scalabilité verticale (augmenter les capacités du serveur) et horizontale (distribuer sur plusieurs serveurs). Il peut être intéressant d’utiliser cette métaphore lorsque l’on parle de diffuser l’agile plus largement.
Prenons le cas d’un projet où l’équipe de la DSI est en charge d’un développement en mode agile. Cette équipe composée de huit personnes fonctionne bien et se pose la question de comment aller plus loin. Les pratiques agiles supposent déjà d’améliorer l’environnement sur lequel on a la maitrise et c’est une étape essentielle. Mais rapidement, on est confronté à d’autres frontières qui vont finalement limiter les avantages de l’agile à un périmètre restreint, ici, l’équipe projet. Il est alors nécessaire de dépasser ces frontières pour aller plus loin. On peut recenser trois frontières souvent présentes dans les organisations :
Développer un logiciel avec une équipe agile sans le métier revient à construire un produit de qualité en respectant un cycle en V en livrant juste plus fréquemment. Pour permettre de profiter des promesses de l’agile (qualité, adaptabilité et gestion du risque), la participation du métier est essentielle. C’est en introduisant des rôles (le product owner), des pratiques agiles (les spécifications par les tests comme BDD) et en définissant clairement les droits et devoirs de chacun (« vous pouvez changer les priorités de développements mais rappelez-vous que nous sommes en budget contraint et donc que certaines fonctionnalités devront sortir du périmètre ») que la frontière peut être gommée.
Ensuite, développer un logiciel avec une équipe agile intégrant le métier sans la production revient à livrer fréquemment en environnement d’acceptance. Bref, le chemin est encore long vers un logiciel en production confronté à ses utilisateurs. C’est pourquoi l’envie de gommer cette frontière vient assez naturellement même s’il ne faut pas la prendre à la légère. En effet, les organisations ont passé ces 20 dernières années à cloisonner ces deux mondes. Beaucoup des solutions permettant de redéfinir cette frontière se cachent derrière le terme DevOps, qui regroupe des pratiques touchant l’architecture, les outils, la méthodologie et l’organisation, visant à améliorer la collaboration entre les études et la production. DevOps repose sur trois principes clés qui sont les garants d’une agilité allant jusqu’à la production:
Enfin, développer un logiciel avec une équipe agile intégrant le métier et la production revient à livrer un produit bien exécuté mais pas forcément le bon produit. La nuance se situe dans cette dernière frontière où la compréhension ou les hypothèses spécifiées par le métier peuvent être parfaitement exécutées par l’équipe tout en ne correspondant finalement pas aux attentes des utilisateurs. C’est dans certaines pratiques issues du milieu des startups (lean startup notamment) qu’une diminution de cette frontière est possible. Ces approches s’échinent à découvrir simultanément les utilisateurs et le produit afin d’en assurer la convergence. Ainsi, sur la base d’hypothèses ou d’idées, on commence à construire le produit que l’on va confronter aux utilisateurs afin de se rassurer qualitativement et valider quantitativement les hypothèses dans des itérations courtes propices à l’apprentissage.
Maintenant que notre équipe projet a pu, de façon itérative, dépasser ses frontières en projetant l’agilité sur tout son cycle projet et donc de changer d’échelle, essayons de transposer ces pratiques non pas à un projet mais à tous les projets de l’entreprise.
Si réaliser les étapes précédentes sur un projet représente déjà un challenge, l’opérer jusqu’à la gestion du portefeuille de projets est bien plus complexe mais c’est le chemin à suivre vers une entreprise agile en capacité à accepter le changement et à s’améliorer en continu. Les frontières en question, cette fois-ci, sont celles présentes entre chaque équipe projet et entre les différentes strates de gouvernance au-dessus de ces équipes. Gommer ces frontières va revenir à opérer simultanément sur toutes les constituantes de l’entreprise. Nous proposons une lecture de ces modifications au travers de cinq piliers :
Instruire une transition agile dans une entreprise revient donc à travailler sur ces cinq piliers en introduisant petit à petit les concepts jugés les plus pertinents.
Ces pratiques ont déjà été évoquées lorsque nous avons parlé de DevOps ou BDD. Il y en a bien d’autres pour la plupart introduites via l’ eXtreme Programming. Deux choses sont à retenir lorsque l’on parle d’agilité à large échelle. La première est que l’on a tout intérêt à diffuser les meilleures pratiques dans l’entreprise sans volonté de les imposer à tout prix. La deuxième est que certaines de ces pratiques sont obligatoires à moins de subir une montée en pression issue des changements opérés dans les autres piliers (notamment l’accélération des cycles). Trois pratiques paraissent obligatoires :
Quand on parle de processus autour de la gestion et du pilotage des projets, on les présente généralement sur trois niveaux, à savoir :
Trois frameworks dits agiles (DAD, LeSS, SaFE) tentent aujourd’hui, à l’instar d’un PMI sur la gestion de projet en V, de fournir une description de ces processus. Aujourd’hui SaFE porte plus de promesses dès que l’on remonte au niveau de la gestion de portefeuille. Qu’en est-il donc des processus dans ces trois niveaux ?
Coté gestion de projet, rien de très neuf, le processus décrit par SCRUM est aujourd’hui le plus couramment usité. On opère à la taille de la user story et on parle d’itération de deux semaines. Cependant d’autres méthodes existent avec notamment KANBAN issue du LEAN qui est plus difficile à digérer au démarrage mais plus à même de gérer une problématique de flux.
Coté gestion de programme, le processus est opéré à partir de la roadmap qui se décline en releases, on parle de fonctionnalités du programme et une release regroupe plusieurs itérations de multiple équipes. Les besoins de synchronisation sont évidents et sont adressés par la réunion des product owners de chaque équipe (assimilable à du SCRUM de SCRUM) accompagnés d’un directeur de programme ou plutôt product manager et d’un super coordinateur responsable du release management. D’autres éléments de cohérence sont assurés à ce niveau via des rôles transversaux d’architecte ou d’ergonome par exemple.
Enfin coté gestion de portefeuille, il s’agit finalement d’apporter des approches agiles au niveau des décideurs. On opère sur un portefeuille de projets a minima annuel où l’on pilote les investissements. La mise en place d’une gestion de portefeuille avec un processus en flux de type KANBAN peut permettre d’avoir une approche où on limite l’encours, où on se permet une re-priorisation bimestrielle tout en restant dans un environnement contraint. Une méthode de cadrage agressive (maximum deux mois) est un prérequis afin de pouvoir statuer rapidement sur l’instruction ou non des programmes.
Il ne semble finalement pas y avoir de révolution par rapport aux processus actuels. Cependant trois éléments sont notables. D’abord cela démontre la capacité à opérer à large échelle avec une approche agile. Ensuite la réduction des temps de cycle est présente à chaque étage ce qui est en vérité lourd d’impacts. Enfin, les changements qui peuvent paraître anodins sont amplifiés par leurs interactions avec les autres piliers.
Les transformations potentielles à opérer côté organisation sont fortement liées au postulat suivant : une équipe projet comprend de 5 à 12 collaborateurs. La sociologie a démontré qu’en dessous de cinq un groupe est trop dépendant des absences et qu’il manque de créativité. Au-delà de 12 personnes, les groupes ont tendance à se diviser et l’efficacité chute brutalement. Si l’on respecte ce postulat, la vraie question est d’identifier les clés de découpage. La première idée est de regrouper les personnes sous la forme de component team correspondant soit à un savoir-faire soit à une strate d’architecture. Cette organisation atteint ses limites lorsque les demandes métier touchent toutes les équipes de façon inégale tout en les noyant dans la synchronisation. Une deuxième idée, appelée feature team, va au contraire regrouper toutes les compétences nécessaires pour adresser une fonctionnalité même si cela nécessite de traverser toutes les strates d’architecture. Les risques d’incohérences inhérentes à cette organisation sont en partie adressés par des réunions de partage par spécialité appelées communauté de pratiques. C’est un mélange de ces deux modes d’organisation qui est observé dans les entreprises agiles avec un ratio de 80/20 entre feature et component team.
Les changements à opérer sur la dimension du produit ont déjà été explicités lorsque nous avons évoqué la première et la troisième frontière au début de cet article. Le vrai changement de paradigme résultant de l’instruction de ce pilier est le passage de la notion de projet vers la notion de produit (un projet a une fin, un produit pas nécessairement). Cette transformation a bien sûr un impact direct sur l’organisation et sur nos trois niveaux de processus.
Si les quatre piliers précédents semblent complexes à faire évoluer, la culture reste le pilier le plus difficile à adresser. Une culture d’entreprise est quelque chose qui s’est construit au fil du temps souvent à l’initiative des fondateurs de l’entreprise. Le changement de culture peut être à ce point traumatisant qu’il va potentiellement challenger les fondations même de l’entreprise. Illustrons cela au travers de quelques traits culturels forts qui sont partagés par des entreprises que l’on va qualifier d’avancées en terme d’agilité. Un premier trait se cache derrière le duo autonomie et responsabilité. C’est l’opposé des pratiques de type command and control. Ces entreprises ont abandonné les rôles de superviseur pour donner plus d’autonomie et de responsabilité aux opérateurs. L’autonomie et la responsabilité sont les qualités clés d’un système agile qui va au contraire péricliter dans un environnement de sur-contrôle, facteur de désengagement. Un autre trait de ces entreprises est la notion de coopération, au sens où la coopération est quelque chose qui fait mal, que la coopération signifie dégrader sa performance individuelle au profit de la performance globale. Une conséquence pratique observée dans ces entreprises est la suppression des objectifs ayant une portée locale et individuelle.
Voilà un aperçu rapide du chemin à parcourir pour tendre vers une entreprise agile ayant intégré la dimension changement à son ADN. L’entreprise agile, en vérité, est un concept à redéfinir pour chaque organisation selon son secteur d’activité, sa stratégie et son ADN. Chaque entreprise se lançant dans cette quête aura donc tout loisir de positionner les piliers les uns par rapports aux autres à la recherche d’une agilité et d’un équilibre qui lui sera propre.
Article préalablement publié dans le magazine ICTJournal du mois de Février 2014.