La place de 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 agile ? »
Le rôle qui est le plus souvent inséré ici, c’est celui d’architecte.
Mais comme pour tous les experts, la réponse est globalement la même.

Que dit le Manifeste ?

place-architecteUn des principes sous-jacents du manifeste agile indique que « les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisé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 vocable 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 (« et si cette personne se fait renverser par un bus et ne peut plus venir travailler, l’équipe pourra-t-elle continuer à produire ? ») ou de sa version sympathique : le Loto factor (« et 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 écrouler ces fameuses tours de savoir et diffuser la connaissance. On peut imaginer d’autres moyens (cf. 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 ?

expert-scrumD’ailleurs, en Scrum, la question est encore plus facile à trancher. Il n’y a que trois rôles : Product Owner, Scrum Master et Team Member. Tout porte à croire que l’expert devra être un team member. 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 être dans l’équipe.

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

proximite-expertsSi on utilise l’AME, L’Agile Manifesto Essence, comme référence nous permettant de déterminer la place de l’architecte dans une organisation agile, on parvient à une conclusion assez similaire. En effet, le principe de proactivité vise, entre autres, à minimiser les risques. On a 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. La proximité des experts et des équipiers en charge de la réalisation du produit semble être une bonne idée pour ce faire.
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 ? (je vous promets, on ne parle toujours pas de spiritualité)

cycle expertOn 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 sur 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 développeur tout simplement. 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 le terme classique de Scrum mais il 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 ?

architecteAutant 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 le faire ». »

L’architecture semble donc être une sorte d’engagement sur la solution qui intervient en amont du codage de celle-ci. 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 qu’il est généralement réalisé par des experts (les architectes). Cela me semble dissonner 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 oeuvre. 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é du BTP, semble confirmer cette impression. Doit-on oublier la notion d’architecture dans une organisation agile pour autant ?
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 ?

mutationOr, on a vu il y a quelques 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, 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.

Un commentaire sur “La place de l’architecte dans une organisation agile, c’est compliqué ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s