![\"Deux](\"https:\/\/i0.wp.com\/nicotondeur.fr\/wp-content\/uploads\/2025\/04\/xinying-lin-Gnp8cPPGd68-unsplash.jpg?resize=723%2C542&ssl=1\")
Je vous propose, \u00e0 travers cette s\u00e9rie d\u2019articles, d\u2019explorer plusieurs mod\u00e8les d\u2019organisation d\u2019\u00e9quipes et de gestion des comp\u00e9tences. Mon intention n\u2019est pas de prescrire un mod\u00e8le parfait \u2013 je doute qu\u2019il existe \u2013 mais de partager des retours d\u2019exp\u00e9rience, des observations et des pistes de r\u00e9flexion pour adapter ces mod\u00e8les \u00e0 votre propre contexte.<\/p>\n\n\n\n
Une \u00e9quipe, un produit\u2026 le mod\u00e8le id\u00e9al ?<\/strong><\/h3>\n\n\n\nQuoi de plus simple que cet adage ? Avoir une \u00e9quipe unique, multi-comp\u00e9tente, capable de r\u00e9pondre \u00e0 l\u2019ensemble des besoins de son produit. Une \u00e9quipe auto-organis\u00e9e, capable de construire, faire \u00e9voluer et maintenir un produit dans la dur\u00e9e. Bref, le fonctionnement SCRUM dans sa forme la plus pure.<\/p>\n\n\n\n
Ce mod\u00e8le a beaucoup d\u2019atouts :<\/p>\n\n\n\n
\n- Une forte proximit\u00e9 avec le produit et ces utilisateurs
<\/li>\n\n\n\n - Un backlog clair, centr\u00e9 sur un objectif commun
<\/li>\n\n\n\n - Des comp\u00e9tences partag\u00e9es au sein de l\u2019\u00e9quipe
<\/li>\n\n\n\n - Une grande r\u00e9activit\u00e9 face aux besoins m\u00e9tiers \/ utilisateurs
<\/li>\n<\/ul>\n\n\n\n![\"Lettres](\"https:\/\/i0.wp.com\/nicotondeur.fr\/wp-content\/uploads\/2025\/04\/merakist-RxOrX1iW15A-unsplash.jpg?resize=723%2C542&ssl=1\")
Photo de Merakist<\/a> sur Unsplash<\/a>\n <\/figcaption><\/figure>\n<\/div>\n\n\n\u00c0 tout moment, l\u2019\u00e9quipe est en capacit\u00e9 de livrer de la valeur. Les fameuses notions de \u201cteam ownership\u201d<\/strong> et de \u201ctruck factor\u201d<\/strong> sont bien trait\u00e9es : la connaissance est partag\u00e9e, les responsabilit\u00e9s sont collectives. L\u2019\u00e9quipe est soud\u00e9e, efficace, agile au sens noble du terme.<\/p>\n\n\n\nOui mais\u2026 la r\u00e9alit\u00e9 revient vite frapper \u00e0 la porte<\/strong><\/h3>\n\n\n\n\u00c0 force de produire de la nouveaut\u00e9, de devoir aller toujours plus vite, l\u2019\u00e9quipe finit par ne plus suffire.<\/p>\n\n\n\n
Elle ne suffit plus \u00e0 g\u00e9rer le RUN<\/strong> dans le cadre d\u2019un fonctionnement SCRUM classique.<\/p>\n\n\n\nElle ne suffit plus \u00e0 livrer les nouveaut\u00e9s les plus attendues<\/strong> dans des d\u00e9lais d\u00e9cents.<\/p>\n\n\n\nElle ne suffit plus \u00e0 faire face \u00e0 la croissance du produit, du nombre d\u2019utilisateurs, des d\u00e9pendances.<\/strong><\/p>\n\n\n\nOn pourra toujours dire que c\u2019est au PO de faire son travail de priorisation. Mais lorsque les contraintes deviennent trop fortes, lorsque les demandes s\u2019accumulent, la taille limit\u00e9e de l\u2019\u00e9quipe<\/strong> devient une contrainte structurelle.<\/p>\n\n\n\nM\u00eame si, dans sa version la plus r\u00e9cente, SCRUM ne met plus vraiment de limite \u00e0 la taille de l\u2019\u00e9quipe, la faire grossir n\u2019est pas si simple :<\/p>\n\n\n\n
\n- Plus l\u2019\u00e9quipe grandit, plus la synchronisation devient complexe <\/strong>(loi de Brooks)
<\/strong><\/li>\n\n\n\n- Les comp\u00e9tences se sp\u00e9cialisent<\/strong>, parfois de mani\u00e8re informelle
<\/li>\n\n\n\n- Le RUN s\u2019accumule<\/strong> et prend de plus en plus de place
<\/li>\n\n\n\n- Le temps pass\u00e9 \u00e0 communiquer, se coordonner, arbitrer<\/strong> augmente
<\/li>\n<\/ul>\n\n\n\nLe mod\u00e8le \u201cune \u00e9quipe, un produit\u201d devient alors difficile \u00e0 maintenir \u00e0 l\u2019\u00e9chelle. Il montre ses limites face \u00e0 la r\u00e9alit\u00e9 du terrain\u2026 ou plut\u00f4t \u00e0 celle du march\u00e9.<\/p>\n\n\n\n
Et maintenant, on fait quoi ?<\/strong><\/h3>\n\n\n\nC\u2019est souvent \u00e0 ce moment-l\u00e0 que les organisations basculent vers d\u2019autres mod\u00e8les :<\/p>\n\n\n\n
\ud83d\udc49 des feature teams<\/strong>,<\/p>\n\n\n\n\ud83d\udc49 des squads<\/strong>,<\/p>\n\n\n\n\ud83d\udc49 des \u00e9quipes build\/run s\u00e9par\u00e9es<\/strong>,<\/p>\n\n\n\n\ud83d\udc49 ou des mod\u00e8les plus hybrides et adaptatifs.<\/p>\n\n\n\n
Mais l\u00e0 encore, chaque solution apporte son lot de nouvelles probl\u00e9matiques.<\/p>\n\n\n\n
Et c\u2019est ce que je vous propose d\u2019explorer dans les prochains articles de cette s\u00e9rie.<\/p>\n\n\n\n
\n\n\n\n\ud83d\udd1c \u00c0 venir dans l\u2019article 2 :<\/strong><\/p>\n\n\n\n\u201cFeature teams : quand les fonctionnalit\u00e9s deviennent des silos\u201d<\/strong><\/p>\n\n\n\nOn parlera de d\u00e9coupage fonctionnel, de chasse gard\u00e9e, de code partag\u00e9 (ou pas), et de ce qu\u2019il se passe quand les \u00e9quipes deviennent un peu trop\u2026 sp\u00e9cialis\u00e9es.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Article cr\u00e9\u00e9 avec l’assistance de ChatGPT en sparring partner…<\/p>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n
\u00c0 tout moment, l\u2019\u00e9quipe est en capacit\u00e9 de livrer de la valeur. Les fameuses notions de \u201cteam ownership\u201d<\/strong> et de \u201ctruck factor\u201d<\/strong> sont bien trait\u00e9es : la connaissance est partag\u00e9e, les responsabilit\u00e9s sont collectives. L\u2019\u00e9quipe est soud\u00e9e, efficace, agile au sens noble du terme.<\/p>\n\n\n\n \u00c0 force de produire de la nouveaut\u00e9, de devoir aller toujours plus vite, l\u2019\u00e9quipe finit par ne plus suffire.<\/p>\n\n\n\n Elle ne suffit plus \u00e0 g\u00e9rer le RUN<\/strong> dans le cadre d\u2019un fonctionnement SCRUM classique.<\/p>\n\n\n\n Elle ne suffit plus \u00e0 livrer les nouveaut\u00e9s les plus attendues<\/strong> dans des d\u00e9lais d\u00e9cents.<\/p>\n\n\n\n Elle ne suffit plus \u00e0 faire face \u00e0 la croissance du produit, du nombre d\u2019utilisateurs, des d\u00e9pendances.<\/strong><\/p>\n\n\n\n On pourra toujours dire que c\u2019est au PO de faire son travail de priorisation. Mais lorsque les contraintes deviennent trop fortes, lorsque les demandes s\u2019accumulent, la taille limit\u00e9e de l\u2019\u00e9quipe<\/strong> devient une contrainte structurelle.<\/p>\n\n\n\n M\u00eame si, dans sa version la plus r\u00e9cente, SCRUM ne met plus vraiment de limite \u00e0 la taille de l\u2019\u00e9quipe, la faire grossir n\u2019est pas si simple :<\/p>\n\n\n\n Le mod\u00e8le \u201cune \u00e9quipe, un produit\u201d devient alors difficile \u00e0 maintenir \u00e0 l\u2019\u00e9chelle. Il montre ses limites face \u00e0 la r\u00e9alit\u00e9 du terrain\u2026 ou plut\u00f4t \u00e0 celle du march\u00e9.<\/p>\n\n\n\n C\u2019est souvent \u00e0 ce moment-l\u00e0 que les organisations basculent vers d\u2019autres mod\u00e8les :<\/p>\n\n\n\n \ud83d\udc49 des feature teams<\/strong>,<\/p>\n\n\n\n \ud83d\udc49 des squads<\/strong>,<\/p>\n\n\n\n \ud83d\udc49 des \u00e9quipes build\/run s\u00e9par\u00e9es<\/strong>,<\/p>\n\n\n\n \ud83d\udc49 ou des mod\u00e8les plus hybrides et adaptatifs.<\/p>\n\n\n\n Mais l\u00e0 encore, chaque solution apporte son lot de nouvelles probl\u00e9matiques.<\/p>\n\n\n\n Et c\u2019est ce que je vous propose d\u2019explorer dans les prochains articles de cette s\u00e9rie.<\/p>\n\n\n\n \ud83d\udd1c \u00c0 venir dans l\u2019article 2 :<\/strong><\/p>\n\n\n\n \u201cFeature teams : quand les fonctionnalit\u00e9s deviennent des silos\u201d<\/strong><\/p>\n\n\n\n On parlera de d\u00e9coupage fonctionnel, de chasse gard\u00e9e, de code partag\u00e9 (ou pas), et de ce qu\u2019il se passe quand les \u00e9quipes deviennent un peu trop\u2026 sp\u00e9cialis\u00e9es.<\/p>\n\n\n\n <\/p>\n\n\n\n Article cr\u00e9\u00e9 avec l’assistance de ChatGPT en sparring partner…<\/p>\n\n\n\nOui mais\u2026 la r\u00e9alit\u00e9 revient vite frapper \u00e0 la porte<\/strong><\/h3>\n\n\n\n
\n
<\/strong><\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\nEt maintenant, on fait quoi ?<\/strong><\/h3>\n\n\n\n
\n\n\n\n