- Les équipes d’ingénierie subissent souvent la pression de devoir « livrer plus de fonctionnalités, plus vite »
- Mais mener trop de chantiers en parallèle finit au contraire par faire baisser la productivité
- « Le secret pour livrer davantage, c’est en réalité d’en faire moins » -
Less is More
Principes clés
- Rendre visible tout le travail
- Définir le travail en petites unités
- Limiter le travail en cours
- Allouer les ressources en fonction de la capacité
- Bonus : prévoir une marge pour l’imprévu
# Rendre visible tout le travail
- Visualiser le travail permet de regarder la réalité en face
- Quand tout le travail est visible d’un seul coup d’œil, cela apporte les avantages suivants
- Possibilité de définir clairement les priorités
- Possibilité d’arrêter ou de suspendre les tâches inutiles
- Possibilité pour l’équipe de se concentrer sur l’achèvement de ce qu’elle a commencé
- L’objectif n’est pas de suivre chaque tâche pour toujours → il s’agit de comprendre clairement la réalité pour prendre de meilleures décisions
# Définir le travail en petites unités
- Quand le travail est trop volumineux, l’énergie de l’équipe s’épuise et l’avancement devient moins lisible
- Limiter la taille des tâches à environ 1 à 2 semaines
- Les développeurs restent motivés grâce à des résultats à court terme
- Il est possible d’obtenir rapidement du feedback et d’ajuster
- Avantages des petites unités de travail
- Les revues de code deviennent plus faciles
- Le partage de connaissances se fait naturellement
- La collaboration entre les membres de l’équipe se renforce
- Le risque de déploiement diminue
- Réduire la taille des tâches accélère le rythme → on évite d’être submergé par des fonctionnalités complexes et on conserve son élan
# Limiter le travail en cours
- Traiter plusieurs fonctionnalités en même temps finit par nuire à la productivité
- Il existe un coût du changement de contexte → il peut falloir jusqu’à 23 minutes pour s’adapter à une nouvelle tâche
- Plus le volume de travail en cours augmente, plus les problèmes suivants apparaissent
- Baisse de la qualité
- Augmentation des bugs
- Baisse du moral de l’équipe
- Signes de surcharge au niveau de l’équipe
- Plus de 4 tâches par développeur
- Des délais d’achèvement plus longs que prévu
- Plus de fonctionnalités en cours que de fonctionnalités terminées
- Signes de surcharge au niveau individuel
- Baisse de la concentration
- Allongement du temps de réponse aux revues de code
- Difficulté à expliquer les priorités lors des points d’avancement
# Allouer les ressources en fonction de la capacité
- L’approche consistant à « confier une fonctionnalité à un seul développeur » est inefficace
- Concentrer les ressources de l’équipe sur le travail le plus important
- Collaboration renforcée → résolution des problèmes plus rapide
- Amélioration de la qualité du code → revues par les pairs en temps réel facilitées
- Accélération de l’achèvement du travail
- Grâce à la collaboration, les développeurs acquièrent une compréhension plus approfondie
- Il faut encourager les résultats à l’échelle de l’équipe → en mettant l’accent sur la performance collective plutôt que sur la performance individuelle
# Prévoir une marge
- Fonctionner à 100 % de capacité finit au contraire par faire baisser les résultats
- Le travail imprévu est inévitable → on ignore seulement quand il surviendra
- Problèmes causés par l’absence de marge
- L’équipe se met à travailler de façon réactive
- Baisse de la qualité
- Réduction de l’innovation
- Augmentation de la dette technique
- Avoir une marge apporte les avantages suivants
- Possibilité de réagir avec souplesse aux problèmes inattendus
- Résolution créative des problèmes
- Maintien d’un haut niveau de qualité
- Maintien d’un rythme de travail durable
- La marge adéquate est d’environ 20 % → à ajuster selon les caractéristiques de l’équipe
Résumé de la stratégie clé
- Rendre le travail visible → pour voir clairement la réalité
- Définir le travail en petites unités → pour garder l’élan
- Limiter le travail en cours → pour améliorer la concentration
- Allouer les ressources selon la capacité → pour se concentrer sur les priorités
- Prévoir une marge → pour gagner en flexibilité
Conclusion
- Pour accomplir davantage, il faut une stratégie qui consiste à en faire moins
- La performance d’une équipe ne se mesure pas au nombre de fonctionnalités traitées en parallèle, mais à sa capacité à fournir efficacement de la valeur aux clients
- Le rôle d’un leader n’est pas d’ajouter toujours plus de travail à l’équipe, mais d’éliminer le travail inutile
12 commentaires
Le livre <Le Projet Phoenix>, souvent mentionné sur GeekNews, raconte une idée similaire. Plus on se rapproche de 100 % de capacité, plus le temps de réponse s’allonge de façon exponentielle.
Oh. Cette idée apparaît aussi dans le livre Goal !
Parce que The Phoenix Project lui-même a été écrit comme une version IT de The Goal.
Oh là là........ merci !!
Nous essayons de garder 80 % de charge de travail et 20 % de marge, mais je me demande à chaque fois selon quels critères le faire... Je me demande aussi s’il faut simplement se baser sur le temps.
C’est pour ça que je réserve carrément mes vendredis après-midi au temps de développement personnel !
Lorsqu’on découpe ainsi le travail en petites tâches, le leader qui a la vision d’ensemble se retrouve avec un pouvoir important. Les ingénieurs qui travaillent avec lui en viennent plutôt à perdre leur motivation et à se demander : « Au juste, vers quoi est-ce qu’on va ? » C’est un défaut typique de l’agile basé sur les sprints.
On a l’impression que c’est écrit de manière trop centrée sur le point de vue du leader, comme l’indique le titre.
L’élan des ingénieurs est aussi fortement influencé par la direction dans laquelle le leader brandit le drapeau. Il semble qu’il faudrait aussi réfléchir davantage à la manière de formuler clairement la valeur qu’on veut apporter au client, ainsi que l’output de chaque sprint et l’outcome de livraison. Bien sûr, ce sont des soft skills difficiles, il est rare de voir des leaders qui les maîtrisent vraiment, et il n’existe pas beaucoup de textes à ce sujet non plus.
Je suis totalement d’accord avec ce commentaire. Il y avait a un risque de micromanagement sur les aspects techniques. Ce n’est vraiment pas facile.
Ne s’agit-il pas de partager la vision d’ensemble, puis de découper le travail en petites tâches une fois que tout le monde l’a bien comprise ?
Si on découpe en périodes de 1 à 2 semaines, il me semble qu’assez naturellement seule une partie limitée des personnes connaîtra la vision d’une fonctionnalité donnée. Un peu comme la différence entre un processus et un thread. L’idée est d’accroître la productivité en limitant le champ d’attention.
Même si cette vision est partagée, cela suppose qu’on la questionnera, mais je me rends compte que j’ai aussi naturellement posé comme hypothèse qu’on n’arrive pas à suivre la vue d’ensemble en fonction d’une orientation qui change un peu à chaque sprint planning.
Je suis entièrement d’accord avec ce que cet article avance, tout en partageant aussi le problème que vous avez mentionné,
c’est d’ailleurs un point sur lequel je réfléchis moi-même en ce moment.
Cela variait selon les squads, mais lorsque les membres de l’équipe participaient activement au sprint planning, le problème que vous avez évoqué ne se produisait pas. En partageant le contexte du projet et l’évolution de la situation à chaque sprint, nous avons cherché à faire en sorte que chacun puisse bien prendre conscience des changements de tâches, tout en demandant que le travail soit découpé de manière très fine.
Comme vous l’avez dit, du point de vue de la gestion, si l’on pense au suivi de l’avancement, à la mesure de la vitesse d’exécution, à la réponse aux imprévus, ainsi qu’au coût d’opportunité lorsque le contenu du travail ne se déroule pas comme prévu, il s’avère qu’en fin de compte, mieux vaut découper finement pour que tout avance correctement.
On voit souvent passer des articles de ce genre, mais la cupidité humaine n’a pas de fin et on répète toujours les mêmes erreurs
Une charge CPU à 100 % n’est pas normale pour un ordinateur,
mais pour la charge de travail des humains, on en conclut qu’il faut travailler encore plus dur...