Mise à l’échelle d’Agile vers de grandes équipes

Les mots grand et Agile ne sont pas souvent utilisés dans la même phrase. Les grandes organisations ont acquis la réputation d’être lentes. Cependant, cela est en train de changer. De nombreuses grandes organisations logicielles réussissent leur transformation vers Agile. Elles apprennent à faire évoluer les principes Agile avec ou sans frameworks populaires tels que SAFe, LeSS, ou Nexus.

Chez Microsoft, une de ces organisations utilise Agile pour créer des produits et des services livrés sous la marque Azure DevOps. Ce groupe compte 35 équipes de fonctionnalités qui font des mises en production toutes les trois semaines.

Chaque équipe au sein d’Azure DevOps possède des fonctionnalités du début à la fin et au-delà. Elles sont responsables des relations avec les clients. Elles gèrent leur propre carnet de commandes de produits. Elles écrivent et vérifient le code dans la branche de production. Toutes les trois semaines, la branche de production est déployée et la version devient publique. Les équipes surveillent ensuite l’intégrité du système et corrigent les problèmes sur le site en direct.

Selon les principes Agiles, les équipes autonomes sont plus productives. Une organisation Agile veut que ses équipes aient le contrôle de leur exécution quotidienne. Toutefois, l’autonomie sans alignement provoquerait le chaos. Des dizaines d’équipes travaillant indépendamment ne produiraient pas un produit unifié et de haute qualité. L’alignement donne aux équipes leur objectif et garantit qu’elles atteignent les objectifs organisationnels. Sans alignement, même les équipes les plus performantes échoueraient.

Pour faire évoluer Agile, vous devez activer l’autonomie de l’équipe tout en garantissant l'alignement avec l'organisation.

Pour gérer l'équilibre délicat entre l'alignement et l'autonomie, les responsables DevOps doivent définir une taxonomie, définir un processus de planification et utiliser des conversations de fonctionnalités.

Définir une taxonomie

Une équipe Agile, et l'organisation Agile dans son ensemble, ont besoin d'un backlog clairement défini pour réussir. Les équipes auront du mal à réussir si les objectifs organisationnels ne sont pas clairs.

Afin de définir des objectifs clairs et d’indiquer comment chaque équipe y contribue, l’organisation doit définir une taxonomie. Une taxonomie clairement définie crée la nomenclature pour une organisation.

Une taxonomie commune est les épopées, les fonctionnalités, les histoires, et les tâches.

Épopées

Les épopées décrivent les initiatives importantes pour le succès de l’organisation. Les épopées peuvent prendre plusieurs équipes et plusieurs sprints à accomplir, mais elles ne sont pas sans fin. Les épopées ont un objectif clairement défini. Une fois atteinte, l’épopée est fermée. Le nombre d’épopées en cours doit être gérable afin de garder l’organisation concentrée. Les épopées sont divisées en fonctionnalités.

Fonctionnalités

Les fonctionnalités définissent les nouvelles fonctions requises pour atteindre l’objectif d’une épopée. Les fonctionnalités sont l’unité de mise en production ; elles représentent ce qui est livré au client. Les notes de version publiées peuvent être créées sur la base de la liste des fonctionnalités récemment terminées. Les fonctionnalités peuvent nécessiter plusieurs sprints, mais doivent être dimensionnées pour garantir un flux cohérent de valeur pour le client. Les fonctionnalités sont divisées en histoires.

Récits

Les histoires définissent la valeur incrémentielle que l’équipe doit fournir pour créer une fonctionnalité. L’équipe décompose la fonctionnalité en éléments incrémentiels. Une seule histoire terminée peut ne pas apporter de valeur significative au client. Cependant, une histoire terminée représente un logiciel de qualité production. Les histoires sont l’unité de travail de l’équipe. L’équipe définit les histoires requises pour compléter une fonctionnalité. Les histoires se décomposent éventuellement en tâches.

Tâches

Les tâches définissent le travail requis pour terminer une histoire.

Initiatives

Cette taxonomie n’est pas un système universel. De nombreuses organisations introduisent un niveau au-dessus des épopées appelées initiatives.

Les noms de chaque niveau peuvent être adaptés à votre organisation. Toutefois, les noms définis ci-dessus (épopées, fonctionnalités, histoires) sont largement utilisés dans l’industrie.

Une ligne d’autonomie

Une fois qu’une taxonomie est définie, l’organisation doit tracer une ligne d’autonomie. La ligne d’autonomie est le point auquel la propriété du niveau passe de la gestion à l’équipe. La gestion n’interfère pas avec les niveaux appartenant à l’équipe.

L’exemple suivant montre la ligne d’autonomie tracée sous les fonctionnalités. La gestion possède des épopées et des fonctionnalités, qui assurent l'alignement. Les équipes possèdent des histoires et des tâches, et disposent d'une autonomie sur la manière dont elles les exécutent.

Dans cet exemple, la gestion ne dit pas à l’équipe comment décomposer des histoires, planifier des sprints ou exécuter du travail.

Toutefois, l’équipe doit s’assurer que son exécution s’aligne sur les objectifs de la gestion. Bien qu’une équipe possède son backlog d’histoires, elle doit aligner son backlog avec les fonctionnalités qui lui sont attribuées.

Planification

Pour faire évoluer la planification Agile, une équipe a besoin d’un plan pour chaque niveau de la taxonomie. Toutefois, il est important d’itérer et de mettre à jour le plan. Ce processus s'appelle planification par vagues.

Le plan fournit une orientation pour une période de temps fixe avec un étalonnage prévu à intervalles réguliers. Par exemple, un plan de 18 mois pourrait être étalonné tous les six mois.

Voici un exemple de méthodes de planification pour chaque niveau d'une taxonomie : épopées, fonctionnalités, histoires, tâches.

Vision

La vision s'exprime à travers des épopées et définit l'orientation à long terme de l’organisation. Les épopées définissent ce que l’organisation souhaite terminer au cours des 18 prochains mois. La direction possède le plan et l’étalonne tous les six mois.

La vision est présentée lors d’une réunion générale. Comme la vision se veut ambitieuse et que beaucoup de choses peuvent changer au cours de cette période, attendez-vous à réaliser environ 60 % de la vision.

Saison

Une saison est décrite à travers des fonctionnalités et définit la stratégie pour les six prochains mois. Les fonctionnalités déterminent ce que l’organisation souhaite apporter à ses clients. La direction est propriétaire du plan saisonnier et présente la vision et les plans saisonniers lors d’une réunion générale. Tous les plans d’équipe doivent s’aligner sur le plan saisonnier de la direction. Attendez-vous à atteindre environ 80 % du plan saisonnier.

Plan à 3 sprints

Le plan à 3 sprints définit les histoires et les fonctionnalités que l’équipe terminera au cours des trois prochains sprints. L’équipe est propriétaire du plan et l’étalonne à chaque sprint. Chaque équipe présente son plan à la direction via la fonctionnalité chat (voir ci-dessous). Le plan spécifie comment l’exécution de l’équipe s’aligne sur le plan saisonnier de 6 mois. Attendez-vous à atteindre environ 90 % du plan à 3 sprints.

Plan de sprint

Le plan de sprint définit les histoires et les fonctionnalités que l’équipe terminera lors du prochain sprint. L’équipe est propriétaire du plan de sprint et l’envoie par e-mail à l’ensemble de l’organisation pour une transparence totale. Le plan comprend ce que l’équipe a accompli lors du sprint précédent et son objectif pour le prochain sprint. Attendez-vous à atteindre environ 95 % du plan de sprint.

Une ligne d’autonomie

Dans cet exemple, la ligne d’autonomie est tracée pour montrer où les équipes ont une autonomie de planification.

Comme indiqué ci-dessus, la direction n’étend pas la propriété en dessous de la ligne d’autonomie. La direction fournit des conseils en utilisant la vision et les plans de saison, puis donne aux équipes l'autonomie pour créer des plans à 3 sprints et de sprint.

Fonctionnalités chat : Où l’autonomie rencontre l’alignement

Une fonctionnalité chat est une réunion informelle au cours de laquelle chaque équipe présente son plan à 3 sprints à la direction. Cette réunion garantit que les plans d’équipe s’alignent aux objectifs organisationnels. Elle aide également la direction à rester informé de ce que fait l’équipe. Alors que le plan à 3 sprints est étalonné à chaque sprint, les fonctionnalités chats sont tenues selon les besoins, généralement tous les un à trois sprints.

Une réunion de fonctionnalités chat alloue 15 minutes à chaque équipe. Avec 12 équipes de fonctionnalités, ces réunions peuvent être planifiées pour durer environ trois heures. Chaque équipe prépare une présentation à 3 diapositives, avec les diapositives suivantes :

Fonctionnalités

La première diapositive présente les fonctionnalités que l’équipe dévoilera au cours des trois prochains sprints.

Dette

La diapositive suivante décrit comment l’équipe gère la dette technique. La dette est tout ce qui ne répond pas aux barres de qualité de la gestion. Le directeur de l’ingénierie définit les barres de qualité, qui sont les mêmes pour toutes les équipes (alignement). Les exemples de barres de qualité incluent le nombre de bogues par ingénieur, le pourcentage de tests unitaires réussis et les objectifs de performances.

Problèmes et dépendances

Les problèmes et dépendances répertoriés sur la diapositive finale incluent tout ce qui a un impact sur la progression de l’équipe, par exemple les problèmes que l’équipe ne peut pas résoudre ou les dépendances sur d’autres équipes qui nécessitent une escalade.

Chaque équipe présente ses diapositives directement à la direction. L’équipe présente comment son plan à 3 sprints s’aligne sur le plan saisonnier de 6 mois. Le leadership pose des questions précises et suggère des changements d'orientation. Elles peuvent également demander des réunions de suivi pour résoudre des problèmes plus approfondis.

Si le plan d’une équipe ne parvient pas à s’aligner sur les attentes de la direction, la direction peut demander un nouveau plan. Dans cet événement rare, l’équipe replanifiera et programmera une deuxième fonctionnalité chat pour l’examiner.

Confiance : la colle qui maintient l’alignement et l’autonomie ensemble

Lorsque l'on pratique Agile à grande échelle, la confiance est une voie à double sens :

• La direction doit faire confiance aux équipes pour faire ce qu'il faut. Si la direction ne fait pas confiance aux équipes, elles ne donneront pas d’autonomie aux équipes.

• Une équipe gagne en confiance en fournissant constamment du code de haute qualité. Si les équipes ne sont pas dignes de confiance, la direction ne leur donnera pas d’autonomie.

La direction doit fournir des plans clairs sur lesquels les équipes peuvent s’aligner, puis faire confiance à leurs équipes pour les exécuter. Les équipes doivent aligner leurs plans sur ceux de l’organisation et les exécuter de manière fiable.

Alors que les organisations cherchent à adapter Agile à des scénarios plus vastes, la clé est de donner aux équipes l’autonomie tout en s’assurant qu’elles sont alignées sur les objectifs organisationnels. Les éléments essentiels sont une propriété clairement définie et une culture de confiance. Une fois qu’une organisation a cette fondation en place, elle trouvera que Agile peut s’adapter très bien.

Étapes suivantes

Il existe de nombreuses façons pour une équipe de toute taille de commencer à voir les avantages aujourd’hui. Découvrez certaines de ces pratiques qui s'adaptent.

Découvrez les fonctionnalités d'Azure DevOps pour la gestion de portefeuille et la visibilité entre les équipes.

Microsoft est l’une des plus grandes entreprises Agile au monde. En savoir plus sur la façon dont Microsoft adapte la planification DevOps.