De la théorie à la pratique : intérêts et limites de la méthode agile
Les Directions des Systèmes d'Information désignées comme porteurs du sujet Agile dans les grands Groupe
Durant la crise sanitaire de 2020, les Directions des Systèmes d’Information (DSI) ont été fortement sollicitées pour accélérer la numérisation.
Cette fonction orientée sur l’innovation numérique, la rationalisation des coûts, l’exploitation de la donnée et la sécurité, a dû repenser l’expérience digitale des collaborateurs et faire preuve de plus d’agilité.
La méthode Agile a d’ailleurs été plébiscitée par les dirigeants des grands groupes après la gestion de la crise et s’en sont suivis des investissements humains, technologiques et financiers importants :
- création de services partagés, tels que des CoE (Agile Center of Excellence) ou des départements regroupant tous les Product Owner de l’organisation
- mise en place d’outils pour faciliter les échanges (ProductBoard, Mural, Jira Altassian, Teams etc.),
- recrutement de rôles Agiles : coach Agile, scrum master, team tech lead, solution architect, product owner, proxi po, product specialist, dev team par exemple.
Les DSI ont donc fait face à un nouveau défi organisationnel et opérationnel avec la méthode Agile comme nouveau mode de travail.
L’intérêt de cette méthode réside essentiellement dans l’accélération de la livraison de nouvelles fonctionnalités :
- en dépassant facilement les silos ;
- en adoptant une méthodologie avec des sprints, fenêtres de travail et moteur principal de l’équipe, qui permettent plus de souplesse et de réactivité par le biais des livraisons partielles ;
- en mettant en avant, la capacité de l’équipe à recontextualiser le besoin client en fonction des évolutions marchés et d’itérer sur des demandes initiales, à l’inverse des méthodes avec cycles en v, qui prônent une vision plus long terme avec une livraison complète.
La méthode Agile devrait de ce fait permettre aux DSI d’être plus flexibles quant à l’évolution de leurs produits internes et/ou externes.
Les DSI sont souvent les plus impliquées parmi les services de leur organisation, non seulement parce qu’elles travaillent traditionnellement en mode projet, recherchent sans cesse la modernisation de leurs infrastructures et méthodes de travail, mais également parce qu’elles bénéficient des méthodes et des outils pour réussir.
Focus sur le flux d'amélioration VS la maintenance dans un contexte de méthode agile
Lorsqu’il s’agit de gestion de produits au sein des DSI, deux flux de mise en production coexistent.
- Le flux d’amélioration / évolution lié à des améliorations demandées par le client : on parle de développement ou « build » ;
- Le flux de maintenance pour des corrections suite à la découverte d’une anomalie ou des copies de données : on parle de maintenance ou « run ».
Dans les grandes organisations informatiques, assurer un suivi rigoureux et efficace ne peut être envisagé sans outil de suivi des demandes (« ticketing »). Mais surtout, elles doivent définir les processus qui les accompagnent et mettre en place la bonne gouvernance de ces demandes.
D’un point de vue organisationnel, deux cas de figure peuvent être considérés :
Organisation | L’équipe agile prend en charge l’amélioration mais pas le support | L’équipe agile prend en charge l’amélioration et le support | ||
Produit | Solution éditeur (Third Party) | Solution maison (In-House) | ||
Livraisons | Flux amélioration | Flux maintenance | Un flux unique amélioration + maintenance | |
Responsables de la livraison | L’équipe agile | L’équipe support | L’équipe agile | |
Fréquence / Horizon de planification | Ponctuel/ au moins 1 an | Récurrent | Récurrent/ au moins 1 an | |
Avantages | Maitrise des rôles et responsabilités.
Souplesse au niveau de la mise en production des correctifs.
Focus de l’équipe agile sur la livraison des améliorations produit.
Bonne satisfaction des end users. | Maitrise du scope des livraisons. Pas de surcoût (les ressources peuvent avoir plusieurs casquettes, par exemple: support analyst et développeur)
| ||
Inconvénients | Coût humain et financier | Mix des sujets support et amélioration durant les cérémonies agiles.
Impact sur la prédictibilité et la vélocité de l’équipe (KPIs majeurs en agile).
Ralentissement des itérations d’amélioration. Manque de flexibilité lié au planning de release.
Satisfaction end user fragilisée par manque de flexibilité sur les livraisons de correctifs. | ||
Retour d'expérience client
Quelques points de difficultés ont été observés chez un client, voici quelques conseils pour les contourner :
Contexte
Dans le cadre d’un plan de transformation global, une DSI reçoit comme objectif de repenser l’organisation de ses équipes pour appliquer les méthodes Agile.
Problème rencontré
Ces sujets étant nouveaux, les DSI investissent beaucoup de temps sur la méthode (comment) et moins sur le fond (quoi et quand). Les équipes doivent parfois se créer et s’affecter des tâches à faible valeur ajoutée pour permettre à leurs managers de suivre les activités et temps passés. On retombe alors dans des processus très lourds qui contraignent les équipes à dire ce qu’ils vont faire, plutôt que de faire ce qu’ils vont dire. On perd en agilité au sens propre du terme.
S’inspirer du concept “less is more” de l’architecte Ludwig Mies van der Rohe
Le courant minimaliste architectural à l’origine du mode de pensée “less is more”, selon lequel l’amélioration d’une œuvre se fait ainsi par soustraction, devrait servir de mantra aux équipes agiles afin de reconnaitre la qualité d’un produit par sa simplicité
- autant dans sa conception
- que dans sa démarche de réalisation.
Au moins nous aurons des règles, au mieux nous serons en capacité de délivrer dans un temps restreint.
Donner la possibilité aux jeunes Product Owners de dire « non »
Les grands groupes sont souvent à la recherche de profils expérimentés (à minima 10 années d’expérience sur ces sujets), tant sur la méthode Agile que sur le secteur d’activité ou les technologies concernées. De par la rareté de ces profils, les recruteurs doivent souvent se tourner vers des profils qualifiés mais plus juniors, dont les capacités à prioriser les sujets sont moins évidentes.
Savoir dire “non” en les rapprochant des sachants ou en partageant des processus d’aide à la décision peut être un point de départ.
Si des Product Owner peu expérimentés sont embarqués sur vos produits, pensez à prioriser les irritants (amélioration à forte valeur, bug) et ne traiter les demandes d’amélioration seulement lorsqu’elles sont approuvées par la majorité et complètement spécifiée.
Ne pas remettre en question les processus à cause d’un surcroît de travail
Les responsables de chaque produit sont contraints par les budgets alloués de leur Direction et souvent au détriment de leurs engagements. La surcharge de travail pousse les équipes à repenser des petits bouts de la méthode. Hors ces changements finissent par nuire à la productivité de l’équipe.
Le process doit faire l’objet d’une remise en question qu’une fois la phase d’observation passée et ce, durant les rituels de rétrospectives Au moins le process sera challengé au mieux l’équipe se portera.
Distinguer les flux Run et Build avec leurs propres cycles de livraison (release)
L’amalgame entre le build et le run peut également fortement compromettre la crédibilité du produit et des équipes. En effet il n’est pas rare de voir des planning de release avec des mix amélioration/incidents. Or pour accroitre le taux de satisfaction du client, il est plus important de résoudre les anomalies qui sont des irritants avant de chercher à développer de nouvelles améliorations.
L’équipe agile doit être en mesure de délivrer des développements en dehors d’un planning préalablement fixé.
Prendre du recul sur la méthode Agile et l’appliquer là où c’est pertinent uniquement
Enfin, il est parfois difficile de reconnaître que la méthode peut ne pas être adaptée à tous les produits. En effet certaines équipes se retrouvent à devoir appliquer des cérémonies, des règles et des process qui ne correspondent en aucun cas à leur métier et produit d’origine. Il n’est pas rare de voir des équipes « tordre » cette méthodologie pour prétendre à l’Agile, mais qui finalement réduit leur réactivité et flexibilité. Cela sera forcément ressenti par l’équipe qui finira par percevoir l’agilité comme un frein plutôt qu’un accélérateur. C’est très souvent le cas pour les équipes qui travaillent sur des projets en parallèle de l’amélioration de leur produit.
DSI : Direction des Systèmes d’Information
- SLA : Service Level Agreement
