Adopter une culture agile

S’il y a une leçon à tirer de la dernière décennie de « Transformations Agiles », c’est qu’il n’y a pas de solution unique pour adopter ou mettre en œuvre une approche Agile. Chaque organisation a des besoins, des contraintes et des exigences différents. Suivre aveuglément une ordonnance ne mènera pas au succès.

Le mouvement Agile consiste à trouver continuellement des moyens d’améliorer la pratique de création de logiciels. Il ne s'agit pas d’un standup quotidien parfait ou d’une rétrospective. Il s’agit plutôt de créer une culture où la bonne chose se présente assez régulièrement. Les activités telles que les standups et les rétrospectives ont leur place, mais elles ne changeront pas la culture d’une organisation.

Cet article détaille les éléments fondamentaux dont chaque organisation a besoin pour créer un état d’esprit et une culture Agile. Les recommandations ne doivent pas être suivies aveuglément. Chaque organisation doit appliquer ce qui est logique dans un environnement donné.

Planification et rythme

Il n’y a pas de longueur de sprint parfaite. Les équipes ont réussi avec des longueurs de sprint allant d’une à quatre semaines. Ce qui compte le plus est la cohérence.

Sélectionnez une durée de sprint qui convient à la culture, au produit et au désir de votre organisation de fournir des mises à jour. Par exemple, la division Outils de développement de Microsoft (environ 6 000 personnes) travaille en sprints de trois semaines. L’équipe dirigeante n’a pas choisi cette durée de sprint ; elle provient des commentaires directs des équipes d’ingénierie. Toute la division fonctionne selon ce calendrier de sprint de trois semaines. Les sprints sont depuis devenus la pulsation de l'organisation. Maintenant, chaque équipe marche au rythme du même tambour.

Il est important de choisir une durée de sprint et de s'y tenir. S’il y a plusieurs équipes Agile, elles doivent toutes utiliser la même durée de sprint. Si les commentaires entraînent un changement, soyez réceptif. Cela deviendra clair quand le bon terme est en place.

Une culture expédition

Peter Provost, directeur principal des programmes du groupe chez Microsoft, a déclaré : « Vous ne pouvez pas tricher l’expédition. » La simplicité et la vérité de cette déclaration constituent une pierre angulaire de la culture Agile. Ce que Peter veut dire, c’est que l’expédition de vos logiciels vous apprendra des choses que vous ne pouvez pas et ne comprendrez pas, à moins que vous n'expédiiez réellement vos logiciels.

La nature humaine est de retarder ou d’éviter de faire les choses jusqu'à ce que ce soit absolument nécessaire. Cela ne pourrait pas être plus vrai quand il s’agit de développement de logiciels. Les équipes repoussent les bogues jusqu'à la fin du cycle, ne pensent pas à la configuration ou à la mise à niveau avant d’y être obligées, et évitent généralement des choses comme la localisation et l’accessibilité dans la mesure du possible. Lorsque ce modèle apparaît, les équipes créent une dette technique qui devra être payée ultérieurement. L’expédition exige que toutes les dettes soient payées. Vous ne pouvez pas tricher sur l’expédition. Pour établir une culture Agile, commencez par essayer d’expédier le produit à la fin de chaque sprint. Ce ne sera pas facile au début, mais quand une équipe tente de le faire, elle découvre rapidement tout ce qui devrait se produire, mais ne se produit pas.

Des équipes saines

Il n’y a pas de recette pour l’équipe Agile parfaite. Toutefois, quelques caractéristiques clés rendent le succès beaucoup plus facile à atteindre.

Colocaliser les équipes dans la mesure du possible

Une équipe peut-elle trouver du succès avec des personnes réparties dans différentes zones géographiques ? Oui, mais c’est plus difficile. Lorsque les gens sont colocalisés et assis dans la même pièce, les bonnes conversations ont tendance à avoir lieu. Il est toujours possible de réussir avec des équipes situées dans le monde entier et dans différents fuseaux horaires. Mais cette même équipe n’aurait-elle pas un avantage sans tous ces obstacles ?

Conserver les équipes intactes pendant une durée raisonnable

Permettre aux équipes de maîtriser l’art de la création de logiciels ensemble. Lorsque les équipes sont brouillées, toute chimie qu’elles ont développée est perturbée. Parfois, il est approprié de réorganiser, mais les équipes sont généralement plus productives lorsqu’elles ont le temps d’apprendre à travailler ensemble. En guise de directive, essayez de garder les équipes intactes pendant au moins 12 mois.

Équilibrer la charge de travail, et non les personnes

Parfois, les équipes prennent du retard et ont besoin d’aide. Une tactique courante pour résoudre ce problème est de prêter une personne d’une équipe à une autre. Toutefois, cela peut être contre-productif. Une meilleure solution consiste à équilibrer la charge de travail avec une autre équipe, plutôt que d’équilibrer la charge entre les personnes. Retirer une personne d’une équipe pour en aider une autre perturbe les deux équipes, et peut frustrer la personne déplacée, même temporairement. Tout cela affecte la productivité de l’équipe et, plus probablement qu'autrement, affecte négativement la capacité à respecter le calendrier.

L’équilibrage de charge de travail au lieu de personnes permet à une équipe déjà établie d’intervenir et d’aider. Cela devient une conversation sur les priorités, et non sur les personnes.

Laisser les équipes posséder des zones de fonctionnalités, et non des couches d’architecture

S’efforcer de créer des équipes verticales qui possèdent des zones de fonctionnalités. Ces équipes sont responsables de tout le travail nécessaire pour ajouter des fonctionnalités à leur zone, de la base de données aux modifications apportées à l’interface utilisateur. L’équipe est habilitée à offrir et à posséder une expérience de bout en bout.

Lorsque les équipes horizontales possèdent des couches d’architecture, aucune équipe unique n’est responsable de l’expérience de bout en bout. L’ajout d’une fonctionnalité nécessite plusieurs équipes de coordonner et nécessite un niveau supérieur de gestion des dépendances. La résolution des bogues nécessite que plusieurs équipes examinent si elles possèdent le code requis pour corriger le bogue. Les bogues sont battus lorsque les équipes déterminent qu’il ne s’agit pas de leur bogue et l’assignent à une autre équipe.

Les équipes de fonctionnalités n’ont pas ces problèmes. La propriété et la responsabilité sont claires. Il peut y avoir une place pour certaines équipes architecturales. Toutefois, les équipes axées verticalement sont plus efficaces.

Étapes suivantes

À mesure que les équipes se lancent dans leur propre transformation Agile, gardez ces principes fondamentaux à l’esprit. N’oubliez pas qu’il n’y a pas de recette unique qui fonctionnera pour chaque organisation. Les transformations Agile sont un parcours. Apportez des modifications et apprenez-en. Au fil du temps, l’organisation développera la culture Agile dont elle a besoin.

Microsoft est l’une des plus grandes entreprises Agile au monde. En savoir plus sur la façon dont Microsoft a adopté une culture Agile pour la planification d'DevOps.

Découvrez comment Azure DevOps permet aux équipes d’adopter et de mettre à l’échelle une culture Agile.