Adopter une culture Agile

S’il existe une leçon à apprendre de la dernière décennie de « transformations agiles », c’est qu’il n’y a pas de solution unique pour adopter ou implémenter une approche Agile. Chaque organisation a des besoins, des contraintes et des exigences différents. La suite aveugle d’une ordonnance n’entraîne pas de succès.

Le mouvement Agile consiste à trouver continuellement des moyens d’améliorer la pratique de la création de logiciels. Ce n’est pas à propos d’un standup ou d’une rétrospective quotidienne parfaite. Au lieu de cela, il s’agit de créer une culture où la bonne chose se produit plus souvent que non. 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 agile et une culture. Les recommandations ne doivent pas être suivies aveuglement. 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 longueur de sprint qui fonctionne pour la culture, le produit et le désir de fournir des mises à jour. Par exemple, la division Outils de développement chez Microsoft (environ 6 000 personnes) fonctionne dans les sprints de trois semaines. L’équipe de direction n’a pas choisi cette longueur de sprint ; elle provient de commentaires directs des équipes d’ingénierie. L’ensemble de la division fonctionne selon ce cycle de sprint de trois semaines. Les sprints sont depuis devenus le cœur de l’organisation. Maintenant, chaque équipe marche à la batte du même tambour.

Il est important de choisir une longueur de sprint et de rester avec elle. S’il existe plusieurs équipes Agile, elles doivent toutes utiliser la même longueur de sprint. Si les commentaires entraînent un changement, soyez réceptive. Cela deviendra clair lorsque le bon terme sera en place.

Une culture d’expédition

Peter Provost, directeur principal du programme de 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 signifie, c’est que l’expédition de vos logiciels vous apprendra des choses que vous ne pouvez pas et ne comprendra pas, sauf si vous expédiez réellement vos logiciels.

La nature humaine est de retarder ou d’éviter de faire des choses jusqu’à ce qu’il soit absolument nécessaire. Cela n’a pas pu être plus vrai quand il s’agit de développement de logiciels. Les équipes reportent les bogues à la fin du cycle, ne considèrent pas la configuration ou la mise à niveau avant d'y être contraints, et évitent généralement des éléments tels que la localisation et l'accessibilité autant que possible. Lorsque ce modèle apparaît, les équipes créent une dette technique qui devra être payée ultérieurement. L’expédition requiert que toutes les dettes soient payées. Vous ne pouvez pas tricher dans l'expédition. Pour établir une culture Agile, commencez par essayer d’expédier le produit à la fin de chaque sprint. Il ne sera pas facile au début, mais quand une équipe tente de le faire, ils découvrent rapidement toutes les choses qui devraient se produire, mais ne le sont pas.

É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 chambre, les bonnes conversations ont tendance à se produire. Il est toujours possible de réussir avec des équipes situées dans le monde entier et 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 réorganisées, toute dynamique qu'ils 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 tombent derrière 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 à répartir la charge de travail vers une autre équipe, plutôt que de répartir les personnes entre les équipes. Prendre une personne d'une équipe pour aider une autre et perturber les deux équipes, cela peut frustrer la personne déplacée, même si c'est temporaire. Tout cela affecte la productivité de l’équipe et, plus probablement que non, a un impact négatif sur la capacité à revenir à la planification.

L'équilibrage de la charge de travail au lieu des personnes permet à une équipe déjà établie d'intervenir et d'aider. Il 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’efforcez 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 à délivrer et assumer 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 s’ils possèdent le code requis pour corriger le bogue. Les équipes se renvoient les bogues lorsqu'elles 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 basées sur l'architecture. 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 agiles sont un parcours. Apportez des modifications et apprenez-en davantage. Au fil du temps, l’organisation développera la culture Agile dont elle a besoin.

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

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