Press "Enter" to skip to content

Ne pas aller plus vite que la musique…

Un soucis qu’on voit souvent dans les organisations : les équipes sont mises sous pression pour délivrer plus.

Cette situation est-elle étonnante ? En soi, non. Je le vis d’ailleurs moi-même en étant maintenant à mon compte : on veut toujours en accomplir plus que ce qu’il est physiquement possible.

Ce qui est étonnant, c’est quand cette situation perdure depuis déjà des années.

C’est comme si on ne s’était jamais rendu compte que globalement on n’arrivait pas à livrer ce qu’on voulait. Que les projets en retard c’était normal. Que le turn-over était élevé sans faire le lien avec l’usure des personnes.

Si je reprend l’exemple de ma propre personne, aujourd’hui à mon compte : c’est exceptionnel de réussir à avoir accompli en fin de journée tout ce que je comptais faire. Et pourtant, je m’en rend compte. Ne serait-ce que parce que c’est extrêmement frustrant. 😠

Alors on analyse, on expérimente… On essaie d’optimiser sa propre efficacité. Et tôt ou tard on est bien obligé de s’y résigner : on n’est pas lent, on avance juste au rythme normal. Il faut se donner moins de travail à faire, voir les objectifs à la baisse. Et là, miracle ! Les journées deviennent épanouissantes. On a le sentiment du travail accompli en fin de journée. On est content de ce qu’on a fait plutôt que de regretter ce qu’on n’a pas pu faire. 😌

Ce cheminement intellectuel, c’est ce que devraient vivre aussi ces équipes et ces organisations. On a l’illusion d’être trop lent, on est frustré. (voire on est dans la panade si on l’a promis au client) Alors on réagit pour être plus efficace, avant de se rendre compte que ça ne change pas vraiment les choses. On se rend compte que le vrai problème est trop d’ambition ainsi que la création d’un niveau d’attentes trop élevé.

Bref, il faut moins se charger.

Pourquoi rien ne change ?

Alors pourquoi n’est-ce pas arrivé ? Pourquoi ces équipes continuent-elles à toujours trimer pour atteindre des objectifs irréalistes ?

Un premier élément de réponse se trouve peut-être dans les Rétrospectives. Tout d’abord : ont-elles bien lieu ? Et ensuite : sont-elles efficacement menées ? Car après tout c’est une boucle de feedback importante pour détecter ce problème et réagir. Sans Rétrospective, ou avec des Rétrospectives expédiées qui restent à un niveau superficiel, on peut passer à côté et même laisser la situation empirer.

Une culture à l’opposé

Regardons les faits. Par exemple les indicateurs, ce que disent les dashboards, ou encore les attitudes des personnes.

  • Pas de vélocité, c’est à dire pas de mesure du volume de travail qu’accomplit en moyenne une équipe. Le point essentiel ici est bien qu’il s’agit d’une mesure.
  • Le burn-down chart affiche par exemple les heures effectuées ou restantes de travail à faire. Et non pas le volume de travail réellement et complètement terminé, le fameux Done. Qu’est-ce que cela implique et suggère ? Que ce qui compte, ce n’est pas la création de valeur (ce qui passe par terminer des choses) mais bien de passer des heures à travailler (ce qu’il est possible de faire sans jamais rien terminer).
  • Ne pas respecter les estimations, c’est le drame. Cela fiche le plan en l’air. Lors des Rétrospectives, le sujet le plus souvent abordé, c’est comment améliorer les estimations pour qu’elles soient plus juste. Et c’est probablement ce qui arrive, mais grâce à quoi au final ? Estime-t-on réellement mieux ou bien ajuste-t-on consciemment ou inconsciemment le temps passé sur les tâches pour que cela corresponde aux estimations ? Quitte à rogner sur la qualité, ou à traîner un peu. Ou alors peut-être qu’on estime effectivement mieux, mais à quel prix ? Les équipes ne veulent plus donner d’estimation rapide, les études techniques deviennent obligatoires quand une estimation est demandée.
  • On objective les équipes sur des périmètres détaillés. Ainsi, lors d’un retard, le plan dérive. À moins d’un énorme coup de chance, ce retard ne sera jamais absorbé et il va falloir briser une promesse faite à un client. Et ne parlons même pas de la motivation d’une équipe à avoir pour rôle de dépiler une liste de chose sans sens plus large donné au travail.

Et si cela ne suffisait pas, ces éléments vont se renforcer entre eux :

  • Pour être le plus efficace possible, je me concentre sur mes tâches
  • Pour ne pas être en retard sur mes tâches, je n’aide pas mes collègues dans la même équipe
  • Comme le moindre retard est une mauvaise nouvelle, j’hésite avant de l’annoncer. J’espère jusqu’au dernier moment que ça va s’arranger et je retarde le moment de le communiquer
  • Je gonfle mes estimations, alors je passe pour un feignant, on ne me fait pas confiance et c’est quelqu’un d’autre — pas la personne qui fera le travail — qui décide des estimations, ce qui diminue encore ma motivation
  • Je ne suis pas motivé et je m’en fiche de ce qu’on construit, alors je n’aide pas mes collègues dans la même équipe
  • D’ailleurs comme on a peur que je glande, on calcule la capacité individuelle de chaque membre de l’équipe pour s’assurer que j’ai suffisamment de tâches pour être occupé pendant toute l’itération. Je n’ai vraiment aucune raison d’aider mes collègues dans la même équipe
  • Je rogne sur la qualité pour minimiser les retards, ce qui rend les estimations encore plus aléatoires, les retards encore plus imprévisibles, le travail plus long et moins efficace, et l’environnement moins épanouissant

Quelques pistes pour avancer

Objectif de Sprint et Daily Scrum

Notons tout d’abord que Scrum, de son côté, demande un engagement sur un objectif de Sprint et non pas sur le périmètre qui y mènera. Ce périmètre, ce n’est qu’un plan temporaire qui peut être révisé à tout instant si l’objectif de Sprint est en péril.

Chaque jour, en Daily, l’équipe se rencontre formellement pour vérifier si le plan tient toujours la route, et pour réagir si ce n’est pas le cas.

… Et non pas pour que chacun raconte sa vie à tour de rôle. Cela peut être une manière de l’animer mais ce n’est jamais le but.

Seul le Done compte

Soyez inflexible avec le Done. C’est la seule chose qui compte vraiment : que le travail soit vraiment, totalement, complètement terminé et dans son intégralité.

Les indicateurs doivent le refléter. Ainsi, le burn-down chart choisit cette granularité-là. Et oui, cela fera un escalier tout moche car le volume de travail terminé bougera par gros à-coups. Ce n’est pas grave, et cela envoie le bon signal.

Refusez également de voir les démonstrations de travaux qui ne sont pas terminés. Si ce n’est pas 100% terminé, c’est comme si c’était à 0%. Il n’y a pas d’intermédiaire significatif.

Au passage, valorisez bien ce travail comme un travail d’équipe. Si une seule personne n’a pas fait sa part, alors rien du tout n’est terminé, pour personne. À l’inverse, une fois que c’est terminé, félicitez l’équipe dans son ensemble pour le travail accompli.

Vélocité ou débit (throughput)

Quitte à continuer d’estimer le travail, il est essentiel que cela passe par une mesure, factuelle et moyenne, pour déterminer la quantité de travail que pourra livrer l’équipe d’ici la prochaine release. C’est la fameuse vélocité.

Ou alors, basez-vous plutôt sur le débit de livraison des tickets, ou throughput en anglais, et oubliez les estimations.

Lead Time

Un bon indicateur de performance de l’équipe est son Lead Time, c’est à dire le temps qu’elle met à livrer quelque chose, de bout en bout.

Pour optimiser cet indicateur, on va devoir travailler en équipe. Cet indicateur crée une dynamique saine et positive.

Slack Time

Cela ne sert à rien de charger l’équipe à 100%. Une bonne analogie reste l’autoroute : une autoroute remplie à 100%, cela s’appelle un embouteillage. Il faut garder de la marge pour que le système soit fluide.

On parle de Slack Time, littéralement temps de glandouille, pour désigner cette marge, cet investissement dans du temps non productif mais qui permettra au système d’être fluide.

Bref : ne chargez pas une équipe à 100%. Ou mieux encore : laissez-les décider du volume de travail qu’ils prennent et incitez-les à prendre de moins en moins de travail jusqu’à qu’ils arrivent à atteindre leurs objectifs de manière récurrente.

On ne négocie pas la qualité

Tout d’abord, on arrête de créer plus de dette technique. Avant même de commencer à boucher le trou, il faut déjà arrêter de continuer de le creuser.

Mesurez le taux de bugs introduits par nouvelle fonctionnalité implantée. Cette statistique doit diminuer avec le temps. Sinon, et bien demandez à l’équipe pourquoi et qu’est-ce qu’il faudrait faire pour que ça arrive. Croyez-moi, ils auront un tas d’idées.

Ne vous empêtrez par contre pas dans des outils comme SonarQube pour piloter cette qualité. Laissez les équipes s’en charger. Laissez-leur le temps de le faire.

Estimez s’il le faut pour le bien du Release Planning, mais une fois dans une itération ces estimations n’existent plus : on fait le travail comme il faut le faire et tant pis si cela ne correspond pas aux estimations. Cela marche évidemment dans les deux sens : si on va plus vite que prévu, inutile de s’appesantir et passons à autre chose.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top