Organisations orientées-produits

La transition d'une organisation centrée sur des projets à une organisation centrée sur les produits, attribut fréquent des Transformations Digitales, est un processus complexe qui a des impacts à plusieurs niveaux et qui nécessite des changements significatifs un peu partout dans l'organisation.

C'est un débat qui fait rage dès qu'une organisation se tourne vers l'Agilité. Au début on se tourne vers Scrum et quand on est à mettre ce type d'Agilité en place pour un horizon long, on se rend à l'évidence que l'orientation "projets" ne fait pas trop de sens ^[1] . On se rend aussi compte que ce type d'organisation du travail, en "projets", rend compliquée l'innovation. On en vient alors très vite à élargir son angle de vue et on se dirige, tout naturellement, vers une orientation "produits". Comme indiqué plus haut, ce n'est pas sans conséquences. Je vous propose d'examoiner ce type de transition sous trois angles principaux : (1) les équipes, (2) l'organisation du support et du helpdesk, et (3) le financement des équipes.

Des équipes assemblées pour du long terme

Passer d'une entreprise orientée "projets" à une organisation orientée "produits" est un changement de paradigme. Un projet a une date de début et une date de fin; après le projet, l'équipe est pour tout ou partie désassemblée et/ou réaffectée ailleurs dans l'organisation.

Ce n'est pas le cas d'un produit : on connait la date de démarrage; on ne connaît pas la "date de fin" du produit : idéalement le produit durera 100 ans et profitera de sa période de maturité plus ou moins longue, période qui typiquement engrange les plus hautes marges. L'équipe (ou les équipes) va suivre le produit sur, potentiellement, une longue durée et restera alors en place. ELle est assemblée sur du long terme.

Cette nécessité de travailler avec des équipes assemblées sur le long terme impose de facto le changement de méthode Agile : on passe alors volontiers de Scrum à Kanban, une méthode agile également mais mieux adaptée à l'orientation "produits". On ne fonctionne plus avec des sprints; on fonctionne avec une mise à disposition quasi immédiate : dès la chose développée et testée elle est amenée en production. Si l'organisation ne s'est pas encore muée en organisation Dev[Sec]Ops, elle va devoir le faire pour être à la hauteur du processus requis !.

Cohésion et Connaissance Partagée

Travailler avec des équipes stables sur le long terme favorise la cohésion et la connaissance partagée. Lorsque les membres d'une équipe collaborent sur une période prolongée, ils développent une compréhension mutuelle des compétences, des forces et des faiblesses de chacun. Cela permet d'améliorer la communication et de réduire les frictions, ce qui est essentiel pour une collaboration efficace. Mais c'est aussi la garantie de ne pas encourir une coûteuse période d'apprentissage (learning curve). Dean Leffingwell met cela très bien en avant dans ses livres, des conférences et dans SAFe.

Amélioration Continue

Des équipes durables sont mieux positionnées pour mettre en œuvre des cycles d'amélioration continue. Elles peuvent affiner leurs processus et méthodes de travail au fil du temps, ce qui conduit à une augmentation de la productivité et de la qualité des livrables. Cette constance permet également d'établir des pratiques de travail optimisées, basées sur des retours d'expérience concrets qui demeurent en place tant que l'équipe existe.

Engagement et Motivation

La stabilité des équipes contribue à l'engagement et à la motivation des membres. Lorsque les individus se sentent valorisés et intégrés dans un groupe, ils sont plus susceptibles de s'investir dans leurs tâches et de prendre des initiatives. Cela est particulièrement important dans un environnement agile, où l'autonomie et la responsabilité sont des valeurs clés, vous ne me contredirez pas sur le sujet !

de Scrum à Kanban

Scrum et Kanban sont deux méthodologies agiles qui répondent à des besoins différents. Scrum est basé sur des itérations fixes appelées sprints, où les équipes planifient et livrent des fonctionnalités dans un délai déterminé. En revanche, Kanban fonctionne sur un flux continu, permettant aux équipes de gérer les tâches à mesure qu'elles arrivent, sans cycles de livraison rigides. Cette flexibilité est particulièrement bénéfique pour les projets où les exigences changent fréquemment ou où les délais sont imprévisibles, voire même quand les tâches sont imprévisibles, ce qui est le cas lorsqu'on fait face à des incidents, par exemple.

Adaptabilité et Priorisation

Le passage à Kanban permet une meilleure adaptabilité face aux priorités changeantes. Dans un environnement dynamique, les équipes peuvent ajouter de nouvelles tâches au tableau Kanban à tout moment, ce qui leur permet de réagir rapidement aux besoins des clients ou aux urgences. Cela contraste avec Scrum, où les nouvelles demandes doivent en général attendre le début d'un nouveau sprint.

Du reste, Scrum s'adapte mal au paradigme "You Build It, You Run It". En cas d'incident critique, il faut être sur la balle immédiatement. Cela ne convient pas trop à Scrum; pour Kanban, au contraire, c'est son mode de fonctionnement naturel !

Dès que vous passez de Scrum à Kanban, le reporting change, un long sujet que je n'ai pas envie de traiter ici car il faut le détailler mais ce qui est sûr c'est que si le burndown chart illustre bien le reporting du mode itératif par blocs, il n'est plus du tout représentatif de ce qui se passe en mode Kanban !

Visualisation du Flux de Travail

Kanban utilise un tableau visuel pour représenter le flux de travail, ce qui améliore la transparence et la communication au sein de l'équipe. Chaque tâche est représentée par une carte qui évolue à travers différentes colonnes (par exemple, "À faire", "En cours", "Terminé"). Cette visualisation aide les équipes à identifier les goulets d'étranglement et à optimiser leur processus de travail.

J'ai besoin de retourver mes graphiques pour illustrer cela MAIS ce sera fait !!!

You Build It, You Run It!

Le principe "You Build It, You Run It" (YBIYRI) incarne une approche où les équipes de développement sont responsables non seulement de la création de produits, mais aussi de leur fonctionnement et de leur maintenance. Cela favorise une culture de responsabilité et d'autonomie, encourageant les équipes à adopter une mentalité orientée produit. Comme dirait Adrian Cockcroft^[2] , il n'y a plus d'Ops (comprenez que les Ops sont des développeurs) et un développeur qui a le pager / beeper la nuit, il fait attention au code qu'il réalise car il n'a pas envie d'être réveillé à 2h du mat !

Support et helpdesk

La transformation vers une organisation centrée sur les produits implique également une réévaluation de la structure et des processus du support et du helpdesk.

Implications pour le support :

• Support Proactif : Plutôt que d'attendre que les problèmes surviennent, le support doit adopter une approche proactive, en anticipant les besoins des utilisateurs et en résolvant les problèmes avant qu'ils n'affectent l'expérience client.

• Intégration des Outils Digitaux : L'utilisation d'outils numériques pour le support, tels que les chatbots et les systèmes de gestion des tickets, peut améliorer l'efficacité et la réactivité du service client.

• Formation et Sensibilisation : Les équipes de support doivent être formées non seulement aux produits qu'elles soutiennent, mais aussi à la culture de l'entreprise et à l'importance de l'expérience utilisateur, afin de mieux répondre aux attentes des clients.

Financement des équipes

Le financement des équipes dans une organisation centrée sur les produits doit être révisé pour soutenir cette nouvelle orientation.

Implications pour le financement

• Financement Basé sur la Valeur : Les équipes doivent être financées en fonction de la valeur qu'elles apportent plutôt que sur des budgets fixes. Cela encourage l'innovation et la prise de risques calculés. En d'autres termes, vous êtes amenés à financer une équipe fixe pour … l'année, ce qui est BEAUCOUP BEAUCOUP plus simple !

• Allocation flexible de nouveaux produits aux équipes en place : les équipes risquent d'être surdimensionnées lorsque le produit dont elles s'occupent entrent en phase de maturité car c'est la période où on ne fait pas grand chose sauf à maintenir le produit dans son crénau de marché. Pour ne pas avoir des gens qui se tournent les pouces, vous devz être capable de leur assigner des produits similaires, fonctionnellement ou techniquement.

• Investissement dans la Formation : Un budget doit être prévu pour la formation continue des équipes, afin qu'elles puissent s'adapter aux nouvelles technologies et méthodologies qui émergent dans le cadre de la transformation digitale et adapter les produits pour qu'ils ne deviennent pas obsolètes (trop vite).

Conclusion

La transition vers une organisation centrée sur les produits dans le cadre d'une transformation digitale nécessite une approche holistique qui englobe les équipes, le support et le financement. En adoptant des pratiques telles que "You Build It, You Run It", en réorganisant le support pour qu'il soit proactif et en ajustant le financement pour encourager l'innovation, les entreprises peuvent créer une culture dynamique qui favorise la réussite à long terme dans un environnement numérique en constante évolution.