Qu'est-ce qu'une équipe agile et comment la former ?
Le texte ci-dessous est la traduction d'un article de Mike Cottmeyer pour le site leadingagile.com :
Une équipe agile n’est pas simplement un regroupement aléatoire de personnes. Une équipe agile n’est pas un groupe d’analystes d’affaires faisant un daily standup – réunion quotidienne debout – pour coordonner leur travail. Ce n’est pas non plus un groupe de développeurs qui se réunissent toutes les semaines pour faire des sprint planning – réunions pour entamer une session de travail. Ce n’est pas une équipe de projet avec des gens matricés sur deux ou plusieurs équipes agiles.
Une équipe agile est un groupe inter-fonctionnel de personnes qui ont tout le nécessaire, matériel et humain, pour développer un produit fonctionnel et testé de façon incrémentielle. Ces personnes sont dédiées à l’équipe, et ont comme règle de ne pas changer d’équipe selon les allés et venues.
Je suggère que la définition même d’une équipe agile… un groupe inter-fonctionnel de personnes qui ont tout le nécessaire, matériel et humain, pour développer un produit fonctionnel et testé de façon incrémentielle… tire son besoin dans la formation des équipes agiles, surtout à cause de notre méprise de ce qu’est en fait un produit.
De façon simpliste cette orientation est simple… il s’agit d’un système qui part des interactions de l’utilisateur pour arriver aux données et inversement ainsi que toutes les compétences pour déployer et installer ledit produit en production. De manière générale, former une équipe comme cela n’est pas toujours possible, et aussi souvent que possible, n’est pas souhaitable.
De façon plus globale un produit est en fait un sous-système faisant partie intégrante de systèmes plus larges.
En acceptant cette définition, il devient souvent tout à fait possible de monter un petit groupe inter-fonctionnel de personnes qui ont tout le nécessaire, matériel et humain, pour développer un produit fonctionnel et testé de façon incrémentielle.
L’idée est de s’organiser autour des produits et des fonctionnalités quand c’est possible, et de s’organiser autour des sous-systèmes lorsqu’il y a des fonctionnalités partagées. Nous appelons cela collectivement les capacités entrepreneuriales. Une fois que vous avez compris les capacités entrepreneuriales, vous pouvez aligner les capacités entrepreneuriales avec l’architecture technique et finalement l’architecture organisationnelle.
L’intersection et l'organisation des architectures entrepreneuriale, technique et organisationnelle apparaissent lorsque vous former un groupe complet inter-fonctionnel de personnes qui ont tout le nécessaire, matériel et humain, pour développer leur partie du produit fonctionnelle et testée de façon incrémentielle.
Puisque vos architectures entrepreneuriale, technique et organisationnelle sont probablement cassées, vous allez avoir des dépendances entre les équipes qui devront être gérer. Pour l’instant.
Au cours du temps, le boulot de l’initiative de transformation est de casser ces dépendances.
Les dépendances sont mauvaises et doivent être cassées.
Plus vous avez à gérer des dépendances, moins vous êtes agiles, point.
Au cours du temps, en cassant ces dépendances, vous pourrez traiter chacune de ces équipes comme des équipes purement et parfaitement agiles.
Tant que vous ne commencez pas à former des équipes qui s’organisent autour des capacités entrepreneuriales et des architectures technique et organisationnelle, et que vous ne faites pas le difficile travail de casser les dépendances… tout ce que vous pourrez faire est d’aller vers du Scrum. Et vous n’aurez jamais la valeur à laquelle prétend l’orientation de votre travail.
Je vous le dis… la raison pour laquelle vous faites de l’agile sans vous sentir agile pour autant est parce que vous n’avez pas ce genre d’équipes et vous avez beaucoup trop de dépendances.
Aucun daily standup ne pourra résoudre le problème.
Une culture agile ne pourra pas faire le travail à votre place.
