- Le développement logiciel d’aujourd’hui est bien plus stressant que dans les années 1990 et au début des années 2000
- À l’époque, le travail ne devenait fou qu’à l’approche des échéances, et le reste du temps était relativement calme
- L’auteur s’est demandé pourquoi le stress avait augmenté au cours des dernières décennies
- Ce n’est pas à cause de la concurrence, des évolutions du marché ou des délais serrés, mais à cause du travail en sprint
1. Les sprints ne s’arrêtent jamais
- Les sprints sont une suite ininterrompue d’échéances
- Le modèle waterfall était aligné sur de vraies dates limites et de vrais événements
- Les sprints sont des échéances artificielles, sans temps de repos naturel
- Le stress de courte durée peut être bénéfique pour la santé, mais le stress de longue durée est nocif pour l’organisme
2. Les sprints ne sont pas volontaires
- Ce n’est pas la même chose qu’une équipe qui choisit volontairement de déployer du code toutes les deux semaines
- Tous les aspects des sprints sont définis à l’avance
- L’autonomie joue un rôle important dans l’expérience de travail
- Le travail imposé provoque du stress et de l’inconfort
3. Les sprints ignorent les activités de support essentielles
- Les sprints ne laissent pas de temps pour préparer le travail suivant
- Un temps de préparation est nécessaire pour accomplir le travail
- Les sprints tentent de séparer préparation et exécution, mais cela génère du stress
Scrumban/waterfall : la vraie image (et en pire)
- La plupart des implémentations de Scrum sont un mélange de waterfall et de Scrum
- Une grosse échéance est toujours présente en arrière-plan
- Quand cette grosse échéance approche, Scrum s’interrompt et le stress augmente
Conclusion
- Les sprints n’offrent aucun répit, peu d’autonomie et pas assez de temps de préparation
- Les développeurs devraient pouvoir contrôler leur travail et leur processus
- Pour cela, il faut par exemple construire une organisation éthique ou passer au freelancing
Résumé de GN⁺
- Cet article explique pourquoi la méthode Scrum génère un stress continu chez les développeurs
- Les principales causes sont la succession permanente d’échéances, le manque d’autonomie et le manque de temps de préparation
- Il faut permettre aux développeurs de contrôler leur manière de travailler
- Parmi les autres approches offrant des fonctionnalités similaires, on trouve la méthode Kanban
8 commentaires
Même lorsqu’on mène des projets comme des SI publics, on pousse sans relâche avec des phases 1, 2, 3, etc. Et à chaque phase individuelle, il y a encore énormément de changements. Dans ces conditions, il est absolument impossible d’atteindre l’objectif même du scrum, qui est de développer avec succès. Au final, dans cette ambiance chaotique et désordonnée, seuls les développeurs s’épuisent complètement.
Je suis PM en poste.
Dans les organisations Agile/Scrum qui me semblaient bien fonctionner, à la fin des principaux sprints, on faisait une rétrospective et on nous accordait du temps pour souffler. L’équipe de développement comme l’équipe produit avaient un moment pour se reposer avant de préparer la suite.
Dans les modes de fonctionnement qui, comme dans l’article, me semblaient ne pas bien marcher, le stress s’accentuait parce qu’on faisait aussi tourner un mode Scrum en interne dans l’équipe produit, tout en restant sous des deadlines imposées en waterfall. Et comme ces deadlines elles-mêmes n’étaient pas négociables, on courait chaque semaine sans même avoir le temps de se reposer ou de faire une rétrospective, avec l’impression d’une course sans fin.
D’après moi, l’intention du waterfall est d’identifier autant que possible les exigences dès le départ et, puisqu’il existe des dépendances entre les phases de conception, d’implémentation et de test, de faire le travail dans l’ordre. Et l’intention de l’agile et des sprints serait de découper en petites parts un travail trop volumineux pour être conçu ou implémenté à l’avance avec une approche waterfall, puis d’essayer ainsi. Les deux ont leurs avantages et leurs inconvénients, et je me dis qu’au lieu de poursuivre une méthodologie de façon dogmatique, on pourrait simplement sélectionner ce qui est nécessaire selon la situation. Comme l’affirme l’article, il faut aussi des temps de pause, ainsi que du temps de préparation pour les revues techniques ou la création de prototypes. Peu importe qui décide de l’ordre des tâches, tant qu’on comprend les éléments perturbateurs et qu’on fixe les priorités selon le flux réel du travail, je me demande même si la question de l’autonomie des développeurs a tant d’importance.
Est-ce que ce genre d’articles apparaît sur des blogs étrangers parce qu’il y a beaucoup de managers, sans aucune expérience de développement, qui essaient d’appliquer aveuglément les procédures des méthodologies de développement ? Cela me rappelle presque les conflits, chez nous, entre des chefs de produit qui ne connaissent rien au terrain et les développeurs.
La personne la mieux placée pour définir les priorités selon le flux réel du travail, c’est sans doute le développeur lui-même. J’estime donc que lui retirer son autonomie et confier cela à quelqu’un d’autre comme principe même finit au contraire par créer une séparation entre le terrain et la planification de l’équipe.
Si le management est en soi un domaine d’expertise, alors même un manager sans expérience du développement devrait, lorsqu’il se retrouve face à une situation où la gestion des ressources de développement ne fonctionne pas bien, adapter son approche ou y répondre lui-même. Pourtant, j’ai trop souvent vu cette responsabilité être reportée sur les contributeurs individuels...
Oui, en fin de compte, c’est au manager d’en assumer la responsabilité. Mais visiblement, dans la réalité, ce n’est pas le cas. Un peu comme un CEO qui sait seulement faire de la gestion, sans rien comprendre au métier de l’entreprise, et qui finit parfois par la mener à sa perte.
Il y a tellement de PM qui ne font que jouer au ping-pong, bouhouhou...
Avis Hacker News
En citant Rich Hickey, l’idée est que les programmeurs, contrairement à des coureurs de courte distance, résolvent les problèmes en relançant sans cesse un nouveau sprint, comme si on redonnait le signal de départ tous les 100 yards
J’en suis venu à détester les processus logiciels. Si l’on dimensionne correctement l’équipe et qu’on donne aux développeurs l’autonomie nécessaire pour atteindre leurs objectifs, ils peuvent très bien s’en sortir sans tout le flux de productivité managérial. Agile et consorts existent pour que les managers justifient leur salaire
Je me demande ce que signifie « les sprints ne sont pas volontaires ». L’équipe choisit les caractéristiques du sprint, elles ne sont pas attribuées au hasard. C’est une collaboration entre le leadership, les membres de l’équipe et les parties prenantes externes à l’équipe. J’aimerais qu’on explique pourquoi Scrum est trop rigide
Dès l’apparition de Scrum, j’ai trouvé absurde que les développeurs enchaînent les sprints en permanence. Un sprint est censé être court et rapide, puis nécessiter du repos. Transformer tout le travail en sprint, c’est de la folie
Dans la pratique, Scrum se transforme souvent en un « scrumpfall » encore pire. Au départ, Scrum était utilisé pour faciliter la communication d’équipes à distance, puis cela s’est peu à peu transformé en objectifs dictés par le marketing et en sprints stressants. Le burn-out des développeurs est devenu évident
Au début des années 2000, les équipes d’ingénierie travaillaient de façon autonome, sans chef de projet. Les logiciels n’étaient pas aussi interconnectés qu’aujourd’hui et les cycles de déploiement étaient plus longs. Maintenant, avec le CI/CD et le déploiement continu, tout va très vite. SCRUM est stressant
La plupart des discussions peuvent se résumer à : « Scrum dans mon entreprise est mauvais à cause de X, Y, Z » et « ce n’est pas du vrai Scrum idéal »
Je développe des logiciels depuis 40 ans et, quelle que soit la méthode utilisée, il faut découper le travail et montrer que les objectifs sont atteints. Dans une petite équipe avec une base de code simple, Kanban peut suffire, mais dans les grandes équipes ou pour des solutions complexes, il faut du reporting
Nous n’utilisons ni Agile, ni Scrum, ni standups. Nous réajustons les priorités lors d’une réunion hebdomadaire et suivons l’avancement via un système de tickets. Les développeurs travaillent de manière autonome. Il faut passer plus de temps à coder qu’en réunions ou en rapports TPS
Après avoir travaillé dans 8 entreprises, l’approche Shape Up de Basecamp a été la plus efficace. Il est important de demander non pas « combien de jours », mais « combien de temps sommes-nous prêts à y consacrer ». Shape Up prévoit des périodes de cooldown entre des cycles de 6 semaines et permet de livrer des produits de manière régulièrement réussie