Pas simple de faire passer l’agile à l’échelle
Logiquement, au-delà des discours triomphants des directions générales, une transformation organisationnelle de telle ampleur n’est pas sans risque et fait grincer des dents. De multiples tribunes quelque peu discordantes sont apparues ces derniers mois sur le Web, issues de développeurs, mais aussi parfois d’experts en méthodes agiles. « Developers Should Abandon Agile », de Ron Jeffries ; « Stop delivering software with Agile – it doesn’t work », de James Whitman ; « Why Agile and especially Scrum are terrible », de Michael O. Church… Toutes ces tribunes montrent que l’Agile at Scale, c’est-à-dire l’agilité à l’échelle d’une DSI de plusieurs centaines voire milliers d’informaticiens, est loin d’être un sport de masse. Ainsi, un coach agile confie : « Des cas d’implémentation réellement réussis de SAFe en France, je n’en connais aucun ! L’agilité est devenue un vecteur de communication des entreprises et, même nous, qui sommes au cœur des dispositifs agiles, nous réagissons parfois mal à ces plans de communication. La réalité du terrain chez les grands comptes diffère parfois de la communication qui est faite autour des projets. » Des entreprises qui animent des conférences sur leur expérience réussie de transformation vers l’agile alors que les équipes ont le plus grand mal à fonctionner, il semble que ce soit un scénario fréquent. « Mon anecdote préférée que j’observe chez des clients, c’est les équipes qui ont un tableau de suivi – Scrum ou Kanban –, mais qui ne comprennent pas comment le tableau fonctionne », explique cet autre coach. « S’ils ont un tableau blanc, c’est que leur patron leur a demandé d’en faire un parce que pour eux, c’est ça être Agile… » Certaines DSI s’attachent à dresser un rideau de fumée devant les couacs de leur stratégie agile. « Dans une entreprise que je connais, une grosse initiative de transformation a été lancée il y a environ sept ans », évoque ce coach agile. « Ils avaient beaucoup investi sur un gros projet avec plusieurs centaines de personnes impliquées. La culture d’entreprise n’était pas portée sur la transparence et personne n’osait dire que le projet était en retard à la direction. On parle d’un projet de près de 10 millions d’euros… Un mois avant la date de livraison, il n’était plus possible de cacher que le projet allait être en retard. Seuls 20 % du développement avait été complété. Il a fallu que l’entreprise ajoute quelques millions l’année suivante afin que le projet puisse être en mesure de livrer un minimum de fonctionnalités utiles.»
Le passage à l’agile à l’échelle implique de mettre en place une nouvelle organisation de la DSI, désormais organisées en équipes/squad/tribus, chapitres ou guildes. Ce modèle « à la Spotify » est actuellement déployé avec plus ou moins de succès chez plusieurs opérateurs de télécom, banques et assureurs français.
N’est pas Spotify qui veut !
Logiquement, le risque d’échec est proportionnel à l’ampleur de la stratégie agile de l’entreprise. Déjà, en 2015, l’étude CHAOS Report du Standish Group pointait un taux d’échec directement proportionnel à l’ampleur du projet et les quelques entreprises pionnières des méthodes agiles qui ont tenté d’étendre leur initiative à l’échelle de la DSI ont connu des déboires. Ainsi, ING fut l’une des premières banques à miser sur l’agilité pour gagner en réactivité, avec les premières équipes montées dès 2010 et une généralisation à l’échelle de la DSI engagée en 2011 n’a pas atteint les résultats escomptés car les métiers n’étaient pas impliqués dans cette transformation. En 2015, la banque néerlandaise choisissait de copier le modèle Spotify en tribus/squads/ équipes produits et chapitres pour relancer sa stratégie agile. Ces projets d’agilité à l’échelle font apparaître les difficultés liées aux méthodes agiles dans les entreprises dont le digital n’est pas la finalité. Stand-up meetings, livraisons de code en continu bousculent les informaticiens mais aussi les métiers qui peuvent refuser la logique de devoir accepter un MVP (Minimal Viable Product) qui ne correspond pas à leurs attentes. À ce jeu, même un géant tel que Google peut échouer comme ce fut le cas avec Google Wave. La version beta n’a pas séduit les early adopters qui devaient jouer le rôle d’évangélistes pour le service et celui-ci n’a jamais décollé. Il est important que les premières évolutions présentent déjà suffisamment de fonctions clés pour que les utilisateurs ne s’en détournent pas.Faut-il vraiment développer des applications sans fin ?
Dans un fonctionnement à la Spotify, le développement des applications n’est théoriquement jamais achevé et continue à itérer sans fin. Cette approche est acceptée par les utilisateurs de Facebook, Gmail ou Twitter, mais peut-elle l’être pour un ERP, un logiciel de pilotage de machine outil ? Les éditeurs Saas comme Salesforce.com, ServiceNow, SAP ou Oracle poussent fortement en ce sens, mais est-ce un modèle tenable ad vitam aeternam pour une entreprise dont le cœur de métier n’est justement pas d’être un éditeur de logiciels ? « J’ai récemment rencontré un DSI qui, après le passage à l’agile, se félicitait de ce que ses projets ne dérivaient plus dans le temps… », raconte David Feldman, un spécialiste dans l’analyse des causes de dérives et d’échec des projets informatiques. « Ses projets ne dérivaient plus, mais ils ne se terminent jamais non plus ! Dès le début des années 2000, nous avons eu des projets RAD, donc développés sur une méthode itérative, qui sont partis en contentieux car si les méthodes sont agiles, les hommes le sont tout autant pour détourner les méthodes. En dépit de la méthode itérative choisie, on a une perte de maîtrise du périmètre fonctionnel tout comme c’était le cas avec une méthode en V. » En outre, quelle direction métier souhaiterait brûler son budget pour, non pas développer une application mobile pour ses clients, mais financer le renouvellement de licences Windows Server sur l’infrastructure, ou rénover une infrastructure de stockage ?, ce qui à court terme ne lui apporte aucun avantage compétitif… Outre cette problématique de la dette technique, de nombreux points d’achoppement doivent être résolus pour que ces stratégies fonctionnent, notamment le besoin de maintenir des architectures IT cohérentes ou celui de la synchronisation du travail de plusieurs dizaines d’équipes agiles au sein d’un même projet.Pas simple de mener un projet au forfait en environnement agile
L’agile remet aussi en cause les relations entre DSI et prestataires, notamment sur les projets au forfait. En mettant les utilisateurs dans la boucle de développement, les prestataires prennent le risque de dérives et donc de dépassement de budget comme l’explique David Feldman : « La perte de maîtrise du périmètre fonctionnel est une cause de dérive que l’on retrouve très fréquemment dans les projets informatiques et elle est d’autant plus grave que l’on est dans un contrat au forfait. Avec les méthodes agiles, le périmètre devient mouvant ; toute l’économie du projet et du contrat tombe. » Le prestataire au forfait va freiner des quatre fers pour ne pas se laisser embarquer par les utilisateurs vers des développements qui vont manger sa marge et mécaniquement brider l’intérêt des méthodes agiles d’avoir une application qui converge petit à petit vers les besoins réels des utilisateurs.
Pionnière des méthodes agiles dès le début des années 2010, la banque ING est l’une des rares grandes entreprises à avoir évoqué publiquement ses difficultés à tirer profit des méthodes agiles.
Face à ces difficultés, la tendance est donc à réinternaliser les équipes de développements pour les faire passer en DevOps et le télétravail, ou même l’offshore, semble poser des problèmes aux DSI. Pionnier de la délocalisation, IBM a demandé en 2017 à des milliers d’employés qui étaient en télétravail aux États-Unis de revenir travailler dans des « Agile Hubs ». L’objectif était alors pour rapprocher physiquement les équipes à l’occasion du passage à l’agile à l’échelle et faciliter le travail collaboratif. Cette volte-face a coûté 380 millions de dollars à IBM pour mettre en places ces Agile Hubs. De grandes entreprises françaises ont adopté une démarche assez similaire de création de pôle agile dans des locaux de type WeWork, plus propices à l’innovation que les open space vieillissants des sièges sociaux.
Comment gérer le mid-management ?
Se réinventer en start-up n’a rien d’évident pour une entreprise du CAC 40 et le management doit, lui aussi, se mettre à la page. « Il faut avoir un vrai courage RH pour retoucher la pile managériale de l’organisation, avoir la volonté de remettre en cause les prérogatives du management intermédiaire notamment », soutient Stéphane Monnot-Boudrant, Coach Agile Senior. « Si l’agilité fait partie de l’ADN des start-up, chez les grands comptes où, pendant des années, les développeurs n’avaient pas le droit d’émettre une opinion sur le produit qu’ils développaient, faisaient parfois face à un management ultra autoritaire, voire un management par la terreur, l’agile permet de libérer des énergies. L’agile apporte un gain immédiat, mais lorsqu’on veut aller au-delà de Kanban ou Scrum, so what ? C’est là où les projets agiles échouent. » Si, pour l’ensemble des coachs agiles il ne faut pas prendre les méthodes agiles au pied de la lettre mais les adapter au contexte de chaque entreprise, le manque d’agilité des organisations des entreprises françaises et des hommes eux-mêmes est pointé comme le principal facteur d’échec. Le poids des hiérarchies joue contre l’agilité et si, bien évidemment, un sponsorship fort de la direction générale est indispensable, ce sont bien les couches intermédiaires, très présentes dans certains secteurs qui peinent le plus à trouver leur place dans une organisation agile et compliquent sérieusement la marche des entreprises vers l’agilité. ❍
« L’agilité n’est pas la fin, mais le moyen »
Stéphane Monnot-Boudrant, Coach Agile Senior
« Les méthodes agiles sont une source d’inspiration, bien entendu, mais il ne faut aller vers l’agile de manière autoritaire et avec prosélytisme. Le garde-fou doit être le pragmatisme et l’efficacité. Il faut mettre la performance et l’humain au centre de la démarche et avoir une démarche sélective, retenir ce qui nous semble pertinent dans telle ou telle méthode, sans imposer un framework de manière aveugle. Il faut partir de la culture de l’entreprise, respecter son histoire, son métier et essayer de lui donner des outils, des pratiques pour expérimenter sur des optimaux locaux ou un changement dans une dynamique de type juste assez, juste à temps. Former une organisation à Scrum ne sert à rien si on ne trouve pas du sens, on n’insuffle pas de maîtrise et de l’autonomie aux équipes. Si on ne le fait pas, la transformation n’est pas pérenne et dès lors les coachs agiles s’en vont, le dispositif boit la tasse. »
« Des DSI commencent à culpabiliser de ne pouvoir appliquer les méthodes agiles chez eux ! »
David Feldman, fondateur de DFC Partners
« Ce que développent les GAFA en méthodes agiles ne correspond pas à ce que développent nos entreprises. Celles-ci ont besoin d’applications qui doivent être déployées sur le terrain afin de mener à bien leurs processus. Elles ont besoin de déployer des ERP et pas uniquement besoin de réseaux sociaux ou d’applications mobiles ! Elles ont besoin d’applications finies et stabilisées. Beaucoup de DSI commencent à culpabiliser de ne pouvoir appliquer les méthodes agiles chez eux, car c’est devenu un signe de modernité, de capacité d’innovation pour les entreprises. L’intégration d’un ERP avec ses processus rigides, ce n’est pas un projet agile : si on prend un projet de refonte d’une application métier, c’est a priori un projet taillé pour l’agilité, mais si le projet n’est qu’une refonte d’un logiciel spécifique existant sur une nouvelle plate-forme, les méthodes agiles ne servent absolument à rien. Au contraire, l’agilité peut devenir un piège, car on va fonctionner dans des sprints qui laisseront la possibilité au client de faire des demande qui iront au-delà de l’existant, or si le projet est au forfait, le budget va être consommé avant la fin du portage. »
« Il faut savoir donner un sens à cette transformation vers l’agilité »
Steffan Surdek, conseiller et formateur Agile chez Pyxis Technologies
« Avant d’engager le déploiement des méthodes à grande échelle dans son organisation, l’entreprise doit se poser la question du pourquoi adopter des approches agiles ?, et comment est-ce que cette transformation peut aussi faire partie du quotidien des gens ? Si la transformation est un projet à côté, personne n’aura du temps à mettre dessus. Dans une équipe que j’ai accompagnée il y a quelques années, c’est exactement ce qui est arrivé. La transformation était un projet à côté et le quotidien consommait tout le temps des gens. C’est quand on a donné un sens à ce que l’on faisait – dans ce cas que cette équipe redevienne crédible dans l’organisation – que tout a basculé dans le bon sens. Nous avons adopté des pratiques agiles mais dans le but de devenir plus crédibles, prévisibles, de bâtir des relations avec les gens autour de nous… Il y avait un sens à ce que nous faisions, donc ça ne devenait pas juste le projet d’un gestionnaire ou de la direction, c’était le projet d’une équipe tout entière de huit personnes. »