Les en­tre­prises face à l’agilité gé­né­ra­li­sée

Les en­tre­prises face à

L'Informaticien - - SOMMAIRE - ALAIN CLAPAUD

Presque 20 ans après la pu­bli­ca­tion de l’Agile Ma­ni­fes­to, toutes les di­rec­tions gé­né­rales veulent pou­voir an­non­cer que leur DSI a bas­cu­lé sur les « mé­thodes agiles » . Les géants du CAC 40 ri­va­lisent dans la com­mu­ni­ca­tion sur leurs stra­té­gies agiles. Pour­tant, der­rière les beaux dis­cours, le pas­sage à l’Agile At Scale reste un exer­cice dif­fi­cile… et la ré­volte des dé­ve­lop­peurs couve.

Àl’heure où toutes les grandes en­tre­prises mènent leur trans­for­ma­tion di­gi­tale, le pas­sage aux mé­thodes agiles semble un pré­re­quis né­ces­saire pour ac­cé­lé­rer le rythme des dé­ve­lop­pe­ments. So­cié­té Gé­né­rale,

Axa, Air France KLM, Air­bus, En­gie, Mi­che­lin, les pro­jets de pas­sage à l’Agile At Scale se mul­ti­plient dans le CAC40. Il ne s’agit plus seule­ment de faire bas­cu­ler la pe­tite équipe qui dé­ve­loppe les ap­pli­ca­tions mo­biles en sui­vant Scrum ou Kan­ban, mais bien de bas­cu­ler toute la DSI sur un mo­dèle agile à l’échelle de l’en­tre­prise, donc po­ten­tiel­le­ment des cen­taines d’équipes DevOps à faire tra­vailler en si­mul­ta­né. Sca­led Agile Fra­me­work ( SAFe), Nexus ou en­core [email protected] Scale et Large- Scale Scrum ( LeSS), de mul­tiples modèles sont ap­pa­rus afin de me­ner à bien ce pas­sage à l’échelle de l’agilité, mais ce chan­ge­ment d’or­ga­ni­sa­tion reste un dé­fi ma­jeur.

Pas simple de faire pas­ser l’agile à l’échelle

Lo­gi­que­ment, au- de­là des dis­cours triom­phants des di­rec­tions gé­né­rales, une trans­for­ma­tion or­ga­ni­sa­tion­nelle de telle am­pleur n’est pas sans risque et fait grin­cer des dents. De mul­tiples tri­bunes quelque peu dis­cor­dantes sont ap­pa­rues ces der­niers mois sur le Web, is­sues de dé­ve­lop­peurs, mais aus­si par­fois d’ex­perts en mé­thodes agiles. « De­ve­lo­pers Should Aban­don Agile » , de Ron Jef­fries ; « Stop de­li­ve­ring soft­ware with Agile – it doesn’t work » , de James Whit­man ; « Why Agile and es­pe­cial­ly Scrum are ter­rible » , de Michael O. Church… Toutes ces tri­bunes montrent que l’Agile at Scale, c’est- à- dire l’agilité à l’échelle d’une DSI de plu­sieurs cen­taines voire mil­liers d’in­for­ma­ti­ciens, est loin d’être un sport de masse. Ain­si, un coach

agile confie : « Des cas d’im­plé­men­ta­tion réel­le­ment réus­sis de SAFe en France, je n’en connais aucun ! L’agilité est de­ve­nue un vec­teur de com­mu­ni­ca­tion des en­tre­prises et, même nous, qui sommes au coeur des dis­po­si­tifs agiles, nous ré­agis­sons par­fois mal à ces plans de com­mu­ni­ca­tion. La réa­li­té du ter­rain chez les grands comptes dif­fère par­fois de la com­mu­ni­ca­tion qui est faite au­tour des pro­jets. » Des en­tre­prises qui animent des confé­rences sur leur ex­pé­rience réussie de trans­for­ma­tion vers l’agile alors que les équipes ont le plus grand mal à fonc­tion­ner, il semble que ce soit un scé­na­rio fré­quent. « Mon anec­dote préférée que j’ob­serve chez des clients, c’est les équipes qui ont un ta­bleau de sui­vi – Scrum ou Kan­ban –, mais qui ne com­prennent pas comment le ta­bleau fonc­tionne » , ex­plique cet autre coach. « S’ils ont un ta­bleau blanc, c’est que leur pa­tron leur a de­man­dé d’en faire un parce que pour eux, c’est ça être Agile… » Cer­taines DSI s’at­tachent à dres­ser un ri­deau de fu­mée de­vant les couacs de leur stra­té­gie agile. « Dans une en­tre­prise que je connais, une grosse ini­tia­tive de trans­for­ma­tion a été lan­cée il y a en­vi­ron sept ans » , évoque ce coach agile. « Ils avaient beau­coup in­ves­ti sur un gros pro­jet avec plu­sieurs cen­taines de per­sonnes im­pli­quées. La culture d’en­tre­prise n’était pas por­tée sur la transparen­ce et per­sonne n’osait dire que le pro­jet était en re­tard à la di­rec­tion. On parle d’un pro­jet de près de 10 mil­lions d’eu­ros… Un mois avant la date de livraison, il n’était plus

pos­sible de cacher que le pro­jet al­lait être en re­tard. Seuls 20 % du dé­ve­lop­pe­ment avait été com­plé­té. Il a fal­lu que l’en­tre­prise ajoute quelques mil­lions l’an­née sui­vante afin que le pro­jet puisse être en me­sure de li­vrer un mi­ni­mum de fonc­tion­na­li­tés utiles. »

N’est pas Spo­ti­fy qui veut !

Lo­gi­que­ment, le risque d’échec est pro­por­tion­nel à l’am­pleur de la stra­té­gie agile de l’en­tre­prise. Dé­jà, en 2015, l’étude CHAOS Re­port du Stan­dish Group poin­tait un taux d’échec di­rec­te­ment pro­por­tion­nel à l’am­pleur du pro­jet et les quelques en­tre­prises pion­nières des mé­thodes agiles qui ont ten­té d’étendre leur ini­tia­tive à l’échelle de la DSI ont connu des dé­boires. Ain­si, ING fut l’une des pre­mières banques à mi­ser sur l’agilité pour ga­gner en ré­ac­ti­vi­té, avec les pre­mières équipes mon­tées dès 2010 et une gé­né­ra­li­sa­tion à l’échelle de la DSI en­ga­gée en 2011 n’a pas atteint les ré­sul­tats es­comp­tés car les mé­tiers n’étaient pas im­pli­qués dans cette trans­for­ma­tion. En 2015, la banque néer­lan­daise choi­sis­sait de co­pier le mo­dèle Spo­ti­fy en tr ibus/ squads/ équipes pro­duits et cha­pitres pour re­lan­cer sa stra­té­gie agile. Ces pro­jets d’agilité à l’échelle font ap­pa­raître les dif­fi­cul­tés liées aux mé­thodes agiles dans les en­tre­prises dont le di­gi­tal n’est pas la fi­na­li­té. Stand- up mee­tings, li­vrai­sons de code en conti­nu bous­culent les in­for­ma­ti­ciens mais aus­si les mé­tiers qui peuvent re­fu­ser la lo­gique de devoir ac­cep­ter un MVP

( Mi­ni­mal Viable Pro­duct) qui ne cor­res­pond pas à leurs at­tentes. À ce jeu, même un géant tel que Google peut échouer comme ce fut le cas avec Google Wave. La ver­sion be­ta n’a pas sé­duit les ear­ly adop­ters qui devaient jouer le rôle d’évan­gé­listes pour le ser­vice et ce­lui- ci n’a ja­mais dé­col­lé. Il est im­por­tant que les pre­mières évo­lu­tions pré­sentent dé­jà suf­fi­sam­ment de fonc­tions clés pour que les uti­li­sa­teurs ne s’en dé­tournent pas.

Faut- il vrai­ment dé­ve­lop­per des ap­pli­ca­tions sans fin ?

Dans un fonc­tion­ne­ment à la Spo­ti­fy, le dé­ve­lop­pe­ment des ap­pli­ca­tions n’est théo­ri­que­ment ja­mais ache­vé et conti­nue à ité­rer sans fin. Cette ap­proche est ac­cep­tée par les uti­li­sa­teurs de Fa­ce­book, Gmail ou Twit­ter, mais peut- elle l’être pour un ERP, un lo­gi­ciel de pi­lo­tage de ma­chine ou­til ? Les édi­teurs Saas comme Sa­les­force. com, Ser­vi­ceNow, SAP ou Oracle pous sent for­te­ment en ce sens, mais est- ce un mo­dèle te­nable ad vitam ae­ter­nam pour une en­tre­prise dont le coeur de mé­tier n’est jus­te­ment pas d’être un éditeur de lo­gi­ciels ? « J’ai ré­cem­ment ren­con­tré un DSI qui, après le pas­sage à l’agile, se fé­li­ci­tait de ce que ses pro­jets ne dé­ri­vaient plus dans le temps… » , ra­conte David Feld­man, un spécialist­e dans l’ana­lyse des causes de dé­rives et d’échec des pro­jets in­for­ma­tiques. « Ses pro­jets ne dé­ri­vaient plus, mais ils ne se ter­minent ja­mais non plus ! Dès le dé­but des an­nées 2000, nous avons eu des pro­jets RAD, donc dé­ve­lop­pés sur une mé­thode ité­ra­tive, qui sont par­tis en conten­tieux car si les mé­thodes sont agiles, les hommes le sont tout au­tant pour dé­tour­ner les mé­thodes. En dé­pit de la mé­thode ité­ra­tive choi­sie, on a une perte de maî­trise du pé­ri­mètre fonc­tion­nel tout comme c’était le cas avec une mé­thode en V. » En outre, quelle di­rec­tion mé­tier sou­hai­te­rait brû­ler son budget pour, non pas dé­ve­lop­per une ap­pli­ca­tion mo­bile pour ses clients, mais fi­nan­cer le re­nou­vel­le­ment de li­cences Win­dows Ser­ver sur l’in­fra­struc­ture, ou ré­no­ver une in­fra­struc­ture de sto­ckage ?, ce qui à court terme ne lui ap­porte aucun avan­tage com­pé­ti­tif… Outre cette pro­blé­ma­tique de la dette tech­nique, de nom­breux points d’achop­pe­ment doivent être ré­so­lus pour que ces stra­té­gies fonc­tionnent, no­tam­ment le be­soin de main­te­nir des ar­chi­tec­tures IT co­hé­rentes ou ce­lui de la syn­chro­ni­sa­tion du tra­vail de plu­sieurs di­zaines d’équipes agiles au sein d’un même pro­jet.

Pas simple de me­ner un pro­jet au for­fait en environnem­ent agile

L’agile re­met aus­si en cause les re­la­tions entre DSI et pres­ta­taires, no­tam­ment sur les pro­jets au for­fait. En met­tant les uti­li­sa­teurs dans la boucle de dé­ve­lop­pe­ment, les pres­ta­taires prennent le risque de dé­rives et donc de dé­pas­se­ment de budget comme l’ex­plique David Feld­man : « La perte de maî­trise du pé­ri­mètre fonc­tion­nel

est une cause de dé­rive que l’on re­trouve très fré­quem­ment dans les pro­jets in­for­ma­tiques et elle est d’au­tant plus grave que l’on est dans un contrat au for­fait. Avec les mé­thodes agiles, le pé­ri­mètre de­vient mou­vant ; toute l’économie du pro­jet et du contrat tombe. » Le pres­ta­taire au for­fait va frei­ner des quatre fers pour ne pas se lais­ser em­bar­quer par les uti­li­sa­teurs vers des dé­ve­lop­pe­ments qui vont man­ger sa marge et mé­ca­ni­que­ment bri­der l’in­té­rêt des mé­thodes agiles d’avoir une ap­pli­ca­tion qui converge pe­tit à pe­tit vers les be­soins réels des uti­li­sa­teurs. Face à ces dif­fi­cul­tés, la ten­dance est donc à ré­in­ter­na­li­ser les équipes de dé­ve­lop­pe­ments pour les faire pas­ser en DevOps et le té­lé­tra­vail, ou même l’off­shore, semble po­ser des pro­blèmes aux DSI. Pionnier de la dé­lo­ca­li­sa­tion, IBM a de­man­dé en 2017 à des mil­liers d’em­ployés qui étaient en té­lé­tra­vail aux États- Unis de re­ve­nir tra­vailler dans des « Agile Hubs » . L’objectif était alors pour rap­pro­cher phy­si­que­ment les équipes à l’oc­ca­sion du pas­sage à l’agile à l’échelle et fa­ci­li­ter le tra­vail col­la­bo­ra­tif. Cette volte- face a coû­té 380 mil­lions de dol­lars à IBM pour mettre en places ces Agile Hubs. De grandes en­tre­prises fran­çaises ont adop­té une dé­marche as­sez si­mi­laire de créa­tion de pôle agile dans des locaux de type WeWork, plus pro­pices à l’in­no­va­tion que les open space vieillis­sants des sièges so­ciaux.

Comment gé­rer le mid- ma­na­ge­ment ?

Se ré­in­ven­ter en start- up n’a rien d’évident pour une en­tre­prise du CAC 40 et le ma­na­ge­ment doit, lui aus­si, se mettre à la page. « Il faut avoir un vrai cou­rage RH pour re­tou­cher la pile ma­na­gé­riale de l’or­ga­ni­sa­tion, avoir la vo­lon­té de re­mettre en cause les pré­ro­ga­tives du ma­na­ge­ment in­ter­mé­diaire no­tam­ment » , soutient Stéphane Mon­not- Bou­drant, Coach Agile Se­nior. « Si l’agilité fait par­tie de l’ADN des start- up, chez les grands comptes où, pen­dant des an­nées, les dé­ve­lop­peurs n’avaient pas le droit d’émettre une opinion sur le pro­duit qu’ils dé­ve­lop­paient, fai­saient par­fois face à un ma­na­ge­ment ul­tra au­to­ri­taire, voire un ma­na­ge­ment par la ter­reur, l’agile per­met de li­bé­rer des éner­gies. L’agile ap­porte un gain im­mé­diat, mais lors­qu’on veut al­ler au- de­là de Kan­ban ou Scrum, so what ? C’est là où les pro­jets agiles échouent. » Si, pour l’en­semble des coachs agiles il ne faut pas prendre les mé­thodes agiles au pied de la lettre mais les adap­ter au contexte de chaque en­tre­prise, le manque d’agilité des or­ga­ni­sa­tions des en­tre­prises fran­çaises et des hommes eux- mêmes est poin­té comme le prin­ci­pal fac­teur d’échec. Le poids des hié­rar­chies joue contre l’agilité et si, bien évi­dem­ment, un spon­sor­ship fort de la di­rec­tion gé­né­rale est in­dis­pen­sable, ce sont bien les couches in­ter­mé­diaires, très pré­sentes dans cer­tains sec­teurs qui peinent le plus à trou­ver leur place dans une or­ga­ni­sa­tion agile et com­pliquent sé­rieu­se­ment la marche des en­tre­prises vers l’agilité. ❍

L’agilité pose la ques­tion de l’écla­te­ment géo­gra­phique des équipes et de comment faire fonc­tion­ner une équipes DevOps si les dé­ve­lop­peurs sont dans un centre off­shore, les ad­mi­nis­tra­teurs sys­tème/ ré­seau au siège ? Les coachs agiles es­timent que les ou­tils col­la­bo­ra­tifs peuvent ef­fa­cer les dis­tances, mais en pra­tique beau­coup d’en­tre­prises pré­fèrent un rap­pro­che­ment phy­sique des équipes pro­duit.

Le pas­sage à l’agile à l’échelle im­plique de mettre en place une nou­velle or­ga­ni­sa­tion de la DSI, dé­sor­mais or­ga­ni­sées en équipes/ squad/ tri­bues, cha­pitres ou guildes. Ce mo­dèle « à la Spo­ti­fy » est ac­tuel­le­ment dé­ployé avec plus ou moins de suc­cès chez plu­sieurs opé­ra­teurs de té­lé­com, banques et as­su­reurs fran­çais.

Pion­nière des mé­thodes agiles dès le dé­but des an­nées 2010, la banque ING est l’une des rares grandes en­tre­prises à avoir évo­qué pu­bli­que­ment ses dif­fi­cul­tés à ti­rer pro­fit des mé­thodes agiles.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.