Face à un paysage professionnel en constante évolution, les entreprises modernes cherchent à se réinventer, en visant l'amélioration des conditions de travail et l'optimisation des processus. La méthode Agile, traditionnellement associée au développement logiciel, prouve son adaptabilité et son efficacité au-delà de son domaine d'origine.
Introduction
Beaucoup d’entreprise choisissent aujourd’hui de procéder à des transformations internes selon différents objectifs : Améliorer les conditions de travail des collaborateurs, faire des économies en interne, augmenter le rendement de leur production, faire des produits de meilleure qualité, etc. …
La méthode Agile a le vent en poupe et a fait ses preuves dans divers environnements. Néanmoins elle est généralement mise en place et appréciée dans le domaine du développement applicatif, domaine qui permet la mise en place d’itérations de produit courtes et constantes. Elle est adaptée au cycle de développement des applications. De grands groupes ont démontré qu’il était possible d’appliquer la méthode AGILE, dont la première recommandation est de se fixer des objectifs à court terme, à des domaines où les projets au long court sont les normes.
Le domaine de l’infrastructure est généralement en Cycle en V, ou pratique la méthode ITIL et fait habituellement sa transformation vers du DevOps (qui n’est pas vraiment une méthode mais plutôt une bonne pratique comme le Peer programming ou x programming dans le développement).
Nous avons eu la chance de faire une transformation en méthode Agile au sein d’un Pôle Infrastructure en pleine restructuration. C’est donc en tant que Product Owner (PO) et Scrum master (SCM), responsable entre autres de la construction de la DMZ (demilitarized zone) pour un client dans l’énergie que nous vous présentons la méthode AGILE appliquée par notre équipe.
L’idée dans ces quelques lignes n’est pas de vous former à l’Agilité mais de vous donner notre retour d’expérience, ressenti, de partager des idées à la réalisation de ce type de projet et des notions pour des réponses lors de vos futures expériences.
Organisation interne
Un gros client dans l’énergie dispose d’un pôle Infrastructure qui doit être restructuré à la suite d’une scission interne. Le Client doit devenir indépendant sur son infrastructure et architecturer l’ensemble des éléments nécessaires au bon fonctionnement de tout son parc applicatif ainsi que sa propre connexion à internet, avec un niveau de sécurité très élevé.
Le management de la DSI a décidé de mettre en place l’agilité au sein d’un plateau d’environ 200 personne qui travaillaient en ITIL ou Cycle en V. L’arrivée de coachs agiles a permis de mettre en place les bases de l’agilité SAFe et Scrum/kanban au sein des équipes.
Voici une représentation de l’organisation :
6 socles composés de plusieurs Trains (9 trains dans le socle infrastructure de traitement). Le train Infrastructure est lui-même composé de 22 équipes regroupées en 4 lignes produits. Ces équipes sont composées de 5 à 10 équipiers. Il y a obligatoirement 1 SCM et 1 PO par équipe.
Un train unique, organisé en 4 lignes produits pilotée chacune par un Product Manager (PM), permet de lier l’ensemble des équipes et de répondre aux nombreux sujets transverses.
Le RTE et son équipe, constituée principalement de coachs Agiles, s’assurent du respect de la méthode, des cérémonies au niveau du train (Program incrément planning, phase de démos, etc.), de la circulation des informations au niveau des PM et surtout que la communication transverse aux lignes produit soit efficace.
Les SCM, au-delà de faire respecter la méthode agile au sein des équipes, sont des lanceurs d’alerte dans le cas où un sujet serait transverse et impacterait d’autres équipes.
Rappel, contexte et solution
SPRINT, voilà ce qui vient à l’esprit quand on parle de méthode AGILE, qui n’a jamais vu ce schéma ?
D’une durée de 2 à 3 semaines, il permet d’incrémenter des fonctionnalités de manières successives et d’avoir un retour auprès des parties prenantes après chaque nouvelles fonctionnalités…fonctionnalités qui doivent être réalisées dans ce délai de 2 à 3 semaines…
Le SPRINT n’est pas la méthode Agile, c’est simplement un des outils (une cérémonie pour être exacte) mis à disposition pour développer et/ou maintenir un produit.
Dans la théorie, la méthode ou manifeste Agile s’articule autour de 4 piliers et 12 principes qui sont mis à la disposition des entreprises et animés au travers du trio : Product Owner (PO) / Scrum Master (SCM) / Equipiers (dans notre cas des experts réseaux).
En lisant le manifeste on commence à entrevoir les contradictions que soulève la méthode AGILE sur des chantiers d’infra, par exemple :
Concernant le Product Owner, il peut être présenté en tant que Chef de projet Agile comme on peut voir apparaitre sur certaines présentations de poste et il est vrai que dans un premier temps on se raccroche à ce que l’on maitrise et c’est souvent Chef de Projet ou Pilote de Service pour du RUN.
Et pourtant la différence majeure est dans l’énoncé « Responsable Produit », l’idée est simple : accélérer la réactivité, la prise de décision et d’en finir avec les attentes de 3 semaines et le prochain COPIL pour savoir si on part sur telle ou telle solution. Une des tâches principales de votre fonction de Product Owner est d’aller échanger de manière continue avec l’ensemble des parties prenantes (Métier/Client, Technical Leader, Architecte etc.) afin de s’assurer d’être toujours au plus proche de l’attendu et d’anticiper les risques et évolutions.
Il existe bien sûr d’autres tâches qui incombent au PO (rédaction des User Stories, suivi du Backlog, etc.) et d’autres plus exclusives à l’entreprise dans laquelle vous exercez (administration et gestion de l’équipe, recrutement par exemple).
Au final, on comprend que toute cette méthode est axée sur l’accélération du temps :
- Pour développer
- Pour modifier ou corriger
- Pour prendre des décisions
Alors, Comment associer temporalité courte et chantier long sur lesquels les risques de dérives sont intrinsèques à la nature des projets d’infrastructure ?
Montée à l’échelle (SAFe), Program Incrément et Kanban
En tant que PO, il est difficile d’imaginer piloter un chantier d’infrastructure réseaux et télécom avec les contradictions relevées précédemment. Cependant la méthode Agile est permissive et offre un panel d’outils sur lesquels les équipes peuvent s’appuyer pour établir une roadmap sur plusieurs trimestres : la montée à l’échelle dite L’agilité SAFe (Scaled Agile Framework).
SAFE permet, à l’aide de son « framework » de définir une stratégie et une vision à moyen terme. Evidement ce framework est réadapté au contexte entreprise. Sachant qu’en Infra on sait généralement ce que l’on veut et comment (mise en place d’un cœur de réseau, déployer un réseau Wifi, etc.), l’idée est de « découper » le chantier en « fonctionnalités » comme on le ferait dans un jalonnement « standard » (A, B, C etc.) puis de rédiger à l’attention de l’équipe les « User Stories » (US) permettant de réaliser la fonctionnalité.
Le schéma ci-dessus vous représente le parallèle entre Cycle en V et Agilité, de l’avant-projet à sa mise exploitation par le NOC (Network Operation Center (Phase de RUN des projets en production)).
Cette découpe est possible via l’intégration des «Program Increment » (PI) du framework SAFE qui permet une approche structurée pour développer Agile à grande échelle en synchronisant plusieurs équipes ensemble. Dans le cas présent nous représentons un projet Infra porté par une seule équipe mais SAFe est conçu pour répondre aux besoins liés à de grandes organisations : département, entreprise et regroupe plusieurs équipes Agiles via un train comme présenté précédement.
Pour résumer, les PI sont utilisés pour découper le projet d’Infra et réaliser une roadmap du projet.
Program Increment (PI) et fonctionnalités
D’une durée d’un trimestre dans notre exemple celui-ci débute par un « PI Planning » de deux jours durant lequel on planifie tout le travail qui va être réalisé et se termine par 3 sessions de démos (ou revue des fonctionnalités : elle consiste à présenter devant les parties prenantes et l’ensemble du TRAIN les fonctionnalités développées) pour valider ce qui a été réalisé et mettre au courant l’ensemble du TRAIN des avancées, puis on recommence le cycle.
Ainsi dans chaque PI nous découpons notre chantier en « fonctionnalités » et nous donnons une première vision macro du Prochain Trimestre de travail. Les fonctionnalités sont estimées et priorisées et vont remplir un backlog produit.
NB1 : Nous savons qu’un PI est censé être de 8 à 12 semaines et qu’un TRAIN doit avoir entre 50-125 personnes. Notre Train fait 250 personnes sur des périodes de 13 semaines c’est une contrainte entreprise avec laquelle nous devons composer.
NB2 : En Agile, la notion de temps de réalisation est proscrite, on parle plutôt de capacité à faire d’une équipe mais vos clients vous demanderont d’estimer quand même un temps de livraison. La capacité à faire est un travail statistique réalisé par le Scrum Master (SCM) qui permet de connaitre la charge de travail possible et d’éviter la surcharge ou simplement la non-réalisation d’un produit. Il utilise également la « vélocité » pour calculer au mieux la charge de travail d’une equipe.
Finalement durant le PI vous avez la possibilité d’encapsuler un certain nombre de Sprints comme le suggère la méthode SCRUM. Néanmoins le Sprint est efficace pour une équipe réellement autonome dans sa réalisation de fonctionnalités « courtes » mais n’est pas assez permissif aux aléas externes forts et études. Nous avons donc opté pour la méthode KANBAN plus adaptée et préférée par les équipes qui subissent moins de pression due au timeboxing de 2 ou 3 semaines.
Retour d’expérience – Product Owner
Comme expliqué au début, ce billet est une présentation personnelle d’une méthode fonctionnelle dans un contexte particulier, il existe surement d’autres variantes peut-être plus adaptées à la gestion d’un projet Infra avec la méthode Agile.
Quoiqu’il en soit, nous tenons à vous partager nos remarques ou limitations que nous observons dans un cas concret sur le terrain.
User Story (US) et Kanban
Généralement les US sont rédigées par le PO, elles doivent décrire une fonctionnalité du point de vue de l’utilisateur, en langage non-technique et s’appuyer sur le formalisme suivant :
« En tant que [profil client], je souhaite [objectif du produit] afin de [résultat] ».
Deux problématiques majeurs apparaissent ici, la première est que le PO ne peut pas être au même niveau technique que les équipiers (qui sont des experts). La deuxième se situe au niveau du formalisme ou l’utilisateur final est souvent très éloigné de la fonctionnalité, par exemple « configurer des clusters de FW » ou simplement « câblage du matériel ».
Dans notre cas nous avons la DOR (définition of ready) à travers le formalisme Contexte / Quoi / Pourquoi en description de la fonctionnalité. Cela suffit amplement pour permettre à l’équipe de demander plus d’information et pour provoquer la discussion en cas d’incompréhension.
En tant que DOD (Définition of DONE) nous avons des critères d’acceptation qui sont fixés par le PM.
L’équipe rédige le titre des US qui sont utilisées en tant que tâches à réaliser. Cela permet d’avoir de la souplesse sur plusieurs lignes produit pour les équipes transverses comme la nôtre.
Retrouvez-ci-joint un exemple de fonctionnalité et des US qui y sont attribuées. Notez que pour le moment les US ne sont pas priorisées, la priorisation est à la charge du PO.
NB : Les CDP le savent, un projet qui dérive c’est normal, un projet à l’arrêt c’est souvent très mauvais signe, il est donc impératif de découper votre « Fonctionnalité » en un maximum d’US car vous savez que certaines peuvent se retrouver « en attente » pour une problématique qui n’est pas du fait de l’équipe (retard de livraison par exemple). Multiplier les US vous permettra de basculer sur une autre qui peut être faite en parallèle. Comme représenté sur le schéma du projet X, une fonctionnalité peut être déterminante pour lancer la suivante (dépendances) à contrario des US qui peuvent être lancée en parallèle (indépendantes).
Au travers du tableau Kanban, constitué de 3 ou 4 colonnes « A faire », « En cours » et Terminé » le PO va pouvoir prioriser, assigner et suivre l’évolution des US de toutes les fonctionnalités attachées à l’équipe. Dans notre exemple ci-dessous nous avons aussi plusieurs lignes produits (ZNET, VPA, DMZ, etc.)
Revue de Backlog & préparation de PI Planning
Concernant les rituels ou cérémonies, le plus connu est le Daily, quotidien, cours (15 min maximum, s’il dure 5 min ce n’est pas grave) et animé par les équipiers qui échangent autour de leur travail en cours, des difficultés rencontrées, etc. Attention, ce n’est pas un compte-rendu journalier au PO (le PO, comme un CDP, n’est pas un manager), ce dernier peut être présent ou non, demander ou donner des informations.
La revue de backlog (Product Backlog refinement) est hebdomadaire, d’une heure, animé par le PO, elle permet de faire une passe sur l’ensemble des US, de valider celles qui sont terminées et de clarifier si besoin celles qui passent en réalisation.
Le « PI planning » enfin débute à chaque nouveau PI, d’une durée de 2 jours, c’est probablement la cérémonie la plus importante du Framework SAFe, il permet d’aligner l’ensemble des équipes (gestion des dépendances) et c’est pendant celui-ci que nous allons valider le backlog pour le PI à venir. Ce rituel est assez dense nous le préparons avec 2-3 réunions de préparation afin d’avoir une idée précise de son backlog et de gérer simplement les dépendances durant le PI Planning.
NB : Les difficultés doivent être remontées rapidement au PO. Il aura à sa charge de débloquer la situation en activant les Technical Leaders, Architectes, achat dans le cas d’un retard de livraison, autres équipes via les autres PO, etc.
Concernant les US non terminées dans le temps imparti : prenons le cas ci-après, entre les PI du 3ème et 4ème trimestre, avec l’hypothèse que vous rencontriez des problématiques de câblage lors de l’intégration des équipements et que l’US « Câblage du matériel » ne soit pas terminée.
En revanche, la découpe etant bien faite, l’équipe a pu terminer la majorité des autres US et valider la majorité des « critères d’acceptation ». Vous vous retrouvez finalement dans l’impossibilité de valider cette fonctionnalité alors qu’elle est à 95% terminée et que les 5% restants ne sont pas du fait de l’équipe… frustrant ! Un partenaire externe empêche la clôture d’une fonctionnalité. Les conséquences sont que l’ensemble de la Feature n’est pas comptabilisée comme terminé pour le PI en clôture.
Vous avez plusieurs possibilités :
- Soit vous décalez la fonctionalité entière sur le PI suivant avec l’hypothese que la derive est minime et que vous allez pouvoir la terminer sur le debut du prochain PI.
- Soit vous decalez la fonctionnalité mais estimez que la charge supplementaire va avoir un impact sur ce qui était prévu à l’origine et decidez de rescoper la fonctionnalité suivante
- Soit vous decidez de transferer l’US restantes dans la suivantes afin de valider celle en cours. Cette manipulation va necessiter de revoir le scope de la fonctionctionnalité en cours pour la cloturer (changer les « critères d’accepations » avec le Product Manager)
Ce travail est fait en collaboration avec le SCM en particulier au sujet de la capacité à faire de l’équipe mais également avec votre Product Manager pour les modifications de scope des fonctionnalités mais surtout pour lui expliquer le pourquoi du comment vous avez pris du « Faux » retard.
NB du SCM : Nous sommes conscient que le changement de Scope du travail initial en cours de PI est une hérésie pour les évangélistes de l’Agilité. Néanmoins, quand 3 mois de travail de 2 ou 3 personnes est « Invalidé » sur les statistiques du train et passe comme du travail non fait a cause d’un papier de validation d’un partenaire externe manquant, nous avons estimé que cela était incohérent et finalement faussait toutes les statistiques de vélocité d’équipe.
De notre point de vue, et surtout pour avoir testé les trois, la troisième solution est souvent appliquée pour plusieurs raisons, en particulier pour l’humain et la gestion du bien-être de l’équipe :
- Comme expliqué plus haut, c’est frustrant pour l’équipe de ne pas pouvoir valider une fonctionnalité a cause d’une raison qu’elle ne maitrise pas.
- Garder une dynamique dans l’équipe et dans l’avancement du projet. On évite ainsi cette sensation de stagner qui peut avoir un effet négatif.
- Egalement en ce qui concerne notre rôle de PO/SCM, de se remettre en question dans la capacité à faire de l’équipe, la découpe de la fonctionnalité en US et anticiper les risques.
NB SCM : Une option un peu plus propre est de découper d’une manière plus fine les fonctionnalités, et découper la fonctionnalité sous forme de « Lot ». cela permet de conserver l’avancé de la charge de travail, de voir le « reste a faire prévue mais non réalisé », et de pouvoir le faire glisser sur une nouvelle fonctionnalité.
Documentation et reprise en exploitation
Une des 4 valeurs de l’Agilité est « le produit opérationnel plus que le documentation exhaustive » de ce fait il est facile et acceptable de minimiser et de repousser la documentation.
Mais en tant que responsable du produit (PO), vous ne devez pas vous arrêter à la valeur pour le client mais le produit dans son ensemble. En particulier dans le cas d’un projet Infra car ce que vous construisez sera ensuite exploité, en général par une autre équipe, entité voire une autre entreprise (NOC, service desk etc..).
Dans le cas de SAFe, le « client » sera généralement représenté par le Product Manager (PM) qui, avec l’aide de Technical Leader (TL) ou Architecte qui transforme les besoins fonctionnels métiers en fonctionnalités techniques qui devront être réalisées par les équipes Agile.
Il sera donc votre contact privilégié, votre N+1 opérationnel et peut être, en tant que prestataire, votre client.
Dès qu’un produit est opérationnel, le PM va vous envoyer un nouveau besoin… mais en tant que PO, vous êtes responsable du produit jusqu’à son exploitation, même si pour le client final, cela ne représente aucune valeur ajoutée, certaines tâches sont indispensables avant sa mise en production (recette, validation cyber sécurité etc.). Vous devrez donc bien rappeler et surtout quantifier ces taches avec l’aide du SCM car elles représentent un travail non négligeable et obligatoire pour l’équipe.
Il est nécessaire de créer des US de documentations tout au long du projet (DAT, DEX, Recette par exemple) afin de pouvoir réaliser le transfert de compétences et la reprise en exploitation de votre produit fini par un autre service comme le NOC.
Par ailleurs le « Turn Over » élevé des ressources au sein de nos structures nécessite un maintien de la documentation pour ne pas avoir de perte de connaissance et une passation de compétence efficace.
Projet Transverse
Pour faire une analogie, sur un navire il n’y a qu’un seul Capitaine, responsable de la direction que doit prendre le navire. Idem pour le pilotage d’un projet, celui-ci doit aussi être porté par une seule personne ou entité.
Dans un « Train SAFe », si un Projet Transverse se présente, il va d’abord falloir qu’un PO « référent » se propose comme responsable du produit à développer (en plus de son périmètre actuel) pour ensuite négocier avec les autres PO et prioriser les besoins de tout le monde en prenant en compte les charges et staffing de chaque équipe, tout en sachant que les PM sont différents pour tout le monde… ça devient vite une énorme dépense d’énergie pour trop peu de résultat.
Ceci reste notre point de vue, mais un CDP/PO/PMO ou une entité au-dessus des PM aura plus de facilité à faire avancer un projet en allant piocher dans les diverses compétences que lui offre un train Agile. (Cf. schéma)
Retour d’expérience – Coach Agile
Dans un premier temps, il a fallu éduquer les équipes à utiliser les nouveaux outils de gestion Agile (Go Jira dans notre cas). Des formations sur les bonnes pratiques et les objectifs de l’agilité sont devenues obligatoires. Les SCM ont pour mission de procéder petit à petit en fonction de la maturité de leurs équipes et des personnes qui les composent à une migration en agilité.
La première étape est l’acceptation des cérémonies de l’Agilité comme souvent dans les transformations c’est un point qui demande du temps de pratique. Les Scrum ont aussi des manières différentes de proposer la migration. Certains pratiquent facilement l’agilité à travers des jeux, d’autres sont plus sur l’échange interne etc. Le choix a été pris de laisser faire les Scrum master en fonction de leur équipe, il n’y a pas d’uniformisation des process dans un premier temps. Dans un second temps, les Scrum master ont fixé un cadre plutôt Scrum ou Plutôt Kanban en fonction de ce qui collait le mieux à la typologie d’équipes qu’ils avaient.
Il y a des lignes Guide rédigées par les Coachs agiles pour uniformiser certains points comme les rôles et actions communes à l’ensemble des équipes : rédaction de digit dashboard (« Météo projet » sur les features principales à la charge des Scrum master, Les PM ont le dernier mot pour la clôture d’une features, uniformisation des Definition Of Ready et Definition of Done, et.). Néanmoins le contexte infra implique d’avoir certaines libertés au sein de chaque équipe.
Le framework Agile adapté à l’infrastructure étant mis en place avec une grande part de liberté et de souplesse sur la méthode il faut tout de même préciser que le domaine de l’infrastructure a des particularités qui augmentent la difficulté de cette mise en place.
Nous pouvons relever au moins 4 points de particularité Majeurs liés à l’infrastructure.
Des équipes avec des compétences multiples très différentes
- Au sein d’une même équipe, certain doivent faire de l’installation de Hardware avec des contrainte d’approvisionnement en matériel et d’installation et d’autres doivent faire du développement pour de la configuration de serveur, quand d’autres équipes doivent s’occuper de la sauvegarde de données ou du portail d’accès des applications.
- Ainsi, au sein d’une même équipe vous avez des contraintes très différentes et quand certains pourraient travailler en sprint de 2 semaines certains ne peuvent tout simplement pas car on parle de délais énormes concernant la livraison de matériel par exemple.
La gestion hardware
- Les délais de livraison matériel : peuvent varier de 1 à 6 mois sans avoir aucun pouvoir dessus. Ce qui implique que la gestion en sprint de 2 ou 3 semaines est tout simplement inapplicable pour les personnes s’occupant de l’installation en Datacenter. Les informations d’installation étant délocalisées, il est extrêmement compliqué (voire impossible) d’avoir des dates précises. Aussi la moindre tâche n’est pas résolue avant au minimum 2 à 3 semaines, même en forçant l’équipe à découper le plus petit possible les fonctionnalités en User Stories
- De fait, une méthodologie en SCRUM incluant des Sprints parait difficilement applicable au sein des équipes qui souvent ne le souhaitent pas.
L’interdépendance forte entre les équipes et les prestataires externes
- Le nombre de prestataires externes est très élevé, et surtout le Client n’a pas de moyen de gestion ou de priorisation sur ces prestataires qui sont reliés par contrat au client. Malgré la mise en place des Program incréments (de 3 mois), chaque PM gèrent un domaine (ligne produit) précis au sein du pôle et a ses propres contraintes et priorités. En effet, les équipes métiers ne sont pas les mêmes avec des demandes parfois contradictoires. Certains pôles demandent rapidement que la connexion internet soit établie quand d’autres ont besoin que leurs applications soient hébergées rapidement. Les Product Manager ont une grosse responsabilité sur la priorisation des fonctionnalités
- De fait, les équipes sont souvent frustrées et ont les mains liées concernant l’urgence ou la priorisation d’une action par rapport aux prestataires et aux autres équipes qui ne sont pas forcément dans la même ligne produit qu’eux. Les taches engagées ont beaucoup d’incertitude sur leur complétion probable au bout des 3 mois de chaque Program Incrément. Cela nécessite un management d’équipe rassurant et surtout une très forte protection des Scrum Master envers leurs équipes afin que ces équipes ne soient pas reconnues comme responsables de certains retards qu’elles ne maitrisent pas.
- Dans ce contexte le train étant surdimensionné, il y a une tendance à surcharger les Program Incréments de fonctionnalités par manque de visibilité sur les priorités des autres lignes produit. Pour les Scrum master, il est primordial d’avoir rapidement une vélocité d’équipe afin de s’engager uniquement sur la charge de travail que peuvent engager les équipes avec une bonne priorisation et limiter cette surcharge.
La typologie humaine des collaborateurs en infrastructure
- Sans faire une généralité, nous sommes à l’opposé des stéréotypes de jeunes personnes dynamiques et motivées au sein de start-up florissantes. Ce sont des personnes qui ont plusieurs années voire dizaines d’années d’expérience dans des technologies diverses et variées extrêmement complexes, ce sont des travailleurs précis et souvent peu enclins au changement ou à la transformation des méthodes organisationnelles. Le frein humain est très présent, et l’accompagnement pour les Scrum Master est d’autant plus délicat.
- Ce sont des personnes qui ont le sens des procédures, le framework Agile a souvent une image négative à leurs yeux à cause de la souplesse et des changements d’objectifs récurrents, il y a beaucoup d’accompagnement et d’éducation à faire. Les Scrum Master doivent en permanence être vigilants à ce que les process mis en place soient conservés. Nous préconisons d’avoir un Scrum Master expérimenté attitré à des équipes plutôt qu’un coéquipier qui fasse aussi le rôle de Scrum Master.
- Généralement les taches en infrastructure laissent peu de place à la réflexion, il y a des canevas à respecter à cause de « bonne pratique », et beaucoup de travail exécutif qui prend beaucoup de temps (plusieurs semaines).
Les point fort de l’agilité en infrastructure
- Avoir des équipes clairement distinctes qui peuvent atteindre l’autonomie quand elles ont atteint une bonne maturité dans l’agilité.
- Obtenir un cadre rassurant et de protection sur les équipes et arrêt des effets de culpabilisation dans le cas de retard car le problème n’est pas forcément à cause des équipes et de ses compétences. On limite fortement les demandes « impromptues » venant du management parce qu’une priorité a changé du jour au lendemain.
- L’assainissement du cadre de travail : l’agilité permet de clarifier les problèmes que personne ne voulait ou refusait de voir. Les vrais problèmes émergent et peuvent être identifiés et traités. Souvent ces problèmes sont connus mais cela arrange un peu tout le monde de ne pas y faire face car « ça fonctionne comme ça depuis des années ». L’agilité retire les freins qui peuvent jouer sur une surcharge fictive de travail.
- Apporte de la visibilité sur l’ensemble des sujets et la réelle force de travail des équipes qui est souvent surestimée et la direction ne comprend pas pourquoi les sujets n’avancent pas. Désormais la réponse est apportée, les dépendances et interconnexions des équipes est mise en avant.
En tant que coachs agiles nous sommes conscients que l’agilité est une méthode qui porte une notion globale, au-delà de toutes les règles et cérémonies avec lesquelles elle est structurée. De fait, l’agilité est clairement adaptable à tous les environnements pour peu qu’elle soit appliquée intelligemment. Nous allons être très clairs : L’agilité SAFe, Scrum, Kanban « By the book » n’est pas applicable en l’état. Mais la méthodologie SAFe est clairement applicable avec un TRAIN adapté à pas plus de 70-80 personnes, la méthode KANBAN et l’utilisation de backlog et tableaux de suivi est tout à fait applicable. L’ensemble des cérémonies aussi sont applicables quand elles sont amenées avec tact auprès des collaborateurs.
Conclusion
Faire cohabiter Méthode Agile et Projet d’infrastructure Réseaux et Telecom c’est possible !
La méthode Agile est permissive, il existe des courants (LEAN) accompagnés de Frameworks (SAFe) sur lesquels s’appuyer pour l’adapter au besoin client. La méthode Agile est efficace quand elle est appliquée avec intelligence, souplesse et adapté au contexte. Aussi il y a un dimensionnement à respecter pour que l’agilité dévoile toutes son efficacité.
La souplesse de la méthode ne veut pas dire que tout est possible, l’accompagnement par des Coachs Agiles et Scrum Masters dans les équipes est nécessaire afin de ne pas trop s’éloigner du manifeste ou à l’inverse de vouloir trop respecter le manifeste. Il est important de recruter des personnes expérimentées et nous déconseillons des juniors pour qui l’expérience peut être très désagréable ou démotivante à cause des contraintes et des difficultés inhérentes au domaine de l’infrastructure.
En prenant en compte les remarques de ces derniers, il revient à chacun d’entre nous de tester, d’évaluer nos erreurs afin d’améliorer la méthode et ainsi répondre aux mieux à notre besoin de produire le plus rapidement de la valeur tout en diminuant le gâchis. L’objectif est de conserver l’essence et la mentalité de l’Agilité tout en prenant en compte les contextes environnementaux et les contraintes des entreprises.
Nous vous remercions pour votre lecture.
Benjamin Gratté, Coach agile / Directeur de projet chez Apollo
Cédric Vallée, Product Owner chez Devoteam.