L’épuisement peut-il se produire lorsque vous faites des sprints de Scrum en continu?

Je suis avec un petit démarrage et nous avons commencé à utiliser une forme de cycle de développement Scrum / Agile.

À bien des égards, j’aime Scrum. Nous avons des sprints relativement courts (2 semaines) et j’aime bien le tableau de réduction des effectifs pour suivre les progrès de l’équipe. J’aime aussi le Feature Board, donc je sais toujours ce que je devrais faire ensuite. Cela fait du bien de retirer la carte d’un personnage du tableau, de la compléter et de la mettre ensuite dans la stack de combustion.

Cependant, nous entrons maintenant dans notre cycle de sortie du 18ème Sprint et je commence à me sentir un peu épuisé. Ce n’est pas que je n’aime pas le travail ou mes collègues, c’est juste que ces sprints sont … eh bien, les sprints . Du début à la fin, j’ai littéralement l’impression de courir contre la montre pour maintenir notre vitesse de développement. Lorsque nous en avons terminé avec le sprint, nous passons une journée à planifier les fonctionnalités et les estimations du prochain sprint, puis nous repartons.

Pour les personnes qui travaillent dans un processus de développement Agile / Scrum mature, est-ce normal? Ou est-ce qu’il nous manque quelque chose? Est-ce qu’il y a normalement du temps dans un environnement Scrum qui n’est pas assigné / non suivi pour faire des choses mineures et se vider la tête?

C’est relativement normal et peut parfois être une plainte des membres de notre équipe si les projets se poursuivent pendant une longue période.

La clé de ce dont nous parlons ici est le rythme durable . Si vous et votre équipe êtes en mesure de maintenir votre rythme à long terme, cela est excellent – vous avez atteint l’hyperproductivité que recherchent toutes les équipes Scrum.

Sinon, si vous constatez que vous surestimez la quantité de travail que vous pouvez réellement accomplir en une journée, vous devrez peut-être réévaluer cela pendant votre rétrospective. La quantité de temps productif dans une journée qu’une équipe choisit de reconnaître lors de la planification de ses capacités pour un sprint est appelée facteur de focalisation .

Henrik Kniberg a ceci à dire:

Le facteur de focalisation «par défaut» que j’utilise pour les nouvelles équipes est généralement de 70%, puisque c’est là que la plupart de nos autres équipes ont fini avec le temps.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Cependant, ce dont vous parlez, c’est tout simplement l’élan sans relâche du sprint après le sprint, pas nécessairement votre productivité en un jour. Voici quelques suggestions de solutions:

  • Terminez le sprint un vendredi matin. Ayez votre revue de sprint et votre rétrospective le matin et laissez l’équipe travailler sur autre chose le rest de la journée pour se vider la tête. Ramassez avec la planification Sprint lundi.
  • Nous avons introduit la notion de “jours de laboratoire”. Ce sont des journées entières pendant lesquelles l’équipe est retirée du projet et ils passent la journée à améliorer leurs propres compétences techniques grâce à des recherches et à une collaboration sur des sujets techniques spécifiques. La plupart du temps, ils n’ont absolument rien à voir avec le projet spécifique et permettent aux membres de l’équipe de réfléchir à des sujets plus légers.

De Wikipedia sur le burn-out: “le surmenage est en grande partie un problème d’organisation causé par de longues heures, peu de temps d’arrêt et une surveillance continue des pairs, des clients et supérieure”

Ils pourraient aussi avoir une image d’icône de Scrum à côté de la définition de l’épuisement professionnel.

Si vous pensez pouvoir envoyer quelqu’un d’autre pour une brève déjudiciarisation afin de corriger l’épuisement professionnel, vous n’avez évidemment pas réfléchi. Toujours partir en vacances après avoir été épuisé et retourner au travail en pensant, Wow! Maintenant, je suis rafraîchi et prêt pour 6 autres mois de torture jusqu’à ce que je reçoive enfin une pause. Non, ce qui se passe est que vous réalisez, Wow! Mon travail est nul. Maintenant, je peux vraiment voir comment le processus de développement et de micro-gestion de mon gestionnaire stupide est juste une autre façon de tirer le meilleur parti de moi et la vie est trop courte pour ça… Je devrais trouver autre chose pour faire quelque chose de moins stressant .

IMHO, court 2 semaines Scrum devrait être interdit, sauf à petites doses, pas plus de 4-8 dans une rangée. Utilisez-le comme un outil pour des choses exceptionnelles ou critiques, pas continuellement. Utiliser le bon sens.

Vous vous épuisez après 36 semaines de dur labeur; ce n’est pas Scrum, c’est la nature humaine! Scrum n’est pas là pour vous faire travailler plus fort, il est là pour vous aider à travailler de manière plus cohérente et plus prévisible. Je vois souvent des gens confondre les symptômes de la gestion de projet normale avec ce qu’ils perçoivent comme des symptômes de méthodologies agiles (c.-à-d. «Le client continue de changer ses exigences – ce doit être la faute de Scrum!»). C’est une distinction importante cependant parce que sans identifier la cause, vous ne pouvez pas traiter les symptômes. Personnellement, je chercherais des moyens de réduire l’épuisement professionnel, comme les techniques de gestion du stress. Il y a beaucoup d’informations sur la façon de réussir dans un environnement stressant.

Un sprint n’est pas un tiret de 100 verges; c’est un kilomètre (aléatoire) dans un marathon, c’est-à-dire un rythme que vous pouvez supporter indéfiniment.

Votre équipe mène-t-elle des rétrospectives à la fin de chaque sprint? C’est l’occasion pour l’équipe de “inspecter et adapter” son processus? En tant que ScrumMaster, je demande régulièrement à l’équipe d’évaluer le «ressenti» de l’équipe en tant qu’entité et si elle s’amuse. Nous explorons pourquoi ou pas, et expérimentons des ajustements et des alternatives.

Dans mon expérience, les membres de l’équipe apprécient (jusqu’à une certaine limite) la «pression» que la boîte de vitesse Sprint impose. L’essentiel est d’approcher, mais de ne pas dépasser, cette zone. Au besoin, le calibrage de cette zone est un sharepoint contrôle primordial dans une rétrospective.

Comme pour “… le temps dans un environnement Scrum qui n’est pas assigné / non suivi pour accomplir des tâches mineures et se vider la tête”, en gardant l’engagement de l’équipe à x% de la capacité disponible (points, de préférence, mais les heures peuvent être utilisées) si nécessaire, dans les deux cas, j’ai trouvé que quelque chose dans la fourchette de 60 à 70% semble être la norme est la clé de la durabilité dans un Sprint, et un «jour de code libre» occasionnel fonctionne bien pour les Sprints extérieurs.

Quel que soit le processus de développement que vous utilisez, si l’équipe est épuisée, quelque chose ne va pas. Cela peut être aussi simple que de ne pas prendre les vacances dont ils ont besoin, ou cela peut être dans les détails de la façon dont vous manipulez vos mêlées. Les équipes sont efficaces à long terme, car tout le monde a le repos dont elles ont besoin.

L’équipe sur laquelle je travaille actuellement résout très bien ce problème. Après trois sprints, nous avons une semaine durant laquelle chaque développeur peut travailler sur ce qu’il veut. Ces projets parallèles doivent être liés à la valeur de l’entreprise, mais il n’y a pas de pression pour y parvenir. C’est une mesure pour nous permettre aux développeurs d’explorer de nouvelles technologies, mais cela nous fournit également une semaine de travail plus détendu et amusant.

Cela m’aide bien sûr à ne pas me brûler.

Une solution consiste à réduire le nombre d’heures dans la journée passée sur le sprint.

Je connais des personnes dont les journées de travail ne représentaient que deux heures et demie de sprint, le rest de la journée étant consacré à diverses autres activités: soutien, allégement de la dette technique, recherche, etc. Leur vitesse de développement était déterminée en conséquence.

Cela peut sembler un peu extrême, mais si je ne me trompe pas, c’était une entreprise rentable jusqu’à ce que le récent choc économique généralisé ait frappé.

Je comprends parfaitement ce que vous dites. Pour ceux d’entre vous qui disent «votre rythme est trop rapide», je ne suis pas certain d’être d’accord pour dire que le rythme est toujours le problème lorsque les gens s’épuisent. Même si le suivi de tous vos progrès est une bonne chose, cela peut aussi être un facteur de stress (et ne pas suivre peut être aussi bien), pas seulement parce que votre patron / PM sera sur vous s’il voit que quelque chose ne va pas selon le plan, mais pour vous-même. Le simple fait d’avoir cette information connectée est quelque chose qui rendra la plupart des gens plus difficiles à travailler que vous ne le feriez normalement TOUT LE TEMPS et je ne suis pas sûr que consacrer plus de temps à vos estimations résoudra ce problème pour tout le monde. Je ne pense pas qu’un facteur de motivation (comme votre tableau d’épuisement) soit toujours positif.

Certaines personnes ne ressentiront pas cela, d’autres le feront. Il n’y a PAS UNE seule façon de travailler qui conviendra à tous. Ce ne sera jamais, à mon avis.

Aussi, si vous dites que ces méthodes et sprints agiles ne sont pas plus efficaces / productifs, pourquoi les utilisez-vous? Pourquoi pensez-vous que les entresockets veulent utiliser ces méthodes? Ce n’est pas parce qu’ils sont amusants …

L’efficacité / la productivité a toujours un prix, à mon avis. Il n’apparait pas de nulle part en utilisant simplement les méthodes magiques (si vous avez mon point).

La seule façon pour vous de devenir plus efficace (travail et pression) et de faire moins de travail consiste à faire faire le travail par quelqu’un d’autre ou en l’automatisant.

À mon avis, il faut toujours examiner ses processus et voir ce qui peut être automatisé et consacrer du temps à l’automatisation de vos processus. L’automatisation a pour effet de faire du travail supplémentaire au lieu de faire “le vrai travail”, mais peu importe la taille de la tâche automatisée, vous en tirerez toujours des bénéfices à long terme. TOUJOURS! Sinon un jour, sur deux. Pas un mois, deux. Pas un an, dans deux ans. Vous avez eu l’idée.

Cependant, j’aime l’idée d’avoir du temps libre pour travailler sur des projets personnels. La plupart des entresockets ne le permettront jamais. Mais peut-être pouvez-vous persuader votre employeur d’avoir ce temps pour automatiser vos processus et ce travail pourrait être «hors du contrôle du sprint» pour laisser le temps dont vous parlez de vous «reposer» et de récupérer de l’énergie pour un nouveau sprint.

Ce ne sont que mes 2 cents. J’ai un peu peur quand les gens disent que ces méthodes ne sont pas là pour nous rendre plus efficaces et travailler plus dur. Bien sûr qu’ils sont! Lorsque vous n’avez aucune trace de ce que vous faites, vous vous reposerez lorsque votre corps vous le demandera. Quand “tout” vous êtes tracé, vous allez vous pousser. Ou je me corrige, la plupart des gens travaillent de cette façon, certains se reposeront quand même.

Vous êtes dans votre 18ème sprint !?

Considérant 2 semaines par sprint, cela signifie 36 semaines de travail sans interruption sur le même projet. Vous commentez également ce travail environ 6 heures par jour. Ça semble beaucoup!

Je ne sais pas grand chose sur les méthodologies agiles (bien que nous utilisions en fait Scrum dans notre projet actuel), mais il y a un principe sur vos heures de travail (je veux dire, le temps passé à faire une tâche) devrait être de 60% ~ 70%. Maintenant, si vous faites des chiffres à nouveau, si votre journée de travail dure 8 heures et que vous passez 6 heures à travailler, vous consacrez réellement environ 75% de votre temps de travail. Cela pourrait être un petit écart qui vous a finalement fait ressentir ce sentiment.

Je pense que si votre projet prend beaucoup de temps, les sprints devraient être plus longs, pas 2 semaines, mais pas un mois. Considérez une courbe descendante sur votre tableau d’épuisement professionnel: Commencez votre sprint par une tâche régulière et réduisez votre activité au cours des 2 ou 3 derniers jours avant la fin du sprint.

L’agile n’est pas une pierre avec la gravure: “travailler plus vite / plus fort / mieux / plus dur”, c’est plus un ciel bleu avec des nuages ​​blancs qui se lisent: “travail agréable, beau plus productif”. (un peu lol à la fin de la courtoisie de daft punk + radiohead).

Le rythme durable est un principe clé de l’agilité. Lors des pratiques de gestion (SCRUM) et des pratiques d’ingénierie (XP), une équipe peut délivrer le sprint après le sprint indéfiniment. Cependant, parce que l’on ne peut pas dire que l’on doit.

Il semble que vous ayez besoin d’un changement contre la série infinie de sprints que vous voyez devant vous. Un certain nombre d’options peuvent être proposées. Chaque X nombre de sprints, un membre de l’équipe (ou une paire) peut quitter une équipe. Pendant votre rotation, vous pouvez soutenir l’équipe de course, prendre un cours, vous concentrer sur un ensemble de pointes, prendre des vacances, etc.

Si l’équipe a 5 paires et que vous faites pivoter une personne de la ligne, une personne peut effectuer une rotation off tous les 10 sprints (si une seule personne) ou toutes les 5 itérations (si une paire). Les questions de budget et de retour sur investissement pour vos activités devront être traitées par votre direction ou votre partenaire commercial. Mais clairement, avoir du temps pour «aiguiser la scie» serait bénéfique pour l’équipe, donc pour le projet. Garder l’équipe fraîche et concentrée est une très bonne chose. Mais nous devons nous rappeler que nous sums payés et que nous devons apporter de la valeur aux dollars que nous gagnons.

Je pense que vous manquez quelque chose, mais vous n’êtes pas le seul. Comme le dit Jim Highsmith: «Velocity est de plus en plus utilisé comme mesure de productivité (et non comme mesure d’étalonnage de la capacité qu’il était censé être) qui concentre trop d’attention sur le volume de récits livrés.

Je suppose que c’est ce qui arrive à votre équipe. Je recommande de lire le post séminal de mon Highsmith IMHO: Velocity is Killing Agility!