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 a eu une influence considérable sur l’organisation du travail. 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.

Récits sur la division du temps

Cycle en V

Sur mon blog, l’article qui a longtemps était le plus lu (du temps lointain où je mesurais), 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.

Taylorisme

Le taylorisme désigne cette forme d’organisation du travail pour la production de masse.

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.

Déconstruction de la division du temps

Dans la Fresque de l’agilité nous déconstruisons cette division du temps.

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 problèmes 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

Intention de maîtrise

La 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

Ces problèmes très faciles à identifier ont souvent été présentés pour justifier le passage à l’agilité au début des années 2000.

Effet tunnel

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.

Choix prématurés

Faire des choix de conception très tôt engendre des problèmes pour l’équipe qui va devoir vivre avec ces décisions.

Évolutions des besoins ignorées

Les besoins des utilisateurs sont impossibles à cerner en détail et en plus ils changent vite, on va développer des choses inutiles.

Des itérations 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 en produisant un résultat concret pour les utilisateurs constituent 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 détaillée

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’idée est de tout définir pour que ces exécutants n’aient pas besoin de réfléchir.

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

Plans déconnectés de la réalité

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.

Engagement non consenti

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.

Retards fréquents

Pour les utilisateurs, leur perception est que les projets sont souvent en retard et qu’on ne leur dit pas pourquoi.

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”.

Bullshit job

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 :

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.

Pression hiérarchique

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

Mesures opaques pour les utilisatuers

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.