Un burn-out peut-il se produire lors de sprints Scrum en continu?
Je suis avec une petite startup 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 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 dois faire ensuite. Cela fait du bien de retirer une carte de fonction du plateau, de la compléter et de la mettre dans la pile de gravure.
Cependant, nous entrons maintenant dans notre 18e cycle de sortie de 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, sprints. Du début à la fin, j'ai l'impression de courir contre la montre pour maintenir notre vitesse de développement. Lorsque nous avons terminé avec le sprint, nous passons une journée à planifier l'ensemble de fonctionnalités et les estimations du sprint suivant, puis nous recommençons.
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 quelques petites choses et pour se 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 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 recherchent.
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 pendant votre rétrospective. La quantité de temps productif dans une journée qu'une équipe choisit de reconnaître lorsqu'elle fait sa planification de la capacité pour un sprint est appelée facteur de concentration .
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%, 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 parliez simplement de l'élan continu de sprint après sprint, pas nécessairement de votre productivité en une journée. Voici quelques suggestions de choses que nous avons essayé de traiter:
- Fin du sprint un vendredi matin. Faites réviser et rétrospectivement votre sprint le matin et laissez l'équipe travailler sur autre chose le reste de la journée pour se vider la tête. Reprenez avec la planification Sprint lundi.
- Nous avons introduit la notion de "lab days". Ce sont des journées entières pendant lesquelles l'équipe est retirée du projet et elle passe la journée à travailler sur l'amélioration de ses propres compétences techniques par le biais de recherches et de 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 Wikipédia 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 supérieure"
Ils pourraient aussi bien avoir une image d'icône de Scrum à côté de la définition de l'épuisement professionnel.
Si vous pensez que vous pouvez envoyer quelqu'un sur quelque chose d'autre pour une brève diversion pour corriger l'épuisement professionnel, vous n'avez évidemment pas réfléchi. Jamais 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 je reçoive enfin une pause. Non, ce qui se passe, c'est que vous vous rendez compte, Wow! Mon travail est nul. Maintenant, je peux vraiment voir comment la micro-gestion de mon stupide manager, le processus de développement n'est qu'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 d'emploi en quelque chose de moins stressant .
À mon humble avis, la Scrum courte de 2 semaines doit être interdite 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 ses 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 tels que les techniques de gestion du stress. Il y a des tas 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 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? C'est 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 elle se sent en tant qu'entité 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 bénéficient (jusqu'à une limite) de la "pression" que la timebox 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 principal dans une rétrospective.
Quant à "... le temps dans un environnement Scrum qui n'est pas assigné/non suivi pour faire des choses mineures et pour se vider la tête", en gardant l'engagement de l'équipe à x% de la capacité disponible (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 dans la plage de 60 à 70% semble être la norme) est la clé de la durabilité à l'intérieur d'un Sprint, et un `` jour de code gratuit '' 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 les gens qui 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 car tout le monde obtient le repos dont il a besoin en cours de route.
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 le faire. 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.
Une solution consiste à réduire le nombre d'heures de la journée consacrées au sprint.
Je connais des personnes dont les journées de travail ont consisté en seulement deux heures et demie de sprint, le reste de la journée étant consacré à diverses autres activités: soutien, allégement de la dette technique, recherche, etc. Leur vitesse de développement a été définie 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é.
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 que le rythme est toujours le problème lorsque les gens sont épuisés par ce processus. Même si garder une trace de tous vos progrès IS une bonne chose, cela peut aussi être un facteur de stress lui-même (et ne pas garder la trace peut être aussi bien), pas seulement parce que votre patron/PM sera sur vous s'ils voient que quelque chose ne se passe pas comme prévu, mais pour vous-même. Le simple fait de disposer de ces informations enregistrées fera que la plupart des gens travailleront un peu plus fort que vous le feriez normalement TOUT LE TEMPS et je ne suis pas sûr d'en mettre plus le temps sur vos estimations de temps réglera cela pour tout le monde. Je ne pense pas qu'un facteur de motivation (comme votre tableau de gravure) soit toujours positif.
Certaines personnes ne se sentiront pas de cette façon, d'autres le ressentiront. Il n'y a PAS UNE façon de travailler qui conviendra à tous. Je ne le serai jamais, à mon avis.
De plus, si vous dites que ces méthodes et sprints agiles ne deviennent pas plus efficaces/productifs, pourquoi les utilisez-vous du tout? Pourquoi pensez-vous que les entreprises souhaitent utiliser ces méthodes? Ce n'est pas parce qu'ils sont amusants ....
L'efficacité/productivité vient toujours à un certain type de prix, à mon avis. Il n'apparaît 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 par quelqu'un d'autre ou en l'automatisant.
À 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 de faire un travail supplémentaire au lieu de faire "le vrai travail", mais peu importe la taille de la tâche automatisée, vous profiterez toujours à 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. La plupart des entreprises ne le permettront jamais. Mais vous pouvez peut-être persuader votre employeur d'obtenir ce temps pour automatiser vos processus et ce travail pourrait être "hors du contrôle du sprint" pour permettre au temps dont vous parlez de "se reposer" et de récupérer de l'énergie pour un nouveau sprint.
Ce n'étaient 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 demandera. Lorsque "tout" ce que vous faites est tracé, vous vous poussez. Ou je me corrige, la plupart des gens travaillent de cette façon, certains se reposeront quand même.
Vous êtes dans votre 18e sprint!?
Compte tenu de 2 semaines par sprint, cela signifie 36 semaines de travail continu sur le même projet. Vous commentez également que cela fonctionne environ 6 heures par jour. Ça semble beaucoup!
Je ne sais pas grand-chose sur les méthodologies agiles (bien que nous utilisons 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, refaire les chiffres, si votre journée de travail dure 8 heures et que vous passez 6 heures à travailler, vous dépensez 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 prendra du temps, les sprints devraient être plus grands, pas 2 semaines, mais pas un mois. Considérez une courbe descendante sur votre tableau 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.
L'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: "travailler Nice, beau plus productif". (un peu lol à la fin avec l'aimable autorisation de daft punk + radiohead).
Je pense que vous manquez quelque chose, mais vous n'êtes pas le seul. Comme le dit Jim Highsmith: "La vélocité est de plus en plus utilisée comme une mesure de productivité (et non la mesure d'étalonnage de capacité qu'elle était censée être) qui concentre trop d'attention sur le volume de récits fournis. "
Je suppose que c'est ce qui arrive à votre équipe. Je recommande de lire ce post séminal IMHO de Highsmith: Velocity is Killing Agility!
Le rythme durable est un principe clé de l'agilité. Lors des pratiques de gestion (SCRUM) et d'ingénierie (XP), une équipe peut livrer sprint après sprint indéfiniment. Cependant, parce que l'on peut ne signifie pas que l'on devrait.
Il semble que vous ayez besoin d'un changement contre la chaîne sans fin 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 tourner hors d'une équipe. Pendant votre rotation, vous pouvez soutenir l'équipe de course, prendre des 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 hors de la ligne, une personne peut effectuer une rotation hors chaque 10e sprint (si une seule personne) ou chaque 5e itération (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 il est clair qu'avoir un peu de temps pour "affûter la scie" profiterait à l'équipe ainsi au projet. Garder l'équipe fraîche et concentrée est une très bonne chose. Mais nous devons nous rappeler, nous sommes payés et nous devons apporter de la valeur aux dollars que nous gagnons.