L’architecte dans une organisation Agile, c’est compliqué?

On pose souvent ce genre de question à un agiliste convaincu : « Quelle est la place de [insérer un rôle ici] en Agilité ? » Le rôle qui est le plus souvent inséré est celui d’architecte. Mais comme pour tous les experts, la réponse est globalement toujours la même.

Que dit le Manifeste?

Un des principes sous-jacents du manifeste Agile est que « les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. » Les notions d’architecture devraient donc venir de l’intérieur de l’équipe. L’architecte serait donc un composant d’une équipe Agile.

Par ailleurs, le vocabulaire utilisé dans le manifeste Agile semble le confirmer. On y parle de commanditaires, de développeurs, d’utilisateurs et de clients seulement. Aucun autre type d’intervenant n’est cité.

En outre, je conseille d’éviter ce que Richard Sheridan appelle les « tours de connaissance » dans son livre Joy Inc. Le danger de concentrer un certain type de savoir chez un même spécialiste est bien connu. Il s’agit du Bus factor (« Si cette personne se fait renverser par un bus et ne peut plus venir travailler, l’équipe pourrait-elle continuer à produire? ») ou de sa version sympathique: le Loto factor (« Si la personne gagnait au Loto et venait déguisée en canard pour dire au revoir président? »)

Sheridan conseille le Pair Programming pour faire s’écrouler ces fameuses tours de savoir et diffuser la connaissance. On peut imaginer d’autres moyens (réf. les idées autour des T-Shaped Skills) pour y arriver, mais la proximité entre le spécialiste et les destinataires du partage de connaissances semble le moyen le plus efficace (le manifeste Agile insiste d’ailleurs sur l’efficacité du dialogue en face à face). Cela confirmerait donc la présence de ce genre d’experts dans les équipes de production.

Que dit Scrum?

D’ailleurs, en Scrum la question est encore plus facile à trancher. Il n’y a que trois rôles : Product Owner, Scrum Master et membre de l’équipe de développement. Tout porte à croire que l’expert devra être un membre de l’équipe. D’ailleurs, l’équipe doit être pluridisciplinaire (attention, cela ne signifie pas que tous les membres de l’équipe savent tout faire!) et doit donc posséder en son sein toutes les compétences nécessaires à la réalisation du produit. Si les connaissances de l’expert sont utiles pour ladite réalisation, alors il doit faire partie de l’équipe.

Que dit l’AME (non pas celle-là)?

Si nous utilise l’AME (Agile Manifesto Essence), comme référence nous permettant de déterminer la place de l’architecte dans une organisation Agile, nous parvenons à une conclusion assez similaire. En effet, le principe de proactivité vise, entre autres, à minimiser les risques. Nous avons déjà parlé du risque relatif à la concentration de certains savoirs entre les mains d’un nombre limité de personnes et de la possibilité de le diminuer en favorisant la diffusion des connaissances. Pour ce faire, la proximité des experts et des équipiers responsables de la réalisation du produit semble être une bonne idée.

Par ailleurs, le principe de personnes de l’AME nous explique que ces équipiers, étant ceux qui agissent, sont les mieux placés pour savoir quoi faire. Les préconisations d’experts qui ne seraient pas engagés dans la réalisation « risquent » de ne pas être adaptées, ou d’être irréalisables, voire irréalistes. Comme tout à l’heure, le principe de proactivité nous invite à tenter de minimiser ce risque. Intégrer les experts à l’équipe de réalisation semble aider à ce que leurs préconisations soient émises dans les meilleures conditions puisqu’ils feront partie de ceux qui font et donc de ceux qui savent.

Comment gérer les cycles de vie différents des experts et des équipiers?

On oppose souvent à cela que le temps pendant lequel les connaissances de l’expert sont utilisées n’est pas aussi long que le cycle de réalisation complet du produit. L’architecte intervient ponctuellement, surtout au début du cycle de vie du produit. Mais s’il doit malgré tout faire partie de l’équipe, que doit-on faire ?

Il y a deux solutions. La théorie des contraintes nous pousse à impliquer notre expert dans des tâches qui ne relèvent pas de sa spécialité si ses capacités spécifiques ne sont pas requises. Il pourrait être tout simplement développeur. L’autre solution consiste à dire que l’expert est certes membre de l’équipe mais pas forcément à temps plein. Cependant, le risque est grand d’obtenir un spécialiste n’intervenant que ponctuellement, sans être un véritable membre de l’équipe.

Il faut évidemment impliquer le plus possible l’expert dans la vie de l’équipe. L’idéal étant qu’il participe à toutes les cérémonies (j’utilise ici les termes classiques de Scrum, mais c’est applicable à d’autres méthodologies), à tous les rituels, les temps forts, de chacune des équipes dont il est membre. Cela signifie qu’il ne peut pas être membre de trop d’équipes à la fois ! Il doit en effet suivre le cycle de vie complet de la réalisation effectuée par chaque équipe dont il est membre.

Si on sait à présent où mettre les experts, et donc a fortiori les architectes, dans les organisations Agiles, nous pouvons pousser la question initiale un peu plus loin et nous demander quelle est la place de l’architecture dans l’Agilité.

OK pour l’architecte, mais quid de l’architecture?

Autant le sens donné à l’expertise n’était pas très important jusque-là (on traitait l’architecte comme n’importe quel spécialiste jusqu’à maintenant dans l’article), autant il me semble désormais important d’expliciter le terme « architecture ».

Je ne vais pas faire dans l’originalité, mais utiliser l’explication donnée par Wikipédia : « L’architecture logicielle décrit d’une manière symbolique et schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle d’architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre aux spécifications. L’analyse décrit le quoi faire alors que l’architecture décrit le comment faire. »

L’architecture semble donc être une sorte d’engagement sur la solution qui intervient en amont de son développement. D’expérience, j’ajoute que l’architecture est un procédé qui n’est pas anodin (en termes de temps, de coût, etc.), dont le résultat semble le plus souvent quasi figé, et qui est généralement réalisé par des experts (les architectes).

Cela me semble dissoner avec le principe de complexité de l’AME. Ce principe indique que la création d’un logiciel est un problème complexe (Captain Obvious!). Cela signifie qu’on ne peut pas établir de lien cause-conséquence a priori et que tenter d’apporter une réponse au problème modifie sa nature. Ainsi, s’engager sur le comment faire d’une solution a priori (et monopoliser des experts pour cela) me semble peu adapté.

Ce comment faire dans lequel on a investi de l’énergie deviendra peut-être inadéquat une fois qu’on aura vu le résultat de sa mise en œuvre. Il faudra peut-être abandonner l’architecture imaginée et passer à un autre type de solution; et ce ne sera peut-être pas chose aisée. Les coûts échoués seraient alors importants.

On a vraiment l’impression que l’architecture est une façon de faire imaginée pour répondre à des problèmes compliqués. Problèmes qui nécessitent le suivi de préconisations faites par des experts. Rien que le nom « architecture », inspiré de l’industrie du bâtiment, semble confirmer cette impression. Doit-on pour autant oublier la notion d’architecture dans une organisation agile?

Telle que définie plus haut, peut-être. Cependant, on peut imaginer que l’architecture permette de prévoir des comment faire particulièrement tolérants au changement, à la mise à jour ou au remplacement, ce qui limiterait l’effet « solution a priori non adaptée aux problèmes complexes adaptatifs. » Cela reviendrait à favoriser la proactivité (autre principe de l’AME), le fait de tenter de tirer le meilleur de chaque situation, à moindre coût, au sein des phases de réalisation de la solution.

L’architecture doit-elle muter?

Or, on a vu il y a quelque temps qu’on avait un rôle prévu pour favoriser la proactivité au sein des organisations : celui de Coach Agile. On pourrait s’en inspirer pour établir celui du remplaçant de l’architecte. D’ailleurs, Robert C. Martin, dit Uncle Bob et co-signataire du manifeste Agile, cherche dans cette direction avec son mouvement Software Craftsmanship au sein duquel on parle de plus en plus de coach (technique).

L’architecture n’est pas complètement incompatible avec l’Agilité. Mais comme les organisations doivent s’adapter, l’architecture doit muter, devenir quelque chose de plus adaptable, de plus perméable au changement. Cela nécessite éventuellement de nouvelles compétences et c’est sans doute pour cela que l’on assiste à l’émergence de postes de coaching dits techniques.