Agile est un terme à la mode dans le développement de logiciels, certaines organisations et équipes se faisant passer pour « agiles » alors qu’elles font en réalité quelque chose de très différent. J’ai vu cela à de nombreuses reprises au cours de ma carrière de coach agile : un dirigeant prétend adhérer aux valeurs agiles, mais gère de manière micro-économique les équipes d’ingénierie et utilise l’agilité comme un moyen de manipuler les développeurs pour qu’ils travaillent de longues heures. Le résultat ? Certains ingénieurs de notre secteur déteste le développement agile de logiciels parce qu'ils ont le sentiment que ce concept a été récupéré par des personnes extérieures à l'ingénierie pour les manipuler et gamifier la création de logiciels.

Dans cet article de blog, je vais partager trois « problèmes » rencontrés par les ingénieurs avec Agile et Scrum. Je répondrai ensuite en expliquant pourquoi ce ne sont pas des problèmes du tout, une fois que vous aurez fait le tri dans les « conneries agiles » que les mauvais acteurs et les malentendus ont répandues.

Avant de commencer, définissons « Agile BS » :

Connaissances agiles : Utilisation du terme « agile » pour désigner une équipe, un projet ou une organisation qui n'est pas aligné avec les principes et les valeurs d'Agile, par exemple, une cascade se faisant passer pour agile ou apposant le mot « agile » sur ce qui, en réalité, est un processus dysfonctionnel.

Pour ancrer cette définition dans votre esprit, voici quelques exemples de « conneries agiles » indiquant qu’une équipe ou une organisation n’est pas agile :

• Les membres de l'équipe d'ingénierie ne parlent pas et n'observent pas les utilisateurs du logiciel
• Les retours d'information continus des utilisateurs à l'équipe d'ingénierie ne se produisent pas
• La satisfaction de l’ensemble des exigences du projet est considérée comme une priorité plus élevée que l’expédition d’un MVP dès que possible pour obtenir un retour d’information précoce.

Pour en savoir plus sur les « BS agiles », consultez le Guide du ministère de la Défense pour détecter les conneries agiles Il est important de noter que les principes et valeurs agiles ont été créés pour résoudre les problèmes mêmes que les gens expriment parfois avec Agile, en particulier ceux évoqués dans cet article.

Problème 1 : Agile fournit de nombreux processus et outils que les managers peuvent utiliser de mauvaise foi, et peu d’entre eux permettent aux ingénieurs d’exercer une influence ascendante.

Il est vrai que les managers peuvent utiliser les Daily Standups pour microgérer les membres de leur équipe. Et les managers peuvent confondre l'engagement d'une équipe Scrum avec une « garantie », en poussant les ingénieurs à travailler de longues heures pour atteindre leur objectif de sprint (voir problème 2). Mais il ne s'agit pas de problèmes de développement logiciel agile, mais de problèmes de gestion. Et vous ne pouvez pas surmonter une mauvaise gestion avec le développement logiciel agile. Cela revient à définir de mauvaises attentes quant à ce que les principes et les valeurs agiles visent à accomplir.

Supposons qu'une organisation dispose d'une gestion adéquate. Comment peut-elle adopter l'agilité ? L'organisation doit vivre les principes et valeurs agiles à tous les niveaux. Cela nécessite un engagement envers l'agilité de la part des dirigeants et peut être réalisé grâce à des efforts de transformation agile (éventuellement avec le soutien d'un coach agile). Dans le cas de PagerDuty, nous disposons d'une équipe de direction agile dédiée à la création et au développement de systèmes, de processus et d'une culture qui améliorent en permanence l'efficacité de notre organisation, libérant ainsi tout le potentiel de nos équipes.

Étroitement liées à ce « problème », les valeurs agiles individus et interactions sur processus et outils. Qu'est-ce que cela signifie réellement ?

• Les personnes avant les processus. Les personnes gèrent le développement logiciel, pas les processus ni les outils.
• Une approche unique des processus et des outils ne fonctionne pas bien pour le développement de logiciels
• Méfiez-vous des processus qui ne permettent pas la variation et des outils qui entravent les interactions. Pensez orientation plutôt que gouvernance.

Lorsque l’on pense aux processus et aux outils, voici les signaux d’alarme indiquant qu’une équipe ou une organisation n’est pas agile :

• Les considérations de processus telles que la définition de ce qui est terminé sont définies de haut en bas pour les équipes d'ingénierie
• Les équipes ne sont pas propriétaires de leurs solutions de processus (par exemple, le choix Scrum contre Kanban )
• Les managers utilisent les Daily Standups et les Sprint Goals comme un moyen de microgérer leurs ingénieurs

Problème 2 : Agile confond intentionnellement les « estimations » avec les « engagements », manipulant les ingénieurs pour qu’ils travaillent des heures supplémentaires.

Je vais diviser ce problème en deux parties :

1. Agile confond intentionnellement « estimations » et « engagements »

Le langage est particulièrement important lorsqu'on parle de l'engagement d'une équipe. Pour expliquer le concept Scrum d'« engagement sprint », voici les conseils de Mike Cohn , co-fondateur de Scrum Alliance et d'Agile Alliance :

« Il est important que l’engagement de l’équipe ne soit pas considéré comme une garantie. L’engagement de l’équipe consiste à faire de son mieux. J’aimerais qu’elle respecte cet engagement dans 80 % des cas. Elle doit le prendre au sérieux et le faire la plupart du temps. C’est nécessaire pour que l’entreprise ait confiance dans ce que l’équipe dit pouvoir offrir. »

Ce qui est important ici, c'est que l'engagement d'une équipe n'est pas perçu comme une garantie L’équipe fait de son mieux, réfléchit à ce qu’elle a livré par rapport à son objectif à la fin de chaque itération et adapte son processus en conséquence.

2. Manipuler les ingénieurs pour qu'ils travaillent des heures supplémentaires

Faire des heures supplémentaires n'est pas tant une question d'agilité que de culture d'entreprise. Cela étant dit, l'un des principes du manifeste agile est que les processus agiles favorisent le développement durable Cela signifie-t-il que les ingénieurs n’auront plus jamais à travailler de longues heures ? Bien sûr que non.

Il est important que les responsables de l'ingénierie définissent des attentes appropriées en matière d'horaires de travail avec leurs équipes. Par exemple, un responsable de l'ingénierie peut communiquer ses attentes comme suit :

Je m'attends à ce que chacun travaille entre 40 et 50 heures par semaine. Cela correspond généralement à une journée de travail de 8 heures et à une astreinte une semaine par mois. Deux fois par an, je demande à l'équipe de faire des heures supplémentaires. Je ne le fais pas à moins que ce soit absolument nécessaire.

Notez que le manager ne demande pas à l'équipe de faire des heures supplémentaires de manière régulière. Il prévoit toutefois que cela puisse se produire plusieurs fois par an.

En rapport avec le développement durable, voici quelques signaux d’alarme indiquant qu’une équipe ou une organisation n’est pas agile :

• Lorsque l'équipe d'ingénierie s'engage dans un sprint, c'est synonyme de garantie
• L'équipe Scrum toujours respecte ses engagements de sprint
• L'équipe d'ingénierie travaille régulièrement des heures supplémentaires pour respecter son engagement de sprint

Problème 3 : La notion d’« engagement » de Scrum signifie produire une quantité spécifique de travail fini toutes les deux semaines, ce qui est trop hostile aux ingénieurs qui souhaitent prendre des décisions à long terme concernant le développement de leur logiciel.

Lorsqu'une équipe Scrum commence à planifier son prochain sprint, elle sélectionne les éléments qui sont considérés comme les plus prioritaires pour son client. Les décisions à long terme d'une équipe sont planifiées à l'avance dans la feuille de route du produit de l'équipe. Mais les feuilles de route des produits sont à double sens : un Product Owner définira le prochain problème le plus important que l'équipe devra résoudre. Il appartient aux ingénieurs de l'équipe de fournir des commentaires sur la feuille de route et de faire marche arrière s'ils estiment qu'il y a quelque chose de plus intéressant sur lequel l'équipe doit travailler.

Pourquoi les ingénieurs voudraient-ils fournir des commentaires (ou repousser) leur feuille de route produit ?

• Pour les équipes qui ont une rotation d'astreinte, si leur astreinte a été particulièrement bruyante et pénible ces derniers temps, leur travail le plus précieux pour le sprint à venir pourrait être de prioriser les améliorations d'infrastructure
• Si l’équipe a accumulé une grande quantité de dette technique, elle devra peut-être ajuster sa feuille de route pour se concentrer sur ce point avant que cela ne devienne plus problématique.
• Si l'équipe a reçu des commentaires d'un utilisateur ou d'une partie prenante, ce qui améliorerait la valeur qu'elle fournit, l'adaptation de sa feuille de route pour donner la priorité à la prise en compte de ces commentaires peut être son travail le plus précieux.

Lorsque vous réfléchissez à des décisions à long terme, voici les signaux d’alarme indiquant qu’une équipe ou une organisation n’est pas agile :

• L'équipe d'ingénierie reçoit une solution, plutôt qu'un problème à résoudre, de la part du Product Owner
• L'équipe d'ingénierie ne dispose pas d'un mécanisme permettant de fournir des commentaires sur la feuille de route du produit

À quoi ressemble le succès

Un développement logiciel agile réussi nécessite l'adhésion de l'organisation à tous les niveaux, l'engagement de l'ingénierie, la concentration sur le client et éventuellement l'intervention de coachs agiles dédiés.

Une fois qu’une organisation a adopté la véritable agilité :

• Les ingénieurs peuvent et doivent exercer une influence ascendante sur l'organisation en utilisant des mécanismes tels que des mesures (par exemple, l'engagement du produit, l'impact sur les revenus, la prévisibilité), contrôles de santé de l'équipe , et rétrospectives d'équipe
• Des équipes Scrum et Kanban bien formées sont reconnus pour offrir une valeur prévisible à leurs clients tout en travaillant à un rythme durable
• Les ingénieurs sont habilités de donner leur avis et d'adapter leur feuille de route produit afin de toujours travailler sur l'élément le plus précieux. Pour aller plus loin, programmer régulièrement une Hack Week donne aux ingénieurs une autonomie totale pour travailler sur ce qu'ils considèrent comme le plus important pour l'organisation.

Partagez vos apprentissages

Avez-vous remarqué d’autres façons dont les organisations et les équipes se font passer pour « agiles » alors qu’elles font en fait quelque chose de très différent ? Nous aimerions avoir de vos nouvelles dans le Communauté PagerDuty .