Un dev chez les Product Owners
Chaque année a lieu LA conférence "produit" française : School of product. Cette année j'ai eu l'opportunité d'y participer. En tant que développeur, j'y suis allé avec un regard bien particulier. Je vous présente dans ce blog ce que j'en retiens.
En immersion totale
Lorsque, sur notre Discord, un collègue a proposé une place à pour la conférence School of product, je me suis d'abord dit que ça n'était pas pour moi. Je suis développeur après tout, les problématiques produit sont pour les Product Owner (PO), moi je ne fais que concrétiser ce qui a été formalisé par une User Story et une maquette éventuellement...
Mais après avoir lu le programme, je me suis dit qu'il pouvait être intéressant de sortir un peu de mon quotidien de techos et de m'ouvrir un peu l'esprit sur des sujets qui pourraient sembler ne pas être directement le cœur de mon métier.
J'ai donc décidé de participer à cette conférence, en immersion totale au pays des PO.
De l'autre côté du miroir
Le premier sujet auquel j'assiste porte un intitulé qui m'intrigue : "De l'autre côté du miroir". Quel est cet autre côté ? Qui plaçons-nous devant le miroir ?
À la première slide je suis fixé : Thomas PIERRAIN nous parle de la relation PO/Développeurs, ça tombe plutôt bien !
Un même produit, deux visions différentes
Il y a certaines choses qui peuvent paraître évidentes une fois dites, mais que le quotidien fait oublier et qu'il est donc bon de verbaliser. En l'occurrence, ici, Thomas nous parle de la différence de vision d'un même produit, selon que l'on soit PO ou Dev.
Lorsque le PO transmet sa vision aux équipes de dev, il y a eu en amont tout un travail d'analyse, d'échanges avec le client, qui est difficile à faire passer sur une User Story ou dans une maquette. Cela mène inévitablement à certains raccourcis, certains implicites, menant le PO à se dire "Je ne comprends pas qu'il ne comprenne pas, l'expression du besoin est pourtant claire...".
Thomas PIERRAIN parle de contexte, chaque partie prenante sur un produit a un contexte propre à son métier. Prendre conscience de cela permet d'agir pour lever les incompréhensions liées. Du point de vue PO il est important de garder en tête d'expliciter les implicites, et du point de vue dev de poser le plus de questions possible : Est-ce que tu aurais un exemple ?.
La dette technique
Tout PO a pu se poser cette question. Thomas apporte un éclairage intéressant à cette problématique : Bâcler un développement désengage les devs. On peut faire une analogie avec un cuistot qui travaille dans une cuisine sale et en bazar. De la même manière, les devs aiment travailler dans un environnement propre et organisé. Travailler sur un code "sale" et désorganisé est usant et démotivant au quotidien.
Ce point peut paraître anecdotique, mais me semble assez représentatif des différences de point de vue qu'il peut y avoir entre une vision dev et une vision PO.
Quels outils ?
Établir ces différences de point de vue est déjà intéressant en soi, ne serait-ce que pour s'interroger sur la manière dont nous percevons une expression de besoin, une remarque, et sur la manière dont nous sommes perçus nous-mêmes.
Mais nous pouvons aller plus loin et essayer de nous mettre tous sur un même pied d'égalité. Là-dessus, la conférence passait rapidement sur ces solutions (le temps de présentation est relativement court pour présenter des solutions), mais la séance de questions/réponses a pu apporter quelques éléments.
Cela pourrait être exprimé en un mot : communication.
Pour cela Thomas a mentionné un format d'atelier qu'il affectionne particulièrement : L'event storming.
Je ne détaillerai pas ici ce qu'est l'event storming, mais si vous ne connaissez pas, sachez qu'il s'agit d'un format d'atelier ayant pour but de formaliser, sous forme de kanban, le métier en question, en impliquant toutes les parties prenantes du projet.
Un autre outil, à disposition de tous, est l'implication.
Éviter les "Il y a déjà trop de monde à cette réunion", et impliquer les dev dans les réunions dans lesquelles des sujets métier sont abordés. Même s'ils n'interviennent pas directement, cela permet de s'imprégner des sujets, d'avoir un éclairage différent sur une notion que l'on pensait comprendre, et de poser des questions.
C'est d'ailleurs le troisième point que j'ai retenu de cette présentation : le pouvoir du questionnement. Poser des questions, même si elles paraissent bêtes (ça n'est jamais le cas), elles permettent toujours à celui qui la pose de trouver des réponses, et à celui qui la reçoit de comprendre comment telle ou telle notion a été comprise.
Du point de vue PO, favoriser un environnement propice à l'interrogation est de ce fait primordial (pas de jugement, pas de sourire en coin quand une notion qui paraît évidente est interrogée).
(not) Scaling bad?
Dans cette présentation, Hervé LOURDIN nous explique comment Le Bon Coin a su adapter son organisation pour suivre sa croissance exponentielle.
Première mue
Le point de départ est le constat que l'organisation de l'entreprise ne tiendra pas la montée en puissance prévue. En effet, à l'origine, les équipes étaient organisées par stack technique, avec une équipe responsable de la partie web, une autre du back, d'android, d'iOS etc.
Cette organisation se confronte vite au fait que les features touchent à plusieurs stacks techniques en même temps, introduisant des points de contention du fait de l'occupation de certaines équipes. À l'inverse, d'autres équipes sont beaucoup moins sollicitées.
Pour réagir à cela, leboncoin s'est inspiré de ceux qui, à l'époque, étaient les plus avancés sur le sujet : Spotify (je vous invite à lire cet article très intéressant à ce sujet). Spotify prône une organisation par les features plutôt que par la technique.
Une organisation participative
Hervé nous explique que ce qu'il retient de cette transformation, au-delà de la réorganisation elle-même qui est un succés, c'est ce sentiment de fierté des équipes d'avoir participé à cette transformation.
Cela s'est fait en impliquant tout le monde dans le processus, menant à ce qu'il appelle maintenant le TOO (Travail d'Organisation Ouvert).
Tout le monde peut remonter une problématique organisationnelle à résoudre, voir les problématiques en cours, contribuer ou suivre sa résolution. Cette méthode a permis de mettre en avant des sujets tels que :
- Bilan télétravail et confinement
- POC d'orga sur des projets multi-équipe
- Vocabulaire d'organisation
- Gestion des environnements de validation
Un point important sur ces chantiers est d'avoir un sponsor au niveau de la direction, qui permettra d'appuyer la problématique et de se faire le porte-voix. Les forces de cette méthode résident dans l'implication qu'elle nécessite et l'amélioration continue qu'elle introduit, faisant "passer le changement comme un élément classique de notre quotidien".
La manœuvre de Conway inversée
Mais cette organisation, composée maintenant de 8 tribus et de 50 feature teams, atteint tout de même ses limites avec une croissance toujours plus grande. Les fonctionnalités deviennent de plus en plus ambitieuses, de plus en plus transverses. Comment faire cohabiter des verticales métier et des horizontales techniques ?
Melin Conway a exprimé en 1967 sa "loi de Conway", qui dit que : "les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation.". Pour paraphraser, l'architecture d'un système tendra à reproduire l'organisation.
On peut prendre la loi dans l'autre sens et tenter de définir l'organisation pour provoquer une structure logicielle. C'est le principe même de la manœuvre de Conway inversée. C'est ce qu'a fait leboncoin, en provoquant une organisation qui tend vers une architecture cible.
Ils ont introduit, en plus des feature teams, des platform teams.
Pour schématiser, là où les feature teams ont pour responsabilité l'expérience utilisateur, les platform teams ont pour responsabilité l'expérience développeur.
Grow and split
Une autre problématique, liée à la croissance d'une organisation, est l'évolution des équipes.
Avec le temps, les équipes vont naturellement grossir, jusqu'à atteindre un stade où la taille devient critique et l'exécution des tâches s'en trouve ralentie. On peut alors opter pour la technique du "Grow and Split". Concrètement, grossir jusqu'à identifier une ligne de fracture et splitter l'équipe à ce moment-là.
La difficulté consiste à identifier ces lignes de fracture. Pour faciliter cela, Hervé nous conseille de penser le code dans cette optique en respectant des frontières bien définies dans le code lui-même.
Il suggère également d'informer au plus tôt l'équipe de ce fonctionnement, en anticipant les frictions lors du split. Les équipes sachant d'emblée qu'un split aura lieu dans le futur, cela ne sera pas une surprise, mais fera partie de l'organisation.
Capital social
Le dernier point sur lequel a insisté Hervé était l'aspect social d'une organisation.
Mettre en place une organisation ouverte et participative est un premier pas, faire circuler les idées et concepts émergeant de ce travail est encore mieux. Pour cela il faut inciter au partage et éviter le plus possible l'isolement (des équipes, des personnes...).
Le capital social répond à cette problématique. Une entreprise, finalement, est aussi un réseau social. Favoriser les moments d'échange et de partage de connaissance est de ce fait primordial. Parmi les exemples donnés par Hervé, je retiens le fait de permettre à un membre d'une équipe d'intégrer une autre équipe sur le temps d'un sprint. Cela donne l'occasion de voir une autre manière de travailler, de découvrir et d'échanger avec d'autres personnes de l'organisation, de faire des échanges d'expérience et de partager des connaissances.
Ce que je retiens
En premier lieu, je me suis senti un peu comme un poisson hors de son bocal (un dev parmi les PO, rendez-vous compte), mais très rapidement, le fait d'avoir un regard différent sur mon métier m'a paru très enrichissant et rafraîchissant.
Prendre conscience de la manière dont sont perçues mes estimations, mes dailies, mes retours en général permet de mieux adapter mon discours, et de mieux comprendre les remarques et les retours des PO et plus largement des autres acteurs du projet.
En conclusion, même si vous êtes un tech pur et dur, que seules les conf techniques vous intéressent, ne passez pas à côté de l'occasion de vous rendre au "School of PO" au moins une fois dans votre vie, pour vous ouvrir l'esprit et découvrir votre métier "de l'autre côté du miroir".
