Agile et architecture de SI : réussir son premier projet
Comment s’y prendre.
Lorsqu’une grande entreprise se met à l’agile, même si le premier projet est parfois déconnecté du SI, il faut bien à un moment s’y raccorder.
La méfiance est alors souvent de mise de part et d’autre : quand on cherche un contre-exemple à l’agile, l’architecture de SI est souvent citée, avec ses process gravés dans le marbre et ses programmes multi-annuels.
Lorsque ce premier projet se passe bien, des liens entre coaches agiles et architectes peuvent se créer. Cela peut être le début de cette "transformation agile" dont beaucoup parlent mais que peu réussissent.
Dans le cas contraire, chacun reste sur ses positions, le projet est en danger, et les perspectives de changements s’éloignent.
Fruits de retours d’expériences de nos missions, cet article va vous permettre d’avoir toutes les chances de votre côté pour réussir ce premier projet.
L’architecture de SI et l’agile
L’architecture de SI "classique" et l’agile ont souvent des visions différentes.
L’architecture du SI porte une vision globale de l’écosystème de l’entreprise. Même dans un mode d’innovation, il ne doit pas perdre de vue le moyen et le long terme. À l’échelle du SI, une mauvaise décision peut avoir des conséquences catastrophiques, les architectes préfèrent donc cadrer les prises de risque.
Pour cela, il·elle·s privilégient les process formalisés. Pour garder les choses sous contrôle et limiter les coûts, ces process sont souvent standardisés.
L’agile va privilégier la capacité de répondre au changement. Sa stratégie de minimisation du risque est d’avoir des feedbacks rapides afin de détecter les problèmes au plus tôt et donc de baisser le coût de correction. Ses process seront donc plus souples et plus informels. Cela peut l’amener à des optimisations tournées vers le local et le court terme.
Les deux visent à maîtriser le risque, mais avec des modes de fonctionnement différents et qui peuvent facilement s’opposer. L’objectif n’est pas que l’un des deux gagne, mais de trouver une manière de les combiner.
La première étape est de se mettre d’accord sur le fait que les deux visions sont légitimes.
Ce travail est souvent difficile, et demande du temps : le temps d’apprendre à se comprendre le temps d’apprendre à travailler ensemble, et le temps de trouver des réponses aux enjeux de pouvoir, de budget, et de personnes.
Le minimum est de maintenir un lien de communication, sinon, les désaccords se transformeront en batailles, et vous risquez d’échouer.
S’isoler du SI, une tentation contre-productive
Pour démarrer en agile, un projet déconnecté du SI permet de limiter les risques. C’est sans doute la meilleure solution lorsque l’enjeux est de prouver que l’agile fonctionne, et c’est encore le cas dans certaines situations.
Cependant elle pose un risque car elle créé une attente qui va être déçue.
Lorsqu’un tel projet réussi, il devient une référence qui sert de point de comparaison. Il attire aussi les jalousies car il n’a pas eu à subir les mêmes contraintes que les autres. Les projets suivants où le SI interviendra auront sans doute d’avantages de difficultés, difficultés qui seront jugées en fonction du premier projet.
Il faudra alors lutter contre l’idée qu'"en fait l’agile ça ne fonctionne pas dans la vraie vie", et cela même si ces projets donnent objectivement de meilleurs résultats que les projets non agiles.
Un premier projet agile connecté au SI sera plus difficile et sa réussite sera probablement moins éclatante. Cependant cette réussite sera incontestable, et devrait être représentative de la suite. Il permettra aussi de commencer plus tôt à faire bouger le reste du SI.
À vous de décider en connaissance de cause en fonction du but que vous visez avec ce projet.
Le rôle de l’architecte sur ce projet
Comme sur une projet classique, l’architecte a un rôle d’interface entre le projet et le SI : cellules d’architecture transverses, personnes de la production et de l’infrastructure, sécurité… Son objectif est que le projet s’intégre harmonieusement dans l’écosystème du SI.
Pour le premier projet agile, l’architecte joue en plus un rôle d’agent agilifiant vis-à-vis du SI afin d’essayer d’aménager les process pour le bien du projet.
Dans un projet classique, le projet avance au rythme des process de l’entreprise. Ainsi, si les projets délivrent une nouvelle version tous les trimestres, avoir besoin de deux mois pour ouvrir un flux réseau n’est pas un problème, il suffit d’être bien organisé.
Par contre si le projet envisage de livrer une version tous les mois, voire toutes les deux semaines, cela va coincer. Dans ces situations, il faut trouver un terrain d’entente.
Vis-à-vis du projet, il·elle doit détecter ces contraintes structurantes afin de préparer le terrain pour que le projet ait la voie libre.
Il·elle joue ainsi le rôle d’un interprète entre les deux mondes. Il est donc nécessaire qu’il·elle parle les deux langues.
D’ailleurs, faut-il un·e architecte SI ?
Même si votre projet a des interconnexions avec le SI, la présence d’un·e architecte n’est pas forcément nécessaire.
Elle dépendra du niveau d’adhérence, car c’est lui qui détermine l’effort à fournir.
Dans tous les cas, la présence d’un·e architecte est souhaitable lors de la phase de cadrage afin d’identifier les risques et les sujets à traiter. En fonction de ces informations, il est alors possible de déterminer le niveau d’implication nécessaire.
En l’absence d’un·e architecte, c’est souvent un·e "référent·e technique" applicatif qui endosse cette casquette.
Tout d’abord, l’architecture de SI demande une réelle expertise. Avoir déjà baigné dans ces sujets ne remplace pas l’expérience directe.
Ensuite, le travail d’architecte SI sur un projet peut être consommateur de temps quand il faut remplir des documents, et être très fragmenté en fonction des disponibilités des interlocuteurs. Il est donc difficilement compatible, avec l’engagement et la disponibilité qu’on attend d’un·e référent·e technique, qui risque alors de devoir négliger un des deux aspects.
Si le travail d’architecture n’est pas suffisant pour occuper une personne à temps plein, il est possible de lui confier des tâches techniques qui ne sont pas sur le chemin critique des itérations. Cette configuration lui permet de s’interrompre à tout moment sans provoquer de retards.
L’architecte et l’équipe agile
Vis-à-vis de l’équipe, son rôle principal va être de traiter les contraintes venues de l’extérieur. Il·elle se fait alors un peu l’apporteur·se de mauvaises nouvelles.
Son travail va avoir pour effet de mettre l’équipe sous tension :
- le·a PO en influant négativement sur ses demandes ;
- le·a coach en ajoutant des contraintes ou des lenteurs au process ;
- le·a référent·e technique en limitant ses choix.
L’ensemble de l’équipe doit malgré tout avoir confiance en l’architecte sur le fait qu’il·elle travaille pour le bien commun, et n’est pas du côté du SI : il·elle fait bien partie de l’équipe.
La relation qu’il·elle entretient avec le reste de l’équipe est donc très importante.
Son travail est de savoir en permanence faire la part des choses entre l’existant du SI et des process et les besoins du projet.
S’il·elle penche trop du côté du SI, il·elle nuira à l’agilité du projet, s’il·elle prend parti pour son projet et ne sait pas choisir ses combats, ses demandes auprès du SI deviendront inaudibles.
En cas de problème, il·elle peut prendre parti, mais sans tenter d’imposer son point de vue. Ainsi si le·a référent·e technique n’est pas d’accord avec l’architecte SI, l’architecte peut proposer une solution, mais il·elle ne doit jamais tenter de l’imposer sous peine d’abîmer le lien avec le·a référent·e technique. Dans ce cas de figure, il faut tenter de concilier les deux positions, et en cas d’échec trouver comment sortir de l’impasse.
Une bonne expérience de l’agile est donc nécessaire, pour savoir quand une contrainte est acceptable pour le projet, et quand il faut la remettre en cause. Sans cela il devra passer beaucoup de temps à se synchroniser avec l’équipe avant de pouvoir donner un avis, c’est le syndrome du proxy-PO appliqué à l’architecture.
L’enjeux dépend aussi de l’historique de l’équipe :
- S’il s’agit d’une équipe qui a l’habitude de l’agile et peu celle des adhérences SI, il·elle doit réussir à leur faire intégrer les contraintes sans les démotiver et sans les braquer contre lui.
- S’il s’agit d’une équipe "autochtone" qui découvre l’agile, deux cas sont possibles. S’il·elle·s sont très motivés par l’agile il faut, comme ci-dessus, éviter que le soufflé ne retombe. S’il·elle·s sont méfiants, il faut leur montrer qu’on peut travailler mieux, même en restant dans un contexte proche.
L’architecte et le reste du SI
L’architecte pédagogue
En début de projet, un travail de pédagogue est essentiel.
En effet, beaucoup de ses interlocuteurs n’ont probablement jamais travaillé avec une approche agile. Pour certain·e·s agile pourra être synonyme de "à l’arrache". Il faudra donc prendre le temps de s’expliquer pour venir à bout de ces préjugés.
Il est possible de commencer par les convaincre que leurs préoccupations sont partagées, puis de leur expliquer que l’objectif est de répondre à leurs attentes tout en transformant la manière d’y parvenir.
Une expérience significative de l’architecture du SI permet de se faire identifier comme un pair. Avoir expérimenté l’agile directement donnera du poids au discours.
Satisfaire les besoins en aménageant le process
Pour faire bouger les choses, la marche à suivre tient en quatre étapes :
- Comprendre le fonctionnement actuel ;
- Identifier sa finalité ;
- Identifier les contraintes limitantes pour le projet ;
- Chercher une manière de répondre aux finalités, tout en aménageant le process pour réduire le poids des contraintes.
Prenons l’hypothèse où une demande d’ouverture réseau doit se faire un mois à l’avance, le formulaire de demande d’ouverture contenant une description du format du flux.
Avoir un format un mois à l’avance demande de traiter le point en avance de phase, ce qui ajoute une contrainte an projet. Après discussion, ce temps sert à allouer la personne qui s’en occupera, en revanche le format de flux est uniquement nécessaire à des fins documentaires, et n’est pas nécessaire pour l’ouverture de flux. Peut-être est-il alors possible de faire la demande sans le format, tant que celui-ci est renseigné avant que la règle ne soit activée sur les serveurs de production. La contrainte projet est alors plus légère.
Pour chaque tâche, il faut donc mesurer si les contraintes sont gênantes pour le projet ou si elles sont acceptables. Cette analyse nécessite de l’expérience, et une vision partagée avec l’équipe. Elle évite d’accepter des décisions sans se rendre compte qu’elles posent problème.
Une expérience DevOps est un atout. Il ne s’agit pas des outils (il n’est pas question de convaincre le SI de migrer vers un Chef ou Ansible), mais du fait que l’approche à suivre est sensiblement la même que celle nécessaire dans une stratégie DevOps de rapprochement des pratiques. Une manière de rapprocher les personnes peut être de proposer à celles qui s’occupent de l’infrastructure de participer de temps en temps aux réunions quotidiennes et aux rétrospectives.
Avoir du doigté, sans se faire marcher dessus
Il n’est pas possible de tout remettre en cause, en tout cas pas tout de suite. Il faut donc concentrer son énergie sur les sujets qui font une vraie différence pour le projet.
Si besoin, il ne faut pas hésiter à mobiliser le PO et d’autres sponsors qui pourront faire valoir les contraintes métier.
Les projets agiles ont également souvent des passe-droits, il faut savoir s’en servir sans en abuser.
Anatomie d’un architecte SI pour projet agile
- Connaissance en architecture de SI : pour faire son travail, et être pris·e au sérieux
- Connaissance en agile : pour pouvoir travailler avec l’équipe, et savoir déterminer quelles contraintes du SI sont limitantes pour l’équipe :
- Connaissance en DevOps : pour proposer les changements de process qui vont dans le sens de l’agile ;
- Approche de facilitateur : pour être au service du bien commun plutôt que de ses marottes ;
- Endurance : pour tenir le coup sur le long terme sans baisser les bras.
Cela fait beaucoup pour une seule personne : il s’agit d’un mouton à 5 pattes. De plus, si vous vous mettez à l’agile, il y a de grande chance que vous n’ayez pas ce type de profil en interne.
Une solution possible est de démarrer en s’appuyant sur des compétences externes, en prenant soin de rapidement former des personnes chez vous : les transformations sont des affaires de longue haleine, pour lesquelles il faut des personnes prêtes à s’impliquer sur la durée.
De l’importance de commencer tôt
Il est vital que l’intervention de l’architecte ait lieu au plus tôt dans la vie du projet. Si le rôle de l’architecte est tenu par un·e référent·e technique, il·elle devra fournir un gros investissement sur l’architecture lors de la phase de démarrage.
Les contraintes du SI peuvent être structurantes sur le fonctionnement de l’équipe agile, par exemple en influant sur la manière de faire des tests, ou la manière de livrer. Déterminer ces contraintes au plus tôt permet de partir dès le début sur un fonctionnement adapté (taille d’itérations, process…), plutôt que d’avoir à le modifier après-coup.
Les stories qui ont une adhérence avec le SI doivent être identifiées. En général elles ne peuvent pas être réalisées en une itération, à cause de leur partie SI. Il faudra donc les identifier pour les préparer du point de vue SI, avant que le travail de développement puisse se faire sans blocage. Cela demande d’y faire attention lors des phases de planning d’itération. Ils peuvent faire l’objet d’une zone de Kanban spécifique avec ses propres étapes, afin d’éviter de polluer la partie développement.
À retenir
- L’architecture de SI et l’agile ne sont pas ennemis, mais faire fonctionner les deux ensembles demande de la bonne volonté et des efforts.
- Lors de votre premier projet agile interagissant avec votre SI, l’architecte a un rôle très important.
- Pour remplir son rôle, il·elle doit connaître l’architecture de SI et l’agile.
- Il·elle doit avoir une posture de facilitateur·rice pour comprendre les contraintes du SI et des process pour agrandir l’espace de liberté du projet.
- Pour le projet, il·elle sera l’apporteur de mauvaises nouvelles, avoir une relation de confiance avec le reste de l’équipe est très importante pour éviter les antagonismes.