Adapter Agile pour des grandes équipes

Les mots volumineux et Agile ne sont pas souvent utilisés dans la même phrase. Les grandes organisations ont acquis la réputation d’être lents. Toutefois, cela change. De nombreuses grandes organisations logicielles effectuent avec succès la transformation vers Agile. Ils apprennent à mettre à l’échelle des principes Agile avec ou sans frameworks populaires tels que SAFe, LeSS ou Nexus.

Chez Microsoft, une telle organisation utilise Agile pour créer des produits et des services fournis sous la marque Azure DevOps. Ce groupe dispose de 35 équipes de fonctionnalités qui publient en production toutes les trois semaines.

Chaque équipe au sein d’Azure DevOps possède des fonctionnalités de début à fin et au-delà. Ils possèdent des relations avec les clients. Ils gèrent leur propre backlog de produits. Ils é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 de site en direct.

Selon les principes Agile, les équipes autonomes sont plus productives. Une organisation Agile souhaite que ses équipes aient le contrôle sur leur exécution quotidienne. Mais l’autonomie sans alignement entraînerait un chaos. Des dizaines d’équipes travaillant indépendamment ne produirait pas de produit unifié et de haute qualité. L’alignement donne aux équipes leur objectif et garantit qu’elles répondent aux objectifs de l’organisation. Sans alignement, même les équipes les plus performantes échouent.

Pour mettre à l’échelle 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 la plus grande organisation Agile à laquelle elle appartient, ont besoin d’un backlog clairement défini pour réussir. Les équipes lutteront pour réussir si les objectifs organisationnels ne sont pas clairs.

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

Une taxonomie courante est des épopées, des fonctionnalités, des histoires et des tâches.

Épopées

Les épopées décrivent les initiatives importantes pour le succès de l’organisation. Les épopées peuvent nécessiter plusieurs équipes et plusieurs sprints pour être accomplies, mais elles ne sont pas sans une fin. Les épopées ont un objectif clairement défini. Une fois atteinte, l’épopée est terminée. Le nombre d’épopées en cours doit être gérable afin de maintenir le focus de l’organisation. Les épopées sont divisées en caractéristiques.

Fonctionnalités

Les fonctionnalités définissent de nouvelles fonctionnalités nécessaires pour réaliser l’objectif d’une épopée. Les fonctionnalités sont l'unité de livraison ; elles représentent ce qui est livré auprès du client. Les notes de publication publiées peuvent être basées sur la liste des fonctionnalités récemment terminées. Les fonctionnalités peuvent prendre 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.

Articles

Les récits 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 fournir une valeur significative au client. Toutefois, une histoire terminée représente un logiciel de qualité de production. Les histoires sont l’unité de travail de l’équipe. L’équipe définit les récits requis pour terminer une fonctionnalité. Les récits se décomposent éventuellement en tâches.

Tasks

Les tâches définissent le travail nécessaire 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, caractéristiques, histoires) sont largement utilisés dans l’industrie.

Ligne d’autonomie

Une fois qu’une taxonomie est définie, l’organisation doit dessiner 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 dessinée sous les caractéristiques ci-dessous. La direction détient les epics et les fonctionnalités, qui assurent l'alignement. Les équipes possèdent des récits et des tâches, et ont une autonomie sur la façon dont elles s’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.

Planning

Pour mettre à l’échelle la planification Agile, une équipe a besoin d’un plan pour chaque niveau de taxonomie. Toutefois, il est important d’itérer et de mettre à jour le plan. Ce processus est nommé planification en vagues successives.

Le plan fournit une direction pour une période fixe avec l’étalonnage attendu à intervalles réguliers. Par exemple, un plan de 18 mois peut être étalonné tous les six mois.

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

Vision

La vision est exprimée par des épopées et définit la direction à 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 plénière. Comme la vision est destinée à être ambitieuse et beaucoup peut changer sur cette période, attendez-vous à atteindre environ 60% de la vision.

Saison

Une saison est décrite par le biais de fonctionnalités et définit la stratégie pour les six prochains mois. Les fonctionnalités déterminent ce que l’entreprise souhaite mettre en valeur pour ses clients. La direction détient le plan saisonnier et présente les plans saisonniers et la vision lors d’une réunion plénière. Tous les plans d’équipe doivent s’aligner sur le plan saisonnier de la direction. Attendez-vous à atteindre environ 80% du plan saisonnier.

Plan de 3 sprints

Le plan de 3 sprints définit les histoires et les caractéristiques que l'équipe terminera au cours des trois prochains sprints. L’équipe possède le plan et l’étalonne chaque sprint. Chaque équipe présente son plan à la direction via le chat des fonctionnalités (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 de 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 possède le plan 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 dans le sprint passé et leur focus pour le sprint suivant. Attendez-vous à accomplir environ 95% du plan sprint.

Ligne d’autonomie

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

Comme indiqué ci-dessus, la direction n’étend pas la propriété sous la ligne d’autonomie. La direction fournit des conseils à l’aide des plans de vision et de saison, puis donne à l’équipe l’autonomie pour créer des plans 3 sprint et sprint.

Discussions sur les fonctionnalités : Où l’autonomie rencontre l’alignement

Une réunion sur les fonctionnalités est une réunion informelle où chaque équipe présente son plan de 3 sprints à la direction. Cette réunion garantit que les plans d’équipe s’alignent sur les objectifs de l’organisation. Il aide également la direction à rester informé de ce que fait l’équipe. Le plan de 3 sprints est étalonné à chaque sprint, et les réunions sur les fonctionnalités sont organisées selon les besoins, généralement tous les un à trois sprints.

Une réunion de discussion sur les fonctionnalités 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 un jeu de 3 diapositives, avec les diapositives suivantes :

Fonctionnalités

La première diapositive présente les fonctionnalités que l’équipe va mettre en œuvre 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 ont besoin d’escalade.

Chaque équipe présente ses diapositives directement à la gestion. L’équipe présente comment son plan de 3 sprints s’aligne sur le plan saisonnier de 6 mois. Le leadership pose des questions précises et suggère des changements dans la direction. Ils 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 ce cas rare, l’équipe reprogrammera et organisera une deuxième discussion sur les fonctionnalités pour l’examiner.

Confiance : le ciment qui maintient l’alignement et l’autonomie ensemble

Lorsque vous pratiquez Agile à grande échelle, la confiance est un échange mutuel.

• La gestion doit faire confiance aux équipes pour faire la bonne chose. Si la gestion ne fait pas confiance aux équipes, elles ne donnent 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 gestion ne leur donnera pas d’autonomie.

Les responsables doivent fournir des plans clairs pour permettre aux équipes de s'aligner, puis leur faire confiance pour qu'elles puissent agir. Les équipes doivent aligner leurs plans avec l’organisation et s’exécuter de manière fiable.

À mesure que les organisations cherchent à mettre à l’échelle Agile vers des scénarios plus volumineux, la clé consiste à donner aux équipes l’autonomie tout en s’assurant qu’elles sont alignées sur les objectifs de l’organisation. Les blocs de construction critiques sont une définition claire de la propriété 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 adaptables.

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 agiles du monde. En savoir plus sur la façon dont Microsoft met à l’échelle la planification DevOps.