Les facteurs de stress dans le cadre de l’agilité et de Scrum et leur impact sur la performance.


Les membres de l’équipe ressentent du Stress? Mais voyons nous avons adopté l’agilité c’est Impossible !
Lorsque l’on relit les préceptes derrière Agile, scrum et xtreme programming on retrouve des éléments tels que :
– rythme de développement soutenable
– l’equipe décide de ce qu’elle pense pouvoir accomplir
– pas d’heures supplémentaires
– Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier.
– un des objectifs est de rendre le travail agréable
– avec des gens motivés
– …
Avec tout cela on peut, à juste titre, penser qu’avec l’adoption de l’agilité l’environnement de travail sera efficace et agréable, et que le stress sera absent et le plaisir omniprésent.

La réalité est toute autre, les équipes nouvellement devenues agile vivent d’intenses périodes de stress.

Qu’est ce que le stress ?
Selon wikipedia : Le stress (en anglais pression émotionnelle, de l’ancien français destresse) est l’ensemble des réponses d’un organisme soumis à des pressions ou contraintes de la part de son environnement, le tout dépendant toujours de la perception des dites pressions de la part de l’individu les vivant. Selon la définition médicale il s’agit d’une séquence complexe d’évenements se résultant en des réponses physiologiques, psychosomatiques. Dans le langage courant, on parle de stress positif (eustress en anglais) ou négatif (distress).

ON note immédiatement, que le stress n’est pas forcément négatif.

Selon de nombreuses études, il existe un lien direct entre l’intensité du niveau de stress subi par un individu et sa capacité à performer grâce à son adaptation aux changements de contraintes de l’environnement. En effet en absence de stress, l’efficacité est faible car la motivation et la mobilisation sont peu présentes; c’est ce qu’engendre la monotonie et l’absence de défi. Lorsque le niveau de stress augmente, dans un premier temps la performance augmente très significativement, on entre dans une zone ou le stress est en fait perçu comme un défi, un challenge, et devient un grand stimulateur. Lorsque le stress dépasse ce niveau et qu’il devient de plus en plus pénible de s’y adapter, la performance chute drastiquement, la motivation et la mobilisation disparaissent aussi rapidement.

La courbe suivante exprime clairement le phénomène.

Tout le défi pour l’équipe (et l’entreprise) est alors de trouver l’équilibre de stress pour maintenir un niveau de performance optimale.

Pour cela il faut d’abord identifier les facteurs de stress. Dans son étude sur le stress au travail, le docteur Patrick LÉGERON Psychiatre, praticien attaché au service hospitalo-universitaire du Centre hospitalier Sainte-Anne à Paris, nous propose le tableau suivant :

Évidemment, le gestionnaire et l’entreprise doivent être conscients de tous ces facteurs de stress et tenter de mettre en oeuvre tout ce qui permettrait de laisser place à un niveau de stress stimulant la performance.

Le Dr Légeron déclare aussi que les deux principaux facteurs sont la charge de travail et l’incertitude :

Actuellement les stresseurs les plus fréquemment retrouvés, et source des plus grandes difficultés pour les individus semblent être :
1) la charge de travail.
Celle-ci se caractérise par une quantité de travail importante à réaliser sous une forte contrainte de temps. Les interruptions de travail sont fréquentes (on parle de « zapping » des activités) : on estime ainsi qu’en moyenne un cadre est interrompu dans son travail toutes les dix minutes. Par ailleurs les objectifs à atteindre et le culte de la performance accentuent encore la pression ;
2) les incertitudes.
C’est une banalité de constater que le monde du travail est en pleine évolution. Il faut cependant souligner que l’accélération du rythme du changement est souvent associée à des incertitudes
majeures et à l’impossibilité de prévoir et donc de s’organiser. Que ce soit l’organisation de l’entreprise (fusions, restructurations, etc.) ou les technologies nouvelles (on parle maintenant du « techno-stress »), l’individu doit s’adapter sans cesse à la nouveauté et à l’inconnu.

Mais qu’en est il de notre environnement Agile ?

Dans l’article d’aujourd’hui je vais vous présenter quelques facteurs de stress provenant d’une mauvaise compréhension ou d’une mauvaise application des principes Agile-Scrum.

Premiere facteur: en rapport avec l’engagement individuel.
Les membres de l’équipe souffrent d’un attachement historique au respect des délais, si bien que l’évaluation qu’ils font des taches déclenche un sablier mental, qui fait augmenter le stress au fur et à mesure qu’on approche du délai. On retrouve ici le stresseur « Charge de travail ».
On ne veut pas décevoir ses coéquipiers ni se sentir moins « productif » que les autres, on ressent les daily sprints comme des facteurs de stress. (Stresseur lié aux difficultés relationnelles)

Autre résultante de ce comportement, on commence à tourner les coins ronds, non pas pour finir plus vite mais simplement pour ne pas trop depasser le temps évalué, et evidemment la qualité se dégrade.
En dégradant la qualité on induit deux nouveaux facteurs de stress :
– 1 : on va cumuler de la dette inévitablement, et comme on se doit d’être transparent les autres membres de l’équipe ainsi que le product owner en seront informés.
– 2 : on prend de gros risques de ne plus correspondre à la définition de fini et donc ne pas apporter de valeur durant le sprint. Comme on le sait, on vient de plus en plus stressé vis a vis de l’équipe.

Deuxième facteur: en rapport avec l’engagement collectif.
L’équipe prend le sprint backlog comme un engagement, une liste de fonctionnalités à livrer immuable. Elle se sent dans l’obligation de livrer l’ensemble du contenu. (Encore le stresseur lié à la charge de travail)
On remarque facilement ce comportement dès le sprint planning, on notera que l’équipe a tendance à vouloir en inclure moins que ce dont elle est capable afin de limiter son stress.
À vouloir absolument livrer l’ensemble, dès qu’elle rencontre des obstacles (stresseur lié à l’incertitude) et qu’elle prend un peu de retard par rapport à ce qu’elle avait envisagé, elle se retrouve dans la même position que dans la première raison et commet les mêmes erreurs avec les mêmes résultats.

Troisième Facteur : vouloir toujours faire plus et prendre l’augmentation de la vélocité pour objectif
Certaines équipes ont tendance à penser que la vélocité doit impérativement augmenter sprint après sprint pour démontrer qu’ils progressent ou tout simplement pour satisfaire leur fierté. Inévitablement l’équipe s’impose de plus en plus une charge de travail inatteignable, un rythme insoutenable, et immanquablement va se conduire à un échec et un sprint de 0 points qui, en plus d’avoir engendrer un énorme niveau de stress, va produire une grosse déception pour l’équipe.

Quatrième Facteur : des rétrospectives orientées « Performance »
Lorsque les rétrospectives sont orientées performance, on recherche à travers la rétrospective des moyens pour augmenter le volume, la quantité, la velocité. Comment en faire plus en moins de temps. Dans ces temps là on ne fait que renforcer les autres facteurs. On confond amélioration continue avec augmentation de la vélocité continue.

Comment éliminer ces 4 facteurs ?
Initialement il faut rappeler les vrais objectifs, les vrais enjeux : Livrer des logiciels de QUALITÉ et maximiser la COLLABORATION et l’APPRENTISSAGE.

Premier facteur : Il faut se rappeler que les temps évalués pour les taches ne sont pas des barrières mais des indicateurs d’ampleur sur lesquels on peut se baser pour évaluer l’avancement.
On pourrait donc changer ces indicateurs pour des valeurs comme « Petit, Moyen, Grand » ou si on veut chiffrer utiliser 4h, 8h, 16h sachant qu’une tache ne devrait pas dépasser 2 jours/homme. De cette façon on n’évalue plus les taches aussi précisément et donc on détruit le sablier mental.
La qualité étant l’objectif principal, le temps que l’on met à la réalisation d’une tache devient donc secondaire. Attention ca ne veut pas dire marginale, sinon on pourrait aller vers une dérive entraînant une vélocité très basse. Il faut aussi se souvenir que les pratiques Xtreme programming nous encouragent à rechercher la simplicité et donc les solutions les plus rapides respectant la qualité désirée. Il faut trouver l’équilibre!

Deuxième facteur : En plus de ce qui a été précisé pour le premier facteur, il faut préciser que le sprint backlog n’est pas un engagement, une liste d’éléments qui doivent impérativement être livrés mais simplement un prévision de ce qui pourrait être livré si tout le sprint se déroulait sans aucun obstacle ou évènement perturbateur.
Lorsque l’équipe a établi une vélocité historique, si la sélection respecte cette vélocité les chances de parvenir à livrer l’ensemble du sprint backlog sont grandes mais pas absolues. Ceci est tout à fait normal, l’équipe doit toujours composer avec un certain niveau d’incertitude.

Troisième facteur : le but, sprint après sprint n’est pas d’augmenter la vélocité mais de trouver quelle est la vélocité que l’équipe peut soutenir de façon constante.
Cet indicateur est essentiel au Product Owner pour évaluer le périmètre livrable dans un délai défini tout comme il est important pour la planification de l’équipe.
C’est ce message qu’il faut bien comprendre et transmettre à l’équipe.

Quatrième facteur : Se souvenir que les rétrospectives n’ont absolument pas pour objectif de trouver comment faire plus.
Ce qu’elles doivent permettre de trouver c’est comment faire mieux!
Mieux au niveau de la collaboration, mieux au niveau de la qualité, mieux au niveau des outils, mieux au niveau des interactions, mieux dans le relationnel, mieux comme plus agréable aussi, pas mieux comme plus … même si il se peut que faire mieux finisse pas faire plus ..

Advertisements

Durée des sprints : deux, trois ou quatre semaines ?


Je vois souvent des équipes qui se demandent quelle devrait être la durée de leurs sprints ? Deux, trois ou quatre semaines ?
En fait pour répondre à cette question, il faut d’abord comprendre quelles sont les differentes variables qui influencent ce choix.

Première variable : la taille de l’équipe.
On le sait, les équipes scrum doivent être constituées de 3 à 9 membres. On parle tout de même d’un ratio du simple au triple.
Des équipes de 3 personnes ont évidemment une capacité de développement moindre, partant de cette idée, des sprints courts ne permettront pas suffisament d’ajout de valeur, les sponsors (stakeholders) risquent de perdre interet pour les sprint review.
À l’opposé, de grosses équipes utilisant des sprints longs, vont produire beaucoup de valeur à chaque sprint et necessiter beaucoup de travail de plannification en amont des sprints. Il permettrons aussi moins de changements à faible coût.

Deuxième variable : l’experience de l’équipe
Si il s’agit d’une équipe qui a peu d’experience tant au niveau de l’approche agile qu’au niveau du travail collectif, des sprints plus courts entraineront une plus grande fréquence des sprint retrospective. Plus une équipe est jeune, plus les retrospectives, si elles sont bien conduites et si on applique les pistes d’améliorations que l’on y découvre, sont importantes. Elles sont l’élément principal de l’amélioration continue de l’équipe.
Pour une équipe plus aguerrie, le besoin d’amélioration est moins présent on peut donc se permettre d’étirer un peu les sprints.

Troisième variable : la disponibilité du Product Owner
Plus les sprints sont courts, plus les meetings de sprint planning, sprint review et sprint retrospective sont fréquents, bien qu’ils soient de durées proportionnelles au sprint, plus ils sont fréquents plus c’est demandant pour le po.
Un Product owner qui gererait plusieurs projets ou équipes aurait beaucoup de difficulté à tenir le rythme.
À l’opposé un po qui ne gère qu’une seule équipe pourrait trouver des sprints de 4 semaines beaucoup trop longs et manquant d’interaction.

Quatrième variable : le besoin de changement, de réactivité
Lorsque le projet nécessite une plus grande réactivité dûe à une compétition plus féroce, un domaine jeune en plein évolution, des sprints courts offriront au Product Owner la souplesse nécessaire pour assurer une grande compétitivité.

Sachant qu’il est peu recommandé de changer la durée des sprints en cours de release, avant de définir celle-ci, verifiez ces variables pour vous assurer le bon choix.

Scrum outil d’amélioration continue


Un des objectifs de scrum est d’encourager l’amélioration continue de l’équipe.

Qu’entend on par amélioration  continue ?
La philosophie japonaise du kaizen ( http://fr.wikipedia.org/wiki/Kaizen) présente l’amelioration continue comme une démarche quotidienne basée sur une participation volontaire de chacun qui engendre des progrès réels et peu onéreux.

Toute la philosophie du Kaizen réside dans ces phrases : « Fais-le mieux, rends-le meilleur, améliore-le même s’il n’est pas cassé, parce que si nous ne le faisons pas, nous ne pouvons pas concurrencer ceux qui le font. » « Mieux qu’hier, moins bien que demain. »


Quels sont les outils mis à notre disposition par Scrum pour permettre cette amélioration ?

L’outil principal proposé par Scrum pour atteindre cet objectif est bien entendu le Sprint Retrospective, meeting qui intervient à la fin de chaque sprint après la review.

Lors de la rétrospective on identifiera en équipe ce qui fonctionne bien, ce qui fonctionne moins bien et comment l’améliorer.
Dans cet article : https://sebastienboyer.wordpress.com/2012/02/14/scrum-sprint-retrospective-la-magie-des-post-its/ je partage certains trucs pour réussir ses rétrospectives.

Évidemment ce meeting n’a lieu qu’à tous les 2 à 4 semaines dépendant de la durée de vos sprints, on ne parle pas d’une démarche quotidienne.
Néanmoins une équipe qui cherche de façon proactive et volontaire à s’améliorer à ce rythme là est déjà un gage de succés.


Que cherche t on a ameliorer exactement ?

La réponse est en fait simple : absolument tout ce qui peut l’être ! Dans la mesure du raisonnable, tant au niveau de l’effort à fournir que des moyens financiers à déployer.
Concrètement on parle souvent, de l’équipe, de ses interactions, des outils, des processus scrum, des méthodes, de l’implication etc…

Les pieges pour une jeune équipe agile : la perte de focus, l’écart à la définition de fini


Lorsqu’une compagnie décide de prendre le virage de l’agilité, ses équipes de developpement font face à de nombreux pièges.
Bien sur l’ajout de scrum master experimentés aiderait grandement à prévenir l’équipe face à ces pièges, la réalité est que dans la plupart des cas l’entreprise va vouloir effectuer cette transition avec les effectifs déjà en place.
Dans cette optique il est impératif de former des employés à certains des rôles importants d’une équipe scrum.

1: un Product Owner, il faudra déjà identifier la bonne personne, quelqu’un qui connait le metier, les attentes du marché. Une personne qui allie à la fois des compétences techniques et commerciales serait idéale.

2: Des scrum master, il faudra prevoir deux scrum master par équipe afin qu’ils puissent se valider et se surveiller l’un l’autre pour s’assurer que celui qui jouera le role pendant le sprint n’oublie rien et ne devie pas du processus. On leur donnera le rôle en alternance de 2 ou 3 sprints.

Dans notre cas, j’ai suivi les deux formations, je joue donc le role de PO mais aussi celui de facilitateur et de coach agile auprès de l’équipe et des scrum masters.
C’est ce qui me permet de déceler les pièges dont je vais vous parler.

Le premier que je vous présente est la perte de focus.
Il faut se rappeler qu’un des objectifs du processus scrum est de maximiser la valeur de ce qui est créé en éliminant le superflus.
Pour les programmeurs qui ont une longue experience de développement waterfall, l’élimination du superflus n’est pas du tout une habitude.
Et dans le pire cas cela risque de se présenter comme suit :
Votre Product Owner va construire un backlog priorisé allant à l’essentiel.
L’équipe selectionnera ce qu’elle peut réaliser dans le prochain sprint en respectant les priorités du po.
Le sprint commence l’équipe ajoute des tâches reliées aux stories mais certaines de ces taches vont au dela de ce que decrivent les stories, elle en vient a fabriquer un marteau pneumatique pour écraser une mouche.
Elle anticipe sur ce qu’elle pense que le po priorisera pour les prochains sprints.
Et puis l’équipe identifiera des taches « urgentes » pour répondre à des besoins technologiques et réalisera ces tâches au dépend de celles nécessaires aux stories.

Le deuxième est l’écart à la définition de fini :
L’équipe oublie de se referer à la définition de fini pour valider que les stories qu’elle considère terminées le sont bel et bien.
Unvou plusieurs des éléments ne correspondent pas. Par exemple on oublie de valider un des browsers sélectionnés.

Résultat : peu ou pas de stories sont considerées finies.
Est-ce-que ce sprint est un echec ? Absolument pas, il est une source d’enseignements considérable !

Maintenant que l’on a identifié ces pièges, on peut trouver des pistes de solutions.
1- lors de chaque création de tâche reliée à une story, relire la story ET la définition de fini et se poser la question suivante « Comment cette tâche m’aide-t-elle à terminer cette story ?  »
Si la réponse n’est pas évidente, pourquoi réaliser cette tâche ? Plutôt se reposer la question « Comment finir cette story ou comment la finir mieux ou différemment ?

2- lors de l’ajout de tâches « urgentes » non reliées directement à une story, se poser la question suivante « Quel obstacle qui bloque la réalisation de stories de ce sprint cette tâche va-t-elle permettre d’éliminer et comment pourrais je le faire sans cette tâche ou avec une meilleure approche? »
Si la tâche demeure la meilleure option … go for it !
Sinon il faut se poser la question suivante  » Comment cette tâche va me permettre de réaliser les stories plus rapidement et m’assurer de les finir dans ce sprint et comment pourrais je faire autrement ou mieux ? »

Si la tâche ne demeure pas un réel levier dès ce sprint, bien qu’elle puisse être justifiée elle n’est pas urgente et devrait etre réevaluée et repriorisée avec le PO.

3- En tout temps chercher le chemin de moindre résistance permettant de créer la valeur ajoutée attendue par la story en éliminant le superflu.

4- Imprimer la définition de fini et la mettre très visible dans un lieu de passage ou bien exposée sur chaque cubicule afin qu’on s’en impreigne.

5- Se faire de mini démos en cours de sprint entre les membres de l’équipe pour valider l’aspect fini de chaque story terminée.