La division du temps met la pression

Adam Smith a inventé la division du travail. Frederick Taylor l’a complétée en divisant le temps de production en une suite de tâches élémentaires, répétées et chronométrées. Le taylorisme désigne cette forme d’organisation du travail pour la production de masse.

Le taylorisme a eu une influence considérable sur l’organisation du travail dans l’industrie. On en retrouve des traces, voire plus, dans des types de travaux pour lesquels il n’a pourtant pas été conçu, comme ceux de la connaissance et des services.

En particulier, la division verticale du travail, qui établit une distinction entre la conception et la réalisation, perdure dans bien des projets. Cela conduit à une façon de travailler avec la séparation stricte entre réflexion et exécution et des phases séquentielles. La première phase sert à concevoir et planifier, la suite n’étant que l’exécution de ce plan avec des contrôles effectués pour garantir sa bonne exécution.

Dans la Fresque de l’agilité nous déconstruisons cette approche.

Nous retenons 3 éléments d’organisation du travail particulièrement significatifs de la division du temps, que nous détaillons avec :

• l’intention initiale du taylorisme et ses dérivés,
• les difficultés que cela engendre pour les coéquipiers, mais aussi pour les utilisateurs et le sponsor,
• les pratiques de substitution pour une équipe agile, permettant de répondre aux problèmes.

Méthode séquentielle

Sur mon blog, l’article qui a longtemps était le plus lu (du temps lointain où je regardais les statistiques de fréquentation), c’est Le cycle en V n’existe pas qui date de 2007. Le cycle en V (ou en cascade pour waterfall) était l’objet de nombreux débats. Il pousse à diviser le travail en étapes dédiées à des activités spécialisées.

Intention de maîtrise

Le taylorisme ne se souciait pas des utilisateurs. Quand il s’est décliné pour autre chose que de la production de masse, on a donc cherché à définir ses besoins, à les spécifier en détail. Cela a conduit à la rédaction de documents : des cahiers des charges ou des spécifications détaillées.

L’intention en suivant une méthode séquentielle composée de phases et de jalons est de définir à l’avance tout ce qu’il va falloir faire faire aux exécutants.

Dans le développement de logiciel aussi, cela est arrivé, avec de longues phases d’études aboutissant à de gros documents utilisés lors des jalons pour évaluer le passage à la phase suivante.

Problèmes avec les grosses spécifications et conceptions en amont

Les difficultés engendrées —très faciles à identifier— ont souvent été utilisées pour convaincre de passer à l’agilité au début des années 2000.

Le délai avant une première livraison est long, parfois très long, sans qu’on sache où on est, cela est connu sous le nom d’effet tunnel. J’en ai entendu parler pour la première fois en 1982 par le service logiciel de Telic (pas encore Alcatel).

Faire des choix de conception très tôt est une contrainte pour l’équipe qui va devoir vivre avec ces décisions alors qu’elle ne les approuve pas.

Les besoins des utilisateurs sont impossibles à cerner en détail et en plus ils changent. En se basant sur les spécifications initiales, on va développer des choses inutiles.

Des boucles en substitution aux phases et jalons

L’agilité propose une approche temporelle radicalement différente, basée sur :

• un prélude court pendant lequel on définit la vision partagée et la mission de l’équipe,
• puis des itérations (ou sprints) successives. La notion de bloc de temps (timebox) renforce ce rythme nouveau.

Pour contrer l’effet tunnel, les itérations produisent un résultat concret pour les utilisateurs. Avec le feedback rendu possible, cela constitue des boucles de feedback.

Du point de vue de la valeur, les mises en service rapides permettent un usage bien plus précoce qu’avec un cycle de vie avec des phases séquentielles, où il faut attendre la dernière pour avoir une mise en service (donc pas de valeur d’usage avant).

La perception du temps change, en passant du séquentiel au cyclique avec les boucles de feedback ritualisées à différents horizons, dans une approche fractale.

Planification de projet

La planification est une activité de la gestion de projet.

Intention de tout planifier avant de réaliser

Avec la division verticale du travail, la planification est faite par des personnes qui imposent la division horizontale (la décomposition en tâches élémentaires) aux exécutants. L’intention est de définit le temps accordé à une personne pour exécuter un travail.

Les personnes qui planifient sont souvent des experts du chiffrage, qui produisent des plans détaillés sous forme de Gantt.

Problèmes avec les plans détaillés faits au début

Les plans détaillés au début deviennent vite déconnectés de la réalité : aucun plan ne résiste au contact avec l’ennemi ! D’autant plus quand ils ont été faits par des personnes qui ne sont pas sur le terrain.

Les deadlines issues de ces plans sont mal vécues par les personnes qui travaillent. En effet, on leur demande de s’engager, mais il s’agit d’un engagement non consenti qui n’emporte pas l’adhésion.

La perception des utilisateurs est que les projets sont souvent en retard. Ils seraient prêts à comprendre si on leur donnait les raisons des retards. Mais on ne leur dit pas pourquoi, ou alors en termes vaseux (du genre “à cause de l’arrivée tardive de l’appareil”), ce qui sape leur confiance et les décourage de participer.

Estimation et planification agiles

L’agilité a apporté des réponses à ces questions d’estimation et planification. Le planning poker est une pratique d’estimation collective. La planification se décline à différents horizons (saison, sprint) pour éviter d’aller trop vite dans le détail.

Cependant, dans le domaine de la connaissance, l’incertitude fait que les estimations sont délicates. Dans certaines situations, on peut s’en passer (no estimates) et prévoir avec des objectifs définis par l’équipe.

Micro-management

Intention de suivre le plan initial

L’intention de maîtriser le quoi et le comment et de tout planifier en détail au début pousse à contrôler l’avancement de l’équipe par rapport à ce plan initial, pour faire en sorte que ce plan soit suivi.

Problèmes avec le management des tâches détaillées

Ce contrôle sur des tâches qui n’apportent pas de valeur constitue du micro-management, un style de management où le manager contrôle étroitement le travail de son équipe. Il s’assure que le temps passé plus le reste à faire reste en deçà du temps prévu et que les personnes ne perdent pas de temps à réfléchir plutôt qu’à produire. Le temps passé en commun (réunions, discussions, entraide) est qualifié de “non productif”.

Le travail de ces personnes qui effectuent les contrôles sur le suivi des plans et des processus perd son sens, au risque de devenir un bullshit job, défini par Graeber ainsi :

si une personne trouve que son boulot n’a pas de sens, que s’il disparaissait cela ne changerait rien, qu’à la limite le monde s’en porterait légèrement mieux, ça veut dire qu’il fait un job à la con.

La pression hiérarchique entraîne des souffrances pour les coéquipiers qui se sentent surveillés.

L’insistance à contrôler des petits morceaux de travail fait perdre la notion de valeur pour les utilisateurs. On se préoccupe plus de produire quelque chose (output) que de son intérêt pour l’utilisateur (outcome).

Pratiques pour en finir avec le micro-management

L’agilité incite l’équipe à s’organiser elle-même pour effectuer le travail. Le Scrum Master est là pour faciliter cette auto-organisation et mettre les coéquipiers en confiance, à l’opposé du contrôle.

L’avancement collectif vers l’objectif commun est examiné lors des rites d’équipe :

• la mêlée quotidienne pour la coopération permettant d’aboutir à un résultat,
• la revue d’itération (ou de sprint) pour montrer ce résultat aux parties prenantes et en obtenir du feedback.

D’autres pratiques agiles permettent d’aller plus loin :

• le flux tiré plutôt que poussé (pour plus d’efficacité),
• la coopération (travailler en même temps sur la même chose) plutôt que la collaboration (parallélisation de travail, en même temps).

Un grand merci à Jean-Pascal pour sa relecture approfondie et ses suggestions.