Application de La méthode AGILE dans les projets d’infrastructure

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é.

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.