Il m’est arrivé de travailler avec des clients ayant une certaine fragilité. Cette fragilité n’apparaissait pas au grand jour au quotidien. Lorsque tout ce passait bien, ils étaient capables de finir leurs tâches et de livrer le produit fini.

Mais que se passe t’il lorsqu’une personne insère du code qui casse quelque chose « quelque part ». Ou lorsque quelqu’un est amené à travailler sur les problèmes de production et qu’il n’est plus disponible pour l’équipe pendant plusieurs semaines. Ou s’il y a une catastrophe naturelle et que les personnes se trouvent dans l’incapacité de se rendre au travail.

Les managers pensaient auparavant qu’il était possible de se remettre de ces différents évènements. Les équipes peuvent s’en remettre. Toutefois, elles ne peuvent pas s’en remettre rapidement.

Les équipes ont peu de résilience.

Les équipes peuvent mettre des semaines à s’en remettre. Les managers pensent que c’est « trop long ». Je suis tout à fait d’accord. Et les managers ne réalisent pas que leurs décisions ont créé ces problèmes.

Définir la résilience

Lorsque je parle de résilience, je parle de la capacité à expérimenter une alternative. Quelques fois, cette expérience n’est qu’une petite étape (comme dans l’image). Quelques fois, il s’agit d’une expérience à réaliser à partir d’une hypothèse, etc

(Si vous voulez en savoir plus sur la résilience, lisez Quelle est la différence entre résilience et adaptabilité (vo) ? sur mon autre blog.)

Les équipes peuvent construire la résilience de plusieurs manières. Dans cette série d’articles, je vais uniquement aborder les trois problèmes suivants sur la résilience d’équipe :

  • L’équipe ne travaille pas en tant qu’équipe - elle travaille de manière individuelle
  • L’équipe a de longues boucles de feedback
  • L’équipe n’a pas la capacité de travailler « n’importe où » et certainement pas « n’importe quand »

Cet article aborde le problème lorsque les gens travaillent individuellement.

Du travail individuel, pas d’équipe

L’Entreprise A travaille sur son énième « transformation agile ». J’ai mis cela entre guillemets parce que les managers veulent que les équipes changent. En réalité ce sont les managers qui doivent d’abord changer.

L’un des plus gros problèmes c’est que les managers pensent que les approches agiles leur permettront de livrer plus vite. Oui, et, cette livraison découle de cycles de feedback rapides, autrement dit d’apprentissages rapides.

Le développement de produit logiciel c’est de l’apprentissage (vo) avant tout. Le plus rapidement nous apprenons, le plus vite nous pouvons livrer quelque chose d’utile.

Quand nous n’apprenons pas ensemble, nous livrons de la merde. Ou bien alors, nous ne pouvons pas livrer et c’est la merde. Je ne sais pas ce qui est le pire - le fait de livrer de la merde ou de ne pas livrer et c’est la merde.

Les managers de l’Entreprise A ne croient pas en l’efficience du flux (vo). Les managers donnent des objectifs individuels aux gens. Et, les managers s’attendent à ce que les gens livrent le fruit de « leur » boulot, atteignant ainsi les objectifs.

Les soi-disant Scrum Masters (qui ressemblent à mes yeux à de bons vieux chefs de projets en mode commande-et-contrôle et non à des facilitateurs) demandent aux gens quand « leur » boulot sera fait.

L’emphase mise sur le travail individuel signifie que les équipes de l’Entreprise A coopèrent - quand ils peuvent. Toutefois, les équipes ne collaborent pas.

La coopération n’est pas la même chose que la collaboration

Ces équipes coopèrent le plus souvent à travers la revue de code. L’équipe fait plutôt du bon boulot de revue de code - lorsqu’elle fait de la revue de code.

Toutefois, la manière dont elle fait la revue de code comporte les problèmes suivants :

  • Elle ne fait pas toujours de la revue de code parce qu’un développeur est en « retard ». (Souvent parce que le code est plus difficile que ce qu’il ou elle avait anticipé. Eh oui, c’est dans ces moments-là que le développeur a besoin le plus d’une revue de code).
  • J’ai demandé à des équipes de mesurer leurs temps de cycle (vo). Je le leurs demande afin que les équipes réalisent qu’ils attendent quelques fois des jours pour faire une revue de code. Personne n’est capable d’atteindre ses objectifs avec ces délais-là.

Les membres de l’équipe essayent de collaborer. Toutefois, les objectifs personnels créent des effets dissuasifs à titre individuel pour collaborer

(J’ai déjà suggéré le travail en binôme, en groupe, en masse (vo) pour aider à réduire le temps de cylce et accroître la collaboration.)

Pourquoi cette emphase sur le travail individuel ?

Lorsque j’ai expliqué les concepts de l’efficience des ressources et du flux, les managers ont acquiescés. Ils avaient compris.

Qu’est-ce qui les empêchent d’utiliser l’efficience du flux. Le système de gestion de la performance et les RH. Mais aussi les problèmes de capitalisation logicielle (vo). (Plus les gens livrent rapidement quelque chose, plus vite ils pourraient capitaliser.)

Les managers doivent changer la manière dont ils travaillent. Les managers doivent résoudre ces problèmes.

J’ai demandé à des managers quels objectifs sont les plus importants aux yeux des managers :

  1. Mesurer le travail de quelqu’un
  2. Livrer un produit opérationnel pour gagner plus d’argent

Eh non, je n’ai pas à offrir de 3ème option comme dans la règle des trois (vo). Nous ne sommes pas ici en mode résolution de problèmes. Nous sommes ici en mode identification de problèmes.

Après quelques discussions, ils ont finalement été d’accord par dire que la livraison de produit était plus importante que la capacité de mesurer la contribution d’une seule personne.

Pffiou !

À partir de là, nous pourrions travailler sur des alternatives au travail individuel pour s’occuper de la résilience de l’équipe. Dans le prochain article, nous nous attaquerons aux problèmes des boucles de feedbacks.

La série d’articles :

Auteur : Johanna Rothman
Source : Build Team Resilience: Work Together (Part 1)
Date de parution originale : 04 Mars 2020

Traducteur : Nicolas Mereaux
Date de traduction : 19/03/2020

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.