Agile est un terme à la mode dans le développement logiciel. Certaines organisations et équipes se font passer pour « agile » alors qu'elles font en réalité quelque chose de très différent. J'ai pu le constater à maintes reprises au cours de ma carrière de coach Agile : un leader prétend adhérer aux valeurs agiles, mais microgère les équipes d'ingénieurs et utilise l'agilité pour forcer les développeurs à travailler de longues heures. Le résultat ? Certains ingénieurs de notre secteur. déteste le développement logiciel agile 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, je vais partager trois « problèmes » rencontrés par les ingénieurs avec Agile et Scrum. J'expliquerai ensuite pourquoi il ne s'agit pas de problèmes, une fois que vous aurez dissipé les « conneries » agiles propagées par les acteurs malveillants et les malentendus.

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

Conneries 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 de l'agile, par exemple, une cascade se faisant passer pour agile ou en 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 signaux d’alarme 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
• Répondre à l’ensemble des exigences du projet est considéré 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 micromanager les membres de leur équipe. Ils peuvent également confondre l'engagement d'une équipe Scrum envers le sprint avec une « garantie », 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 ; ce sont des problèmes de gestion. Or, une mauvaise gestion ne peut être surmontée par le développement logiciel agile. Cela revient à définir de mauvaises attentes quant aux objectifs des principes et valeurs agiles.

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 exige un engagement de la direction en faveur de l'agilité et peut être atteint grâce à des efforts de transformation agile (éventuellement avec le soutien d'un coach agile). Chez PagerDuty, nous disposons d'une équipe de direction agile dédiée à la construction et au développement de systèmes, de processus et d'une culture qui améliorent continuellement l'efficacité de notre organisation, libérant ainsi le plein 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. Le développement logiciel est géré par les personnes, et non par les processus et 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. Privilégiez l'orientation plutôt que la 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'il s'agit d'aborder 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 perçu comme une garantie. L'engagement de l'équipe est de faire de son mieux. J'aimerais qu'ils respectent cet engagement environ 80 % du temps. Ils doivent le prendre au sérieux et le consacrer au maximum. C'est essentiel pour que l'entreprise ait confiance en ses capacités.

Ce qui est important ici, c'est que l'engagement d'une équipe n'est pas considéré 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 relève moins de l'agilité que de la culture d'entreprise. Ceci étant dit, l'un des principes du manifeste agile est le suivant : 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 pourrait communiquer ses attentes de la manière suivante :

J'attends de chacun qu'il 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 que si c'est absolument nécessaire.

Notez que le manager ne demande pas à l'équipe de faire des heures supplémentaires régulièrement. 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, cela 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 leurs logiciels.

Lorsqu'une équipe Scrum commence à planifier son prochain sprint, elle sélectionne les éléments jugés prioritaires pour le client. Les décisions à long terme de l'équipe sont planifiées à l'avance dans sa feuille de route produit. Or, cette feuille de route est à double sens : un Product Owner définit le prochain problème le plus important à résoudre pour l'équipe. Les ingénieurs de l'équipe doivent fournir un retour sur la feuille de route et réagir s'ils estiment qu'il y a un point plus pertinent à traiter pour l'équipe.

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 de l'infrastructure.
• Si l'équipe a accumulé une dette technique importante, 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, au lieu d'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 potentiellement 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é), bilans 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 fournir des commentaires et d'adapter leur feuille de route produit afin de toujours travailler sur l'élément le plus précieux. Pour aller plus loin, ils planifient régulièrement des HackWeek 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 réalité quelque chose de très différent ? Nous serions ravis de vous lire dans le Communauté PagerDuty .