Product Owner et Architecte : deux visions complémentaires pour une architecture agile

Avec la digitalisation et l’évolution continue des tendances de consommation, adapter rapidement sa stratégie est devenu une question de survie pour une entreprise. Le premier semestre 2020 avec la crise sanitaire a d’ailleurs prouvé encore une fois l’importance de ce besoin d’agilité et d’adaptabilité.

Si les méthodes agiles concourent à cette souplesse, l’agilité est, elle, multifacette. L’architecture d’entreprise s’inscrit elle aussi dans cette dynamique. Comment démarche agile et architecture contribuent à agiliser l’entreprise ? Comment se combinent-elles ?

Dans cette interview, Nolwen, consultante et Product Owner, et Dominique, architecte, croisent leurs points de vue sur la complémentarité de l’architecture et de l’agilité.

Quelle est pour vous la différence entre « faire de l’agilité » et « être agile » ?

Dominique :

Poussées à limiter au maximum leur time to market, beaucoup d’entreprises sont tentées de suivre la mode de l’agilité. Dans une bonne partie des cas, il s’agit surtout d’essayer de suivre un framework agile sans reconsidérer ses modes de fonctionnement. Les entreprises « font de l’agile » mais ne le sont pas !

Être agile implique de se remettre en cause. Les structures en entreprise peuvent être assez lourdes et impliquer des temps de réponse longs pour répondre aux changements du marché. Pour être réactif, il faut parfois savoir court-circuiter les structures établies, avancer avec une logique de POC pour tester rapidement de nouveaux concepts. Le client doit rester le sujet de toutes les préoccupations.

Nolwen :

Avant d’être une méthodologie, être agile est un état d’esprit ! Au-delà de la méthodologie SCRUM, ce sont des principes et des valeurs. Il faut savoir être pragmatique, déroger à quelques règles quand c’est nécessaire, en sachant pourquoi on le fait.

Dans les DSI, les formations à l’agilité peuvent être motivées par l’idée de « faire de l’agilité », sans adapter l’organisation à la méthodologie et aux outils. Dans ce cas, on peut vite se retrouver confronté à la mise en place d’une méthodologie agile dans un environnement qui ne s’y prête pas. Par exemple s’il est organisé en silos, qu’ils soient structurels, politiques ou liés à la croissance de l’entreprise. L’élaboration des budgets au travers d’une estimation de charge annuelle de projets est aussi antinomique avec une démarche agile itérative composée de sprints de quelques semaines. La route peut être longue dans ce cas s’il n’y a pas d’accompagnement au changement !

Le premier principe agile « Les individus et leurs interactions plus que les processus et les outils » ne doit jamais être perdu de vue. Ce sont justement les personnes qui font la différence entre le « être agile » et « faire de l’agilité ».

Derrière l’architecture d’entreprise, on pense parfois process, structuration… Est-ce compatible avec l’agilité ?

Nolwen :

Si l’agilité est un mouvement de fond, sur le terrain l’architecture aussi se transforme pour devenir agile. Il y a 10 ans, l’architecte  travaillait de son côté avec de temps en temps des points de synchronisation. Ce n’est plus le cas ! L’architecture d’entreprise est maintenant, et à raison, intégrée de plus en plus dès le cadrage des projets. Cela assure d’avoir une longueur d’avance, une Road Map à long terme. Associer agilité et architecture est la meilleure manière pour qu’être agile fonctionne vraiment dans la pratique.

Chercher l’agilité sans architecture, c’est prendre le risque de multiplier les sprints sans cohérence d’ensemble. Être agile ne signifie pas se passer d’un alignement d’entreprise !

Dominique :

Oui, associer architecture et agilité est une vraie opportunité pour co-construire . L’architecte d’entreprise a tout intérêt à être associé le plus en amont possible de la réflexion. Architecte et PO doivent apprendre à travailler ensemble !

Comme le disait Nolwen, le travail en équipe, le partage de standards, le décloisonnement sont liés à l’agilité aussi bien qu’à l’architecture. L’architecture n’empêche pas d’être agile, au contraire. Elle permet d’intégrer la démarche agile dans la stratégie d’entreprise. Elle porte la vision de la direction dans laquelle on souhaite aller !L’architecture d’entreprise doit aider les directions métiers à décliner la stratégie d’entreprise et à guider justement les explorations à mener.

La complémentarité est évidente : l’architecture apporte la pérennité et la prise en compte de la stratégie d’entreprise. L’agilité assure une réponse rapide aux besoins de son écosystème.

L’architecte ne doit pas attendre que les métiers le sollicitent ! Il doit réfléchir avec eux aux solutions. C’est tout une relation de confiance à bâtir.

Cette complémentarité implique donc aussi de remettre l’agilité et l’architecture à leur place appropriée dans l’entreprise ?

Dominique :

Oui bien sûr ! L’architecture doit être impliquée le plus en amont possible, pour que la vision soit pérenne. Elle doit aussi intervenir sur plusieurs plans (processus métier, services fonctionnels, applications, infrastructure technique) et veiller à la cohérence globale. L’architecture trouve sa vraie valeur au niveau de l’entreprise. Elle éclaire la route à différentes longueurs de phare : sur du long terme, du moyen terme et du court terme. Elle ne doit pas être cantonnée au volet technique. On peut citer SAFe (Scaled Agile Framework) dont l’objectif est d’adapter la méthodologie Agile à l’échelle de l’entreprise et dont la version 5.0 intègre la notion d’agilité métier.

Nolwen :

Entièrement d’accord ! Et il en est de même pour l’agilité. Limiter le travail en mode agile  à une dimension IT, c’est aussi limiter son retour sur investissement. Sans changement de culture, et donc d’un terrain de jeu plus large, elle sera difficile à mettre en place et ses apports seront limités.

Dominique :

La meilleure approche pour tester l’agilité afin de mieux mettre en œuvre ensuite, c’est un sujet transverse, comme un nouveau produit ou un nouveau segment de marché. La structure et les services impliqués peuvent alors travailler en mode agile, avec un objectif commun et une orientation métier.

Le vrai test de l’agilité se réalise sur un processus de bout en bout, du besoin métier jusqu’à la mise en œuvre des solutions !

Nolwen :

Pour pouvoir infuser au sein de l’organisation, l’agilité, tout comme l’architecture d’ailleurs, doit être portée par le Management et sur un projet dès son cadrage. Peu importe que le projet soit organisationnel, commercial ou informatique !  Le management doit alors être sponsor des démarches d’architecture et d’agilité pour leur donner du sens et pour accompagner les équipes au changement. Si seul un service (ou une équipe projet) est formé à l’agilité et que celui-ci continue à travailler avec d’autres équipes qui ne le sont pas, la situation peut s’avérer complexe et ne produira pas les effets escomptés !

Je rejoins donc complètement cette conviction : l’agilité doit s’appliquer au niveau du projet métier, pas par service ! Elle doit s’inscrire au niveau stratégique, tout comme l’architecture d’entreprise.

Les termes « Continuous architecture » ou « architecture agile » commencent à être utilisés. C’est conforme à votre vision ?

Dominique :

Selon moi, « continuous architecture » est un pléonasme. L’architecture, par sa vocation même, ne s’arrête jamais. Elle est itérative, continue et doit délivrer par incrément.

L’agilité est une composante en plus à prendre en compte au niveau de l’architecture pour répondre aux enjeux de réactivité. C’est donc une exigence à intégrer dans le travail de l’architecte lorsqu’il conçoit des solutions. L’architecte doit devenir agile lui-aussi ! Cette complémentarité entre architecture et agilité préserve la cohérence des roadmaps des produits et des services. Les visions des produits sont plus pérennes, plus adaptables. L’entreprise est capable de répondre aux enjeux du client aujourd’hui et aussi dans le futur. Être plus connecté aux marchés renforce aussi l’image de marque et la fidélisation des clients.

Cela implique par exemple de maintenir le plus longtemps possible différentes options au sein des solutions mises en place afin que le produit final dispose d’une durée de vie plus longue. Préserver la variabilité et accepter de délivrer des architectures incomplètes favorise l’agilité !

Nolwen :

Je suis persuadée que la mise en place d’une démarche d’architecture participe directement à l’agilité de l’entreprise. Travailler avec des briques interchangeables, agiliser son Système d’information  permet de proposer aux département métiers et aux clients finaux des services complémentaires, de s’adapter plus facilement. Parler d’architecture agile a tout son sens.

Comment architectes d’entreprise et product owners peuvent-il travailler ensemble ?

Nolwen :

Comme dans tout projet d’entreprise, c’est le management qui doit être le sponsor. La haute direction bien sûr, mais aussi le management de proximité. Dans mon rôle de Product Owner, j’inclus les architectes dans les réunions dès le cadrage. Ils ne doivent pas prendre le train en marche ! Leurs points de vue sont très complémentaires. Lors d’une mission, j’ai travaillé avec un architecte sur un diagramme de séquence. J’ai beaucoup appris et cela a permis d’apporter une vision plus pragmatique. En favorisant l’interaction dès le début, le PO évite aussi de faire office de « passe-plat » par la suite, et on limite le biais entre le métier et l’IT.

Dominique :

Oui, l’agilité doit être incarnée par le manager et impulsée par le top management. C’est un changement de culture d’entreprise : permettre aux gens de se tromper, de revenir en arrière, d’arrêter un projet grâce au suivi régulier des bons indicateurs, mais aussi de responsabiliser les intervenants en privilégiant la prise de décision décentralisée.

Dans toutes mes missions d’architecte, mon objectif est de remonter au besoin métier. En étant avec les personnes qui définissent ce besoin, on peut préciser avec elles les tenants et aboutissants, déterminer les contraintes, prendre les bonnes hypothèses. C’est aussi l’occasion de partager les impacts des décisions sur la solution finale.

La collaboration entre Product Owner et architecte sur le terrain va enrichir les deux côtés de la réflexion. Côté Architecture c’est l’occasion de mieux comprendre les besoins. Pour le PO, c’est l’opportunité d’appréhender les implications des choix, et ainsi de les faire murir et de les préciser.

Par la co-construction, et par une meilleure compréhension des enjeux, les solutions imaginées seront plus durables et cohérentes !

Si vous aviez une idée principale à appuyer en conclusion ?

Nolwen :

L’agilité et l’architecture apportent toutes les deux une vision à long terme, au niveau du Système d’Information mais aussi de l’organisation. Le développement de ces deux démarches et leur complémentarité au sein des entreprises peuvent beaucoup apporter au niveau stratégique des entreprises.

Dominique :

La co-construction ! Il n’y a pas un architecte d’un côté et un PO de l’autre. La richesse vient de la confrontation des différents points de vue au bénéfice de la solution.

Nolwen Ollivier

Consultante en organisation
management de projets

Dominique Baele

Consultant en architecture d’entreprise
et management de projets

Projexion est un cabinet de conseil en accompagnement au changement. Les profils variés des consultants, aussi bien Product Owners qu’architectes, chefs de projet, formateurs… apportent une vraie complémentarité à nos clients.

Vous souhaitez en savoir plus ? Découvrez notre formation à l’architecture d’entreprise, notre formation Agilité et gestion de produit ou contactez-nous pour nous rencontrer !