Quelques remarques :
Si un exécutant a besoin qu’on lui découpe / donne du travail et qu’il n’y a personne qui donne du travail aux exécutants, oui on se dirige tout droit vers l’oisiveté. Cependant, en vrai, personne n’est un « pur » exécutant, et la plupart des gens qui se retrouvent sans rien à faire du tout (je ne parle pas d’une baisse d’activité mais d’une absence totale) vont généralement au moins solliciter leur superviseur. Ensuite ils vont commencer à ressentir les symptômes d’un brownout. En l’absence de réaction appropriée, la situation peut s’aggraver soit en démission, soit en dépression, et dans le pire des cas en suicide. C’est l’exemple France Telecom.
Si on met en place une organisation dans laquelle les exécutants sont abreuvés de tâches à réaliser par des personnes qui n’ont pas les compétences nécessaires (managériales et techniques), alors ça ne peut pas fonctionner non plus. Ce n’est pas lié à une organisation agile ou non, c’est juste incompatible avec la notion d’organisation tout court.
un exécutant a besoin qu’on lui donne du travail (pas d’autonomie sur la prise de tâches)
On peut quand même qualifier d’exécutant une personne qui prend du travail dans une pile déjà ordonnée pour lui. Même si techniquement c’est lui qui prend le travail dans la pile, son travail est organisé par autrui, donc ça reste un exécutant. Bien que ça semble anecdotique, c’est en fait redoutable en terme de productivité. C’est ce qui a permis à Toyota de devenir le premier constructeur automobile au monde.
Comment une entreprise peut transformer un exécutant en développeur ?
Ce n’est pas la bonne question à poser.
Pour simplifier, la transformation agile consiste à adopter un commandement par objectif (voici l’effet souhaité) en lieu et place d’un commandement par ordre (voici la liste des actions à effectuer). Un commandement par objectif place le collaborateur en posture de développeur, alors qu’un commandement par ordre place le collaborateur en posture d’exécutant. Même s’il y a des contre-exemples, c’est généralement l’organisation qui met le collaborateur dans une posture d’exécutant. La bonne question à poser est donc plutôt : « Comment une entreprise peut se transformer pour mettre les collaborateurs en posture de développeurs plutôt que d’exécutants ? ».
Comment gérer une personne qui souhaite rester exécutant ?
Lui donner du travail en cohérence avec ses compétences, dans un environnement sain, et s’interroger sur ses propres croyances et motivations …
Quelques questions complémentaires :
Peut-on employer Scrum avec des exécutants ?
Oui complétement, mais il faut quand même des vrais développeurs à côté. Le premier ajustement, à mon avis, est de sortir les exécutants des réunions Scrum. Sauf peut-être en démo/rétrospective. Il est primordial que le contrôle d’avancement se fasse en dehors des réunions scrum, qui ne sont pas là pour ça, en particulier le daily. Le fonctionnement reste tel qu’indique dans le scrum guide, si ce n’est qu’on n’invite que les devs et non les exécutants. En revanche, ça nécessite que le SM et les devs connaissent très bien les exécutants pour organiser leur travail. C’est souvent là que le bât blesse.
Peut-on faire de l’agile avec des exécutants ?
Comme dit plus haut, schématiquement, l’agilité consiste à adopter un commandement par objectif (voici l’effet souhaité) en lieu et place d’un commandement par ordre (voici la liste des actions à effectuer). Elle repose donc sur l’aptitude des subalternes à savoir comment s’organiser pour obtenir l’effet souhaité, ce qui n’est pas compatible avec une attitude d’exécutant. Cependant, comme c’est surtout l’organisation qui a mis les collaborateurs dans une posture d’exécutants, on devrait plutôt dire que la manière dont on dirige l’équipe détermine si on fait de l’agile ou pas, et si on a des exécutants ou pas. Et qu’on ne peut pas adopter un style de management qui soit à la fois directif et délégatif.