L'épuisement professionnel peut-il se produire lorsque vous effectuez des sprints Scrum en continu? [fermé]

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

À bien des égards, j'apprécie Scrum. Nous avons des sprints relativement courts (2 semaines) et j'aime bien le Burn Down Chart 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'une fonction du plateau, de la compléter, puis de la mettre dans la pile à brûler.

Cependant, nous entrons maintenant dans notre 18e cycle de publication de Sprint et je commence à me sentir un peu épuisé. Ce n'est pas que je n'aime pas mon travail ou mes collègues, c'est juste que ces sprints sont ... enfin, des 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 avons terminé le sprint, nous passons une journée à planifier l'ensemble de 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 manquons-nous quelque chose? Y a-t-il normalement du temps dans un environnement Scrum qui n'est pas assigné / non suivi pour faire des choses mineures et pour vous vider la tête?

Ceci 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 capables de maintenir votre rythme sur le long terme, c'est excellent - vous avez atteint l'hyperproductivité que toutes les équipes Scrum aspirent.

Alternativement, si vous constatez que vous surestimez la quantité de travail que vous pouvez réellement faire en une journée, vous devrez peut-être réévaluer cela lors de votre rétrospective. La quantité de temps productif dans une journée qu'une équipe choisit de reconnaître lors de la planification de sa capacité pour un sprint est appelée un facteur de concentration .

Henrik Kniberg a ceci à dire:

Le facteur de concentration «par défaut» que j'utilise pour les nouvelles équipes est généralement de 70%, car c'est là que la plupart de nos autres équipes se sont retrouvées au fil du temps.

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

Cependant, il semble que vous parlez simplement de l'élan non-stop du sprint après le sprint, pas nécessairement de votre productivité en une journée. Voici quelques suggestions de choses que nous avons essayé de résoudre:

• Terminez le sprint un vendredi matin. Faites revoir votre sprint et votre rétrospective le matin et laissez l'équipe travailler sur autre chose le reste de la journée pour se vider la tête. Ramassez avec la planification de Sprint le lundi.
• Nous avons introduit la notion de «jours de laboratoire». Ce sont des jours entiers que l'équipe est éloignée du projet et ils passent la journée à travailler sur l'amélioration de leurs propres compétences techniques par la recherche entre eux et la 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.

Extrait de Wikipedia sur l'épuisement professionnel: «l'épuisement professionnel est en grande partie un problème organisationnel causé par de longues heures, peu de temps d'arrêt et une surveillance continue des pairs, des clients et de qualité supérieure»

Ils pourraient tout aussi bien avoir une image d'icône de Scrum à côté de la définition du burnout.

Si vous pensez que vous pouvez envoyer quelqu'un sur autre chose pour une brève diversion pour réparer l'épuisement professionnel, vous n'y avez évidemment pas réfléchi. Partir en vacances après avoir été épuisé et retourner au travail en pensant, Wow! Maintenant, je suis rafraîchi et prêt pour encore 6 mois de cette torture jusqu'à ce que j'aie enfin une pause à nouveau. Non, ce qui se passe, c'est que vous vous rendez compte, Wow! Mon travail est nul. Maintenant, je peux vraiment voir comment le processus de micro-gestion et de développement de mon stupide manager est juste une autre façon de tirer le meilleur parti de moi pour moins et la vie est trop courte pour cela ... je devrais trouver autre chose à faire ou changer de travail en quelque chose de moins stressant .

À mon humble avis, Scrum court de 2 semaines devrait être interdit sauf à petites doses, pas plus de 4-8 d'affilée. Utilisez-le comme un outil pour des choses exceptionnelles ou critiques, pas continuellement. Utiliser le bon sens.

Vous vous fatiguez 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 dur, il est là pour vous aider à travailler de manière plus cohérente et avec une plus grande prévisibilité. Je vois souvent des gens confondre les symptômes d'une gestion de projet normale avec ce qu'ils perçoivent comme des symptômes de méthodologies agiles (c'est-à-dire «le client ne cesse de changer les exigences - ce doit être la faute de Scrum!»). C'est une distinction importante car 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 des tas d'informations sur la façon de réussir dans un environnement stressant.

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

Cela m'aide à coup sûr à ne pas m'épuiser.

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 les gens ne prennent pas le temps de vacances dont ils ont besoin, ou cela peut être dans les détails de la façon dont vous gérez vos mêlées. Les équipes sont efficaces sur le long terme parce que chacun obtient le repos dont il a besoin en cours de route.

Un sprint n'est pas un tiret de 100 verges; c'est un mile (aléatoire) dans un marathon, c'est-à-dire un rythme que vous pouvez maintenir indéfiniment.

Votre équipe mène-t-elle des rétrospectives à la fin de chaque sprint? Est-ce l'occasion pour l'équipe «d'inspecter et d'adapter» leur processus? En tant que ScrumMaster, je demande régulièrement à l'équipe d'évaluer comment l'équipe en tant qu'entité `` se sent '' et si elle s'amuse. Nous explorons pourquoi ou pourquoi pas, et expérimentons des ajustements et des alternatives.

D'après mon expérience, les membres de l'équipe apprécient (jusqu'à une certaine limite) la «pression» que la boîte de temps Sprint contraint. La clé est d'approcher, mais pas de dépasser, cette zone. Au besoin, l'étalonnage de cette zone est un point de contrôle de premier ordre dans une rétrospective.

Quant à "... du temps dans un environnement Scrum qui n'est pas assigné / non suivi pour accomplir certaines petites choses et pour se vider la tête", en gardant l'engagement de l'équipe à x% de la capacité disponible (des points, de préférence, mais des heures peuvent être utilisées si nécessaire; dans les deux cas, j'ai trouvé que quelque chose de l'ordre de 60 à 70% semble la norme) est la clé de la durabilité à l'intérieur d'un Sprint, et un `` jour de code libre '' occasionnel fonctionne bien pour les Sprints extérieurs.

Une solution est de réduire le nombre d'heures dans la journée passées sur le sprint.

Je connais des personnes dont la journée de travail consistait en seulement deux heures et demie de sprint, le reste de la journée étant consacré à diverses autres activités: support, allégement de la dette technique, recherche, etc. Leur vitesse de développement a été fixée en conséquence.

Cela peut sembler un peu extrême, mais si je ne me trompe pas, c'était une entreprise rentable jusqu'au récent choc économique généralisé.

Vous êtes dans votre 18e sprint !?

Considérant 2 semaines par sprint, cela signifie 36 semaines de travail sans interruption sur le même projet. Vous commentez également que travailler 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 concernant vos heures de travail (je veux dire, le temps que vous passez à faire une tâche) devrait être de 60% ~ 70%. Maintenant, refaites les chiffres, si votre journée de travail dure 8 heures et que vous passez 6 heures à travailler, vous passez vraiment environ 75% de votre temps de travail. Cela pourrait être une petite déviation qui vous a finalement fait ressentir ce sentiment.

OTOH, je crois que si votre projet prend du temps à être réalisé, les sprints devraient être plus longs, pas 2 semaines, mais pas un mois. Considérez une courbe descendante sur votre graphique d'épuisement professionnel: commencez votre sprint avec une tâche régulière et réduisez votre activité les 2 ou 3 derniers jours avant la fin du sprint.

Agile n'est pas une pierre avec la gravure: "travailler plus vite / plus fort / mieux / plus dur", c'est plus comme un ciel bleu avec des nuages ​​blancs qui disait: "travaille bien, beau plus productif". (un peu lol à la fin avec l'aimable autorisation de daft punk + radiohead).

Je comprends parfaitement ce que vous dites. Pour ceux d'entre vous qui disent «votre rythme est trop rapide», je ne suis pas sûr d'être d'accord pour dire que le rythme est toujours le problème lorsque les gens sont épuisés par ce processus. Même si suivre tous vos progrès est une bonne chose, cela peut aussi être un facteur de stress en lui-même (et ne pas suivre peut l'être aussi), 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 ces informations enregistrées est quelque chose qui obligera la plupart des gens à travailler un peu plus dur que vous le feriez normalement TOUT LE TEMPS et je ne suis pas sûr que consacrer plus de temps à vos estimations de temps résoudra ce problème pour tout le monde. Je ne pense pas qu'un motivateur (comme votre graphe brûlé) 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. Jamais, à mon avis.

De plus, si vous dites que ces méthodes agiles et ces sprints ne deviennent pas plus efficaces / productifs, pourquoi les utilisez-vous? Pourquoi pensez-vous que les entreprises souhaitent utiliser ces méthodes? Ce n'est pas parce qu'ils sont amusants ...

L'efficacité / la productivité vient toujours à un certain type de prix, à mon avis. Cela ne vient pas de nulle part simplement en utilisant les méthodes magiques (si vous comprenez mon point).

La seule façon pour vous de devenir plus efficace (travail et pression) et de faire moins de travail est de faire faire le travail à quelqu'un d'autre ou de l'automatiser.

À mon avis, il faut toujours revoir ses processus et voir ce qui peut être automatisé et passer du temps à automatiser vos processus à la place. L'automatisation se fait au prix d'un travail supplémentaire au lieu de faire «le vrai travail», mais quelle que soit la taille de la tâche automatisée, vous en tirerez toujours profit à long terme. TOUJOURS! Sinon un jour, sur deux. Pas un mois, deux. Pas un an, en 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. Cependant, la plupart des entreprises ne le permettront jamais. Mais peut-être pouvez-vous persuader votre employeur d'obtenir cette fois pour automatiser vos processus et ce travail pourrait être "en dehors du contrôle du sprint" pour laisser le temps dont vous parlez se "reposer" et reprendre de l'énergie pour un nouveau sprint.

Ce n'était 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 le sont! Lorsque vous n'avez aucune trace de ce que vous faites, vous vous reposerez lorsque votre corps vous le dira. Lorsque «tout» que vous faites est retracé, vous vous poussez. Ou je me corrige, la plupart des gens travaillent de cette façon, certains se reposeront de toute façon.

Un rythme durable est un principe clé de l'agilité. Lorsqu'elle effectue les pratiques de gestion (SCRUM) avec les pratiques d'ingénierie (XP), une équipe peut livrer sprint après sprint indéfiniment. Cependant, parce qu'on peut ne veut pas dire qu'on devrait.

Il semble que vous ayez besoin d'un changement par rapport à la chaîne interminable de sprints que vous voyez devant vous. Un certain nombre d'options peuvent être proposées. Chaque fois que X nombre de sprints, un membre de l'équipe (ou une paire) peut tourner hors d'une équipe. Pendant votre rotation, vous pouvez soutenir l'équipe de course, suivre un cours, vous concentrer sur un ensemble de pics, prendre des vacances, etc.

Si l'équipe a 5 paires, et que vous faites pivoter une personne hors de la ligne, une personne peut effectuer une rotation hors ligne tous les 10 sprint (si une personne seule) 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 et / ou votre partenaire commercial. Mais clairement, avoir un peu de temps pour "affûter la scie" serait bénéfique à l'équipe donc au projet. Garder l'équipe fraîche et concentrée est une très bonne chose. Mais nous devons nous rappeler que nous sommes payés et que nous devons valoriser les dollars que nous gagnons.

Je pense que quelque chose vous manque, mais vous n'êtes pas le seul. Comme le dit Jim Highsmith: «La vélocité est de plus en plus utilisée comme mesure de productivité (et non comme mesure d'étalonnage de capacité qu'elle était censée être), qui se concentre trop sur le volume de points d'histoire livrés.»

Je suppose que c'est ce qui arrive à votre équipe. Je recommande de lire l'article fondateur de ce Highsmith IMHO: Velocity is Killing Agility!